2. LVM, file systems, y determinación de problemas de disco............................................16 2.1 Estructuras de datos en el LVM .................................................. ................................................................................. ............................... 16 2.1.1 Volúmenes físicos ................................. ................ ................................... ................................... ................................... ................................... ..................... .... 16 2.1.2 Grupos de volúmenes .................................. ................. ................................... ................................... ................................... ................................. ............... 16 2.1.3 Volúmenes lógicos ................................... .................. ................................... ................................... ................................... ................................... ................... 17 2.1.4 Object Data Manager (ODM)...................... (ODM)..... ................................... ................................... ................................... ................................. ............... 17
2.2 Determinación de problemas del LVM ................................................ ...................................................................... ...................... 17 2.2.1 Redistribución de datos .................................. ................. ................................... ................................... ................................... .............................. ............ 17 2.2.2 Backup de la información............................ información........... ................................... ................................... ................................... ................................. ............... 18 2.2.3 Re-sincronización de la ODM ................................. ............... .................................... ................................... ................................... ..................... ... 18 2.2.4 Entendiendo los problemas del importvg ................................. ................ .................................. .................................. ...................... ..... 19 2.2.4.1 2.2.4.1 Nivel de versión versión de AIX.................... AIX.................................. ............................ ............................ ............................ ............................ ............................ ................ 19 2.2.4.2 PVID inválido inválido ............................ .......................................... ............................ ............................ ............................ ............................ ............................ ...................... ........ 19 2.2.4.3 Modificación de algún disco mientras mientras el grupo de volúmenes estaba exportado.............. exportado... ................ ..... 20 2.2.4.4 2.2.4.4 Entorno Entorno de discos discos comparti compartidos dos ............................ .......................................... ............................ ............................ ............................ ........................ .......... 20
2.2.5 Extendiendo Extendiendo la cantidad cantidad máxima de de particiones particiones físicas .................................. ................. ................................. ................ 20
2.3 Reemplazo de discos ................................................ .................................................................................................. .................................................. 21 2.3.1 2.3.1 Reemplazando un disco................. disco .................................. ................................... ................................... ................................... .............................. ............ 21
2.3.1.1 2.3.1.1 Eliminand Eliminandoo un disco defectuoso. defectuoso............... ............................ ............................ ............................ ............................ ............................ ...................... ........ 23 2.3.1.2 2.3.1.2 Agregando Agregando un disco nuevo.............................. nuevo............................................ ............................ ............................ ............................ ............................ ................ 23
2.3.2 Recuperando Recuperando un disco removido incorrectamente................................ incorrectamente............... .................................. ........................... .......... 25
2.4 EL JFS en AIX ................................................ ....................................................................................................... ........................................................... .... 26 2.4.1 Creando un JFS................................... JFS.................. ................................... ................................... ................................... ................................... ........................ ....... 26 2.4.2 Aumentando Aumentando el tamaño tamaño del file system...................................... system.................... ................................... ................................... ..................... ... 27 2.4.3 Verificación y recuperación de file systems.................. systems ................................... .................................. ................................. ................ 27 2.4.3.1 Reparando un superbloque dañado...................... dañado............ ..................... ..................... ..................... ..................... ..................... ..................... .............. .... 28
2.5 Espacio de paginado...................................................................................................30 2.5.1 Recomendaciones para crear o extender los espacios de paginado............... paginado ................................ ................... 31 2.5.2 Cómo determinar si hace falta más espacio de de paginado paginado ................................ ............... ................................. ................ 31 2.5.3 Cómo disminuir el espacio de paginado paginado por defecto (hd6)............... (hd6) ................................ .............................. ............. 32
3. Dumps del sistema............................................................................................................35 3.1 Configuración de los dispositivos de dump................................................................35 3.1.1 Estimar Estimar el tamaño de un un pposible osible dump............................. dump........... ................................... ................................... .............................. ............ 35 3.1.2 Seleccionando el dispositivo de dump................................. dump............... ................................... ................................... ........................... ......... 35 Página 2 de 283
3.1.3 Creando un dispositivo de dump ................................... ................. ................................... ................................... ................................. ............... 36 3.1.4 Cambiando Cambiando el tamaño del del dispositivo dispositivo de dump dump ................................. ............... ................................... .............................. ............. 37 3.1.5 Configuración adicional ................................. ................ ................................... ................................... ................................... .............................. ............ 38
3.2 Revisando el estado del dump ..................................................... .................................................................................... ............................... 39 3.2.1 Información del último dump................. dump .................................. ................................... ................................... ................................... ..................... ... 39 3.2.2 Códigos de estado de un dump.................. dump ................................... ................................... ................................... ................................... .................. 39 3.2.3 Log de errores.................... errores.. ................................... ................................... ................................... ................................... ................................... ........................ ....... 40
3.4 Introducción al análisis del dump...............................................................................44 3.4.1 Usos del comando crash ................................. ................ ................................... ................................... ................................... .............................. ............ 44 3.4.2 ¿Qué es el kernel?............................ kernel?........... ................................... .................................... ................................... ................................... ........................... ......... 45 3.4.3 Examinando un dump del sistema............... sistema ................................. ................................... ................................... ................................. ............... 45 3.4.4 3.4.4 Subcomandos básicos del crash......................... crash........ ................................... ................................... ................................... ........................... ......... 45
3.4.4.1 3.4.4.1 El subcomand subcomandoo stat ........................... ......................................... ............................ ............................ ............................ ............................ ............................ ................ 47 3.4.4.2 3.4.4.2 El subcomand subcomandoo trace –m .......................... ........................................ ............................ ............................ ............................ ............................ ...................... ........ 47 3.4.4.3 3.4.4.3 El subcomando subcomando proc................................. proc............................................... ............................ ............................ ............................ ............................ ...................... ........ 50 3.4.4.4 3.4.4.4 El subcomand subcomandoo thread thread ............................ .......................................... ............................ ............................ ............................ ............................ ........................ .......... 51 3.4.4.5 3.4.4.5 El subcomando subcomando od ............................ .......................................... ............................ ............................ ............................ ............................ ............................ ................ 52 3.4.4.6 3.4.4.6 Revisando Revisando el log de errores errores ........................... ......................................... ............................ ............................ ............................ ............................ ................. ... 52 3.4.4.7 3.4.4.7 El subcomando subcomando le ............................ .......................................... ............................ ............................ ............................ ............................ ............................ ................. ... 53 3.4.4.8 3.4.4.8 El log de errores errores del VMM ........................... ......................................... ............................ ............................ ............................ ............................ ................. ... 53
3.4.5 Manejando la salida del crash......................... crash........ ................................... ................................... ................................... .............................. ............ 54 3.4.6 Tipo de caídas.................... caídas.. ................................... ................................... ................................... ................................... ................................... ........................ ....... 55 3.4.6.1 3.4.6.1 Kernel panic o trap................................... trap................................................. ............................ ............................ ............................ ............................ ...................... ........ 55 3.4.6.2 3.4.6.2 Addressing Addressing exception exception o data storage interrupt interrupt ............................ .......................................... ............................ ............................ ................ 55 3.4.6.3 3.4.6.3 Bloqueo Bloqueo del sistema sistema (System (System hang) ............................ .......................................... ............................ ............................ ............................ ................. ... 55
3.4.7 Información Información requerida requerida por el centro de soporte.......... soporte........................... .................................. .................................. ..................... 55
4. Optimización del rendimiento ................................................. .......................................................................................... ......................................... 68 4.1 Introducción al monitoreo y optimización del rendimiento en AIX .......................... 68 4.1.1 Rendimiento de CPU.................. CPU ................................... ................................... ................................... ................................... ................................. ............... 69
4.1.1.1 4.1.1.1 Procesos Procesos y threads threads............. ........................... ............................ ............................ ............................ ............................ ............................ ............................ ................. ... 69 4.1.1.2 4.1.1.2 Time slice............................... slice............................................. ............................ ............................ ........................... ........................... ............................ ........................... ............. 69 4.1.1.3 Modo kernel kernel y modo usuario...... usuario.................... ............................ ............................ ............................ ............................ ............................ ...................... ........ 69 4.1.1.4 4.1.1.4 Rendimient Rendimientoo en SMP ........................... ......................................... ............................ ........................... ........................... ............................ ........................... ............. 70 a. Coherencia de cache (Cache coherency) ...................................................... ................................................................................... .............................................. ................. 70 b. Afinidad de procesador (Processor affinity)......................................................................... affinity)............................................................................................... ...................... 70 c. Locking ............................................................ .......................................................................................... ............................................................ ........................................................... ............................... 71
4.1.2.1 4.1.2.1 Advertenci Advertenciaa inicial inicial ............................ .......................................... ............................ ............................ ............................ ............................ ............................ ................ 72 4.1.2.2 4.1.2.2 Segmentos Segmentos de memoria memoria ............................ .......................................... ............................ ............................ ............................ ............................ ...................... ........ 72 a. La lista libre (Free list)........................... list) ......................................................... ............................................................ ............................................................ ........................................ .......... 73 b. Reemplazo de páginas (Page replacement) replacement) ....................................................... .................................................................................... ......................................... ............ 73 c. Mecanismo de control de la carga de memoria ...................................................... ................................................................................... .................................... ....... 74
4.1.2.3 4.1.2.3 Espacio Espacio de paginado............ paginado.......................... ............................ ............................ ............................ ............................ ............................ ............................ ................ 74 Página 3 de 283
a. Ajustando el umbral del espacio de paginado paginado ........................................................ ..................................................................................... .................................... ....... 75
4.1.3 Rendimiento de I/O de disco ................................... ................. .................................... ................................... ................................... ..................... ... 76
4.1.3.1 4.1.3.1 Advertenci Advertenciaa inicial inicial ............................ .......................................... ............................ ............................ ............................ ............................ ............................ ................ 77 4.1.3.2 4.1.3.2 El diseño diseño del subsistema subsistema de disco .......................... ........................................ ............................ ............................ ............................ ...................... ........ 77 4.1.3.3 Consideraciones Consideraciones de rendimiento rendimiento relativas al ancho de banda ..................... ........... ..................... ..................... ................ ...... 78 4.1.3.4 4.1.3.4 Diseño del disco..................................... disco................................................... ............................ ............................ ............................ ............................ ........................ .......... 78 a. Tiempo de acceso del disco............................................ disco......................................................................... .......................................................... ............................................... .................. 79 b. Discos por bus o loop (lazo) del adaptador ....................................................... .................................................................................... ......................................... ............ 80 c. Buffers físicos de disco ......................................................... ...................................................................................... ........................................................... ........................................ .......... 80
4.1.4.1 4.1.4.1 Protocolo Protocoloss TCP/IP.................... TCP/IP.................................. ............................ ............................ ............................ ............................ ............................ ........................ .......... 83 4.1.4.2 Modificación Modificación de los parámetros parámetros de red ........................... ......................................... ............................ ............................ ........................... ............. 83 4.1.4.3 Optimización de los buffers de red.................... red.......... ..................... ...................... ..................... ..................... ..................... ..................... ................ ..... 84
4.2 Herramientas de rendimiento de CPU y memoria......................................................85 4.2.1 El comando sar ................................... .................. ................................... ................................... ................................... ................................... ........................ ....... 85
4.2.1.1 4.2.1.1 Ejemplos Ejemplos del uso del comando comando sar ............................ ......................................... ........................... ............................ ............................ .................... ...... 85 4.2.1.2 4.2.1.2 Sumario Sumario del comando comando sar.............. sar ............................ ............................ ........................... ........................... ............................ ............................ .................... ...... 89 4.2.1.3 4.2.1.3 El comando comando sadc ........................... ......................................... ............................ ............................ ............................ ............................ ............................ ................... ..... 89 4.2.1.4 4.2.1.4 Los comandos comandos sa1 y sa2....................................... sa2..................................................... ............................ ............................ ............................ ........................ .......... 90
4.2.2 El comando vmstat ................................... .................. ................................... ................................... ................................... ................................... ................... 90 4.2.3 El comando comando ps .................. ........................... ................... ................... .................. .................. .................. .................. .................. .................. ................... ............. ... 95 4.2.3.1 Uso del comando comando ps para estudiar estudiar la utilización de CPU................ CPU...... .................... ..................... ..................... .................. ........ 95 a. La columna C ........................................................ ...................................................................................... ............................................................ ....................................................... ......................... 95 b. La columna TIME............................. TIME ........................................................... ............................................................ ............................................................ ............................................. ............... 96 c. La columna %CPU.............................................................................. %CPU............................................................................................................ ....................................................... ......................... 96 U
4.2.3.2 Uso del comando comando ps para estudiar la utilización de memoria .................... ......... ..................... .................... .................. ........ 97 a. La columna SIZE ....................................................... ..................................................................................... ............................................................ .................................................. .................... 97 b. La columna RSS ........................................................ ...................................................................................... ............................................................ .................................................. .................... 97 c. La columna %MEM ........................................................ ...................................................................................... ............................................................ ............................................. ............... 98
4.2.4 El comando tprof ................................... .................. ................................... ................................... ................................... ................................... ..................... .... 99 4.2.4.1 4.2.4.1 Usando Usando el reporte reporte general general del tprof tprof ........................... ......................................... ............................ ............................ ............................ ................... ..... 99 4.2.4.2 Utilizando Utilizando el tprof en un programa programa ........................... ......................................... ............................ ............................ ............................ ................. ... 100
4.3 Herramientas de rendimiento de I/O de disco ............................................... .......................................................... ........... 118 4.3.1 Revisión general ................................. ................ ................................... ................................... ................................... .................................... ...................... .... 118 4.3.2 4.3.2 El comando iostat .................................. ................. ................................... ................................... ................................... ................................... ..................... 119
4.3.2.1 4.3.2.1 El histórico histórico de I/O de disco.................................. disco................................................ ............................ ............................ ............................ ...................... ........ 120 4.3.2.2 Reporte Reporte de util utilizaci ización ón de TTY y CPU .......................... ........................................ ............................ ............................ ........................... ............. 121 4.3.2.3 4.3.2.3 El comando comando iostat iostat en sistemas sistemas SMP................................ SMP.............................................. ............................ ............................ ......................... ........... 122 4.3.2.4 Reporte de util utilizaci ización ón de disco ............................ .......................................... ............................ ............................ ............................ ...................... ........ 123
4.3.3 Análisis de rendimiento del LVM utilizando utilizando el lslv............................. lslv............ .................................. ......................... ........ 124
a. Espejado...................................................... Espejado.................................................................................... ............................................................ ........................................................... ..................................126 .....126 b. Política intra..................................................... intra................................................................................... ............................................................ ........................................................... .............................126 126 c. Política inter .......................................................... ........................................................................................ ............................................................ ......................................................127 ........................127 d. Striping ............................................................ .......................................................................................... ............................................................ ........................................................... .............................127 127
4.3.3.2 4.3.3.2 Fragmentaci Fragmentación ón de volúmenes volúmenes lógicos lógicos ........................... ......................................... ............................ ............................ ........................... ............. 128 4.3.3.3 4.3.3.3 Asignación Asignación de volúmenes volúmenes lógi lógicos cos .......................... ........................................ ............................ ............................ ............................ .................... ...... 128 4.3.3.4 4.3.3.4 El mejor mejor rendimien rendimiento to del LVM........................................ LVM...................................................... ............................ ............................ ........................ .......... 130
4.3.4 Monitoreo del LVM y file systems..................................... systems.................... .................................. .................................. .......................... ......... 130 4.3.4.1 4.3.4.1 El comando comando filemon filemon .......................... ........................................ ............................ ............................ ............................ ............................ ........................... ............. 130 a. Usando el comando filemon...................................... filemon................................................................... .......................................................... ...................................................131 ......................131
4.3.4.2 4.3.4.2 Análisis Análisis del reporte reporte ........................... ......................................... ............................ ............................ ............................ ............................ ........................... ............. 132 a. Reporte a nivel archivo lógico............................................................................... lógico............................................................................................................ ....................................132 .......132 b. Reporte a nivel n ivel volumen lógico ......................................................... ...................................................................................... .......................................................134 ..........................134 c. Reporte a nivel volumen físico............................. físico .......................................................... .......................................................... ........................................................135 ...........................135 d. Reporte a nivel memoria virtual..................................... virtual.................................................................. .......................................................... ..............................................136 .................136
4.3.4.3 Comportamiento típico del sistema AIX........... AIX. ..................... ..................... ..................... ..................... ..................... ..................... .............. .... 137
4.3.5 Rendimiento de los file systems ................................ ............... .................................. .................................. ................................... .................. 137
4.3.5.1 4.3.5.1 El comando comando fileplace.............. fileplace............................ ............................ ............................ ............................ ............................ ............................ ........................ .......... 138 4.3.5.2 4.3.5.2 Desfragment Desfragmentación ación de un file system ........................... ......................................... ............................ ............................ ............................ ................ 139
4.3.6 Recomendaciones Recomendaciones generales de rendimiento rendimiento de I/O I/O ................................... ................. ................................... ..................... 140 4.3.7 Consumo de las herramientas de rendimiento................. rendimiento ................................... ................................... ............................ ........... 141 4.3.8 Sumario de comandos.................................... comandos................... .................................. ................................... ................................... ............................. ............ 142
4.4 Herramientas de rendimiento de red.........................................................................142 4.4.1 Visión general............................ general........... ................................... .................................... ................................... ................................... ............................... ............. 143 4.4.2 Optimización de las colas colas de transmisión y recepción de de los adaptadores.................... adaptadores............... ..... 144 4.4.3 Optimización de protocolos.............................. protocolos............. .................................. ................................... ................................... .......................... ......... 145 4.4.4 Herramientas de monitoreo del rendimiento de red ................................... ................. ................................... ..................... 147
4.5 Herramientas Herramientas específicas para el manejo de rendimiento ........................................ 159 4.5.1 4.5.1 El scheduler scheduler de AIX ................... ............................ .................. .................. .................. .................. .................. .................. .................. ................... ............ 159 4.5.1.1 Cálculo de prioridad prioridad en versiones de AIX anteriores a la 4.3.2 ..................... .......... ..................... ..................... ............. 160 4.5.1.2 Cálculo Cálculo de prioridad en AIX Versión 4.3.2 y posteriores ..................... .......... ..................... ..................... ..................... .......... 162
4.5.2 Colas de de ejecución múltiples múltiples con balanceo de carga en AIX Versión 4.3.3 ................. ................ . 163
4.5.2.1 4.5.2.1 Balanceo Balanceo de carga inicial..... inicial................... ............................ ............................ ............................ ............................ ............................ ........................... ............. 164 Página 5 de 283
4.5.3 Manejo del rendimiento del scheduler................................... scheduler.................. .................................. .................................. ....................... ...... 165 4.5.3.1 4.5.3.1 El comando comando schedtune......... schedtune....................... ............................ ............................ ............................ ............................ ............................ ........................... ............. 165 a. Primer ejemplo de schedtune.......................................... schedtune....................................................................... .......................................................... ..............................................165 .................165 b. Segundo ejemplo de schedtune .......................................................... ....................................................................................... .......................................................166 ..........................166 c. Tercer ejemplo de schedtune.................................................... schedtune................................................................................. .......................................................... ....................................166 .......166 d. Lineamientos generales de SCHED_R y SCHED_D ....................................................... ................................................................................166 .........................166 e. Sumario del comando schedtune........................... schedtune ........................................................ .......................................................... .......................................................167 ..........................167
4.5.3.2 4.5.3.2 Los comandos comandos nice y renice renice ............................ .......................................... ............................ ............................ ............................ ........................... ............. 167 a. Ejecutando un comando con nice ....................................................... .................................................................................... .......................................................167 ..........................167 b. Cambiando el valor nice de un thread en ejecución ......................................................... ..................................................................................168 .........................168 c. Sumario de los comando nice y renice ......................................................... ...................................................................................... .............................................169 ................169
4.6 Escenarios de rendimiento........................................................................................174 4.6.1.1 Colección Colección de datos ............................ .......................................... ............................ ............................ ............................ ............................ ........................... ............. 174 4.6.1.2 4.6.1.2 Análisis Análisis de datos ........................... ......................................... ............................ ............................ ............................ ............................ ............................ ................. ... 175 4.6.1.3 4.6.1.3 Recomendaci Recomendación ón............ .......................... ............................ ............................ ............................ ............................ ............................ ............................ .................... ...... 176
4.6.2 Escenario de rendimiento de I/O .................................. ................. .................................. .................................. ................................ ............... 176
4.6.2.1 Colección Colección de datos ............................ .......................................... ............................ ............................ ............................ ............................ ........................... ............. 176 4.6.2.2 4.6.2.2 Análisis Análisis de datos ........................... ......................................... ............................ ............................ ............................ ............................ ............................ ................. ... 178 a. Análisis de la salida del comando vmstat .......................................................... ....................................................................................... ........................................178 ...........178 b. Análisis de la salida del comando iostat.......................................................................... iostat....................................................................................................178 ..........................178
4.6.3.1 4.6.3.1 I/O wait de CPU y threads threads del kernel........................ kernel..................................... ........................... ............................ ............................ .................. .... 179 4.6.3.2 4.6.3.2 Distribuci Distribución ón de I/O.......................... I/O........................................ ............................ ............................ ............................ ............................ ............................ ................ 180 4.6.3.3 4.6.3.3 Fragmentac Fragmentación ión de un volumen volumen lógico lógico ........................... ......................................... ............................ ............................ ........................... ............. 181 4.6.3.4 Monitoreando el escenario utilizando filemon......... filemon .................... ...................... ..................... ..................... ..................... ................. ....... 182 4.6.3.5 4.6.3.5 Asignación Asignación de volumen volumen lógico lógico ........................... ......................................... ........................... ........................... ............................ ......................... ........... 182
4.6.4 Escenario de rendimiento del paginado........................ paginado....... ................................... ................................... ............................... .............. 184
4.6.4.1 Colección Colección de datos ............................ .......................................... ............................ ............................ ............................ ............................ ........................... ............. 184 4.6.4.2 4.6.4.2 Análisis Análisis de los datos.......................... datos........................................ ............................ ............................ ............................ ............................ ........................... ............. 190 a. La columna kthr (kernel thread) ......................................................... ...................................................................................... .......................................................190 ..........................190 b. La columna de memoria.......................................................... memoria....................................................................................... .......................................................... .....................................190 ........190 c. La columna page ........................................................ ...................................................................................... ............................................................ .................................................191 ...................191 d. La columna faults............................................................ faults.......................................................................................... ............................................................ ............................................191 ..............191 e. La columna cpu............................ cpu .......................................................... ............................................................ ............................................................ .................................................191 ...................191
5.1 Identificar un problema genérico de red...................................................................193 5.2 Pasos para aislar un problema de red TCP/IP...........................................................193 5.2.1 Problemas de red en un host determinado ................................... .................. .................................. .................................. ................. 193 5.2.2 No hay acceso a la red ................................ ............... .................................. ................................... ................................... ................................ ............... 193 5.2.3 Problemas de resolución de nombres ................................. ................ .................................. .................................. .......................... ......... 194 5.2.4 Análisis de un problema de ruteo ................................. ................ .................................. .................................. ................................ ............... 194 5.2.5 Ruteo estático o dinámico ................................ ............... .................................. ................................... ................................... .......................... ......... 195 5.2.6 Problemas con las interfases de red ................................. ................ .................................. .................................. ............................. ............ 197
5.6 Resolución de problemas de NIS (Network Information Services) ......................... 213 5.6.1 Herramientas para la resolución de de problemas de NIS................................. NIS................ .................................. ................. 213
5.6.2 5.6.2 Ejemplos Ejemplos de resolución resolución de problemas problemas con NIS NIS ................................. ............... ................................... ............................ ........... 216
5.6.2.1 yppush falla falla al crear crear mapas nuevos.................................... nuevos.................................................. ............................ ............................ ...................... ........ 217 5.6.2.2 5.6.2.2 Los broadcast broadcast de clientes clientes no vinculan.................... vinculan.................................. ............................ ............................ ............................ .................... ...... 217 5.6.2.3 5.6.2.3 El comando comando ypwhich ypwhich es inconsist inconsistente............. ente........................... ............................ ............................ ............................ ........................... ............. 217 5.6.2.4 Mapas muy largos no son soportados....................... soportados............. ..................... ...................... ..................... ..................... ..................... ................. ....... 218 5.6.2.5 Routers, dispositivos de red, y vinculación NIS.................. NIS....... ...................... ..................... ..................... ..................... ................. ....... 218 5.6.2.6 Grupos incorrectos por cambios en un grupo nuevo ..................... ........... ..................... ..................... ..................... .................. ....... 218 5.6.2.7 mkdbm falla para para entradas entradas de mapas NIS muy grandes................. grandes...... ..................... ..................... ...................... ................. ...... 218
5.7 Resolución de problemas de NFS.............................................................................219 5.7.1 Pasos Pasos generales generales para solucionar solucionar un problema de NFS NFS ................................. ................ .................................. ................. 219 5.7.2 Problemas de montaje en NFS................................ NFS............... .................................. .................................. ................................... ..................... ... 219 5.7.2.1 Montajes soft y montajes hard........................ hard............. ..................... ..................... ..................... ..................... ..................... ..................... .................. ....... 221
5.7.3 Problemas de rendimiento de NFS .................................. ................. .................................. .................................. ............................. ............ 221 5.7.3.1 Empeorando el rendimiento del cliente para redes o servidores lentos............. lentos.. ...................... ................... ........ 225
5.7.4 Fallas de locking............................ locking.......... ................................... ................................... ................................... ................................... ............................ .......... 226 5.7.4.1 Iniciando el rpc.lockd con depuración.......................... depuración............... ..................... ..................... ..................... ..................... ..................... .............. .... 226
5.7.5 Un cliente cliente NFS se detiene durante durante el reinicio del sistema........................................ sistema....................... ...................... ..... 227
5.8 Depuración de SLIP (Serial Line Internet Protocol) ................................................ 227 5.9 Depuración de PPP (Point-to-Point Protocol) asincrónico.......................................228 5.9.1 AIX como cliente PPP (llamadas salientes) ................................... .................. .................................. ............................... .............. 228
6. Resolución de problemas de impresión..........................................................................233 6.1 Pasos a seguir para resolver problemas comunes.....................................................234 Página 7 de 283
6.1.1 Pasos a seguir en problemas problemas de impresión local......... local.......................... .................................. .................................. ................. 234 6.1.2 Pasos Pasos a seguir en problemas problemas de impresión remota .................................. ................. .................................. ...................... ..... 234 6.1.3 Revise lo obvio.................. obvio ................................... ................................... ................................... ................................... ................................... ...................... ..... 235 6.1.4 Nada se imprime en impresoras locales ................................... .................. .................................. .................................. .................... ... 235
6.1.4.1 Mi Mi trabajo se perdió, pero otros son impresos..................... impresos.......... ..................... ..................... ..................... ..................... .................. ....... 235 6.1.4.2 Nada se imprime, pero las luces en la impresora parpadean o cambian................... cambian........ ...................... ............. 236 6.1.4.3 6.1.4.3 Nada llega llega a la impresora.................. impresora................................ ............................ ............................ ............................ ............................ ........................... ............. 237 6.1.4.4 ¿Hay espacio suficiente en el file system del spool?.... spool?.............. ..................... ..................... ..................... ..................... .............. .... 240
6.1.5 La salida es basura o está incompleta................ incompleta ................................. .................................. .................................. .......................... ......... 241
6.1.5.1 6.1.5.1 ¿Los parámetros parámetros del puerto puerto son correctos? correctos? .......................... ........................................ ............................ ............................ .................... ...... 241 6.1.5.2 ¿Los tabuladores están configurados correctamente? ..................... ........... ..................... ..................... ..................... ................ ..... 241 6.1.5.3 ¿Se imprime únicamente la primera primera línea o líneas escalonadas? .................... .......... ..................... ..................... .......... 241 6.1.5.4 ¿La impresora funciona bien por por un tiempo y luego luego mal? mal? ...................... ........... ..................... ..................... ................... ........ 242 6.1.5.5 ¿Hay problemas imprimiendo gráficos?....................... gráficos?............ ...................... ..................... ..................... ..................... ..................... .............. ... 243 6.1.5.6 ¿El tipo de impresora es el correcto?....................... correcto?............ ..................... ..................... ..................... ..................... ..................... ................... ......... 243
6.1.7 La La impresión impresión con una fuente incorrecta....................................... incorrecta...................... .................................. .................................. ................. 244 6.1.7.1 ¿El archivo es PostScript o PCL formateado?..................... formateado?.......... ..................... ..................... ..................... ..................... .................. ....... 244 6.1.7.2 ¿Cuál ¿Cuál es la fuente por defecto de la impresora?........... impresora? ...................... ..................... ..................... ..................... ..................... .............. ... 244 6.1.7.3 ¿Qué fuentes están instaladas en la impresora?...................... impresora?............ ..................... ..................... ..................... ..................... .............. .... 245 6.1.7.4 ¿El programa interfase interfase o el backend de impresión impresión fijan la fuente? fuente? ..................... .......... ..................... ................. ....... 245
6.1.8 El trabajo de impresión pide pide un tamaño de papel equivocado equivocado ................................. ................ ...................... ..... 246 6.1.9 El trabajo de impresión por red falla .................................. ................. .................................. .................................. .......................... ......... 246 6.1.9.1 Los trabajos de impresión impresión quedan quedan encolados en la cola local local ...................... ........... ..................... ..................... .............. ... 246 6.1.9.2 ¿Está configurado configurado el tiempo tiempo de espera espera para la la impresión remota con System V? ............... .......... ..... 248 6.1.9.3 Los trabajos de impresión impresión quedan en en la cola remota............... remota..... ..................... ..................... ..................... ..................... ............. ... 248 6.1.9.4 6.1.9.4 Los trabajos trabajos de impresión impresión desaparec desaparecen en ............................ .......................................... ............................ ............................ ........................ .......... 248
6.2 Técnicas de resolución de problemas comunes........................................................249 6.2.1 Utilizando Utilizando lptest para generar archivos de impresión......................................... impresión........................ ............................ ........... 249 6.2.2 Use enscript para generar PostScript................. PostScript .................................. .................................. .................................. .......................... ......... 250 6.2.3 Use splp para ver los dispositivos especiales ................................. ................ .................................. ............................... .............. 250 6.2.4 Imprimiendo a un archivo....................................... archivo...................... .................................. .................................. .................................. ..................... .... 250 6.2.5 Imprimiendo directamente al archivo archivo del dispositivo dispositivo especial.............................. especial............. ......................... ........ 250 6.2.6 Imprimiendo Imprimiendo directamente en impresoras de red............................................. red............................ ............................... .............. 251 6.2.6.1 Imprimiendo Imprimiendo directamente en una impresora conectada a LPD............. LPD... ..................... ...................... ................... ........ 251 6.2.6.2 Imprimiendo Imprimiendo directamente directamente en una impresora impresora conectada conectada a HP JetDirect........... JetDirect ...................... ................... ........ 251 6.2.6.3 Telnet Telnet a impresora impresorass JetDirect................... JetDirect................................. ............................ ............................ ............................ ............................ .................... ...... 251
6.2.7 Utilizando Utilizando iptrace para rastrear una impresión de red................. red ................................... .................................. ................ 252 6.2.8 Capturando archivos.................. archivos. ................................... .................................... ................................... ................................... ............................... ............. 252
6.2.8.1 Capturando Capturando el archivo antes de que pase por por la cola........... cola ..................... ..................... ..................... ..................... .................. ....... 252 6.2.8.2 Capturando Capturando un archivo después de que pasó por la cola ..................... .......... ...................... ..................... ..................... ............. 253 6.2.8.3 6.2.8.3 Capturando Capturando un archivo archivo tal como va por la red ............................ .......................................... ............................ ........................... ............. 253 6.2.8.4 6.2.8.4 Capturando Capturando un archivo archivo en el sistema sistema remoto ............................ .......................................... ............................ ............................ ................ 253
6.2.9 Capturar el flag ................................... .................. ................................... ................................... ................................... ................................... ...................... ..... 254 6.2.9.1 6.2.9.1 Flags de System System V.................................. V................................................ ............................ ............................ ............................ ............................ ...................... ........ 254 6.2.9.2 6.2.9.2 Flags de PowerPC PowerPC ........................... ......................................... ............................ ............................ ............................ ............................ ............................ ................ 254
6.2.10 Utilizando Utilizando script script para capturar las entradas del usuario ................................ ............... ............................... .............. 256 6.2.11 Utilizando fuser para encontrar procesos .................................. ................. .................................. .................................. ................. 256 6.2.12 Utilizando Utilizando el comando echo en scripts shell......................................... shell........................ .................................. ....................... ...... 256
6.3 Resolución de problemas en el subsistema de impresión System V........................256 Página 8 de 283
6.3.1 Problemas de permisos en archivos........................ archivos....... ................................... ................................... .................................. .................... ... 257 6.3.2 ¿El servicio de impresión está activo?............................. activo?............ .................................. ................................... ............................. ........... 257 6.3.3 ¿La impresora tiene los atributos correctos? .................................. ................. .................................. ............................... .............. 257 6.3.3.1 6.3.3.1 Dispositi Dispositivo vo de impresión..... impresión................... ............................ ............................ ............................ ............................ ............................ ........................... ............. 257 6.3.3.2 Atributos de la impresora definidos en System V .................... .......... ..................... ..................... ..................... ..................... .............. 257
6.3.4 Logs y archivos de estado.............................. estado............. .................................. ................................... ................................... ............................. ............ 258
6.3.4.1 6.3.4.1 Revise Revise el correo...................... correo.................................... ............................ ............................ ............................ ............................ ............................ ........................ .......... 258 6.3.4.2 6.3.4.2 Revise Revise los logs en /var/lp/l /var/lp/logs.............. ogs............................ ............................ ............................ ............................ ............................ ........................ .......... 258 6.3.4.3 6.3.4.3 Verifican Verificando do el archivo archivo pstatus....................... pstatus..................................... ............................ ............................ ............................ ............................ ................ 259
6.3.5 ¿La variable LANG LANG está está configurada configurada correctamente?............ correctamente?............................. .................................. ...................... ..... 259 6.3.6 Trabajos remotos cancelados quedan encolados .................................. ................. .................................. ......................... ........ 260 6.3.7 Imprimiendo en un archivo..................................... archivo.................... .................................. .................................. ................................... ..................... ... 260 6.3.8 Limpiando y comenzando de nuevo.................. nuevo. .................................. .................................. .................................. .......................... ......... 261
6.3.8.1 Reiniciar Reiniciar los números de trabajo trabajo del subsistema de impresión impresión ..................... ........... ..................... ...................... ............. 261 6.3.8.3 Limpiando impresoras viejas.......................... viejas............... ..................... ..................... ..................... ..................... ..................... ..................... .................. ....... 261 6.3.8.4 Elimine los archivos temporales............................ temporales................. ..................... ..................... ...................... ..................... ..................... ..................... .......... 261 6.3.8.5 6.3.8.5 Elimine Elimine archivos archivos de log viejos viejos ........................... ......................................... ........................... ........................... ............................ ......................... ........... 262
6.3.9 Desactivando los banners ................................. ................ .................................. .................................. ................................... ........................... ......... 262 6.3.9.1 6.3.9.1 Configurac Configuración ión de los banners........................ banners...................................... ............................ ............................ ............................ ............................ ................ 262 6.3.9.2 6.3.9.2 Evitando Evitando los banners banners por línea de comando comando.............. ........................... ........................... ............................ ............................ .................. .... 262 6.3.9.3 6.3.9.3 Evitando Evitando los banners banners con el archivo archivo interfase......................... interfase....................................... ............................ ............................ ................. ... 262
6.3.10 Resolviendo Resolviendo problemas de scripts scripts interfase interfase en System V ................................ ............... ............................ ........... 263 6.3.11 Revise los tiempos de espera espera en el archivo Systems Systems para las colas colas remotas ............... 264 6.3.12 ¿Está bien ingresado el nombre nombre del servidor en el archivo /etc/lp/Systems? /etc/lp/Systems? .............. 264 6.3.13 Ejemplos: solucionando problemas de impresión remota ................................ ............... ............................ ........... 265 6.3.13.1 Ejemplo: Ejemplo: desaparecen desaparecen trabajos trabajos de impresión de red salientes........... salientes ..................... ..................... ...................... ............. 265 6.3.13.2 Ejemplo: Ejemplo: se pierde un trabajo de impresión impresión remoto remoto entrante entrante ..................... .......... ..................... ..................... .............. ... 266
6.3.14 Resolviendo Resolviendo problemas problemas de impresión de HP JetDirect.................................. JetDirect................. ............................... .............. 267 6.3.14.1 Permisos Permisos de archivo erróneos en el script interfase..................... interfase........... ..................... ..................... ..................... .................. ....... 267 6.3.14.2 6.3.14.2 Revise Revise los archivos archivos de log /tm /tmp/hpn p/hpnpf.* pf.* ............................ .......................................... ............................ ............................ .................... ...... 268 6.3.14.3 6.3.14.3 Salida Salida escalonad escalonadaa en impresora impresorass PCL................................... PCL................................................. ............................ ............................ ................. ... 268
6.4 Resolución de problemas en el subsistema de impresión PowerPC.........................269 6.4.1 Problemas de permisos de archivos........................ archivos....... ................................... ................................... .................................. .................... ... 269 6.4.2 ¿El servicio de impresión está activo?............................. activo?............ .................................. ................................... ............................. ........... 269
6.4.2.1 Iniciando Iniciando los servicios servicios de impresió impresiónn ........................... ......................................... ............................ ............................ ............................ ................ 269 6.4.2.2 El qdaemon qdaemon no permanece permanece activo................ activo.............................. ........................... ........................... ............................ ............................ .................. .... 269
6.4.4 Logs y archivos de estado.............................. estado............. .................................. ................................... ................................... ............................. ............ 270
6.4.4.1 6.4.4.1 Mensajes Mensajes de error por línea de comando..................... comando................................... ............................ ............................ ............................ ................ 271 6.4.4.2 6.4.4.2 Mensajes Mensajes por correo correo .......................... ........................................ ............................ ............................ ............................ ............................ ........................... ............. 271 6.4.4.3 6.4.4.3 Mensajes Mensajes en la consola.................... consola.................................. ............................ ............................ ............................ ............................ ............................ ................ 271 6.4.4.4 Archivos Archivos de mensajes de error error de las impresoras virtuales.......... virtuales .................... ..................... ...................... ................... ........ 271 6.4.4.5 6.4.4.5 Logs de impresion impresiones es remotas remotas .......................... ........................................ ............................ ............................ ............................ ........................... ............. 271 6.4.4.6 6.4.4.6 Archivos Archivos de descripció descripciónn del trabajo trabajo ............................ .......................................... ............................ ............................ ............................ ................ 272 6.4.4.7 6.4.4.7 Archivos Archivos de estado estado ............................ .......................................... ............................ ............................ ............................ ............................ ........................... ............. 273
6.4.5 Imprimiendo Imprimiendo en un archivo archivo con el subsistema subsistema PowerPC ................................ ............... ............................... .............. 273 6.4.6 Limpiando y comenzando de nuevo.................. nuevo. .................................. .................................. .................................. .......................... ......... 274 6.4.6.1 6.4.6.1 Primero Primero se debe encontrar encontrar la causa ........................... ......................................... ............................ ............................ ............................ ................. ... 274 6.4.6.2 Último recurso: limpiar el sistema de impresión................... impresión........ ..................... ..................... ..................... ..................... ................ ..... 275
6.4.7 Revisando los flags para enq .................................. ................. .................................. .................................. ................................... ..................... ... 275 Página 9 de 283
6.4.8.1 6.4.8.1 Configurac Configuración ión de los banners........................ banners...................................... ............................ ............................ ............................ ............................ ................ 276 6.4.8.2 6.4.8.2 Evitando Evitando los banners banners por línea de comando comando.............. ........................... ........................... ............................ ............................ .................. .... 276 6.4.8.3 6.4.8.3 Evitando Evitando los banners banners con la impresora impresora virtual virtual ............................ .......................................... ............................ ........................... ............. 277
6.5 Errores comunes y soluciones ..................................................... .................................................................................. ............................. 277 6.5.1 Problemas agregando agregando una segunda impresora impresora local en el mismo dispositivo dispositivo ............... 277 6.5.2 No se pueden cambiar los atributos atributos porque el dispositivo está ocupado....................... ocupado............. .......... 278 6.5.3 Los trabajos trabajos remotos desaparecen después de activar la cola de impresión........ impresión.................. .......... 278 6.5.4 Bad mandatory environment variable.................................... variable................... .................................. .................................. ....................... ...... 278 6.5.5 LOG: is read only .................................. ................. ................................... ................................... ................................... ................................... ..................... 279 6.5.6 No hay suministro suministro de papel luego de la página página de encabezamiento........ encabezamiento......................... ...................... ..... 279
Lista de abreviaturas...........................................................................................................281 Bibliografía.........................................................................................................................283
Página 10 de 283
1. Introducción a la resolución de problemas La intención de este curso es ayudar a los administradores de sistemas y personal de soporte a tener un mejor entendimiento sobre la resolución de problemas en sistemas RS/6000 utilizando AIX. La intención no es proveer una lista exhaustiva de todas las soluciones para todos los posibles problemas que pueden encontrarse. La intención es guiar a través del proceso de determinación de problemas y reducir e identificar los componentes o subsistemas que estén sufriendo algún problema. El alcance de este curso ayudará a determinar la causa de un problema en un componente o subsistema que previamente funcionaba correctamente. La intención no es ayudar a diagnosticar problemas cuando se está instalando o configurando hardware o software nuevos. Con este fin se debe consultar la documentación apropiada provista con los nuevos componentes.
1.1 Proceso de determinación de problemas Siguiendo la intención de este curso, podemos definir a un problema como una situación donde algo que previamente funcionaba bien, ahora no lo hace como se espera.
1.1.1 Definiendo el problema El primer paso en la resolución de un problema es definir el problema. Es importante que la persona que intenta solucionar el problema entienda exactamente lo que el usuario del sistema percibe como problema. Una definición clara del problema es útil en dos aspectos. Primero, puede entregar indicios sobre la causa del problema. Segundo, es mucho más fácil demostrarle a los usuarios que el problema fue solucionado si se entiende como se ve el problema desde su punto de vista. Tomemos, por ejemplo, la situación donde un usuario no puede imprimir un documento. El problema puede deberse a que el file system /var no tenga espacio. La persona que soluciona el problema puede corregirlo y demostrar que el problema fue corregido utilizando el comando df para probar que el file system /var ahora cuenta con espacio. Este ejemplo también puede ser utilizado para ilustrar otra dificultad en la determinación de un problema. Los problemas pueden estar ocultos por otros problemas. Cuando se corrige el problema más visible, otro puede aparecer. Los problemas que son descubiertos durante el proceso de determinación de problemas deben ser relacionados con el que fue reportado inicialmente, en otras palabras, múltiples problemas con los mismos síntomas. En algunos casos, se pueden descubrir problemas que están completamente inconexos con el problema inicial reportado. En el ejemplo descrito anteriormente, incrementar la cantidad de espacio libre en el file system /var quizás no solucione el problema que experimenta el usuario. El problema de impresión puede ser debido a un cable defectuoso, a un problema con la impresora, o quizás a una falla del daemon lpd. Por eso es tan importante entender el problema desde la perspectiva del usuario. En este ejemplo, la mejor forma de verificar que el problema fue resuelto es lograr que el usuario imprima su documento.
1.1.2 Recolectando información del usuario La mejor manera de entender el problema desde la perspectiva del usuario es realizándole preguntas. Desde su percepción de la situación, se puede deducir si en efecto tiene un problema, y
Página 11 de 283
en cuanto tiempo espera que sea resuelto. Sus expectativas pueden estar más allá del alcance de la máquina o de la aplicación que está ejecutando. Las siguientes preguntas deben ser formuladas cuando se recolecta información del usuario: • ¿Cuál es el problema? Se debe obtener una explicación del usuario sobre cuál es el problema y como lo afecta. Dependiendo de la situación y la naturaleza del problema, esta pregunta debe ser suplementada por una de las siguientes preguntas: • ¿Qué es lo que hace el sistema? • ¿Que es lo que no hace el sistema? Una vez que se determinan cuáles son los síntomas del problema, se debe intentar establecer la historia del problema • ¿Cómo detectó por primera vez el problema? ¿Hizo algo diferente que causó que advirtiera el problema? • ¿Cuando ocurrió? ¿Esto ocurre siempre en el mismo momento, por ejemplo, cuando se ejecuta el mismo trabajo o la misma aplicación? • ¿Ocurre el mismo problema en otro sitio? ¿Sólo una máquina experimenta el problema, o varias máquinas experimentan el mismo problema? • ¿Fueron realizados algunos cambios recientemente? Esto se refiere a cualquier tipo de cambio realizado en el sistema, desde agregar hardware o software nuevo, hasta cambios en la configuración del software existente. • Si fue realizado un cambio recientemente, ¿Se reunieron todos los prerrequisitos antes de que el cambio fuera realizado? Los problemas de software ocurren generalmente cuando se realizaron cambios en el sistema y, o no se reunieron todos los prerrequisitos, por ejemplo, el firmware del sistema no estaba en el nivel mínimo requerido, o las instrucciones no fueron seguidas en el orden exacto, por ejemplo, la persona que realizó el cambio desestimó las instrucciones alegando que conocía un camino más rápido para hacer lo mismo. El desestimar las instrucciones significa que, como la persona percibió una ruta mejor, los prerrequisitos para los siguientes pasos no fueron reunidos, y por lo tanto, el problema derivó en la situación a la que estamos confrontados. Otros cambios, como agregar hardware, traen sus propios problemas, como cables mal conectados, contactos doblados, o direccionamiento desconfigurado. La pregunta ¿Cómo detectó por primera vez el problema? puede que no ayude en forma directa, pero es muy útil para que la persona hable sobre el problema. Una vez que comienza a hablar, invariablemente dirá cosas que ayudarán a construir un cuadro que ayude a decidir el punto de comienzo en la resolución del problema. Si el problema ocurre en más de una máquina, se deben buscar las similitudes y diferencias entre las situaciones.
1.1.3 Recolectando información del sistema El segundo paso en la determinación del problema es recolectar información del sistema. Parte de la información puede haber sido obtenida del usuario, en el proceso de definir el problema. No es sólo el usuario de la máquina quien puede proveer información. Utilizando varios comandos, es posible determinar como está configurada la máquina, los errores producidos, y el estado del sistema operativo.
Página 12 de 283
El uso de comandos, como el lsdev, lspv, lsvg, lslpp, lsattr y otros, permite recolectar información sobre cómo está configurado el sistema. Otros comandos, como el errpt, entregan indicios sobre todos los errores registrados por el sistema. Si el administrador del sistema para realizar tareas administrativas utiliza SMIT o un Sistema de Administración Basado en Web, se deben examinar los archivos log de esas aplicaciones para observar las modificaciones recientes. Los archivos log son guardados normalmente en el directorio raíz del usuario y tienen el nombre /smit.log para SMIT y /websm.log para el Sistema de Administración Admi nistración Basado en Web. Si se busca algo específico basado en el problema descrito por el usuario, a menudo otros archivos son analizados o extraídos para que el centro de soporte lo analice, como dumps del sistema o archivos checkstop.
1.1.4 Resolviendo el problema Una vez que se define el problema, se deben utilizar todos los medios al alcance para encontrar la solución de la forma más rápida y efectiva. Es recomendable consultar los redbooks de IBM, que muchas veces contienen soluciones para problemas conocidos, la documentación de AIX e Internet, donde hay muchos sitios de información sumamente útiles. Durante el proceso de investigación, se debe mantener un historial de las acciones realizadas para determinar el problema y de las acciones realizadas para solucionar el problema. En algunos casos, se encontrarán problemas que no pueden ser resueltos utilizando las técnicas básicas para la resolución de problemas o las técnicas detalladas descriptas en redbooks o la documentación del AIX o el hardware. En estos casos, se debe reportar el problema al centro de soporte. La información recolectada como parte del proceso de determinación del problema también debe ser suministrada al centro de soporte. En algunos casos, no es posible reproducir el problema, por ejemplo, si el problema aparece en forma aleatoria y aparentemente no hay una secuencia de acciones que provoca el problema.
1.1.5 Obteniendo parches de software Los parches de AIX y muchos LPPs están disponibles en Internet en la siguiente URL: http://service.software.ibm.com/support/rs6000/
Para facilitar la descarga de los parches de AIX, en lugar de un navegador Web se puede utilizar una aplicación AIX llamada FixDist. Como una aplicación alternativa a la Web, FixDist provee descargas diferentes y entrega todas las imágenes necesarias con sólo un click. Además, lleva un registro de los parches descargados, de manera que se pueden descargar paquetes de parches más pequeños las veces que sea necesario. FixDist puede ser descargado del sitio Web mencionado anteriormente. Una vez que es determinada la naturaleza del problema, se debe intentar buscar en este sitio o utilizando FixDist, para comprobar si el problema experimentado es conocido y tiene un parche ya disponible.
1.1.6 Otra documentación relevante Cada máquina RS/6000 tiene un conjunto de documentaciones específicas que debe ser utilizado en el proceso de determinación de problemas cuando se sospecha un problema de hardware. Además, cada máquina RS/6000 tiene su propio manual de instalación del sistema (System Installation) y Guía de servicio, (Service Guide), los que son complementados con algunos documentos adicionales, dependiendo si la máquina es un sistema Micro Channel Bus o PCI, también conocido como sistema Multiple Bus. Cada tipo de bus (Micro Channel y Multiple Bus)
Página 13 de 283
tiene un conjunto de dos manuales, uno con procedimientos comunes de diagnóstico, y el otro que describe los adaptadores, dispositivos, y cables que pueden ser usados es los sistemas de ese tipo. Los sistemas Multiple Bus también tienen una guía que detalla las reglas para ubicar los adaptadores PCI. La mayoría de las documentaciones de hardware puede consultarse online en el sitio de Internet de la Biblioteca IBM RS/6000. La dirección del sitio es: http://www.rs6000.ibm.com/library/
Si se precisa, se puede solicitar una copia impresa de los manuales al representante de marketing de IBM.
1.2 Evitar los problemas La confiabilidad, la disponibilidad, y la operabilidad (Reliability, Availability, Serviceability o RAS) son características del AIX que fueron diseñadas para cumplir varias funciones. Además de ayudar a determinar la causa de un problema una vez que ocurre, como el subsistema de diagnóstico, muchas de las características RAS están diseñadas para proveer información sobre problemas potenciales antes de que sucedan. Por defecto, los sistemas RS/6000 son configurados para ejecutar diagnósticos automáticos periódicos. Cualquier error o advertencia que reporte el sistema, aparecerá en el log de errores del sistema. Una buena administración del sistema no consiste únicamente en solucionar los problemas cuando ocurren, implica además administrar el sistema de manera tal que se minimicen las probabilidades de que un problema afecte a los usuarios. El mantenimiento periódico del sistema puede ayudar a reducir la cantidad de problemas experimentados en la máquina. Examinar el log de errores del sistema en forma regular puede ayudar a detectar un problema potencial cuando los mensajes en el log de errores son aún advertencias y no errores concretos.
1.2.1 Verificaciones preventivas Esta es una lista de comandos simples que deben ejecutarse en forma periódica para monitorear un sistema. Ayudarán a mostrar cómo está funcionando el sistema. • Utilice el comando errpt para observar un sumario de los errores en el log. Se debe prestar atención a los últimos errores registrados. Utilice errpt -a para examinar cualquier error sospechoso. • Verifique la disponibilidad de espacio de disco con el comando df -k. Un file system lleno puede provocar varios problemas, por lo que es preferible evitarlo en la medida de lo posible. Las dos soluciones para un file system sin espacio son: o eliminar algunos archivos para ganar espacio libre, o utilizar el LVM para aumentar el tamaño del file system. La opción escogida depende de la naturaleza de los datos en el file system, y de la disponibilidad de espacio en el grupo de volúmenes. • Busque particiones stale en los grupos de volúmenes con el comando lsvg. Si existen particiones stale, se debe intentar repararlas con el comando syncvg. • Verifique el espacio de paginado con el comando lsps -s. Un sistema no se comporta bien si tiene poco espacio de paginado disponible. En circunstancias extremas, el sistema puede finalizar procesos para solucionar la situación. Obviamente, es mejor que el administrador del sistema se asegure que hay espacio de paginado suficiente. Se puede incrementar el tamaño de los volúmenes de espacio de paginado existentes, o añadir un
Página 14 de 283
nuevo volumen de espacio de paginado. Nuevamente, la opción a tomar dependerá del espacio disponible en los grupos de volúmenes del sistema. • Verifique que todos los subsistemas estén funcionando correctamente con el comando lssrc –a. • Verifique el funcionamiento de la red haciendo un ping direcciones conocidas.
Página 15 de 283
2. LVM, file systems, y determinación de problemas de disco Los siguientes temas serán tratados en este capítulo: • Problemas del Logical Volume Manager (LVM). • Reemplazo de volúmenes físicos. • Problemas de los JFS y sus soluciones. • Crear y eliminar el espacio de paginado, y recomendaciones sobre estos. Para entender los problemas que ocurren en el sistema AIX con los grupos de volúmenes, volúmenes lógicos, y file systems, es importante tener un conocimiento detallado sobre como es controlado el almacenamiento por el LVM. No veremos fundamentos del LVM; se considera que son un prerrequisito para entender la temática a tratar.
2.1 Estructuras de datos en el LVM La información que requiere el LVM para operar es almacenada en un número de estructuras. El esquema lógico de estas estructuras esta descrito en las siguientes secciones.
2.1.1 Volúmenes físicos A cada disco le es asignado un Physical Volume Identifier (PVID) cuando es agregado a un grupo de volúmenes. El PVID es una combinación del número de serie de la máquina y la fecha y hora de la operación. El PVID es guardado en el mismo disco y en la Object Data Manager (ODM) de la máquina cuando un grupo de volúmenes es creado o importado. No se debe usar el comando dd para copiar los contenidos de un volumen físico a otro, porque el PVID también sería copiado; esto resultaría en dos discos con el mismo PVID lo que puede confundir al sistema.
2.1.2 Grupos de volúmenes Cada grupo de volúmenes tiene una Volume Group Descriptor Area (VGDA). Hay (normalmente) múltiples copias de la VGDA en un grupo de volúmenes. Una copia de la VGDA es almacenada en cada disco del grupo de volúmenes. La VGDA almacena información sobre el grupo de volúmenes, como los volúmenes lógicos y los discos en el grupo de volúmenes. La VGDA es analizada por el comando importvg cuando importa un grupo de volúmenes al sistema. También la utiliza el comando varyonvg en el proceso de quórum para decidir si un grupo de volúmenes debe ser activado (vary on). Para un grupo de volúmenes de un solo disco, hay dos VGDAs en el disco. Cuando un segundo disco es añadido para hacer un grupo de volúmenes de dos discos, el disco original retiene dos VGDAs y el nuevo disco toma una VGDA. Agregando un tercer disco resulta que la VGDA extra del primer disco es movida a este tercer disco para un quórum de tres con cada disco teniendo un voto. Agregando este disco adicional añade una nueva VGDA por disco. Un grupo de volúmenes con chequeo de quórum activado (por defecto) debe tener al menos un 51 por ciento de las VGDAs en el grupo de volúmenes disponible antes de que éste pueda ser activado. Una vez activado, si el grupo de VGDAs cae por debajo del 51 por ciento, el grupo de
Página 16 de 283
volúmenes es desactivado automáticamente. Por el contrario, un grupo de volúmenes con el chequeo de quórum desactivado debe tener un 100 por ciento de las VGDAs disponibles antes de que pueda ser activado. Una vez activado, sólo es necesaria una VGDA disponible para mantener el grupo de volúmenes activado. Un grupo de volúmenes también tiene un Volume Group Identifier (VGID), un número de serie “soft” para el grupo de volúmenes, similar al PVID para discos. Cada disco en un grupo de volúmenes también tiene una Volume Group Status Area (VGSA), una estructura de 127 bytes usada para rastrear la información de espejado de hasta 1016 particiones físicas en el disco.
2.1.3 Volúmenes lógicos Cada volumen lógico tiene un Logical Volume Control Block (LVCB) que es almacenado en los primeros 512 bytes del volumen lógico. EL LVCB mantiene detalles importantes del volumen lógico, entre otros su fecha y hora de creación, información de espejado y el punto de montaje (si contiene un Journaled File System [JFS]). Cada volumen lógico tiene un Logical Volume Identifier (LVID) que es usado para representar el volumen lógico en las librerías de LVM y los comandos de bajo nivel. El LVID se genera de VGID., donde es el orden en que fue creado dentro del grupo de volúmenes.
2.1.4 Object Data Manager (ODM) La Object Data Manager (ODM) es usada por el LVM para almacenar información relativa a grupos de volúmenes, volúmenes físicos, y volúmenes lógicos del sistema. La información contenida en la ODM es grabada cuando el grupo de volúmenes es importado o cuando cada objeto el grupo de volúmenes es creado. Existe un objeto de la ODM conocido como el vg-lock. Siempre que un comando que modifica la LVM es ejecutado, cerrará el vg-lock del grupo de volúmenes que se está modificando. Si por alguna razón, el vg-lock no se abre cuando el comando termina, se puede correr el comando varyonvg –b, que sólo puede ejecutarse en un grupo de volúmenes previamente activado.
2.2 Determinación de problemas del LVM Los problemas del LVM más comunes están relacionados con fallas de discos. Dependiendo de la gravedad de la falla, es posible salvar la situación con muy poca pérdida de datos o ninguna. Sin embargo, un intento de recuperación fallido puede empeorar el estado del sistema. En este caso, restaurar desde un backup es la única alternativa. Por lo tanto, es sumamente recomendable tomar backups frecuentes del sistema.
2.2.1 Redistribución de datos Cuando ocurre un problema con un disco, puede haber redistribución de datos. La redistribución de datos puede ser de tres tipos diferentes: • Interna del disco • Redistribución por hardware, ordenada por el LVM • Redistribución por software
Página 17 de 283
Típicamente, la redistribución ocurre cuando al intentar realizar una lectura o escritura el sistema falla, debido a problemas con el disco. En algunos casos, el requerimiento de I/O es completado pero con advertencias (warnings). Dependiendo del tipo de error obtenido, el LVM puede estar advertido para el siguiente requerimiento en la misma ubicación física y ordenar una redistribución para estar seguro. La capa lógica mas baja de la redistribución es aquella que es interna del disco. Este tipo de redistribuciones son típicamente privadas del disco y no hay notificaciones al usuario sobre las redistribuciones realizadas. El siguiente nivel en términos de complejidad de la redistribución es una redistribución por hardware ordenada por el controlador de dispositivos del LVM (device driver). Este tipo de redistribución le indicará al disco que reacomode la información de una partición física a otra porción (reservada) del disco. El disco toma los datos en la ubicación física A y los copia a una porción reservada del disco (ubicación B). Sin embargo, una vez que completó la operación, el controlador de dispositivos del LVM continuará direccionando a la ubicación física A, asumiendo que el disco por sí solo va a dirigir la verdadera operación de I/O a la ubicación real B. La capa mas alta de la redistribución de datos es la redistribución por soft manejada por el controlador de dispositivos del LVM. En este caso, mantiene un directorio de bloques defectuosos, y siempre que recibe un requerimiento para acceder a la ubicación lógica A, el controlador de dispositivos del LVM buscará la tabla de bloques defectuosos y traducirá ésta para enviar el requerimiento a la ubicación física B.
2.2.2 Backup de la información El primer paso que se debe realizar si se sospecha un problema con el LVM es tomar un backup del grupo de volúmenes afectado y salvar tanta información como sea posible. Esto será requerido para la recuperación de datos. La integridad del backup debe ser comparada a la del último backup regular tomado antes de detectar el problema.
2.2.3 Re-sincronización de la ODM Los problemas con el LVM tienden a ocurrir cuando un problema con un disco físico provoca que los datos de la ODM no estén sincronizados con la información de VGDA, VGSA, y LVCB almacenada en el disco. La corrupción de la ODM también puede ocurrir si una operación de LVM termina anormalmente y deja la ODM en estado inconsistente. Esto puede ocurrir, por ejemplo, si el file system en el que se encuentra la ODM (normalmente root, /) se llena durante el proceso de importar un grupo de volúmenes. Si sospecha que las entradas en la ODM para un grupo de volúmenes están corruptas, una forma simple de re-sincronizar las entradas es desactivar y exportar el grupo de volúmenes del sistema, luego importarlo y activarlo para refrescar la ODM. Este proceso puede ser realizado en todos los grupos de volúmenes excepto el rootvg. Para el rootvg, se puede usar el comando redefinevg que examina cada disco en el sistema para determinar a que grupo de volúmenes corresponden, y luego actualiza la ODM. Por ejemplo: # redefinevg rootvg
Si sospecha que la información del LVM almacenada en el disco está corrupta, utilice el comando synclvodm para sincronizar y reconstruir el LVCB, la base de datos que contiene la configuración del dispositivo, y las VGDAs en los volúmenes físicos. Por ejemplo: # synclvodm -v myvg
Si tiene un grupo de volúmenes en el que uno o más volúmenes lógicos está espejado, use el
Página 18 de 283
comando syncvg si sospecha que una o mas copias del espejado están dañadas (stale). El comando puede ser usado para re-sincronizar un volumen lógico individual, un disco físico, o un grupo de volúmenes entero. Por ejemplo: # syncvg -l lv02
Sincroniza copias de espejado del volumen lógico lv02. # syncvg -v vg00
Sincroniza todos los volúmenes lógicos en el grupo de volúmenes vg00.
2.2.4 Entendiendo los problemas del importvg Si importar un grupo de volúmenes en un sistema no es posible utilizando el comando importvg las siguientes áreas son típicamente problemáticas: • Nivel de versión de AIX • PVID inválido • El disco cambió mientras el grupo de volúmenes estaba exportado • Entorno de discos compartidos En general, si el comando importvg no concluye satisfactoriamente, busque en el log de errores información que apunte a éste problema.
2.2.4.1 Nivel de versión de AIX Verifique que el grupo de volúmenes que está importando está soportado por el nivel de AIX que corre en el sistema. Nuevas características fueron añadidas al sistema LVM en versiones diferentes de AIX, como por ejemplo, el soporte para grupos de volúmenes grandes. Muchas de estas características requieren un cambio en el formato de las VGDA almacenadas en el disco, y esto provoca no ser entendidas en versiones anteriores de AIX.
2.2.4.2 PVID inválido Verifique que todos los discos en el grupo de volúmenes que está intentando importar estén marcados como disponibles para AIX y tengan PVIDs válidos almacenados en la ODM. Esto puede ser verificado utilizando el comando lspv. Si alguno de estos discos no muestran un PVID, use el comando chdev para resolver el problema. Por ejemplo: # lspv hdisk0 000bc6fdc3dc07a7 hdisk1 000bc6fdbff75ee2 hdisk2 000bc6fdbff92812 hdisk3 000bc6fdbff972f4 hdisk4 None # chdev -l hdisk4 -a pv=yes hdisk4 changed # lspv hdisk0 000bc6fdc3dc07a7 hdisk1 000bc6fdbff75ee2 hdisk2 000bc6fdbff92812 hdisk3 000bc6fdbff972f4 hdisk4 000bc6fd672864b9
rootvg testvg testvg None None
rootvg testvg testvg None None
Página 19 de 283
En este ejemplo, el PVID para el hdisk4 no es mostrado utilizando el comando lspv. Esto se resuelve corriendo el comando chdev. El PVID es leído del disco y puesto en la ODM, si el disco es accesible. Esto sólo escribirá un nuevo PVID si verdaderamente no hay PVID en el disco. Alternativamente, el disco puede ser borrado utilizando el comando rmdev y, ejecutando el comando cfgmgr, el dispositivo es re-creado con el PVID correcto. Después de realizar estos pasos, debería ser posible importar el grupo de volúmenes con el comando importvg.
2.2.4.3 Modificación de algún disco mientras el grupo de volúmenes estaba exportado Si el comando importvg falla con un mensaje de error similar al siguiente mensaje, el volumen físico es marcado perdido (missing) y es posible que alguna modificación en los discos definidos para el grupo de volúmenes haya sido realizada mientras el grupo de volúmenes estaba exportado: 0516-056 varyon testvg: The volume group is not varied on because a physical volume is marked missing. Run diagnostics.
Revise el log de errores con el comando errpt para ver que ocurrió con dicho disco. Para forzar la activación del grupo de volúmenes use el flag -f del comando importvg. Esto hace posible operar con el grupo de volúmenes y, dependiendo de la situación, reconfigurar el grupo de volúmenes excluyendo el disco que es marcado como perdido utilizando el comando reducevg.
2.2.4.4 Entorno de discos compartidos En un entorno de discos compartidos, como un sistema de discos SSA, usado por dos o más sistemas, es posible que los volúmenes físicos definidos no sean accesibles porque están importados y activados por otra máquina. Revise el grupo de volúmenes en ambas máquinas y compare los PVIDs utilizando el comando lspv.
2.2.5 Extendiendo la cantidad máxima de particiones físicas Cuando se agrega un nuevo disco a un grupo de volúmenes, puede presentarse un error debido a que hay muy pocos PP descriptors para el número requerido de volúmenes físicos. Esto puede ocurrir cuando el nuevo disco tiene más capacidad que los discos existentes en el grupo de volúmenes. Esta es una situación muy común en instalaciones antiguas, debido al rápido crecimiento de la tecnología de almacenamiento. Para solucionar esto, un cambio en la meta-data del grupo de volúmenes es requerido. El comando chvg es utilizado para esta operación mediante el flag -t y aplicando un valor de factor, como se muestra en el siguiente ejemplo: # lsvg testvg VOLUME GROUP: testvg VG IDENTIFIER: 000bc6fd5a177ed0 VG STATE: active PP SIZE: 16 megabyte(s) VG PERMISSION: read/write TOTAL PPs: 542 (8672 megabytes) MAX LVs: 256 FREE PPs: 42 (672 megabytes) LVs: 1 USED PPs: 500 (8000 megabytes) OPEN LVs: 0 QUORUM: 2 TOTAL PVs: 1 VG DESCRIPTORS: 2 STALE PVs: 0 STALE PPs: 0 ACTIVE PVs: 1 AUTO ON: yes MAX PPs per PV: 1016 MAX PVs: 32 # chvg -t 2 testvg 0516-1193 chvg: WARNING, once this operation is completed, volume group testvg cannot be imported into AIX 430 or lower versions. Continue (y/n) ? y
Página 20 de 283
0516-1164 chvg: Volume group testvg changed. With given characteristics testvg can include up to 16 physical volumes with 2032 physical partitions each.
Este ejemplo muestra que el grupo de volúmenes testvg con un disco de 9.1 GB tiene un número máximo de 1016 PPs (particiones físicas) por volumen físico. Agregar un disco de 18.2 GB no es posible; el tamaño máximo del disco es limitado a 17 GB a menos que el número máximo de PPs sea incrementado. Utilizando el comando chvg para incrementar el número máximo de PPs por un factor de 2 a 2032 PPs, permite al grupo de volúmenes ser extendido hasta 34 GB aproximadamente. Hay que tener en cuenta que el grupo de volúmenes modificado no podrá ser importado por un sistema corriendo AIX versión 4.3.0 o menor.
2.3 Reemplazo de discos AIX, como todos los sistemas operativos, puede ser problemático cuando hay que cambiar un disco. AIX provee la capacidad de preparar al sistema para el cambio utilizando el LVM. Puede entonces realizar el reemplazo del disco y luego utilizar el LVM para restaurar el sistema nuevamente como estaba antes de cambiar el disco. Este proceso manipula no sólo la información de disco, sino que también es un método para mantener la ODM intacta. La ODM del AIX es una base de datos que mantiene los detalles de configuración de dispositivos y de la configuración de AIX. La función de la ODM es almacenar la información entre los reinicios del sistema, y también provee un rápido acceso a la información del sistema, eliminando la necesidad de comandos AIX para consultar a los componentes sobre la información de configuración. Como esta base de datos contiene mucha información vital referida a la configuración de la máquina, cualquier cambio hecho en la máquina, como el reemplazo de un disco defectuoso, es necesario que sea hecho en una forma que preserve la integridad de la base de datos.
2.3.1 Reemplazando un disco El siguiente escenario muestra un sistema que tiene un error de hardware en un volumen físico. Sin embargo, como el sistema utiliza un ambiente espejado, que tiene múltiples copias del volumen lógico, es posible reemplazar el disco mientras el sistema está activo. Los discos utilizados en este escenario son hot-swap (intercambio en caliente) SCSI, que permiten el reemplazo del disco en un ambiente productivo. Un factor importante es detectar el error del disco. Normalmente, un mail es enviado al administrador del sistema (usuario root) desde el Automatic Error Log Analysis (diagela). El siguiente cuadro muestra la información de dicho mail:
Página 21 de 283
Automatic Error Log Analysis (diagela) provee la capacidad de realizar análisis del log de errores cuando un error permanente de hardware es detectado. Siempre que un error permanente de hardware es detectado, el programa diagela es invocado. Automatic Error Log Analysis es activado por defecto en todas las plataformas. El mensaje del diagela muestra que el hdisk4 tiene un problema. Otra forma de localizar el problema es chequear el estado del volumen lógico utilizando el comando lsvg, como en el siguiente ejemplo: # lsvg -l mirrorvg mirrorvg: LV NAME lvdb01 lvdb02 loglv00
TYPE jfs jfs jfslog
LPs 500 500 1
PPs 1000 1000 1
PVs 2 2 1
LV STATE open/syncd open/stale open/syncd
MOUNT POINT /u/db01 /u/db02 N/A
El volumen lógico lvdb02 en el grupo de volúmenes mirrorvg es marcado con estado “stale”, indicando que las copias en este volumen lógico no están sincronizadas. Busque en el log de errores utilizando el comando errpt, como en el siguiente ejemplo: # errpt EAA3D429 F7DDA124 41BF2110 35BFC499
Esta información de errores muestra la razón por la que el volumen lógico lvdb02 es marcado “stale”. El hdisk4 tiene un error “DISK OPERATION ERROR” y el LVDD no puede escribir el cache de espejado. Según la información en el ejemplo, el hdisk4 necesita ser reemplazado. Antes de realizar cualquier acción en el disco físico del volumen lógico espejado, es recomendable realizar un backup del file system en caso de que algo funcione mal. Como el otro disco del volumen lógico espejado es aún funcional, toda la información debería estar presente. Si el volumen lógico contiene una base de datos, entonces se deben utilizar las respectivas herramientas de backup de la base de datos.
Página 22 de 283
2.3.1.1 Eliminando un disco defectuoso Si el sistema es de alta disponibilidad (7x24), usted debe decidir si mantiene el sistema funcionando mientras realiza el reemplazo del disco, siempre y cuando el hardware soporte un intercambio de discos con el sistema activo (discos hot-swap). No obstante, el procedimiento debe ser aprobado por el administrador del sistema o cliente antes de continuar. Se deben seguir los siguientes pasos para remover un disco: 1. Para remover la copia de la partición física del volumen lógico del disco defectuoso, use el comando rmlvcopy como sigue: # rmlvcopy lvdb02 1 hdisk4
El volumen lógico lvdb02 queda ahora con sólo una copia: # lslv -l lvdb02 lvdb02:/u/db02 PV hdisk3
COPIES 500:000:000
IN BAND 21%
DISTRIBUTION 109:108:108:108:067
2. Elimine del grupo de volúmenes el disco que quiere reemplazar: # reducevg -f mirrorvg hdisk4 # lsvg -l mirrorvg mirrorvg: LV NAME TYPE lvdb01 jfs lvdb02 jfs loglv00 jfslog
LPs 500 500 1
PPs 1000 500 1
PVs 2 1 1
LV STATE open/syncd open/syncd open/syncd
MOUNT POINT /u/db01 /u/db02 N/A
3. Elimine el disco como dispositivo del sistema y de la base de datos ODM con el comando rmdev: # rmdev -d -l hdisk4 hdisk4 deleted
Este comando es válido para cualquier disco SCSI. Si su sistema utiliza SSA, entonces un paso adicional es requerido. Como los discos SSA también definen el dispositivo pdisk, el correspondiente dispositivo pdisk debe ser eliminado también. Utilice los menús de SSA en el SMIT para mostrar la correspondencia entre disk y pdisk. A través de los mismos menús se puede eliminar el dispositivo pdisk. 4. El disco ya está listo para ser removido físicamente del sistema.
2.3.1.2 Agregando un disco nuevo Continuando el escenario de la sección anterior, esta sección describe como agregar un disco nuevo en un ambiente productivo. Después de que el hdisk4 fue removido, el sistema ha quedado ahora con los siguientes discos: # lsdev -Cc disk hdisk0 Available hdisk1 Available hdisk2 Available hdisk3 Available
Siga los siguientes pasos para agregar el disco nuevo: 1. Inserte el disco nuevo y ejecute el comando cfgmgr. El comando cfgmgr configura dispositivos controlados por la Configuration Rules object class,
Página 23 de 283
que es una parte de la base de datos de Configuración de Dispositivos. El comando cfgmgr va a reconocer el disco SCSI nuevo y va a crear el correspondiente dispositivo lógico. El comando no requiere opciones, como muestra lo siguiente: # cfgmgr
El resultado es un nuevo hdisk4 agregado al sistema. # lsdev -Cc disk hdisk0 Available hdisk1 Available hdisk2 Available hdisk3 Available hdisk4 Available
30-58-00-8,0 16 Bit SCSI Disk Drive 30-58-00-9,0 16 Bit SCSI Disk Drive 10-60-00-8,0 16 Bit SCSI Disk Drive 10-60-00-9,0 16 Bit SCSI Disk Drive 10-60-00-12,0 16 Bit SCSI Disk Drive
2. El nuevo hdisk debe ser asignado al grupo de volúmenes mirrorvg utilizando el comando de LVM extendvg: # extendvg mirrorvg hdisk4
3. Para reestablecer la copia del espejado de este volumen lógico utilice el comando mklvcopy. # mklvcopy lvdb02 2
hdisk4
El número de copias del volumen lógico es ahora dos, pero todavía continua marcado como “stale”, debido a que las copias del volumen lógico no están sincronizadas entre sí: # lsvg -l mirrorvg mirrorvg: LV NAME TYPE lvdb01 jfs lvdb02 jfs loglv00 jfslog
LPs 500 500 1
PPs 1000 1000 1
PVs 2 2 1
LV STATE open/syncd open/stale open/syncd
MOUNT POINT /u/db01 /u/db02 N/A
4. Para sincronizar completamente las copias del volumen lógico lvdb02, utilice el comando syncvg: # syncvg -p hdisk4
El comando syncvg puede ser usado con volúmenes lógicos, volúmenes físicos, o grupo de volúmenes. El proceso de sincronización puede consumir bastante tiempo, dependiendo de las características del hardware y del tamaño de los datos. Cuando la sincronización acaba, verificar el estado del volumen lógico por medio de los comandos lsvg o lslv: # lsvg -l mirrorvg mirrorvg: LV NAME TYPE lvdb01 jfs lvdb02 jfs loglv00 jfslog
LPs 500 500 1
PPs 1000 1000 1
PVs 2 2 1
LV STATE open/syncd open/syncd open/syncd
MOUNT POINT /u/db01 /u/db02 N/A
El sistema volvió nuevamente a la normalidad.
Página 24 de 283
2.3.2 Recuperando un disco removido incorrectamente Si un disco fue removido incorrectamente del sistema, y el sistema fue reiniciado, será necesario correr el comando synclvodm para reconstruir el LVCB. En los ejemplos, un disco fue removido incorrectamente del sistema y el LVCB necesita ser reconstruido. Estos eran los discos en el sistema antes de que el volumen físico fuese removido: # lsdev -Cc disk hdisk0 Available hdisk1 Available hdisk2 Available hdisk3 Available
Cuando se intenta montar el file system en el volumen lógico, el error puede ser similar al del siguiente ejemplo: # mount /userfs01 mount: 0506-324 Cannot mount /dev/logvol01 on /userfs01: There is an input or output error.
Para sincronizar el volumen lógico, debe ejecutarse el siguiente comando: # synclvodm -v volg01 synclvodm: Physical volume data updated. synclvodm: Logical volume logvol01 updated. synclvodm: Warning, lv control block of loglv00 has been over written. 0516-622 synclvodm: Warning, cannot write lv control block data. synclvodm: Logical volume loglv00 updated.
El sistema puede ser reparado ahora; si los datos del file system hubieran estado dispersos a través de todos los discos, incluyendo el disco dañado, debería ser restaurado desde el último backup.
Página 25 de 283
2.4 EL JFS en AIX Al igual que para el LVM, la mayoría de los problemas de JFS pueden ser atribuidos a problemas con los discos físicos subyacentes. Como con los grupos de volúmenes, varias características fueron añadidas en diferentes niveles de AIX, lo que imposibilita que esos file systems sean montados si el grupo de volúmenes fue importado en una versión anterior de AIX. Estas características incluyen entre otras, file systems con soporte de archivos largos (mayores a 2 GB), file systems con un tamaño de grupo de asignación que no es por defecto, y JFS2.
2.4.1 Creando un JFS En un Journaled File System (JFS), los archivos son almacenados en bloques de bytes contiguos. El tamaño de bloque (block size) por defecto, también denominado en AIX como tamaño de fragmentación, es de 4096 bytes (4 KB). El i-nodo del JFS contiene una estructura de información del archivo, con un arreglo de 8 punteros a los bloques de datos. Un archivo que es menor a 32 KB es direccionado directamente desde el i-nodo. Un archivo más grande utiliza un bloque de 4 KB, referido a un bloque indirecto, para el direccionamiento de hasta 1024 bloques de datos. Utilizando un bloque indirecto, es posible un tamaño de archivo de 1024x4 KB = 4 MB. Para archivos mayores a 4 MB, es utilizado un segundo bloque, el bloque indirecto doble. Este bloque indirecto doble apunta a 512 bloques indirectos, posibilitando el direccionamiento de archivos de 512 x 1024 x 4 KB = 2 GB. La siguiente figura ilustra el direccionamiento utilizando doble bloque indirecto.
AIX Versión 4.2 y posteriores soportan archivos aún más largos definiendo un nuevo tipo de JFS llamado file system con soporte para archivos largos (“bigfile” file system). En estos file systems, el bloque indirecto doble direcciona bloques de 128 KB en lugar de bloques de 4 KB. Sin embargo, el primer bloque indirecto todavía apunta a un bloque de 4 MB, entonces los bloques largos son utilizados recién cuando el tamaño del archivo es superior a 4 MB. Esto provee un nuevo tamaño máximo de archivo de (512 x 1024 x 128 KB) – 124 KB = 64 GB –124 KB = 67.108.740 KB, algo así como 63,99 GB. Cuando se crea un JFS, la estructura es definida tanto en un volumen lógico nuevo, como en un volumen lógico previamente definido. Los parámetros de un JFS definido pueden ser mostrado tanto a través de los menús de SMIT (smit jfs) como por el comando lsjfs:
El comando lsjfs muestra los atributos del JFS utilizando : (dos puntos) como separador.
2.4.2 Aumentando el tamaño del file system Muchas veces, es necesario ampliar el tamaño de un file system debido a que la demanda de almacenamiento ha aumentado. En AIX, este es un procedimiento muy común, y es posible realizar esto utilizando el comando chfs como en el siguiente ejemplo: # chfs -a size=+300000 /u/testfs Filesystem size changed to 458752
Este ejemplo muestra como el file system testfs es extendido con 30000 bloques de 512 bytes. Cuando el file system es extendido, el volumen lógico que contiene el JFS es también extendido, con el número de particiones lógicas necesarias para alcanzar el espacio necesitado. Si el sistema no cuenta con espacio libre suficiente, el grupo de volúmenes puede ser ampliado con un volumen físico adicional, o se puede reducir el tamaño especificado en el comando chfs de manera que corresponda con la cantidad de particiones lógicas libres.
2.4.3 Verificación y recuperación de file systems El comando fsck chequea y repara interactivamente file systems inconsistentes. Se debe ejecutar este comando antes de montar cualquier file system. Se debe poder leer el archivo del dispositivo en el que reside el file system (por ejemplo, el dispositivo /dev/hd0). Normalmente, el file system está consistente, y el comando fsck simplemente reporta el número de archivos, bloques usados, y bloques libres en el file system. Si el file system es inconsistente, el comando fsck muestra información sobre las inconsistencias encontradas y solicita permiso para repararlas. Si el file system no puede ser reparado, se debe restaurar desde un backup. Montar un file system inconsistente puede provocar una caída del sistema. Si no se especifica un file system, con el parámetro FileSystem, el comando fsck verificará todos los file systems con el atributo check=TRUE en /etc/filesystems.
Nota Por defecto, los file systems /, /usr, /var, y /tmp tienen el atributo check=FALSE en el archivo /etc/filesystems. El at ributo está en FALSE por las siguientes razones: 1. El proceso de boot explícitamente corre el comando fsck en los file systems /, /usr, /var, y /tmp. 2. Los file systems /, /usr, /var, y /tmp son montados cuando se corre el archivo /etc/rc. El comando fsck no modificará un file system montado y por otro lado, los resultados del fsck en un file system montado son imprevisibles.
Página 27 de 283
2.4.3.1 Reparando un superbloque dañado Si se recibe uno de los siguientes errores cuando se corre el comando fsck o el comando mount, el problema puede deberse a que el superbloque está dañado, como se muestra en el siguiente ejemplo: fsck: Not an AIX3 file system fsck: Not an AIXV3 file system fsck: Not an AIX4 file system fsck: Not an AIXV4 file system fsck: Not a recognized file system type mount: invalid argument
El problema puede ser resuelto restaurando un backup del superbloque sobre el superbloque primario utilizando el siguiente comando (se debe tomar la precaución de verificar la última documentación del producto antes de correr este comando): # dd count=1 bs=4k skip=31 seek=1 if=/dev/lv00 of=/dev/lv00
El siguiente es un ejemplo donde el superbloque está corrupto y copiando el backup se soluciona el problema: # mount /u/testfs mount: 0506-324 Cannot mount /dev/lv02 on /u/testfs: A system call received a parameter that is not valid. # fsck /dev/lv02 Not a recognized filesystem type. (TERMINATED) # dd count=1 bs=4k skip=31 seek=1 if=/dev/lv02 of=/dev/lv02 1+0 records in. 1+0 records out. # fsck /dev/lv02 ** Checking /dev/lv02 (/u/tes) ** Phase 0 - Check Log log redo processing for /dev/lv02 ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Inode Map ** Phase 6 - Check Block Map 8 files 2136 blocks 63400 free
Una vez que el proceso de restauración es completado, se verifica la integridad del file system de la siguiente manera: # fsck /dev/lv00
En muchos casos, restaurar el backup del superbloque sobre el superbloque primario repara el file system. En el caso de que no se solucione, se debe re-crear el file system y restaurar los datos desde un backup
2.4.4 Asignación de archivos sparse (esparcidos) Algunas aplicaciones, particularmente bases de datos, mantienen los datos en archivos “sparse” (esparcidos). Son llamados así aquellos archivos que no tienen bloques de disco asignados para cada bloque lógico. Si el offset del archivo es mayor a 4 MB, entonces es asignado un bloque de disco de 128 KB. Las aplicaciones que usan archivos “sparse” mayores a 4 MB requieren más bloques de disco en un file system con soporte para archivos largos que en un file system común.
Página 28 de 283
En el caso de los archivos “sparse”, la salida del comando ls no muestra el verdadero tamaño del archivo, muestra la cantidad de bytes entre el primer y último bloque asignado al archivo, como se ve en el siguiente ejemplo: # ls -l /tmp/sparsefile -rw-r--r-- 1 root system 100000000 Jul 16 20:57 /tmp/sparsefile
El comando du puede ser utilizado para ver el verdadero tamaño, ya que reporta los bloques asignados y en uso por el archivo. Utilice du -rs para reportar el número de bloques asignados en el disco. # du -rs /tmp/sparsefile 256 /tmp/sparsefile
Nota El comando tar no conserva la naturaleza “sparse” de los archivos. Cualquier archivo que originalmente era de tipo “sparse”, después de la restauración tendrá como tamaño todo el espacio asignado en el file system. Nuevas opciones del comando restore en AIX 5L son muy útiles para los archivos “sparse”. Es recomendable utilizar el comando dd en combinación con los sripts de backups existentes para solucionar el problema de los archivos “sparse”.
2.4.5 Problemas desmontando file systems Un file system no puede ser desmontado si existen referencias activas apuntando a dicho file system. El siguiente mensaje de error puede ser mostrado: Device busy
or A device is already mounted mounted or cannot be unmounted
Las siguientes situaciones pueden dejar referencias abiertas apuntando a un file system: • Archivos abiertos en el file system. Estos archivos deben cerrarse antes de que el file system pueda ser desmontado. El comando fuser a menudo la mejor forma de determinar que es lo que se encuentra aún activo en el file system. El comando fuser retornará el ID de todos los procesos que tiene referencias abiertas apuntando a un file system determinado, como se muestra en el siguiente ejemplo: # umount /home umount: 0506-349 Cannot unmount /dev/hd1: The requested resource is busy. # fuser -x -c /home /home: 11630 # ps -fp 11630 UID PID PPID C STIME TTY TIME CMD guest 11630 14992 0 16:44:51 pts/1 0:00 -sh # kill -1 11630 # umount /home
El proceso que tiene una referencia abierta puede ser matado utilizando el comando kill (envía una SIGHUP), y el unmount puede ser llevado a cabo. Una señal más fuerte puede ser necesaria, como un SIGKILL. • Si el file system está todavía busy (ocupado) y no puede ser desmontado, es posible que se deba a una extensión del kernel que ya está cargada pero existe dentro del file system original. El
Página 29 de 283
comando fuser no muestra ese tipo de referencias, dado que un proceso de usuario no se encuentra involucrado. No obstante, el comando genkex reportará todas las extensiones del kernel cargadas. • Otros file systems están montados sobre el file system a desmontar. Es necesario desmontar esos otros file systems antes de que el file system pueda ser desmontado. Si algún file system está montado sobre otro file system, esto deja referencias abiertas en el file system original, en el punto de montaje del otro file system. Utilice el comando mount para obtener una lista de todos los file systems montados. Desmonte todos los file system que estén montados sobre el file system a desmontar.
2.4.6 Eliminando file systems Cuando se debe borrar un JFS, este debe ser desmontado antes de que pueda ser eliminado. El comando para borrar file systems es rmfs. En el caso de un JFS, el comando rmfs borra el volumen lógico en el que reside el file system y la entrada asociada en el archivo /etc/filesystems. Si el file system no es un JFS, el comando borra únicamente la entrada asociada en el archivo /etc/filesystems, como se ve en el siguiente ejemplo: # lsvg -l testvg testvg: LV NAME TYPE LPs PPs PVs MOUNT POINT loglv00 jfslog 1 1 1 N/A lv02 jfs 2 2 1 /u/testfs # rmfs /u/testfs rmfs: 0506-921 /u/testfs is currently mounted. # umount /u/testfs # rmfs /u/testfs rmlv: Logical volume lv02 is removed. # lsvg -l testvg testvg: LV NAME TYPE LPs PPs PVs MOUNT POINT loglv00 jfslog 1 1 1
LV STATE open/syncd open/syncd
LV STATE closed/syncd N/A
Este ejemplo muestra como el file system testfs es eliminado. El primer intento falla debido a que el file system estaba aún montado. El volumen lógico asociado lv02 es también eliminado. El jfslog permanece definido en el grupo de volúmenes.
2.5 Espacio de paginado Para los sistemas AIX, la siguiente lista indica los posibles problemas asociados con el espacio de paginado: • Todos los espacios de paginado están definidos en un volumen físico. • Espacio de paginado casi lleno • Desequilibrio en la asignación espacio de paginado en volúmenes físicos • Fragmentación de un espacio de paginado en un grupo de volúmenes
Página 30 de 283
2.5.1 Recomendaciones para crear o extender los espacios de paginado No poner más de un espacio de paginado en un volumen físico. Todos los procesos que corren durante el proceso de inicio (boot) utilizan el espacio de paginado por defecto (hd6). Después de que los espacios de paginado adicionales son activados, el espacio de paginado es asignado de forma “round robin” en unidades de 4 KB. Si hay espacio de paginado en múltiples volúmenes físicos, y se coloca más de un espacio de paginado en un volumen físico, no se utilizará en forma óptima y pareja sobre los distintos volúmenes físicos. Se recomienda evitar la creación de espacios de paginado en volúmenes físicos con gran actividad, como aquellos que son usados por una base de datos. No es necesario colocar un espacio de paginado en cada volumen físico. Es recomendable crear los espacios de paginado más o menos del mismo tamaño. Si existen espacios de paginado de tamaños diferentes y los más pequeños se quedan sin espacio, no habrá más distribución del paginado a lo largo de todos los espacios de paginado. No se recomienda extender un espacio de paginado en múltiples volúmenes físicos. Si un espacio de paginado esta disperso en múltiples volúmenes físicos no se distribuirá la actividad de paginado sobre todos los volúmenes físicos. Para mejorar el rendimiento del sistema, es ideal crear los espacios de paginado en volúmenes físicos que se encuentren conectados a diferentes controladoras de disco.
2.5.2 Cómo determinar si hace falta más espacio de paginado Asignar más espacio de paginado que el necesario provoca simplemente un mal aprovechamiento del espacio de disco. Si se asigna menos espacio que el necesario, una serie de síntomas negativos pueden presentarse en el sistema. Para determinar cuanto paginado es necesario, es recomendable seguir los siguientes pasos: • Extienda el espacio de paginado si uno de los siguientes mensajes aparecen en la consola o en respuesta a un comando en cualquier terminal: INIT: Paging space is low ksh: cannot fork no swap space Not enough memory Fork function failed fork () system call failed Unable to fork, too many processes Fork failure - not enough memory available Fork function not allowed. Not enough memory available. Cannot fork: Not enough space
• Extienda el espacio de paginado si la columna de %Used en la salida del comando lsps -s es mayor a 80. Utilice los siguientes comandos para determinar si es necesario realizar cambios relativos al espacio de paginado: # iostat # vmstat # lsps
Si desea eliminar o reducir el tamaño de un espacio de paginado del sistema, esto debe ser realizado en dos pasos. El primer paso en cualquiera de los casos es cambiar el espacio de paginado de manera que no se active automáticamente cuando el sistema reinicia. Esto se lleva a cabo con el comando chps. Por ejemplo: # chps -a n paging00
Página 31 de 283
Para borrar el espacio de paginado, es necesario reiniciar el sistema, dado que no hay ninguna forma de desactivar un file system en forma dinámica. Una vez que el sistema reinicia, el espacio de paginado no estará activo. En este estado sí es posible eliminarlo. Para disminuir el tamaño del espacio de paginado, es necesario eliminar el volumen lógico que lo contiene, y recrear el nuevo espacio de paginado con el tamaño deseado. El nuevo espacio de paginado puede ser activado sin necesidad de reiniciar la máquina, utilizando el comando swapon.
2.5.3 Cómo disminuir el espacio de paginado por defecto (hd6) 1- Determine cuantos volúmenes lógicos de espacio de paginado existen en su sistema. Ingrese: lsps -a
Si hay mas de un espacio de paginado en rootvg, anote sus nombres (listados en la columna Page Space) y siga el paso 3. Si sólo hay un espacio de paginado en rootvg (éste se llamará hd6), continúe por el paso 2. 2- Verifique cuantas particiones físicas (PPs) libres hay disponibles. Ingrese: lsvg -p rootvg
Cree un espacio de paginado para usar temporalmente con el siguiente comando. X es un número entre 1 y el total de PPs libres del sistema. mkps -s X -a rootvg
Ejecute lsps -a nuevamente y anote el nombre del nuevo espacio de paginado (posiblemente paging00). 3- Cambie las características del nuevo espacio de paginado (hd6) de manera que no se active en el siguiente reinicio. Ingrese: chps -a n hd6
4- Modifique el siguiente archivo. vi /sbin/rc.boot Cambie la línea swapon /dev/hd6 por swapon /dev/pagingXX , donde XX es el numero de uno de los espacios de paginado encontrados en el paso 1, o el número de el nuevo espacio de paginado creado en el paso 2. 5- Determine cual disco es el disco de inicio con el comando mostrado en la columna PV1 de la salida. Ingrese:
lslv.
El disco de inicio es
lslv -m hd5
ATENCION: No proceda de aquí en más si el sistema es un cliente /usr, cliente sin discos, o cliente sin datos. 6- Ahora, ejecute el comando
bosboot,
utilizando el hdisk# determinado en el paso 5. Ingrese:
Página 32 de 283
bosboot -a -d /dev/ hdisk#
7- El sistema necesita ser reiniciado para desactivar el espacio de paginado hd6. Ingrese: shutdown -Fr
8- El dispositivo de dump por defecto es asignado al hd6. hd6 no puede ser eliminado mientras sea el dispositivo de dump. Verifique el dispositivo de dump. Ingrese: sysdumpdev -l
Si el dispositivo de dump primario o secundario es el hd6 modifíquelo de la siguiente manera: sysdumpdev -P -p /dev/sysdumpnull
9- Como algunos scripts están diseñados para activar el /dev/hd6, es recomendable crear un nuevo espacio de paginado con el mismo nombre. Elimine el hd6 y cree un nuevo hd6 de tamaño más pequeño, con los siguientes comandos ( es el número de PP a asignar al hd6): rmps hd6 mklv -y hd6 -t paging rootvg
10- Modifique el siguiente archivo: vi "/sbin/rc.boot" Cambie la línea de swapon nuevamente por swapon /dev/hd6. 11- Ejecute: lsps -a
para ver si el hd6 está configurado para ser activado al reiniciar el sistema. Esto es determinado por una “y” en la columna “auto”. Si una “n” está en la columna “auto”, ejecute: chps -a y hd6
para cambiar las características del espacio de paginado por defecto. 12- Corra el comando bosboot, utilice el hdisk# determinado en el paso 5. bosboot -a -d /dev/ hdisk#
13- Si un espacio de paginado temporal no fue creado, aquí termina el procedimiento. De lo contrario, continúe con los pasos siguientes. 14- Cambie las características del espacio de paginado temporal (que asumimos es paging00 en estos pasos), de manera que no esté activo en el siguiente reinicio del sistema. Ingrese: chps -a n paging00
15- El sistema necesita ser reiniciado para desactivar el espacio de paginado temporal. Ingrese: shutdown -Fr
Página 33 de 283
16- Elimine el espacio de paginado temporal. Ingrese: rmps paging00
17- Si el dispositivo de dump fue modificado en el paso 8, entonces restablezca la anterior configuración. Ingrese: sysdumpdev -P -p /dev/hd6
Página 34 de 283
3. Dumps del sistema 3.1 Configuración de los dispositivos de dump Es necesario configurar inicialmente el sistema para capturar un dump de forma satisfactoria. Esto se realiza siguiendo los siguientes pasos:
3.1.1 Estimar el tamaño de un posible dump Ante todo, es necesario determinar el tamaño del dispositivo de dump necesario para la máquina. Esto se hace a través del siguiente menú de SMIT: # smit dump_estimate
O corriendo el siguiente comando: # sysdumpdev -e 0453-041 Estimated dump size in bytes: 57671680
Este valor puede cambiar de acuerdo a la actividad del sistema. Es preferible correr el comando cuando la máquina se encuentra con la mayor carga de trabajo. Es recomendable crear el dispositivo de dump apenas masa grande que el valor reportado por el comando sysdumpdev de manera que pueda manejar un dump del sistema durante un pico de actividad. Es muy recomendable hacer un seguimiento a través del tiempo, e ir actualizando el tamaño si es necesario.
3.1.2 Seleccionando el dispositivo de dump Cuando se instala el sistema operativo, el dispositivo de dump es configurado automáticamente. Por defecto, el dispositivo de dump primario es el /dev/hd6, que es al mismo tiempo el volumen lógico de paginado por defecto. El dispositivo de dump secundario es configurado por defecto como /dev/sysdumpnull. Ambos pueden ser modificados para que sean disco, cinta o remoto. Para ver la actual configuración de los dispositivos de dump corra el siguiente comando : # sysdumpdev -l primary secondary copy directory forced copy flag always allow dump
/dev/hd6 /dev/sysdumpnull /var/adm/ras TRUE FALSE
En este ejemplo, el dispositivo de dump primario es el volumen lógico hd6, y el secundario /dev/sysdumpnull, lo que implica que no hay secundario. Originariamente, el dispositivo de dump secundario estaba limitado a ser utilizado cuando el usuario especificara por alguna razón que quería que se almacenara allí. En la práctica, el dispositivo de dump secundario no se usaba nunca. Sin embargo, el uso del dispositivo de dump secundario cambió en la versión 4.2.1 de AIX con la protección de fallas para dumps (dump failover).
Nota Dump failover El dispositivo de dump secundario es ahora utilizado como respaldo del primer dispositivo de
Página 35 de 283
dump. Si ocurre un error durante un dump de sistema en el dispositivo primario, el sistema intenta copiar el volcar el dump en el dispositivo secundario (si está definido). Si también falla el segundo dispositivo, AIX se referirá a cualquier dispositivo que acepte suficientes datos como para contener el verdadero dump. Esto es muy útil cuando el sistema no puede volcar satisfactoriamente un dump del sistema en el dispositivo de dump primario. Hay que tener en cuenta las siguientes reglas cuando se eligen dispositivos de dump: • No utilizar volúmenes lógicos espejados como dispositivo de dump activo. No se mostrará ningún mensaje de error, pero cualquier dump que se intente grabar en un volumen lógico espejado fallará indefectiblemente. • Esta limitación fue eliminada en AIX Versión 4.3.3 y versiones posteriores. • No usar una unidad de disquete como dispositivo de dump. • El dispositivo de paginado primario hd6 es el único dispositivo de paginado que puede ser utilizado como dispositivo de dump. Cualquier otro espacio de paginado que se configure como dispositivo de dump será indefectiblemente desactivado como dispositivo de paginado, no siendo más utilizado por el AIX virtual memory manager. • AIX Versión 4.2.1 o superiores soportan utilizar cualquier dispositivo de paginado en el grupo de volúmenes root (rootvg) como el dispositivo de dump secundario.
Nota Dump en un volumen lógico espejado Las versiones de AIX anteriores a la 4.3.3 no soportan los volúmenes lógicos espejados como dispositivos de dump. Esto es porque el dump ignora los mecanismos del LVM y escribe directamente a una de las copias del volumen lógico. En otras palabras, sólo una de las copias contiene el dump; las otras copias sólo contienen lo que sea que el volumen lógico tuviera antes de que el dump comenzara. Cuando el comando crash intenta leer el dump, utiliza el mecanismo normal de lectura del LVM, por lo que busca los datos de cualquier de las copias, y sólo una contiene el dump. En otras palabras, el crash ve datos del dump mezclados con datos basura y falla la lectura. Esta limitación es eliminada con el AIX Versión 4.3.3, que soporta la utilización de un volumen lógico espejado como el dispositivo primario de dump. Para especificar el dispositivo de dump primario utilice el siguiente comando: # sysdumpdev -P -p /dev/hd7 primary /dev/hd7 secondary /dev/sysdumpnull copy directory /var/adm/ras forced copy flag TRUE always allow dump FALSE
Para especificar el dispositivo de dump secundario utilice el siguiente comando: # sysdumpdev -P -s /dev/hd7 primary /dev/hd6 secondary /dev/hd7 copy directory /var/adm/ras forced copy flag TRUE always allow dump FALSE
3.1.3 Creando un dispositivo de dump
Página 36 de 283
Si quiere crear un volumen lógico de dump común, siga los siguientes pasos: 1. Calcular el tamaño de un dump del sistema. # sysdumpdev -e 0453-041 Estimated dump size in bytes: 54525952
Recuerde que el dispositivo de dumps debe ser apenas más grande que lo que reporta el sysdumpdev para manejar adecuadamente los dumps durante picos de carga de trabajo. 2.
Calcule el número necesario de PPs para el dispositivo de dump. Obtenga el tamaño de PP del grupo de volúmenes con el comando lsvg: # lsvg rootvg VOLUME GROUP: rootvg VG STATE: active VG PERMISSION: read/write MAX LVs: 256 LVs: 10 OPEN LVs: 8 TOTAL PVs: 1 STALE PVs: 0 ACTIVE PVs: 1 MAX PPs per PV: 1016
VG IDENTIFIER: 00017d37a4155bbc PP SIZE: 8 megabyte(s) TOTAL PPs: 537 (4296 megabytes) FREE PPs: 218 (1744 megabytes) USED PPs: 319 (2552 megabytes) QUORUM: 2 VG DESCRIPTORS: 2 STALE PPs: 0 AUTO ON: yes MAX PVs: 32
Determine el número necesario de PPs dividiendo el tamaño del dump por el tamaño de PP. Por ejemplo: 54525952 / 8 megabytes = 6.5 (la cantidad necesaria es 7)
3.
Genere un volumen lógico del tamaño necesario, por ejemplo: # mklv -y hd7 -t sysdump rootvg 7 hd7
3.1.4 Cambiando el tamaño del dispositivo de dump Si el sistema tiene un dispositivo de dump, asegúrese que el tamaño de dump estimado sea menor que el del dispositivo. El comando lslv muestra el tamaño del volumen lógico. Por ejemplo: # lslv hd6 LOGICAL VOLUME: hd6 LV IDENTIFIER: 00017d37a4155bbc.2 VG STATE: active/complete TYPE: paging MAX LPs: 512 COPIES: 1 LPs: 256 STALE PPs: 0 INTER-POLICY: minimum INTRA-POLICY: middle MOUNT POINT: N/A MIRROR WRITE CONSISTENCY: off EACH LP COPY ON A SEPARATE PV ?: yes
Se deben tomar los valores de LPs y PP SIZE. Multiplicando dichos valores se obtiene el tamaño del dispositivo de dump en megabytes. Si el dispositivo de dump es un volumen lógico de dumps común, como hd7, entonces el comando que se debe utilizar para incrementar su tamaño es extendlv. Por ejemplo: # extendlv hd7 1 hdisk
Página 37 de 283
Si es el espacio de paginado hd6, entonces use el comando chps. Por ejemplo: # chps -s'1' hd6
Si el dispositivo de dump es el espacio de paginado, asegúrese que el valor del forced copy flag sea true, por medio del comando sysdumpdev y el tamaño del copy directory sea suficiente. El directorio por defecto es /var/adm/ras. Para revisar el tamaño del copy directory y modificarlo se deben correr los siguientes comandos: # df -k /var Filesystem 1024-blocks Free %Used Iused %Iused Mounted on /dev/hd9var 8192 4776 42% 102 5% /var # chfs -asize=+200000 /var File System size changed to 229376
3.1.5 Configuración adicional Esta sección detalla otras características del AIX y la máquina que puedan afectar la capacidad de acceso a un dump de sistema. • Autorestart Un atributo del sistema muy útil es autorestart. Si autorestart es true, el sistema automáticamente reinicia después de una caída. Esto es sumamente útil si la máquina se encuentra físicamente distante o sin atención frecuente. Para revisar este valor, utilice: lsattr -Dl sys0 Para configurar autorestart como true, use SMIT de la siguiente manera: smit chgsys
O use el comando: # chdev -l sys0 -a autorestart=true sys0 changed
• Always allow system dump Si este ítem es configurado como true, el botón de Reset o una secuencia de teclas pueden iniciar un dump de sistema, aún cuando la llave se encuentre en la posición Normal o cuando el sistema no cuente con llave. Se puede cambiar con smit dump_allow, o con el comando sysdumpdev.
• Surveillance timeout interval La mayoría de los servidores nuevos, como los 7017-S80 y los 7025-F50, tienen un procesador de servicio (service processor), que cumple una función de supervisión del hardware y el software. Algunas veces, un dump del AIX falla debido a que el timeout de supervisión (surveillance timeout) interfiere con el proceso del dump. Esto ocurre porque es insuficiente el tiempo configurado para el timeout de supervisión. Si el sistema tiene un procesador de servicio, asegúrese que el valor del timeout de supervisión sea suficiente. Generalmente, más de 5 minutos es suficiente. Para ver esta información, utilice el comando diag, y seleccione el menú Task Selection, luego el menú Configure Surveillance Policy. Se podrá ver información similar a la siguiente: ------------------------------------------------------------------------------------------------------------------------------------------------CONFIGURE SURVEILLANCE POLICY 802583
The following system configuration parameters are available for
Página 38 de 283
Surveillance Policy. Any data in brackets [] may be changed or added at this time. When finished, use 'Commit' to accept the data. Surveillance Surveillance Time Interval, in minutes Surveillance Delay, in minutes Changes are to take effect immediately F1=Help F5=Reset
No hay necesidad de cambiar el valor del timeout de supervisión en sistemas corriendo AIX Versión 4.3.3, ya que el valor es automáticamente modificado a 60 minutos en el momento que comienza un proceso de dump.
3.2 Revisando el estado del dump Es muy útil revisar que el dump del sistema sea válido y legible, antes de enviarlo al centro de soporte para su posterior análisis. Esto ahorra mucho tiempo en caso de que no sea válido.
3.2.1 Información del último dump Si se corre el comando sysdumpdev -L, este muestra información estadística sobre el dump mas reciente. Esto incluye fecha y hora, tamaño en bytes, el estado de finalización. Por ejemplo: # sysdumpdev -L 0453-039 Device name: /dev/hd6 Major device number: 10 Minor device number: 2 Size: 68197888 bytes Date/Time: Fri Mar 12 14:43:52 CST 1999 Dump status: 0 dump completed successfully 0481-195 Failed to copy the dump from /dev/hd6 to /var/adm/ras. 0481-198 Allowed the customer to copy the dump to external media.
En este caso, el dump finalizó satisfactoriamente y pudo ser copiado a un medio de almacenamiento externo, como por ejemplo, cinta.
3.2.2 Códigos de estado de un dump Cuando se ve el código 888 en el LED, es porque el sistema sufrió una caída. Se puede ver en poco tiempo un 0c9, indicando que un dump del sistema está en progreso. Cuando el dump concluye, el LED muestra el código 0c0 si concluye de manera satisfactoria. La siguiente tabla muestra los posibles códigos de estado de un dump. Dependiendo del nivel de AIX, alguno de estos códigos puede no estar disponible en el sistema.
Código
Código de estado
Descripción Página 39 de 283
del LED del sysdumpdev 0c0
0
El dump concluyó satisfactoriamente.
0c1
-4
Error de I/O. Este mensaje fue agregado para las versiones de AIX 4.1.5 y 4.2.1.
0c4
-2
El dispositivo de dump es muy pequeño. El dump se tomó parcialmente. Este código fue modificado en AIX 4.1.5 y AIX 4.2.1. Ahora es más específico. Es usado para incluir otro tipo de errores internos.
0c5
-3
Error interno. Este código fue modificado en AIX 4.1.5 y AIX 4.2.1. Ahora es mostrado únicamente cuando el sistema de dumps falla en sí mismo. No incluye las fallas de las rutinas de los componentes.
0c8
-1
No hay un dispositivo de dump definido.
0c2
-
Dump en progreso iniciado por el usuario. Este código fue modificado en AIX 4.1.5 y AIX 4.2.1. En AIX 4.2.1 y superiores, este código aparece independientemente de que el dump vaya al dispositivo primario o secundario.
0c6
-
Dump en progreso iniciado por el usuario al dispositivo secundario. Obsérvese que AIX 4.2.1 y superiores soportan dump failover, por lo que este código quedó obsoleto.
0c7
-
Dump esperando autorización de un servidor NFS.
0c9
-
Dump iniciado por el sistema en progreso.
0cc
-
Cambio de dispositivo por failover. Indica que el dump fallo en el dispositivo primario e intenta utilizar el secundario. Soportado en AIX 4.2.1 y superiores.
3.2.3 Log de errores Si se pierde el dump o no es copiado durante el reinicio del sistema, el log de errores (error log) puede ayudar a determinar la naturaleza del problema que provocó el dump. Implementado con AIX 4.1.3, el log de errores puede incluir un error con la etiqueta (label) SYSDUMP_SYMP si el dump era legible por AIX durante el reinicio siguiente a la caída. La entrada en el log de errores también incluye un stack tracebak. Para revisar el log de errores utilice el comando errpt. La siguiente figura muestra un ejemplo de un error del tipo SYSDUMP_SYMP. LABEL: IDENTIFIER:
Description SYSTEM DUMP Probable Causes UNEXPECTED SYSTEM HALT User Causes SYSTEM DUMP REQUESTED BY USER Recommended Actions PERFORM PROBLEM DETERMINATION PROCEDURES Failure Causes UNEXPECTED SYSTEM HALT Recommended Actions PERFORM PROBLEM DETERMINATION PROCEDURES Detail Data DUMP STATUS LED:300 csa:2ff3b400 soo_select 2c8 soo_select 198 selpoll 120 select 4f0 sys_call_ret 0 Symptom Data REPORTABLE 1 INTERNAL ERROR 1 SYMPTOM CODE PIDS/5765C3403 LVLS/430 PCSS/SPI1 MS/300 FLDS/soo_selec VALU/90150008 FLDS/selpoll VALU/120
En este ejemplo, se puede ver el estado del dump (dump status) e información sobre el stack traceback en la sección Detail Data. La sección User Causes siempre dice que el dump fue iniciado por el usuario, aún cuando haya sido iniciado por el sistema.
Página 41 de 283
3.3 Core dump Un archivo core es creado en el directorio que está en uso cuando ocurren los errores. Estos errores pueden ser violaciones a direcciones de memoria, instrucciones ilegales, errores de bus, o señales de salida generadas por usuario, y son comúnmente los causantes de un dump. El archivo core que es generado contiene una imagen de la memoria de los procesos finalizados. Un proceso con un ID de usuario diferente al verdadero ID de usuario no produce una imagen de memoria.
3.3.1 Revisando un core dump Cuando un core dump es generado, un error será reportado y puede verse en el log de errores de la siguiente manera: # errpt IDENTIFIER TIMESTAMP ... C60BB505 0705101400 ...
T C RESOURCE_NAME
DESCRIPTION
P S SYSPROC
SOFTWARE PROGRAM ABNORMALLY TERMINATED
En el reporte anterior se puede ver que el error tiene un identificador C60BB505. Un reporte detallado del error se puede ver de la siguiente manera: # errpt -a -j C60BB505 -------------------------------------------------------------------------LABEL: CORE_DUMP IDENTIFIER: C60BB505 Date/Time: Wed Jul 5 10:14:59 Sequence Number: 8 Machine Id: 000BC6DD4C00 Node Id: client1 Class: S Type: PERM Resource Name: SYSPROC Description SOFTWARE PROGRAM ABNORMALLY TERMINATED Probable Causes SOFTWARE PROGRAM User Causes USER GENERATED SIGNAL Recommended Actions CORRECT THEN RETRY Failure Causes SOFTWARE PROGRAM Recommended Actions RERUN THE APPLICATION PROGRAM IF PROBLEM PERSISTS THEN DO THE FOLLOWING CONTACT APPROPRIATE SERVICE REPRESENTATIVE Detail Data SIGNAL NUMBER 4 USER'S PROCESS ID: 15394 FILE SYSTEM SERIAL NUMBER 5 INODE NUMBER 2 PROGRAM NAME netscape_aix4 ADDITIONAL INFORMATION Unable to generate symptom string. Too many stack elements.
Página 42 de 283
En esta salida, puede verse que el programa que generó el core dump fue netscape_aix4.
3.3.2 Localizando el core dump Cuando un sistema genera un core dump, lo graba con el nombre core. Este archivo puede estar grabado en cualquier directorio del sistema, inclusive en file systems remotos, y es necesario utilizar el comando find para encontrarlo: # find / -name core -ls 737 10188 -rw-r--r-- 1 root system 10430807 Jul 5 10:14 /core
En este ejemplo, el archivo se encuentra en el directorio raíz (root).
3.3.3 Determinando qué programa provocó el core dump Existen dos formas de determinar que programa causó el core dump: uno es utilizar el comando strings, el otro es utilizar el comando lquerypv.
Aunque esta información debería estar en el log de errores, puede haber ocasiones en que el reporte de error no esté disponible o halla sido eliminado. El comando strings mostrará el path completo del programa. Por ejemplo: # strings core | grep _= _=/usr/netscape/communicator/us/netscape_aix4
El comando lquerypv se utiliza de la siguiente manera: # lquerypv -h core 6b0 64 000006B0 7FFFFFFF FFFFFFFF 000006C0 00000000 000007D0 000006D0 00120000 137084E0 000006E0 6E657473 63617065 000006F0 00000000 00000000 00000700 00000000 00000000 00000710 00000000 00000F5A
Utilizando la información provista, el archivo fue generado por el programa netscape_aix4, como se veía en el log de errores.
3.3.4 Verificando el dump Para verificar que el dump sea legible, ejecute el comando crash con los archivos del dump, utilizando la siguiente sintaxis: crash . El comando crash necesita un archivo del kernel (unix) para corresponder con el archivo del dump. Si no se especifica un archivo del kernel, el crash utiliza por defecto el archivo /unix: # crash dump unix >
Si no se ve ningún mensaje sobre rutinas de dump que fallaron, probablemente el dump sea válido. Entonces ejecute el subcomando stat en el prompt >. Por ejemplo: # crash dump unix > stat sysname: AIX nodename: sp5i release: 3 version: 4
Página 43 de 283
machine: 000126774C00 time of crash: Tue May 4 04:56:10 CDT 1999 age of system: 4 min. xmalloc debug: disabled abend code: 300 csa: 0x2ff3b400 exception struct: dar: 0x00000003 dsisr: 0x00000000: srv: 0x04000000 dar2: 0x3c160040 dsirr: 0x06001000: "(unknown reason code)"
Se deben observar la fecha y hora y el abend code. Si son razonables para el dump, entonces se puede comenzar con los análisis iniciales. Un mensaje como el siguiente: dumpfile does not appear to match namelist implica que el dump no es válido. Por ejemplo: # crash dump unix Cannot locate offset 0x02052b8 in segment 0x000000. endcomm 0x00000000/0x011c5e70 WARNING: dumpfile does not appear to match namelist Cannot locate offset 0x00ccf10 in segment 0x000000. 0452-179: Cannot read v structure from address 0x ccf10. Symbol proc has null value. Symbol thread has null value. Cannot locate offset 0x00ccf10 in segment 0x000000. 0452-179: Cannot read v structure from address 0x ccf10. Cannot locate offset 0x00034c4 in segment 0x000000. 0452-1002: Cannot read extension segment value from address 0x 34c4
Cualquier otro mensaje mostrado cuando se ejecuta el comando crash podría indicar que ciertos componentes del dump son inválidos, pero generalmente son manejados por el crash. Si algún componente de la imagen del dump no es encontrado, mensajes adicionales lo indicarán, y el dump deberá ser considerado inválido.
3.4 Introducción al análisis del dump El objeto de esta sección es permitir reconocer algunos problemas comunes utilizando el comando crash, y realizar una determinación básica de las causas del problema.
3.4.1 Usos del comando crash El comando crash puede ser utilizado en un sistema en producción. Invocando el comando crash sin parámetros, esencialmente permite ver la memoria y el estado del sistema examinando el /dev/mem. El subcomando alter en el crash permite modificar el kernel que está corriendo. Esto debe ser utilizado únicamente bajo la dirección del soporte de IBM, dado que el uso incorrecto puede causar una caída del sistema. El usuario debe estar en el grupo system para poder utilizar el comando crash. El comando crash también puede ser utilizado en un dump de sistema. Esta es la principal herramienta utilizada para analizar un dump provocado por una falla en un sistema. Invocando el crash con un parámetro especificando un archivo de dump permite examinar dicho archivo para realizar un análisis del problema. Utilizando el crash, se puede examinar: • Direcciones y símbolos
Página 44 de 283
• Stack traceback del Kernel • Extensiones del Kernel • La tabla de procesos • La tabla de threads • La tabla de archivos • La tabla de inodos Además de los puntos mencionados, se puede utilizar el crash para observar cualquier otra cosa contenida en la memoria del kernel.
3.4.2 ¿Qué es el kernel? El kernel es el programa que controla y protege los recursos del sistema. Corre en modo privilegiado. Opera en forma directa con el hardware. Las principales funciones del kernel son: • Creación y eliminación de procesos/threads • Administración de la CPU (scheduling) • Administración de la memoria • Administración de los dispositivos • Provee herramientas de sincronización y comunicación para procesos. Si el kernel tiene un error, la maquina sufrirá una caída. Un programa de usuario únicamente creará un core dump y finalizará. El comando crash es utilizado para depurar dichos errores del kernel.
3.4.3 Examinando un dump del sistema El comando crash necesita un archivo /unix para corresponder con el archivo de dump a analizar. Por ejemplo: itsosrv1:/dumptest> crash dumpfile unix >
Si no se especifica un archivo de kernel, el archivo por defecto es /unix. itsosrv1:/dumptest> crash dumpfile Using /unix as the default namelist file. >
El comando crash utiliza el archivo del kernel para interpretar símbolos y permite la traducción de esos símbolos y su presentación. Si el archivo del kernel no corresponde con el dump, se obtiene un mensaje de error cuando se corre el crash.
3.4.4 Subcomandos básicos del crash Una vez que se corre el comando crash, el prompt es un signo mayor ( >). Para obtener una lista de los subcomandos disponibles escriba el signo ?. Para salir, tipee q. Se puede ejecutar cualquier comando shell precediéndolo con el signo de exclamación ( !). Es recomendable consultar la documentación de AIX Version 4.3 Kernel Extensions and Device Support Programming Concepts para más información sobre el comando crash y todos sus subcomandos. • stat
Página 45 de 283
Muestra estadísticas del dump. • proc [-] [-r] [TablaDeProcesos] Muestra la tabla de procesos (proc.h). Alias p y ps. • user [TablaDeProcesos] Muestra la estructura de usuario usuario de los procesos nombrados (user.h). Alias u. • thread [-] [-r] [-p] [TablaDeThread] Muestra la tabla de thread (thread.h). • mst [dirección] Muestra la parte mstsave de la estructura uthread (uthread.h, mstsave.h). • ds [dirección] Encuentra los símbolos de datos más cercanos a dirección dada. • knlist [símbolo] Muestra las direcciones de los símbolos dados. Opuesto a ds. • trace [-k][-m][-r][TablaDeThread] Muestra la stack trace del kernel. Alias t. • le Muestra entradas del loader. • nm [símbolo] Muestra valor y tipo de los símbolos como se encuentran en el archivo /unix. • od [nombre de símbolo o dirección] [número] [formato] Muestra un número determinado de palabras de datos del dump, en un nombre de símbolo o dirección, en el formato especificado. • ? o help[] Lista todos los subcomandos. Provee información sobre los subcomandos del crash. • cm [thread slot][seg_número] Cambia el mapa de los punteros internos del comando crash para cualquier segmento de thread de un proceso no paginado. Inicializa el mapa de punteros internos si no se utiliza ningún parámetro. • fs [thread NúmeroDeSlot] Vuelca los stack frames del kernel para un thread específico. • dlock [tid] | -p [processor_num] Muestra información de deadlock sobre todos los tipos de locks: simple, complex, y lockl. • errpt [número] Muestra mensajes del log de errores. El subcomando errpt siempre muestra todos los mensajes que aún no fueron leídos por el errdemon. Número especifica la cantidad de mensajes a mostrar. • du
Página 46 de 283
Vuelca el área de usuario de un proceso. • ppd Muestra el área de datos por procesador, muy útil en sistemas de multiprocesador. Muestra toda la información que cambia según cada procesador, como la Current Save Area (CSA).
3.4.4.1 El subcomando stat El subcomando stat entrega mucha información útil sobre un dump, como el código de dump (dump code), el mensaje de pánico (panic), la fecha y hora de la caída, versión y release del sistema operativo, nombre de la máquina que sufrió la caída, y cuánto tiempo estuvo funcionando la máquina desde el anterior crash o reinicio del sistema (age of system). Por ejemplo: > stat sysname: AIX nodename: kmdvs release: 3 version: 4 machine: 000939434C00 time of crash: Mon May 3 17:49:46 KORST 1999 age of system: 2 day, 4 hr., 28 min. xmalloc debug: disabled dump code: 700 csa: 0x384eb0 exception struct: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 panic: HACMP for AIX dms timeout - ha
El subcomando stat siempre debe ser el primer subcomando que se ejecuta cuando se examina un dump de sistema.
3.4.4.2 El subcomando trace –m El subcomando trace -m entrega un stack traceback del kernel. Este es típicamente el segundo subcomando que se utiliza cuando se examina un dump. Este subcomando muestra información sobre qué estaba pasando en el kernel cuando ocurrió la caída. El subcomando trace -m entrega una historial de function calls y muestra qué proceso de interrupción estaba en funcionamiento en el sistema. Si la caída ocurrió cuando el proceso de interrupción se estaba realizando, este es el subcomando a utilizar. Este comando rastrea la lista enlazada de áreas mstsave. Las áreas mstsave contienen básicamente un historial de los procesos de interrupción que se estaban ejecutando en el sistema.
Página 47 de 283
La machine state save area, o MST, contiene una imagen del contexto de procesos de la máquina. El contexto de procesos incluye los registros de punto flotante y de propósito general, los registros de propósito especial, y otra información necesaria para re-arrancar un thread cuando es despachado. Por ejemplo: > trace -m Skipping first MST MST STACK TRACE: 0x002baeb0 (excpt=00000000:00000000: (excpt=00000000:00000000:00000000:00000000:00000000) 00000000:00000000:00000000) (intpri=3) IAR: .[atmle_dd:atmle_ready_ind]+d8 .[atmle_dd:atmle_ready_ind] +d8 (01b05cb0): tweqi r5,0x0 LR: .[atmle_dd:atmle_ready_ind]+34 .[atmle_dd:atmle_ready_ind] +34 (01b05c0c) 002ba940: .[atmle_dd:atmle_receive_ether_data]+1ec (01b0c35c) 002ba9a0: .[atm_demux:atm_dmx_receive]+204 (01adc0e8) 002baa00: .[atmdd:atm_deqhandler]+1254 (01ac7e6c) 002babc0: .[atmdd:atm_HandleCardRsp]+1a4 (01aba084) 002baca0: .[atmdd:atm_handler]+48 (01aba350) 002bad40: .[atmdd:atm_intr]+ac (01ac4a04) 002bad90: .i_poll_soft+9c (0001ef84) 002badf0: .i_softmod+c8 (0001e964) 002bae70: flih_603_patch+c0 (0000bb9c) 0x2ff3b400 (excpt=00000000:00000000: (excpt=00000000:00000000:00000000:00000000:00000000)(i 00000000:00000000:00000000)(intpri=11) ntpri=11) IAR: .waitproc+c0 (0000edb0): lwz r3,0x6c(r28) LR: .waitproc+d4 (0000edc4) 2ff3b388: .procentry+14 (00045414) 2ff3b3c8: .low+0 (00000000)
En este ejemplo, hay dos niveles de stack traceback. El primer nivel muestra la Instruction Address Register (IAR), apuntando a una instrucción trap, tweqi r5, 0x0. IAR - Instruction Address Register. Contiene una dirección que provocó la caída. LR - Link Register que llamó a la función fatal o donde retornó el último llamado.
Página 48 de 283
Esta instrucción trap es lo que se ve cuando se tiene una caída del tipo Program Interrupt, o Dump Status = 700. Probablemente es el resultado de un assert o panic. También podemos ver que la prioridad de interrupción es 3 (intpri=3). En este caso, podemos ver que ocurría un procesamiento de interrupción cuando ocurrió la caída, ya que la prioridad de la interrupción era menor a 11 o 0xB. La prioridad de interrupción básica es indicada por 0xB u 11. Este es el nivel en el que corre un proceso normal. Cuando se observa un stack traceback, se debe tener en cuenta que la primera línea de la stack es la función en ejecución mas reciente, la cual fue llamada por la función inmediatamente inferior, la cual fue llamada por la función siguiente, y así en adelante. Entonces, en el caso de la stack traceback en nuestro ejemplo, vemos que i_softmod llamó a i_poll_soft, la que llamó a algunas funciones en los módulos atmdd y atm_demux, las que llamaron a atmle_receive_ether_data, que a su vez llamaron a atmle_ready_ind, y un assert fue provocado en atmle_ready_ind. Se deberá revisar el código para tratar de encontrar las causas de este assert. De cualquier forma, se puede asegurar que el módulo atmle_dd hizo algo mal. Es conveniente asegurarse que el módulo que falló esté al último nivel. Los problemas son frecuentemente resueltos en versiones posteriores. Se puede utilizar el subcomando le en el crash y el comando lslpp -w para encontrar el fileset que contiene el módulo especificado. Se puede obtener la última información de filesets en Internet en la siguiente dirección: http://service.software.ibm.com/support/rs6000
Utilice el subcomando le con la dirección listada en el IAR de el área MST. La dirección es mostrada entre corchetes después del nombre del módulo. Por ejemplo: > le 01b05cb0 LoadList entry at 0x04db7780 Module start:0x00000000_01b016e0 Module filesize:0x00000000_00030fbc Module *end:0x00000000_01b3269c *data:0x00000000_0125ef40 data length:0x00000000_0000375c Use-count:0x000c load_count:0x0001 *file:0x00000000 flags:0x00000272 TEXT KERNELEX DATAINTEXT DATA DATAEXISTS *exp:0x04e0e000 *lex:0x00000000 *deferred:0x00000000 *expsize:0x69626f64 Name: /usr/lib/drivers/atmle_dd ndepend:0x0001 maxdepend:0x0001 *depend[00]:0x04db7580 le_next: 04db7380
Uno de los campos listados por el subcomando le es Name (nombre) del módulo. Luego se puede usar el comando lslpp -w para determinar el fileset que contiene el módulo. Por ejemplo: itsosrv1:/> lslpp -w /usr/lib/drivers/atmle_dd File Fileset Type -----------------------------------------------------------------------------------------------------------------------------------------------------------/usr/lib/drivers/atmle_dd bos.atm.atmle File
Este comando está disponible en AIX Versión 4.2 o superior. Revisando la línea: 002ba940: .[atmle_dd:atmle_receive_ether_data]+1ec (01b0c35c)
Se puede ver en la primer columna la dirección de la entrada en la stack (no es importante en realidad). La última columna contiene la dirección retornada del código (01b0c35c). Esta dirección corresponde a la función mostrada, atmle_receive_ether_data, la cual está contenida en el módulo atmle_dd. Los corchetes que rodean al par [módulo:función] indican que esta es una extensión del kernel. Además, la instrucción en esta dirección retornada esta en la posición 1ec desde el comienzo del módulo atmle_dd.
Página 49 de 283
El ultimo de los stack tracebacks indica el nivel del proceso de usuario (intpri=b) y el proceso corriendo es wait. Si se corre el subcomando user, se podrá observar que el proceso corriendo es wait. Sin embargo, wait no causó el problema aquí, el problema fue causado por un programa corriendo a nivel interrupción, y observar el stack traceback del MST es la única manera de ver realmente el problema. Cuando ocurre una Data Storage Interrupt (DSI) con código de dump 300, la estructura de excepción es rellenada de la siguiente manera: 0x2ff3b400 (excpt=DAR:DSISR:SRV:DAR2:DSIRR) (intpri=?)
La estructura de excepción muestra varios registros de la máquina y el nivel de interrupción. Los registros mostrados en una estructura de excepción son definidos como sigue:
DAR Data Address Register DSISR Data Storage Interrupt Status Register SRV Segment Register Value DAR2 Secondary Data Address Register DSIRR Data Storage Interrupt Reason Register La prioridad de interrupción del contexto en ejecución se puede ver en el campo (intpri=?) al final de la línea. El valor intpri está comprendido entre 0xb (INTBASE) y 0x0 (INTMAX). La estructura de excepción no es usada para dumps con código 700.
3.4.4.3 El subcomando proc El subcomando proc muestra entradas en la tabla de procesos. La tabla de procesos esta constituida por entradas del tipo struct proc, una por proceso activo. Las entradas en la tabla de procesos son puestas de manera tal que están siempre residentes en la memoria física. La tabla de procesos contiene información necesaria para que, cuando el proceso se intercambia, más tarde se pueda correr a partir de determinado punto. Por ejemplo: > proc - 0 SLT ST 0 a
Los campos en las primeras líneas de la salida son los siguientes:
Página 50 de 283
SLT
Este es el número de slot del proceso, y simplemente indica la posición en la tabla de procesos. Este número se utiliza para decirle al comando crash específicamente que proceso block o u-block debe mostrar. Los números de slot están en notación decimal.
ST
Este campo es de sólo un carácter, indica el estado del proceso, y puede ser a=activo, i=idle, t=detenido, o z=zombie.
PID
Este es el ID del proceso actual con el que el proceso es conocido por el sistema. El numero de slot del proceso es usado para generar el ID del proceso.
PPID
ID del proceso padre.
PGRP ID del grupo del proceso UID
ID del usuario.
EUID
ID efectivo del usuario.
TCNT Numeración de thread. NAME Nombre del programa. FLAGS Flags de estado. 3.4.4.4 El subcomando thread La tabla de thread contiene información para threads que puede ser usada por otros threads en proceso. Hay una estructura asignada por thread activo. Las entradas que están en uso son puestas de manera que se eviten fallas de página en secciones críticas del kernel. Por ejemplo: > thread - 0 SLT ST TID PID CPUID POLICY 0 s 3 0 unbound FIFO t_flags: wakeonsig kthread
Los campos en la salida del subcomando thread son los siguientes:
Página 51 de 283
SLT
Número de slot.
ST
Estado. Puede ser i=idle, r=corriendo, s=durmiendo, w=cambiado, t=detenido, o z=zombie.
TID
ID del trhead.
PID
ID de los procesos asociados. Debe haber múltiples threads por proceso, pero sólo un proceso por thread.
CPUID
ID de la CPU que esta corriendo el thread. En un sistema de uniprocesamiento siempre deberá ser 0.
POLICY
Esta es la política de scheduling utilizada por el thread y puede tener los valores FIFO, RR, u otros.
PRI
Prioridad de dispatch. Este no es el valor del nice .
CPU
Utilización de CPU. Este valor es utilizado en el scheduling.
PROCNAME
El nombre del proceso para este thread.
EVENTS
Este es el canal de espera si no es cero.
FLAGS
Flags de estado.
3.4.4.5 El subcomando od od Se pueden ver y examinar áreas de memoria del dump utilizando el subcomando od. La sintaxis del subcomando es la siguiente: od [nombre del símbolo] [número] [formato]
Los formatos son ascii, octal, decimal, hex, byte, character, instruction, long octal, y long decimal. Por ejemplo: > od vmker 15 000bde48: 00002001 000bde58: 00200000 000bde68: 00080000 000bde78: 00000ab2
3.4.4.6 Revisando el log de errores Se pueden examinar las últimas entradas del log de errores en el dump utilizando el subcomando errpt. Por ejemplo: > errpt ERRORS NOT READ BY ERRDEMON (MOST RECENT LAST): Sun Apr 6 01:01:11 1997 : DSI_PROC data storage interrupt : processor
3.4.4.7 El subcomando le El subcomando le puede indicar a cual extensión del kernel pertenece una dirección. Tomando, por ejemplo, la dirección 0x0123cc5c. Esta es una dirección del kernel, dado que comienza en 0x01, lo que indica que está en el segmento 0, el segmento del kernel. Para encontrar el módulo del kernel que contiene el código en esta dirección, utilice el subcomando le. Por ejemplo: > le 0123cc5c LoadList entry at 0x04db7780 Module start:0x00000000_012316e0 Module filesize:0x00000000_00030fbc Module *end:0x00000000_0126269c *data:0x00000000_0125ef40 data length:0x00000000_0000375c Use-count:0x000c load_count:0x0001 *file:0x00000000 flags:0x00000272 TEXT KERNELEX DATAINTEXT DATA DATAEXISTS *exp:0x04e0e000 *lex:0x00000000 *deferred:0x00000000 *expsize:0x69626f64 Name: /usr/lib/drivers/pse/pse ndepend:0x0001 maxdepend:0x0001 *depend[00]:0x04db7580 le_next: 04db7380
En este caso, podemos ver que el código en la dirección 0x0123cc5c está en el módulo /usr/lib/drivers/pse/pse. El subcomando le es útil únicamente para módulos que ya se encuentran cargados en el kernel.
3.4.4.8 El log de errores del VMM Cuando el código de estado del dump indica un DSI o un ISI, es necesario ver el log de errores del VMM. Esto se puede hacer con el subcomando od mirando la estructura vmmerrlog. Por ejemplo: > od vmmerrlog 9 a 000c95b0: 9d035e4d 53595356 4d4d2000 00000000 |..^MSYSVMM .....| 000c95c0: 00000000 0a000000 00000000 0000000b |................| 000c95d0: 00000086 |....|
Página 53 de 283
Offset
Significa
0x14 0x1C 0x20
Data Storage Interrupt Status Register (DSISR) Dirección que falla Código de retorno del VMM
En este ejemplo, el código de retorno 0x86 del VMM significa PROTECTION EXCEPTION. Estos son los distintos códigos de retorno del VMM, nombres simbólicos, y significados:
0000000E
Este código de retorno indica un EFAULT. Esto viene de errno.h (14) y es retornado si se intenta acceder a una dirección inválida
FFFFFFFA
Este código de retorno indica que se intentó acceder a una página inválida que no está en memoria. Comúnmente esto es el resultado de un page fault. Esto será retornado si se intenta acceder a algo que está paginado mientras las interrupciones están desactivadas.
00000005
Este código indica un problema de hardware. Un error de I/O ocurre cuando se intenta paginar o se intenta acceder a un archivo mapeado en memoria y la acción no se puede realizar. Se debe revisar el log de errores y buscar problemas de disco o errores SCSI.
00000086
Este código de error indica una protection exception. Esto significa que se intento almacenar en una ubicación que está protegida. Esto es causado normalmente por memoria del low kernel.
0000001C
Este código de retorno indica que no hay espacio de paginado. Esto significa que el espacio de paginado está exhausto.
3.4.5 Manejando la salida del crash Algunos subcomandos del crash generan algunas líneas más de las que pueden caber en la pantalla. Además, el crash no detiene la salida cada vez que se llena la pantalla. Por lo tanto, es necesario contar con un método para manejar el flujo de salida. En el pasado, los comandos script o tee se utilizaban para ello. Por ejemplo: tee -a outf | crash /tmp/dump /unix | tee -a outf
Ahora existe un nuevo método para obtener un archivo de log, utilizando el subcomando set logfile. Por ejemplo: >set logfile crash.log
Una vez que es ingresado, el crash comienza a guardar todas las entradas y salidas en el archivo especificado. El subcomando set logfile es disponible en AIX 4.1.5, 4.2.1, 4.3, y superiores. Además de la utilidad logfile, es posible la concatenación de comandos dentro del crash, esto es muy útil cuando se desea enviar la salida a comandos como more, pg, y grep. Por ejemplo: > le 0123cc5c | grep Name Name: /usr/lib/drivers/pse/pse
Página 54 de 283
3.4.6 Tipo de caídas Estos son problemas muy comunes que provocan una caída del sistema y que requieren un posterior análisis de dump:
3.4.6.1 Kernel panic o trap Esta es normalmente la causa de una caída del sistema con la secuencia de LED 888-102-7000cx. En AIX, los kernel panics se muestran a sí mismos como traps. La rutina panic() en el kernel coloca su mensaje en un buffer, lo escribe en la tty de depuración utilizando el programa de depuración del kernel, y llama a brkpoint(). Si el depurador del kernel está cargado, y una terminal ASCII se encuentra conectada en el puerto serie, esto arranca el depurador; si no es así, esto provoca un dump. Si ocurre un panic o assert, se debe examinar el código fuente para entender la condición que causó ese panic o assert.
3.4.6.2 Addressing exception o data storage interrupt Este tipo de caída es acompañada por la secuencia de LED 888-102-300-0cx. El 300 en la secuencia de LED indica una addressing exception (una Data Storage Interrupt o DSI). Normalmente, esto es provocado por el acceso a una dirección equivocada, o una falla al paginar cuando las interrupciones están desactivadas. Cuando se tiene este tipo de caídas, se debe revisar el código de retorno del VMM.
3.4.6.3 Bloqueo del sistema (System hang) Cuando el sistema se bloquea, se puede forzar un dump para determinar la causa. Un bloqueo del sistema es un congelamiento total del sistema. Para ver que es lo que mantiene al sistema bloqueado se puede forzar un dump, poniendo la llave en la posición de servicio y presionando el botón de reset.
3.4.7 Información requerida por el centro de soporte En cualquier tipo de caída (Trap o DSI), la siguiente información es solicitada por el centro de soporte para realizar la determinación del problema. Lo ideal, la salida del comando snap recolectado de la siguiente manera: /usr/bin/snap -a -o /dev/rmt#
Esto recolecta el dump del sistema, el /unix, y otra información necesaria y la graba en una cinta. Si ocurre que el dump no puede ser enviado, la siguiente información es la mínima necesaria para que el centro de soporte analice el problema: • Un stack trace del kernel obtenido utilizando el subcomando del crash trace –m. Por ejemplo: # crash > trace -m
Esto generalmente es suficiente, a menos que el crash ocurra en una extensión del kernel o en un controlador de dispositivos (driver).
Página 55 de 283
• El log de errores del dump obtenido utilizando el subcomando del crash errpt. Por ejemplo: > errpt
• Un stack dump completo obtenido por medio del subcomando del crash fs. Por ejemplo: > fs
Si este subcomando devuelve Frame pointer not valid, esta salida no será útil.
3.5 Observación y análisis de algunos ejemplos En esta sección se observan algunos ejemplos de dumps y el análisis por medio de algunos subcomandos del crash.
3.5.1 Ejemplo 1 El siguiente es un análisis realizado a un servidor RS/6000 F50, con AIX 4.3.2. Este servidor cumple la función de firewall. Intermitentemente, el servidor sufría un crash y se reiniciaba. Siempre es conveniente comenzar el análisis conociendo un poco sobre el servidor. La siguiente es la salida del comando stat: > stat sysname: AIX nodename: deadbeef release: 3 version: 4 machine: 000315684C00 time of crash: Mon Apr 24 00:01:19 CUT 2000 age of system: 84 day, 19 hr., 36 min. xmalloc debug: disabled abend code: 300 csa: 0x2ff3b400 exception struct: dar: 0x00000000 dsisr: 0x00000000: srv: 0x00000000 dar2: 0x00000000 dsirr: 0x00000000: (errno) "Error 0"
Es un AIX 4.3, como se esperaba. Tenemos también la fecha y hora del crash, que puede ser verificada con otros mecanismos, como el log de errores. Ejecutando el subcomando sysconfig podremos conocer un poco más sobre el servidor: > sysconfig SYSTEM CONFIGURATION architecture: POWER_PC width: cache_attrib: icache_size: icache_asc:
Ahora tenemos la plataforma de hardware. El análisis comienza ahora, cuando se estudia el snack trace. Este muestra los últimos llamados ejecutados por el kernel justo antes del panic. Se utilizará la opción -k para este paso. > trace -k STACK TRACE: 0x2ff3b400 (excpt=00000000:0a000000:00 (excpt=00000000:0a000000:00000000:00000000:00000106) 000000:00000000:00000106) (intpri=11) IAR: .simple_lock+18 (00009518): stwcx. r6,r0,r3 LR: .fselpoll_cleanup+cc (0008c104) 2ff3b260: .select+988 (00198a4c) 2ff3b3c0: .sys_call_ret+0 (00003a10) IAR not in kernel segment.
El kernel estaba en un llamado select cuando las cosas comenzaron a funcionar mal. Esto indica que el proceso (todavía se debe determinar) estaba buscando en un descriptor del socket. Esto parece relacionarse con temas de red. Ahora debemos determinar qué procesos se estaban ejecutando en el momento del crash. Para esto se puede utilizar el comando status: > status CPU TID 0 104d 1 1945
TSLOT 16 25
PID d46 1740
PSLOT 13 23
STOPPED yes yes
PROC_NAME errdemon inetd
De esta forma comprobamos que el problema está relacionado con la red, ya que uno de los procesos que se estaba ejecutando era el inetd. Esto concuerda con el llamado a un select() que informó el subcomando trace. Ahora debemos asegurarnos que vamos a rastrear el CPU 1. Para determinar (y fijar si es necesario) cuál CPU se está investigando, se debe utilizar el subcomando cpu: > cpu Selected cpu number :
1
Ahora, debemos revisar las estructuras proc y u_ del proceso inetd. Comenzando con la estructura proc, debemos referenciar los procs en el kernel utilizando el SLOT del proceso, que se obtuvo con el subcomando status (PSLOT): > p -e 23 SLT ST PID PPID PGRP UID EUID TCNT 23 a 1740 c4e 1740 0 0 1 FLAGS: swapped_in orphanpgrp execed
La estructura normal parece normal. Ahora revisaremos el área u_ por medio del subcomando u. Se debe tener en cuenta que en el kernel, todo se maneja por SLOT de proceso, y no por ID de proceso. La salida es tan abundante como informativa: > u 23 UTHREAD AREA FOR SLOT
Flags AVAILABLE TEXT AVAILABLE AVAILABLE AVAILABLE AVAILABLE AVAILABLE AVAILABLE AVAILABLE AVAILABLE AVAILABLE AVAILABLE AVAILABLE TEXT AVAILABLE WORKING
El área u_ también parece estar normal. Sin embargo, a esta altura tenemos dos puntos para continuar la investigación: 1) El sistema falló durante un llamado a un select(), y 2) el llamado select() fue realizado por el inetd. Por otro lado, sabemos que el inetd es un daemon de red y por lo tanto necesitamos revisar los sockets que estaban conectados al inetd en el momento del crash. Esto se puede realizar con el subcomando crash. Una vez más, se debe recordar que todo en el kernel es relacionado con SLOT de proceso y no ID de proceso. La salida es bastante voluminosa, pero esclarecedora: > socket -p23 fd 0: 702d2e00: type:0x0002 (DGRAM) opts:0x0000 () state:0x0080 (PRIV) linger:0x0000 pcb:0x700dc480 proto:0x000dfb30 q0:0x00000000 q0len:0 q:0x00000000 qlen:0 qlimit:0 head:0x00000000 timeo:0 error:0 oobmark:0 pgid:0 proc/fd: 23/0 23/13 fd 4: 702fec00: type:0x0001 (STREAM) opts:0x0006 (ACCEPTCONN|REUSEADDR) state:0x0080 (PRIV) linger:0x0000 pcb:0x702fee44 proto:0x04f33f90 q0:0x00000000 q0len:0
El ultimo descriptor de archivos (17) es ciertamente un poco extraño. Mientras todos los demás parecen razonables, el 17 sufre una llamativa escasez de información y datos. Ahora debemos observar con detenimiento el socket sospechoso con el subcomando socket: > socket -b 702d2c00 702d2c00: type:0x0000 () opts:0x0000 () state:0x0000 () linger:0x0000 pcb:0x00000000 proto:0x00000000 q0:0x00000000 q0len:0 q:0x00000000 qlen:0 qlimit:0 head:0x00000000 timeo:0 error:0 oobmark:0 pgid:0 rcv: cc:0 hiwat:0 mbcnt:0 mbmax:0 lowat:0 mb:0x00000000 events:0x0000 iodone:0x00000000 ioargs:0x00000000 flags:0x0000 () timeo:0 lastpkt:0x00000000 snd: cc:0 hiwat:0 mbcnt:0 mbmax:0 lowat:0 mb:0x00000000 events:0x0000 iodone:0x00000000 ioargs:0x00000000 flags:0x0000 () timeo:0 lastpkt:0x00000000
No hay datos. Esto puede no ser bueno. Cada socket, una vez fuera de la cola q, contiene datos como el estado, el program control block (pcb), y otros. Este socket carece de todo eso. Utilizando un subcomando de depuración de red del crash, el ndb, obtendremos una visión aún más cercana del socket problemático. ndb> sockets 702d2c00 ----------------- SOCKET INFO ------------------type:0x0000 (BOGUS) opts:0x0000 () state:0x0000 () linger:0x0000 pcb:0x00000000 proto:0x00000000 q0:0x00000000 q0len: 0 q:0x00000000 qlen: 0 qlimit: 0 head:0x00000000 timeo: 0 error: 0 oobmark: 0 pgid:
El tipo de código “(BOGUS)” dice todo. El kernel creó un socket bogus y se lo derivó al inetd. Una vez dentro de la llamada select(), el kernel se encontró con el socket problemático y falló. Una investigación mas profunda en los logs del sistema mostró que este sistema tenía una gran carga de trabajo.
Página 63 de 283
Página 64 de 283
3.5.2 Ejemplo 2 Comenzando el análisis: > stat sysname: AIX nodename: uxtech2 release: 3 version: 4 machine: 0041A83A4C00 time of crash: Thu Jun 13 09:15:59 MSZ 2002 age of system: 19 day, 22 hr., 1 min. xmalloc debug: disabled abend code: 0 csa: 0x0 > status CPU TID TSLOT PID 0 811 8 60c 1 254d 37 2246 > cpu Selected cpu number : 0 > t -mk Skipping first MST
El trace muestra un deadlock en netinet. Buscando en http:/service.software.ibm.com/rs6k/fixdb.htm se encuentra el APAR IY22668, que resuelve este problema, y se le indica al cliente que instale el siguiente fileset: bos.net.tcp.client.4.3.3.80 El snap muestra que el cliente tenía el nivel 4.3.3.75 de este fileset.
3.5.3 Ejemplo 3 Comenzando el análisis: > stat sysname: AIX nodename: copper release: 3 version: 4 machine: 00054262A100 time of crash crash: : Wed Jun 27 15:58:48 CDT 2001 age of system: 57 min. xmalloc debug: enabled abend code: 0 csa: 0x0 Debug kernel error message: No debug cause was specified. > status CPU TID TSLOT PID PSLOT STOPPED PROC_NAME 0 205 2 204 2 yes wait 1 307 3 306 3 yes wait 2 409 4 408 4 yes wait 3 50b 5 50a 5 yes wait 4 60d 6 60c 6 yes wait 5 70f 7 70e 7 yes wait 6 811 8 810 8 yes wait 7 5de9 93 26d6 38 yes sysdumpstart > t -m Skipping first MST MST STACK TRACE: > symptom Symptom criteria were not met. > cpu Selected cpu number : 7 > cpu 1 > t -m Skipping first MST MST STACK TRACE: 0x2ff3b400 (excpt=00000000:00000000:00 (excpt=00000000:00000000:00000000:00000000:00000000) 000000:00000000:00000000) (intpri=11) IAR: .waitproc_find_run_queue+b0 .waitproc_find_run_queue+ b0 (00025488): lha r0,0xc(r4) LR: .waitproc+a0 (00025918) 2ff3b328: .waitproc+a0 (00025918) 2ff3b388: .procentry+14 (00097618) 2ff3b3c8: .low+0 (00000000) all cpu's are the same as this... numpsblks psfreeblks
= 00080000 = 0007fe32
> od thewall
Página 66 de 283
0026b3f8: 00040000
Observando la salida del comando status, y la stack trace, se puede deducir que este es un dump forzado por medio del comando sysdumpstart. Es útil para analizar el estado general del sistema con un fin determinado. No hay necesariamente una falla en este caso.
Página 67 de 283
4. Optimización del rendimiento 4.1 Introducción al monitoreo y optimización del rendimiento en AIX El rendimiento en un sistema computarizado está basado en las expectativas humanas y la capacidad del sistema para cumplir con dichas expectativas. El objetivo en la optimización del rendimiento es que concuerden las expectativas y los resultados logrados. Para lograr este objetivo se debe hacer un balance entre razonables expectativas y la optimización de los recursos disponibles del sistema. El proceso de optimización del rendimiento requiere un alto nivel de conocimientos y experiencia, y no puede ser realizado únicamente analizando estadísticas, gráficos y figuras. Las percepciones humanas sobre el rendimiento no se deben dejar de lado si ayudan en la obtención de resultados. En la optimización del rendimiento entrarán en consideración tanto aspectos de la determinación de problemas como asuntos puramente de rendimiento. Las expectativas pueden ser clasificadas de la siguiente manera: Expectativas de rendimiento: el rendimiento es una medida que intenta expresar la cantidad de trabajo realizado en un período determinado de tiempo. Expectativas sobre el tiempo de respuesta: el tiempo de respuesta es el tiempo transcurrido desde que es realizado un requerimiento hasta que se obtiene la respuesta. El proceso de optimización del rendimiento puede ser iniciado por varias razones: Para lograr una optimización del rendimiento en un sistema instalado recientemente. Para resolver problemas de rendimiento causados durante la fase de diseño (dimensionamiento). Para resolver problemas de rendimiento que ocurran en la fase productiva. La optimización del rendimiento en un sistema instalado recientemente, por lo general implica ajustar algunos parámetros básicos del sistema operativo y aplicaciones. Las limitaciones originadas en la fase de dimensionamiento limitarán la posibilidad de realizar una optimización, o generarán un costo muy alto para poder realizarla. El sistema no cumplirá con las expectativas de rendimiento originales tanto por expectativas poco realistas, problemas físicos en el entorno del ordenador, o error humano al diseñar o implementar el sistema. En el peor de los casos será necesario agregar o reemplazar hardware. Por lo tanto, es muy recomendable tener cuidado particularmente cuando se realiza el dimensionamiento de un sistema, permitiendo que tenga suficiente capacidad como para soportar cargas de trabajo inesperadas. En otras palabras, no se debe diseñar un sistema para que esté un cien por cien activo desde el comienzo del proyecto. Cuando un sistema en un entorno productivo cumple con las expectativas de rendimiento para las cuales fue diseñado, pero las demandas y necesidades de la organización han superado la capacidad básica del sistema, la optimización del rendimiento es realizada con el fin de evitar o retrasar el costo de agregar o reemplazar hardware. Se debe tener en cuenta además, que muchos asuntos de rendimiento pueden finalmente deberse a determinadas operaciones realizadas por personal con conocimientos y experiencia limitada, que intencionalmente restringen algún recurso lógico o físico, vital del sistema.
Página 68 de 283
4.1.1 Rendimiento de CPU Esta sección es una revisión general sobre las operaciones del kernel y la CPU. Para realizar un monitoreo y optimización satisfactorios, se debe entender la forma en que operan los procesos y los threads en un entorno AIX. Los sistemas que presentan problemas de rendimiento, a veces están saturados no por limitaciones de hardware, sino por la forma en que están escritas las aplicaciones o la forma en que está configurado el sistema operativo.
4.1.1.1 Procesos y threads En esta sección veremos las diferencias entre procesos y threads. PROCESOS
Un proceso es una actividad en el sistema que fue iniciada con un comando, un shell script u otro proceso.
THREAD
Un thread es un flujo de control independiente que opera dentro del mismo espacio de direcciones que otros flujos de control independientes dentro de un proceso. Un thread del kernel es un flujo de control secuencial.
Un thread del kernel pertenece a un proceso. Un proceso puede tener uno o más threads del kernel. La ventaja de los threads es que se pueden tener múltiples threads corriendo en paralelo en diferentes CPUs en un sistema de multiprocesamiento simétrico (SMP). Múltiples threads de control permiten que una aplicación atienda los requerimientos de múltiples usuarios al mismo tiempo. Los threads de las aplicaciones pueden ser mapeados a threads del kernel en una relación 1:1 o n:1.
4.1.1.2 Time slice Las CPUs de un sistema son compartidas por todos los threads otorgándole a cada thread una determinada porción de tiempo (time slice) para correr. La porción de tiempo por defecto (1 tick del reloj, es decir 10 ms.) puede ser modificada utilizando el comando schedtune -t. A veces, incrementar el time slice aumenta el rendimiento del sistema al reducir los context switch (cambio de tarea). Los comandos vmstat y sar muestran la cantidad de context switch. Si se observa un valor alto, entonces incrementar el time slice puede mejorar el rendimiento. No obstante, este parámetro debe ser modificado después de un profundo análisis.
4.1.1.3 Modo kernel y modo usuario Hay dos modos en los que opera una CPU. Ellos son, modo kernel y modo usuario . En el modo usuario, los programas tienen acceso de lectura y escritura a los datos de usuario en la región privada del proceso. También pueden leer el texto de usuario y las regiones de texto compartidas, y tienen acceso a las regiones de datos compartidos utilizando funciones de memoria compartida. Los programas también tienen acceso a los servicios del kernel a través de los llamados de sistema (system calls). Entre los programas que operan en modo kernel se incluyen controladores de interrupciones, procesos del kernel y extensiones del kernel. El código que opera en este modo tiene acceso de lectura y escritura al espacio de direcciones globales del kernel y a los datos del kernel en la región de procesos cuando se ejecuta dentro del contexto de un proceso. Los datos de usuario dentro del espacio de direcciones del proceso deben accederse utilizando servicios del kernel. Cuando un programa de usuarios utiliza llamadas del sistema, lo hace en modo kernel. Es importante conocer
Página 69 de 283
el concepto de modo usuario y modo kernel, cuando se interpreta la salida de comandos como vmstat y sar.
4.1.1.4 Rendimiento en SMP En un sistema SMP, todos los procesadores son idénticos y realizan funciones idénticas. Estas funciones son: Cualquier procesador puede correr cualquier thread en el sistema. Esto significa que un proceso o thread listo para ejecutarse puede ser despachado a cualquier procesador, excepto procesos o thread asignados a un procesador específico utilizando el comando bindprocessor. Cualquier procesador puede controlar una interrupción externa excepto en niveles de interrupción asignados a un procesador específico utilizando el comando bindintcpu. Algunos sistemas SMP utilizan un manejo de interrupciones del tipo first fit (primero que sea apto) con el cual una interrupción siempre es direccionada a la CPU0. Si hay múltiples interrupciones al mismo tiempo, la segunda interrupción es dirigida al CPU1, la tercera al CPU2, y así sucesivamente. En este caso, un proceso asignado a la CPU0 por medio del comando bindprocessor puede ser que no obtenga la CPU necesaria para correr con el mejor rendimiento. Todos los procesadores pueden iniciar operaciones de I/O a cualquier dispositivo de I/O.
a. Coherencia de cache (Cache coherency) Todos los procesadores trabajan con los mismos espacios de direcciones virtuales y reales, y comparten la misma memoria real. Sin embargo, cada procesador puede tener su propio cache, en el que guardan una pequeña porción de la memoria del sistema. Para garantizar la coherencia del cache los procesadores utilizan una lógica snooping (espía). Cada vez que es cambiada una palabra en el cache del procesador, este envía un mensaje de alerta a todo el bus. Los procesadores permanentemente están espiando el bus, y si reciben un mensaje sobre la modificación de alguna palabra en el cache de otro procesador, verifican si tienen en su propio cache la dirección modificada. Si es así, invalidan ese dato en su cache. Los mensajes de alerta incrementan la carga en el bus, y los datos del cache invalidados aumentan el número de pérdidas del cache. Ambos teóricamente reducen el rendimiento general del sistema, pero el hardware está diseñado para minimizar el impacto que provoca el mecanismo de coherencia de cache.
b. Afinidad de procesador (Processor affinity) Si un thread se está ejecutando en una CPU y es interrumpido y nuevamente ejecutado, es asignado nuevamente a la misma CPU (si es posible) porque el cache del procesador puede tener aún líneas que pertenecen al thread. Si es asignado a otra CPU, el thread debe tomar nuevamente su información de la memoria principal. Alternativamente, puede esperar hasta que la CPU donde se ejecutó anteriormente se encuentre nuevamente disponible, lo que provocaría un gran retraso. AIX automáticamente intenta promover la afinidad de procesador al tener una cola de ejecución por CPU. La afinidad de procesador puede ser forzada asignando un thread a un procesador con el comando bindprocessor. Un thread que es asignado a un procesador puede ejecutarse únicamente en ese procesador, independientemente del estado de los otros procesadores del sistema. La asignación de un proceso a una CPU determinada se debe hacer con cuidado, ya que se puede
Página 70 de 283
perjudicar el rendimiento de ese proceso si la CPU en la que está asignado es ocupada y hay otras CPU libres en el sistema.
c. Locking El acceso a dispositivos de I/O y a la memoria real es serializado por el hardware. Detrás de los recursos físicos del sistema, como los dispositivos de I/O y la memoria real, hay recursos lógicos del sistema, como los datos compartidos del kernel, que son utilizados por todos los procesos y threads. Como estos procesos y threads pueden correr en cualquier procesador, es necesario un método para serializar los accesos a estos recursos lógicos del sistema. El mismo se aplica para el código de usuario paralelizado. El método primario para implementar la serialización del acceso a recursos es el uso de locks (cerraduras). Un proceso o thread tiene que obtener un lock antes de acceder al recurso compartido. Los procesos o threads deben liberar el lock luego de completar el acceso (unlock). Las funciones lock y unlock son utilizadas para obtener y liberar esos locks. Las operaciones lock y unlock son operaciones atómicas, y son implementadas de manera que ninguna interrupción o thread que se ejecute en otro procesador pueda afectar el resultado de la operación. Si un lock requerido está en poder de otro thread, el thread que lo requiere debe esperar hasta que el lock se encuentre disponible. El thread puede esperar el lock de dos formas diferentes: Locks girando (Spin locks) Un lock spin es adecuado para mantener un lock durante un período muy corto. El thread que espera el lock ingresa en un estrecho lazo (loop) donde repetidamente chequea la disponibilidad del lock. En este período, el thread no realiza ningún trabajo útil, y el tiempo de procesador utilizado es contabilizado dentro del modo del sistema (kernel). Para prevenir que el thread siga girando indeterminadamente, debe ser convertido en un lock dormido. Un límite para la cantidad de veces que gira se puede configurar utilizando: El comando schedtune –s n, donde n es la cantidad de veces que el lock del kernel debe girar dentro del lazo antes de dormir. El valor por defecto del parámetro n para sistemas multiprocesador es 16384, y 1 (uno) para sistemas uniprocesador. La variable de ambiente SPINLOOPTIME=n El valor n es la cantidad de veces que el lock del usuario debe girar dentro del lazo antes de dormir. Esta variable de ambiente se emplea para los locks provistos por libpthreads.a. La variable de ambiente YIELDLOOPTIME=n Controla la cantidad de veces que se puede entregar el procesador antes de bloquearlo con un lock de usuario. El procesador es entregado a otro thread del kernel, asumiendo que hay otro kernel ejecutable con la suficiente prioridad. Esta variable de ambiente se emplea para los locks provistos por libpthreads.a. Locks dormidos (Sleeping locks) Un lock dormido es adecuado para mantener un lock durante un período de tiempo más largo. Un thread que requiere un lock es dormido si el lock no se encuentra disponible. Cuando el lock esté disponible, el thread será colocado nuevamente en la cola de ejecución. Hay una carga adicional por context switch y ejecución de locks dormidos. AIX provee dos tipos de locks, que son: Lock de lectura-escritura
Página 71 de 283
Múltiples lecturas de datos están permitidas, pero el acceso de escritura es exclusivo mutualmente. Los locks de lectura-escritura tienen tres estados: Escritura exclusiva Lectura compartida Desbloqueado Lock de exclusión mutua Sólo un thread puede acceder a los datos. Otros thread deben esperar, aún si quieren realizar únicamente una lectura de datos. El lock de exclusión mutua (mutex) tiene dos estados: Locked (Bloqueado) Unlocked (Desbloqueado) Ambos tipos de locks pueden ser spin locks o sleeping locks. Los programadores en un entorno de multiprocesamiento necesitan decidir la cantidad de locks para datos compartidos. Si hay un solo lock puede ocurrir contención de locks (lock contention), que es ni más ni menos que threads esperando un lock. En este caso, se requieren más locks. Sin embargo, esto puede ser más costoso, porque el tiempo de CPU debe ser desperdiciado bloqueando y desbloqueando, y hay un alto riesgo de que ocurra un deadlock (punto muerto). Como los locks son necesarios para serializar el acceso a ciertos datos, el uso excesivo de los mismos datos por muchos threads puede causar graves problemas de rendimiento.
4.1.2 Rendimiento de memoria En un entorno de multiprocesamiento (multiusuario), el control cuidadoso de los recursos del sistema es indispensable. El manejo descuidado de la memoria del sistema, tanto espacio de paginado como memoria real, puede provocar un mal rendimiento y hasta fallas en los programas y aplicaciones. El sistema operativo AIX utiliza el Virtual Memory Manager (VMM) para controlar la memoria real y el espacio de paginado del sistema.
4.1.2.1 Advertencia inicial Es recomendable no realizar ningún cambio en el VMM hasta tanto no conocer con claridad la carga actual del sistema.
4.1.2.2 Segmentos de memoria Un segmento consiste en 256 MB de espacio de direcciones de memoria virtual contiguas en el cual un objeto puede ser mapeado. Los segmentos de memoria virtual son particionados en tamaños fijos conocidos como páginas. Cada página tiene 4096 bytes (4 KB) de tamaño. Una página en un segmento puede estar en la memoria real o en disco donde es almacenado hasta que se debe utilizar. La memoria real está dividida en marcos de página (page frames) de 4096 bytes (4 KB). Simplemente, la función del VMM es controlar la asignación de los frames de la memoria real y resolver las referencias de un programa a las páginas de memoria virtual. Típicamente, esto ocurre cuando las páginas no están actualmente en memoria o no existen cuando un proceso realiza la primera referencia a una página de su segmento de datos.
Página 72 de 283
La cantidad de memoria virtual utilizada puede exceder el tamaño de la memoria real de un sistema. La función del VMM desde un punto de vista del rendimiento, es: •
Minimizar el uso del procesador y el disco como resultado del paginado Minimizar la degradación del tiempo de respuesta de un proceso como resultado del paginado
Los segmentos de memoria virtual pueden ser de tres tipos: Segmentos persistentes: Son utilizados para mantener datos de archivos, de file systems locales. Dado que las páginas de un segmento persistente tienen una ubicación de almacenamiento permanente en disco, el VMM escribe en esa ubicación cada vez que la página es modificada, si es que no puede mantenerse en memoria. Cuando una página persistente es abierta para una actualización retrasada, los cambios del archivo no son reflejados en el almacenamiento permanente hasta que se realice una operación con la subrutina fsync. Si no se realiza ninguna operación con la subrutina fsync, los cambios son descartados cuando el archivo se cierra. No ocurren operaciones de I/O cuando una página de un segmento persistente es seleccionada para ser colocada en la lista libre (free list), si la página no fue modificada. Si la página es referida nuevamente más tarde, es nuevamente leída. Segmentos de trabajo: Estos segmentos son transitorios y sólo existen mientras son usados por un proceso. Los segmentos de trabajo no tienen un ubicación de almacenamiento permanente y por lo tanto son almacenado en el espacio de paginado cuando las páginas de la memoria real necesitan ser liberadas. •
Segmentos cliente: Estos segmento son grabados y restaurados a través de la red a sus ubicaciones permanentes en un file system remoto en lugar de ser paginados en el sistema local. Los paginados desde CD-Rom y las páginas comprimidas son clasificados como segmentos cliente. Las paginas JFS2 también son mapeadas en segmentos cliente.
a. La lista libre (Free list) El VMM mantiene una lista de páginas de memoria libres disponible para satisfacer un page fault (demanda de página). Esta lista es conocida como la lista libre (free list). El VMM utiliza un algoritmo de reemplazo de páginas. Este algoritmo es utilizado para determinar qué páginas de la memoria virtual tendrán sus frames reasignados a la lista libre.
b. Reemplazo de páginas (Page replacement) Cuando la cantidad de páginas en la lista libre comienza a disminuir, el ladrón de páginas (page stealer) es invocado. El ladrón de páginas es un mecanismo que se mueve a través de la Page Frame Table (PFT) buscando páginas para robar. La PFT contiene flags que indican qué páginas fueron referenciadas y cuáles fueron modificadas. Si el ladrón de páginas encuentra una página en la PFT que fue referenciada, no robará la página, pero blanqueará el flag de referencia. La próxima vez que el ladrón de páginas revise esta página en la PFT, si esta no fue referenciada, la robará. Las páginas que no son referenciadas cuando el ladrón de páginas las revisa por primera vez, también serán robadas. Cuando el flag de modificación es activado en una página que no fue referenciada, le indica al ladrón de páginas que dicha página fue modificada mientras estuvo en memoria. En este caso, se
Página 73 de 283
llama a un page out antes de robar la página. Las páginas que son parte de un segmento de trabajo son escritas en el espacio de paginado, mientras que las páginas de segmentos persistentes son escritas en su ubicación permanente del disco. Hay dos tipos de page fault, un page fault nuevo, cuando la página es referenciada por primera vez y un repage fault, cuando las páginas ya fueron referenciadas (page out) anteriormente. El ladrón investiga las páginas que fueron referenciadas, utilizando un buffer que contiene el ID de página de los page out recientes. El buffer histórico también se utiliza para mantener un balance entre las páginas de los segmentos persistentes y las páginas de los segmentos de trabajo que fueron paginados a disco. El tamaño del buffer histórico depende de la cantidad de memoria del sistema; para un tamaño de memoria de 512 MB, es necesario un buffer histórico de 128 KB. Cuando un proceso finaliza, su almacenamiento de trabajo es liberado y las páginas de memoria liberadas y colocadas en la lista libre. Sin embargo, los archivos que fueron abiertos por un proceso pueden permanecer en memoria. En un sistema SMP, el proceso del kernel lrud es responsable del reemplazo de páginas. Este proceso es despachado a una CPU cuando el límite del parámetro minfree es alcanzado. Este límite puede modificarse con el comando vmtune. En un entorno de uniprocesamiento, el reemplazo de páginas es controlado directamente dentro del campo de acción del thread en ejecución. El algoritmo del reemplazo de páginas es más efectivo cuando la cantidad de repages es baja. El algoritmo de reemplazo perfecto eliminará los repage fault completamente y robará las páginas que no serán referenciadas nuevamente.
c. Mecanismo de control de la carga de memoria Si la cantidad de páginas de memoria virtual activas excede la cantidad de páginas de memoria real, el espacio de paginado es utilizado para todas aquellas páginas que no caben en la memoria real. Si una aplicación necesita una página que fue enviada al espacio de paginado, el VMM la carga en la memoria real. Si en ese momento la cantidad de páginas libres en la memoria real no es suficiente, el VMM debe liberar otra página de la memoria real antes de cargar la página requerida. Si encuentra únicamente páginas computacionales para liberar, el VMM se ve obligado a enviarlas al espacio de paginado. En el peor de los casos, el VMM siempre necesita realizar un page out antes de cargar (page in) una página en la memoria. Esta condición es denominada trashing. En una condición de trashing los procesos encuentran page faults apenas son ejecutados. Ninguno de los procesos avanza significativamente y el rendimiento del sistema se deteriora. El sistema operativo tiene mecanismos de control de carga que detectan cuando una condición de trashing está por comenzar. Una vez que el trashing es detectado, el sistema comienza a suspender procesos activos y retrasa el comienzo de todos los procesos nuevos. El mecanismo de control de carga de memoria es desactivado por defecto en sistemas con más de 128 MB de memoria. Puede manejarse por medio del comando schedtune -h.
4.1.2.3 Espacio de paginado El sistema operativo soporta tres políticas de asignación de espacio de paginado: Asignación tardía del espacio de paginado (Late Paging Space Allocation o LPSA) Asignación temprana del espacio de paginado (Early Paging Space Allocation o EPSA) Asignación diferida del espacio de paginado (Deferred Paging Space Allocation o DPSA)
Página 74 de 283
Asignación tardía del espacio de paginado (LPSA) Con la LPSA, un slot del paginado es asignado en una página de la memoria virtual únicamente cuando esa página es modificada. El riesgo que implica esta política es que cuando el proceso toque el archivo, no haya suficientes páginas disponibles en el espacio de paginado. Asignación temprana del espacio de paginado (EPSA) Esta política asigna la cantidad apropiada de páginas del espacio de paginado en el momento que el rango de direcciones de memoria virtual es asignado a un proceso. Esta política asegura que los procesos no sean matados cuando el espacio de paginado sea escaso. Para activar EPSA, se debe configurar la variable de ambiente PSALLOC=early. Configurando esta política se asegura que cuando un proceso necesite realizar un page out, las páginas estén disponibles. El tamaño del espacio de paginado recomendado cuando se adopta la política EPSA es de al menos cuatro veces el tamaño de la memoria real. Asignación diferida del espacio de paginado (DPSA) Esta es la política por defecto en AIX 5L Versión 5.1. La asignación del espacio de paginado es retardada hasta que es necesario realizar un page out, de manera que el espacio de paginado no es desperdiciado. Sólo se asignará el espacio de paginado cuando se deba hacer el page out de una página de memoria. Este espacio de paginado estará reservado para esta página hasta que el proceso la libere o este finalice. Este método ahorra gran cantidad de espacio de paginado. Para desactivar esta política, el parámetro defps del comando vmtune debe ser configurado en 0 (cero) de la siguiente manera: vmtune –d 0. Con este nuevo valor es utilizada la asignación tardía del espacio de paginado (LPSA)
a. Ajustando el umbral del espacio de paginado Cuando el espacio de paginado se agota, el sistema operativo intenta librear recursos primero advirtiendo a los procesos que debe liberar espacio de paginado, y luego directamente matando procesos. El comando vmtune es utilizado para configurar el umbral que indica cuando se debe iniciar esta actividad. Los parámetros del vmtune que afectan el paginado son: npswarn
El sistema operativo envía la señal SIGDANGER a todos los procesos activos cuando la cantidad de espacio de paginado disponible en el sistema esté debajo de este valor. Un proceso puede ignorar la señal o liberar páginas de memoria utilizando la subrutina disclaim().
npskill
El sistema operativo comienza a matar procesos cuando la cantidad de espacio de paginado esté debajo de este umbral. Cuando el umbral npskill es alcanzado, el sistema operativo envía una señal SIGKILL a los procesos más jóvenes. Los procesos que están controlando una señal SIGDANGER y procesos que utilizan la política EPSA están exentos de ser matados.
nokilluid
Los usuarios con UID más bajo que el número especificado en este parámetro no serán matados cuando el umbral npskil es alcanzado. Configurando este valor en 1 (uno), los procesos root estarán exentos de ser matados cuando el umbral npskill es alcanzado.
Cuando un proceso no puede iniciarse (fork) debido a la falta de espacio de paginado, el scheduler realizará cinco intentos para iniciar el proceso antes de poner el proceso a dormir. El scheduler deja pasar diez ticks del reloj entre cada intento. Por defecto, cada tick del reloj es de 10 ms. Es decir, 100 ms entre cada intento. El flag -f del comando schedtune puede ser usado para cambiar la cantidad de veces que el scheduler reintentará el fork.
Página 75 de 283
Para monitorear la cantidad del espacio de paginado, utilice el comando lsps. Es recomendable utilizar el flag -s en lugar del flag –a porque el formulario incluye las páginas en el espacio de paginado reservadas por la política EPSA.
4.1.2.4 Pérdidas de memoria (Memory leaks) Los sistemas suelen quedarse sin espacio de paginado debido a los leaks (pérdidas) de memoria de aplicaciones interactivas. Una leak de memoria es un error del programa por el cual el programa repetidamente asigna memoria, la utiliza y luego olvida liberarla. El comando svmon es útil detectando leaks de memoria. Para buscar procesos o grupos de procesos cuyos segmentos de trabajo estén continuamente creciendo, se puede usar el comando svmon con el flag -i.
4.1.2.5 Memoria compartida Los segmentos de memoria pueden ser compartidos entre procesos. Utilizar memoria compartida evita el exceso de llamados del sistema y el uso de buffers. Las aplicaciones reducen la sobrecarga de leer y escribir las llamadas del sistema manipulando punteros en esos segmentos de memoria. Los archivos y datos en los segmentos compartidos pueden ser compartidos por múltiples procesos y threads, pero la sincronización entre procesos o threads debe ser realizada en el nivel de la aplicación. Por defecto, cada región o segmento de memoria compartida tiene un espacio de direcciones de 256 MB, y la cantidad máxima de segmentos de memoria compartida que el proceso puede acceder al mismo tiempo está limitada a 11. Utilizando memoria compartida extendida se incrementa este número a más de 11 segmentos y permite que las regiones de memoria compartida sean de cualquier tamaño desde 1 byte hasta 256 MB. La memoria compartida extendida está disponible para los procesos que tienen la variable EXTSHM configurada en ON (es decir EXTSHM=ON en el entorno del proceso). Las restricciones de la memoria compartida extendida son: •
El I/O es restringido de la misma manera que para las regiones de memoria.
•
El I/O raw no es soportado.
•
•
No puede ser usada como buffer de I/O donde el desprendimiento de los buffers ocurre en un controlador de interrupciones. No puede ser abrochada (pinned) utilizando la subrutina plock(). Una página abrochada (pinned) es una página que siempre está residente en RAM y no puede ser movida al espacio de paginado (page out).
4.1.3 Rendimiento de I/O de disco Mucha atención es requerida cuando el subsistema de disco es diseñado e implementado. Por ejemplo, se debe considerar lo siguiente: •
Ancho de banda de los adaptadores de disco y del bus del sistema
•
Ubicación de los volúmenes lógicos en los discos
•
Configuración de arreglos de discos
Página 76 de 283
•
Configuraciones del sistema operativo, por ejemplo striping o espejado
•
Implementación de otras tecnologías, como SSA
4.1.3.1 Advertencia inicial Es recomendable no realizar ningún cambio en los parámetros por defecto del I/O de disco hasta tanto no conocer con claridad la carga actual del sistema. Hay que tener en cuenta, sin embargo, que siempre se debe monitorear la carga de I/O y es muy probable que surja la necesidad de equilibrar la configuración de los volúmenes físicos y lógicos después de la experiencia en el entorno productivo. Hay dos aspectos que limitan el rendimiento del subsistema de I/O de disco que necesitan ser considerados: •
Limitaciones físicas
•
Limitaciones lógicas
Un subsistema de I/O de disco que tenga un rendimiento pobre, normalmente afecta severamente el rendimiento general del sistema. Las limitaciones físicas incluyen el rendimiento del hardware interconectado. Las limitaciones lógicas incluyen el ancho de banda físico y la serialización de recursos y mecanismos de lock, desarrollados en el software de acceso a datos.
4.1.3.2 El diseño del subsistema de disco Para muchos sistemas, el rendimiento general de una aplicación es limitado por la velocidad en que los datos son accedidos desde el disco y la forma en que la aplicación lee y escribe los datos en los discos. El diseño y la configuración óptima de un subsistema de almacenamiento en disco es una tarea compleja que debe ser cuidadosamente estudiada durante las etapas de diseño iniciales de la implementación. Algunos factores que deben considerarse son: •
•
Rendimiento contra disponibilidad Una decisión debe tomarse a tiempo sobre que es más importante; el rendimiento de I/O de la aplicación o la integridad y disponibilidad de la aplicación. Incrementar la disponibilidad de datos generalmente implica disminuir el rendimiento del sistema y viceversa. Alta disponibilidad también implica una mayor cantidad de espacio de disco requerida. Tipo de carga de la aplicación Las características de la carga de I/O de la aplicación deben ser muy bien entendidas antes de implementar el subsistema de disco. Diferentes tipos de carga generalmente requieren diferente configuración de los subsistemas de disco para proveer un rendimiento de I/O aceptable.
Rendimiento requerido del subsistema de disco Los requerimientos de rendimiento de I/O deben ser definidos de entrada, ya que estos juegan un papel fundamental durante la configuración física y lógica del subsistema de disco.
•
•
Espacio de disco requerido Antes de diseñar el subsistema de disco, deben ser entendidos claramente los requerimientos de espacio de la aplicación.
Página 77 de 283
•
Costo Aunque no esté relacionado con el rendimiento, el costo total del subsistema de discos generalmente juega un papel importante durante el diseño del sistema. Genéricamente hablando, un sistema de gran rendimiento cuesta más que uno de menor rendimiento.
4.1.3.3 Consideraciones de rendimiento relativas al ancho de banda El ancho de banda de un vínculo de comunicación, como adaptadores de disco o bus, determina la velocidad máxima en el que los datos pueden ser transmitidos a través de ese vínculo. Cuando se describen las capacidades de un componente de un subsistema de disco particular, los números de rendimiento son expresados típicamente en rendimiento máximo o pico de rendimiento, lo que no describe realmente el verdadero rendimiento que tendrá en un escenario del mundo real. Además, cada componente podrá tener diferentes anchos de banda, lo que creará cuellos de botella en el diseño general del sistema. El ancho de banda de cada uno de los siguientes componentes debe ser considerado cuando se diseña el subsistema de disco: •
•
•
Discos Los últimos discos SCSI y SSA tienen tasas de transferencia de datos máxima sostenida de entre 14 y 20 MB por segundo. Nuevamente, las tasas previstas para el mundo real por lo general serán menores, dependiendo de la ubicación de los datos y las características de carga de I/O de la aplicación. Las aplicaciones que realizan una gran cantidad de lecturas o escrituras secuenciales podrán logran mayores tasas de transferencia que aquellas que realizan principalmente operaciones de I/O aleatorias. Adaptadores de disco Los adaptadores de disco pueden convertirse en cuello de botella dependiendo de la cantidad de discos conectados y su uso. Mientras las especificaciones de SCSI-2 permiten una transferencia de datos de 20 MB/seg como máximo, los adaptadores basados en la especificación UltraSCSI son capaces de proveer un ancho de banda de hasta 40 MB/seg. El bus SCSI utilizado para transferencia de datos es un bus arbitrado. En otras palabras, sólo un dispositivo puede enviar datos a la vez. Esto implica que la tasa de transferencia máxima teórica difícilmente pueda ser sostenida. En comparación, los adaptadores IBM SSA utilizan un protocolo no arbitrado, que además soporta múltiples transferencias de datos punto a punto concurrentes. Los adaptadores SSA actuales son capaces de soportar tasas de transferencia de datos máximas teóricas de 160 MB/seg. Bus del sistema La arquitectura del bus del sistema utilizado puede limitar el ancho de banda general de un subsistema de disco. Así como el ancho de banda de los discos es limitado por el ancho de banda de los adaptadores de disco a los que están conectados, la velocidad del adaptador de disco es limitada por el ancho de banda del bus del sistema. El bus PCI standard está limitado a un máximo teórico de 132 MB/seg (32-bit @ 33MHz) o 528 MB/seg (64-bit @ 66MHz).
4.1.3.4 Diseño del disco Un disco consiste en un conjunto de bandejas circulares giratorias planas. Cada bandeja tiene una o dos caras en que los datos son almacenados. Las bandejas son leídas por un conjunto de cabezas de lectura/escritura posicionables, que se mueven juntas como una unidad. Los siguientes términos son usados cuando se habla de operaciones en bloque de dispositivos de disco.
Página 78 de 283
Término
Descripción
Sector
Es una subdivisión direccionable de una pista utilizada para grabar un bloque de un programa o dato. En un disco, este es un bloque contiguo de tamaño fijo. Cada sector es de 512 bytes.
Pista
Es una vuelta circular en la superficie de un disco en la que la información es grabada y desde la cual se lee la información grabada; un conjunto contiguo de sectores. Una pista corresponde al área superficial de cada bandeja que es barrida por una cabeza mientras esta permanece fija.
Cabeza
Una cabeza es una parte móvil que puede leer y escribir los datos de una pista ubicada en una de las caras de una bandeja. Normalmente un disco tiene un pequeño conjunto de cabezas que se mueven de pista en pista en forma unitaria.
Cilindro
Son las pistas de un disco que pueden ser accedidas sin reposicionar las cabezas. Si un disco tiene n cabezas alineadas verticalmente, un cilindro tiene n pistas alineadas verticalmente.
a. Tiempo de acceso del disco Los tres componentes que definen el tiempo de acceso de un disco son definidos en la siguiente tabla:
Latencia
Descripción
De búsqueda
Una búsqueda es el movimiento físico de la cabeza ubicada en el final del brazo de un disco, de una pista a otra. El tiempo de una búsqueda es el tiempo que necesita el brazo del disco para acelerar, viajar sobre las pistas que se deben evitar, hasta desacelerar y finalmente asentarse y esperar que finalicen las vibraciones mientras ronda sobre la pista destino. El tiempo total de la búsqueda es variable. El promedio de búsqueda es utilizado para medir las capacidades del disco.
Rotacional
Es el tiempo que el brazo del disco debe esperar mientras el disco rota debajo hasta que el sector destino se aproxima. La latencia rotacional es, para todos los propósitos prácticos excepto la lectura secuencial, una función aleatoria con valores uniformemente entre cero y el tiempo requerido para una revolución completa del disco. El promedio de latencia rotacional es tomado como el tiempo de media revolución. Para determinar la latencia promedio, se deben conocer las revoluciones por minuto del disco. Convirtiendo las revoluciones por minuto en revoluciones por segundo y dividiéndolas por 2, obtenemos el promedio de la latencia rotacional.
De transferencia
El tiempo de transferencia de datos es determinado por el tiempo que tarda en moverse el bloque de datos requerido a través del
Página 79 de 283
brazo de lectura/escritura. Es lineal con respecto al tamaño del bloque El promedio del tiempo de acceso del disco es la suma de los promedios de latencia de búsqueda y latencia rotacional más el tiempo de transferencia de datos (normalmente para un bloque de 512 bytes). El promedio de acceso del disco generalmente sobrestima el tiempo necesario para acceder al disco; un típico tiempo de acceso del disco es un 70 % del promedio.
b. Discos por bus o loop (lazo) del adaptador Las discusiones sobre rendimiento de disco, volúmenes lógicos, y file systems a veces llegan a la conclusión de que a mayor cantidad de discos, mejor el rendimiento de I/O de disco. Esto no es siempre cierto, porque hay un límite en cuanto a la cantidad de datos que pueden ser manejados por un adaptador de disco, que puede convertirse en un cuello de botella. Si todos los discos están conectados a un adaptador, y los file systems más activos están en volúmenes físicos separados, será beneficioso utilizar múltiples adaptadores de disco. La mejora del rendimiento dependerá del tipo de acceso. Utilizar la cantidad apropiada de discos por adaptador es esencial. Para adaptadores SCSI y SSA la cantidad máxima de discos por bus o loop no debe exceder de cuatro si es necesario el máximo rendimiento y pueden ser utilizados por las aplicaciones. Para los SCSI el factor limitante es el bus, y para los SSA es el adaptador. El punto más importante en el rendimiento de los discos es normalmente relativo a la aplicación; esto es, gran cantidad de accesos pequeños (aleatorio), o pequeña cantidad de accesos grandes (secuencial). Para el acceso aleatorio, el rendimiento generalmente será mejor utilizando una gran cantidad de discos pequeños. La situación opuesta es para los accesos secuenciales (conviene utilizar discos rápidos o striping con una gran cantidad de discos)
c. Buffers físicos de disco El Logical Volume Manager (LVM) utiliza un término denominado pbuf para controlar I/O a disco pendiente. Un pbuf es utilizado para cada requerimiento de I/O, independientemente de la cantidad de páginas involucradas. El AIX crea pbufs extra cuando un nuevo volumen físico es agregado al sistema. Cuando se utiliza striping, son necesarios más pbufs porque una operación de I/O provoca operaciones de I/O para más discos y, por lo tanto, más pbufs. Cuando striping y espejado es utilizado, aún más pbufs son requeridos. Quedarse sin pbufs reduce el rendimiento considerablemente porque los procesos de I/O son suspendidos hasta que los pbufs estén disponibles nuevamente. Se puede incrementar la cantidad de pbufs con el comando vmtune; sin embargo, los pbufs son abrochados (pinned), de manera que asignar muchos pbufs incrementa el uso de la memoria. Se le debe dar una atención especial al hecho de ajustar la cantidad de buffers físicos en sistemas con muchos discos conectados o disponibles con el comando vmtune. La cantidad de buffers físicos (pbufs) por disco activo debe ser el doble del tamaño de la cola del disco o 32, cualquiera de ambos es mayor. La cantidad máxima de pbufs por defecto no debe superar un total de 65536. El siguiente script extrae la información de cada disco y calcula una recomendación para configurar el flag –b del vmtune (hd_pbuf_cnt). El script no tiene en cuenta los múltiples pdisks o hdisks de los SSA utilizando vpath. Utiliza el algoritmo que se ve a continuación.
Nota: El siguiente script no puede ser utilizado en discos con múltiples conexiones. 1 #!/bin/ksh 2 integer max_pbuf_count=65535 3 integer hd_pbuf_cnt=128 4 integer current_hd_pbuf_cnt=$(vmtune |awk 'BEGIN{count=0}count=="1"{print
Página 80 de 283
$6;exit} /hd_pbuf_cnt/{count=1}') 5 lsdev -Cc disk -Fname| 6 while read disk;do 7 integer queue_depth=$(lsattr -El $disk -aqueue_depth -Fvalue) 8 ((pbuf_to_add=queue_depth*2)) 9 if (( pbuf_to_add < 32));then 10 pbuf_to_add=32 11 fi 12 if (( (hd_pbuf_cnt+pbuf_to_add) > max_pbuf_count));then 13 ((pbuf_to_add=max_pbuf_count-hd_pbuf_cnt)) 14 fi 15 ((hd_pbuf_cnt+=pbuf_to_add)) 16 done 17 if (( current_hd_pbuf_cnt < hd_pbuf_cnt ));then 18 print "Run vmtune -B$hd_pbuf_cnt to change from $current_hd_pbuf_cnt to $hd_pbuf_cnt" 19 else 20 print "The current hd_pbuf_cnt ($current_hd_pbuf_cnt) is OK" 21 fi
El siguiente algoritmo es utilizado para configurar los pbufs: max_pbuf_count = 65535 hd_pbuf_cnt 128 for each disk { pbuf_to_add = queue_depth * 2 if ( pbuf_to_add < 32) pbuf_to_add = 32 if ( (hd_pbuf_cnt + pbuf_to_add) > max_pbuf_count) pbuf_to_add = max_pbuf_count - hd_pbuf_cnt hd_pbuf_cnt += pbuf_to_add }
Nótese que hay más buffers de los que puedan necesitarse incrementar en un gran sistema servidor. En un gran sistema servidor siempre se debe monitorear la utilización con el comando vmtune y ajustar los valores apropiadamente. Nótese que los buffers de file systems para LVM requieren que el cambio sea realizado antes de que el file system esté montado.
4.1.3.5 Conceptos del Logical Volume Manager (LVM) Muchos sistemas operativos UNIX modernos implementan el concepto de un Logical Volume Manager (LVM) que puede ser usado para manejar lógicamente la distribución de los datos en los dispositivos de disco físicos. El LVM del AIX es un conjunto de comandos del sistema operativo, subrutinas de librerías y otras herramientas utilizadas para controlar los recursos de discos físicos brindando una visión lógica simplificada del espacio de almacenamiento disponible. A diferencia de otros LVM, el LVM del AIX es una parte integrada en el sistema operativo básico provisto sin costo adicional. Dentro del LVM, cada disco o volumen físico (Physical Volume o PV) pertenece a un grupo de volúmenes (Volume Group o VG). Un grupo de volúmenes es una colección de 1 a 32 volúmenes físicos (1 a 128 en el caso de un grupo de volúmenes grande o Big Volume Group), que pueden variar en capacidad y rendimiento. Un volumen físico puede pertenecer a un solo grupo de volúmenes. Un máximo de 255 grupos de volúmenes puede definirse en un sistema. Cuando un grupo de volúmenes es creado, los volúmenes físicos dentro del grupo de volúmenes son particionados en unidades contiguas de igual tamaño conocidas como particiones físicas (Physical Partitions o PP). Las particiones físicas son las unidades de espacio de almacenamiento asignable más pequeñas de un grupo de volúmenes. La partición física es determinada durante la creación del grupo de volúmenes, y todos los volúmenes físicos que son asignados al grupo de
Página 81 de 283
volúmenes heredan ese tamaño. El tamaño de las particiones físicas puede ser desde 1 MB hasta 1024 MB, pero debe ser potencia de 2. Si no es especificado, el tamaño por defecto es 4 MB para discos de hasta 4 GB, pero debe ser mas grande para discos mayores a 4 GB, debido a que el LVM, por defecto, sólo acepta hasta 1016 particiones físicas por disco (a menos que se utilice la opción –t del comando mkvg, lo que reduce la cantidad máxima de volúmenes físicos en el grupo de volúmenes). En AIX 5L Versión 5.1, el tamaño de PP mínimo necesario es calculado por el sistema operativo si se especifica el valor por defecto de 4 MB.
4.1.4 Rendimiento de red La optimización de la utilización de la red es una tarea compleja y a veces muy dificultosa. Es necesario conocer como se comunican las aplicaciones y como trabajan los protocolos de red en AIX y otros sistemas implicados en la comunicación. La única recomendación general para la optimización de red es que deben usarse las opciones de red específicas de interfases (Interface Specific Network Options o ISNO) y la utilización de los buffers debe ser monitoreada. Es necesario conocer la topología de red utilizada para entender y detectar posibles cuellos de botella en la red. Esto incluye información sobre los routers y gateways utilizados, la unidad de transferencia máxima (Maximum Transfer Unit o MTU) utilizada por los sistemas en la red, y la carga actual de las redes utilizadas. Esta información debe estar bien documentada, y el acceso a esta documentación disponible en todo momento. AIX ofrece una amplia variedad de herramientas para monitorear redes, adaptadores de red, interfases de red, y recursos del sistema utilizados por el software de red. Se pueden utilizar estas herramientas para obtener información sobre el entorno de red cuando todo funciona correctamente. Esta información será muy útil en la caso de que aparezca un problema de rendimiento, porque la comparación entre la información monitoreada antes y después de la aparición del problema ayuda a detectar el origen del problema. La información recolectada debe incluir: •
•
•
•
Información de configuración del servidor y de los sistemas cliente Un cambio en la configuración puede ser la causa de un problema de rendimiento. A veces ese cambio puede ser realizado por accidente y encontrar el parámetro modificado para corregirlo puede ser muy difícil. El comando snap –a puede ser utilizado para recolectar las informaciones sobre la configuración del sistema. La carga del sistema servidor Un rendimiento pobre en un sistema cliente no es necesariamente un problema de red. Si en cambio, el sistema servidor se encuentra con escasez de recursos locales, como CPU o memoria, no podrá contestar los requerimientos de los clientes en el tiempo espe-rado. La herramienta perfpmr puede ser utilizada para recolectar esta información. La carga del sistema cliente La misma consideración para un sistema servidor se aplica para un sistema cliente. Una escasez de recursos local, como CPU o memoria, puede lentificar las operaciones de red del cliente. La carga en la red La red es normalmente un recurso compartido por muchos sistemas. The network usually is a resource shared by many systems. Un rendimiento pobre entre dos sistemas conectados a la red puede ser provocado por una sobrecarga de la red, y esta sobrecarga puede estar causada por otros sistemas conectados en la misma red. No hay herramientas nativas del AIX que recolecten información sobre la carga en la red misma. Sin embargo, herramientas como ping o traceroute pueden ser usadas para obtener tiempos de retorno de datos en la red. El comando ftp puede ser usado para transferir una gran cantidad de datos entre dos sistemas utilizando /dev/zero como entrada y
Página 82 de 283
/dev/null como salida, y registrar el rendimiento. Esto se realiza abriendo una conexión ftp, cambiando a modo binario y ejecutando el siguiente subcomando del ftp: put “| dd if=/dev/zero bs=32k count=10000” /dev/null
Este comando transfiere 10000 * 32 KB a través de la red. Los comandos atmstat, estat, entstat, fddistat, y tokstat pueden ser utilizados para obtener el rendimiento de una interfase de red específica. El ejemplo anterior del ftp realizando un put utilizando un dd puede ser usado. Sin el count=10000 el subcomando put del ftp correrá hasta que es interrumpido. Mientras el ftp transfiere los datos se puede utilizar la siguiente secuencia para inicializar las estadísticas de red de la interfase, esperar cien segundos y obtener las estadísticas recolectadas. •
La salida de los comandos de monitoreo de red en el servidor y el cliente La salida de los comandos debe ser parte de los datos recolectados por la herramienta perfpmr. Sin embargo, la herramienta perfpmr puede cambiar, por lo que es recomendable asegurarse que las salidas de los comandos netstat y nfsstat estén incluidas.
4.1.4.1 Protocolos TCP/IP Para interpretar los datos generados por programas como los comandos iptrace y tcpdump, formateados por el ipreport, y resumidos con ipfilter, es necesario entender como trabajan juntos los protocolos TCPI/IP. En la siguiente tabla se ven algunos ejemplos de protocolos que corresponden a las distintas capas TCP/IP.
Capa TCP/IP
Ejemplos de protocolos
Aplicación
Telnet, FTP, SMTP, LPD
Transporte
TCP, UDP
Red Internet
IP, ICMP, IGMP, ARP, RARP
Interfase de red
Ethernet, Token-Ring, ATM, FDDI, SP Switch
Hardware
Red física
4.1.4.2 Modificación de los parámetros de red En muchos casos es necesario ajustar algunos parámetros de red en los sistemas servidores. La mayoría de estos parámetros están relacionados con buffers de diferentes protocolos de red. Se pueden modificar los tamaños de estos buffers con el comando no o utilizar las opciones de red para interfases específicas (Interface Specific Network Options o ISNO) para cada adaptador de red. Los cambios se aplicarán para el adaptador de red especificado si se activó el ISNO con el comando no, como en el siguiente ejemplo: # no -o use_isno=1
Si en el sistema son utilizados diferentes adaptadores de red con una gran diferencia en el tamaño de MTU que utilizan (por ejemplo, adaptadores ethernet utilizando un MTU de 1500 y un adaptador
Página 83 de 283
ARM utilizando un MTU de 65527) es preferible utilizar ISNO para realizar la optimización de los parámetros de cada adaptador de red.
Nota Hay cinco parámetros ISNO por cada interfase soportada: rfc1323, tcp_nodelay, tcp_sendspace, tcp_recvspace, y tcp_mssdflt. Cuando se configuran, los valores de estos parámetros sobrescriben los parámetros con el mismo nombre que fueron configurados con el comando no. Cuando las opciones ISNO no esta configuradas para una interfase particular, son utilizadas las opciones del no. Las opciones configuradas por una aplicación para un socket particular utilizando la subrutina setsockopt sobrescriben las opciones del no e ISNO. Es recomendable documentar los valores existentes antes de realizar los cambios, especialmente si se utiliza ISNO. El siguiente ejemplo muestra como usar el comando lsattr para revisar los valores actuales para una interfase de red, en este caso token-ring: # lsattr -H -El tr0 -F"attribute value" attribute value mtu mtu_4 mtu_16 mtu_100 remmtu netaddr state arp allcast hwloop netmask security authority broadcast netaddr6 alias6 prefixlen alias4
1492 1492 1492 1492 576 10.3.2.164 up on on off 255.255.255.0 none
La parte de la salida remarcada en negrita indica las opciones ISNO. Antes de aplicar los ajustes ISNO a las interfases con el comando chdev, se puede usar el comando ifconfig. De esta manera, y si por alguna razón se deben restaurar los valores existentes y no se puede ingresar al sistema (log in), los valores no serán permanentes y no serán activados en el próximo reinicio. Por esta razón no es recomendable configurar los valores ISNO utilizando el ifconfig en cualquier script que sea ejecutado por init.
4.1.4.3 Optimización de los buffers de red Los siguientes valores demostraron entregar el mejor rendimiento. Una regla general es configurar los buffers TCP con un tamaño 10 veces mayor que el tamaño MTU, pero como se puede ver en la tabla, esto no es siempre cierto en todos los tipos de red.
Si una aplicación envía sólo una pequeña cantidad de datos y luego espera una respuesta, el rendimiento puede degradarse si los buffers tcp recvspace son muy grandes, especialmente cuando se utiliza un MTU de gran tamaño. Será necesario ajustar nuevamente los tamaños o desactivar el algoritmo Nagle configurando tcp_nagle_limit=0.
4.2 Herramientas de rendimiento de CPU y memoria En esta sección vamos a revisar varias herramientas que ayudan a determinar problemas de rendimiento de CPU y memoria. Los ejemplos ayudarán a elegir que herramienta utilizar dependiendo del caso.
4.2.1 El comando sar El comando sar (System Activity Report) puede ser utilizado de dos maneras: una es viendo los datos del sistema en tiempo real, la otra es viendo datos capturados con anterioridad. El comando sar es una de las primeras herramientas a ser usada por un administrador. Aunque el comando sar entrega información interesante a cerca de muchas funciones del sistema, se debe tener en cuenta que otras herramientas entregan reportes de utilización del sistema de manera mas exacta, en algunos puntos específicos del entorno.
4.2.1.1 Ejemplos del uso del comando sar El comando sar sin parámetros, entrega una salida con todas línea del día del archivo que fue llenado por el comando sa1.
Página 85 de 283
La cantidad de tiempo puede ser configurada en el archivo crontab, y en el siguiente ejemplo, utiliza la cantidad de tiempo por defecto del archivo /var/spool/cron/crontabs/adm: # sar 08:00:00 08:20:00 08:40:00 09:00:00 Average
%usr 0 0 0 0
%sys 0 0 0 0
%wio 0 0 0 0
%idle 100 100 100 100
El comando sar, utilizando como parámetro sólo intervalos y cantidades, muestra la siguiente salida. Es lo mismo que correr sar -u 1 10. El 1 especifica el intervalo en segundos, y el 10 especifica el número de veces que se captura información. # sar 1 10 AIX server2 3 4 000FA17D4C00 06/30/00 09:14:57 09:14:58 09:14:59 09:15:00 09:15:01 09:15:02 09:15:03 09:15:04 09:15:05 09:15:06 09:15:07
El comando sar -a reporta el uso de las rutinas del sistema para acceso a archivos, especificando cuantas veces por segundo fueron llamadas algunas de las rutinas para acceso a archivos. # sar -a 1 10 AIX server2 3 4 000FA17D4C00 06/30/00 09:28:44 09:28:45 09:28:46 09:28:47 09:28:48 09:28:49 09:28:50 09:28:51 09:28:52 09:28:53 09:28:54
El comando sar -d lee la actividad de disco con promedios de lectura, escritura y block size. Este flag no está documentado en los manuales de AIX, pero es utilizado por algunos gurúes del AIX. Es preferible utilizar el iostat en lugar del sar -d. # sar -d 5 3 AIX server2 3 4 000FA17D4C00 06/30/00 10:08:19 10:08:24 10:08:29 10:08:34
El comando sar -v reporta el estado de los procesos, kernel-thread, i-nodos, y tablas de archivos. # sar -v 1 5 AIX server2 3 4 000FA17D4C00 000FA17D4C00 06/30/00 11:12:39 11:12:40 11:12:41 11:12:42 11:12:43 11:12:44
El comando sar -y reporta la actividad por segundo de dispositivos TTY. # sar -y 1 10 AIX server2 3 4 000FA17D4C00 000FA17D4C00 06/30/00 11:48:36 11:48:37 11:48:38 11:48:39 11:48:40 11:48:41 11:48:42 11:48:43 11:48:44 11:48:45 11:48:46
rawch/s 0 0 0 0 0 0 0 0 0 0
canch/s 0 0 0 0 0 0 0 0 0 0
outch/s 104 58 58 58 58 58 58 58 58 58
rcvin/s 63 9 69 68 69 68 69 25 42 68
xmtin/s 60 60 61 60 3 52 60 60 23 9
mdmin/s 0 0 0 0 0 0 0 0 0 0
0
0
63
55
45
0
Average
Aunque esta no es una lista exhaustiva del comando sar y sus salidas, es un indicador de sus principales funcionalidades. Cuando se corre el comando sar una combinación de parámetros puede ser utilizada para obtener una salida necesaria para el análisis. Por ejemplo: # sar -y -r 1 5 AIX server2 3 4 000FA17D4C00 000FA17D4C00 06/30/00 11:48:56
rawch/s slots
canch/s cycle/s
outch/s fault/s
rcvin/s odio/s
xmtin/s
mdmin/s
11:48:57
0 130767
0 0.00
147 3.96
67 0.00
3
0
11:48:58
0 130767
0 0.00
102 0.00
69 0.00
58
0
11:48:59
0 130767
0 0.00
102 0.00
68 0.00
60
0
11:49:00
0 130767
0 0.00
102 0.00
69 0.00
17
0
11:49:01
0 130767
0 0.00
102 1.00
68 4.00
3
0
0 130767
0 0
111 1
68 1
28
0
Average Average
Página 88 de 283
4.2.1.2 Sumario del comando sar El comando sar escribe el contenido de contadores acumulativos de actividad del sistema operativo a la standard output. La sintaxis del comando sar es la siguiente: sar [ { -A | [ -a ] [ -b ] [ -c ] [ -k ] [ -m ] [ -q ] [ -r ] [ -u ] [ -v ] [ -w ] [ -y ] } ] [ -P IdentificadorDelProcesador , ... | ALL ] [ -ehh [ :mm [:ss ] ] ] [ -fArchivo ] [ -iSegundos ] [ -oArchivo ] [ -shh [ :mm [ :ss ] ] ] [ Intervalo [ Número ] ]
El sistema de contadores (accounting system), está basado en los valores de los parámetros intervalo y número , escribe la información en los intervalos en segundos y el número de veces especificado. El intervalo por defecto del parámetro Número es 1 segundo. Los datos recolectados pueden ser grabados en un archivo especificado por el flag -o archivo . Si la utilización de CPU es cercana al 100 por ciento (user + system), la carga de trabajo mostrada es dedicada a CPU. Si un porcentaje de tiempo considerable es utilizado en I/O wait, esto implica que la ejecución de la CPU está bloqueada mientras espera un I/O a disco- El I/O puede ser por acceso a archivos o puede estar asociado al paginado, debido a cierta escasez de memoria.
Nota El tiempo que el sistema desperdicia esperando el acceso a un archivo remoto no se acumula en el tiempo de I/O wait. Si la utilización de CPU y el tiempo de I/O wait para una tarea es relativamente bajo, el tiempo de respuesta no es satisfactorio, es recomendable investigar cuanto tiempo es desperdiciado en I/O remoto. Dado que no hay comandos de alto nivel que provean estadísticas de I/O wait remoto, realizar un trace de datos es lo más aconsejable para observar la actividad. El comando sar llama a un comando denominado sadc para acceder a los datos del sistema. Dos shell scripts, /usr/lib/sa/sa1 y /usr/lib/sa/sa2, son estructurados para correr con el comando cron y proveer estadísticas y reportes. Algunos ejemplos son provistos (comentados) en el archivo del crontab /var/spool/cron/crontabs/adm para especificar cuando el deamon del cron debe correr esos scripts. Recolectar la información del sistema de esta manera es sumamente útil para caracterizar el uso del sistema en un período de tiempo, y determinar las horas pico en cuanto a la utilización.
Nota El comando sar por sí mismo puede generar una considerable cantidad de lecturas y escrituras, dependiendo de los intervalos en que corra. Es recomendable correr el comando sar sin carga para calcular la influencia del sar en los resultados finales.
4.2.1.3 El comando sadc El comando sadc entrega un reporte del recolector de datos del sistema. La sintaxis del comando sadc es la siguiente: sadc [ Intervalo Número ] [ Archivo ]
Muestra datos del sistema en un intervalo especificado en segundos (Intervalo) una cantidad especificada de veces (Número). Escribe en formato binario en el archivo especificado (Archivo) o a la standard output. Cuando intervalo y número no son especificados, será escrito un registro dummy, que es usado en el arranque del sistema para marcar el momento en que el contador arranca de 0. El comando sadc está diseñado para ser usado como backend del comando sar. AIX contiene un número de contadores que aumentan a medida que ocurren varias acciones en el
Página 89 de 283
sistema. Estas acciones incluyen: • Contadores utilizados por el sistema • Contadores utilizados por el buffer • Contadores de actividad de I/O de disco y cinta • Contadores de actividad de dispositivos TTY • Contadores de subrutinas y switching • Contadores de accesos a archivos • Contadores de actividad de las colas • Contadores de comunicación entre procesos
4.2.1.4 Los comandos sa1 y sa2 El comando sa1 es una variante en shell del comando sadc y maneja todos los flags y parámetros de este comando. El comando sa1 recolecta y almacena datos binarios en el archivo /var/adm/sa/sa dd , donde dd es el día del mes. La sintaxis del comando sa1 es la siguiente: sa1 [ Intervalo Número ]
Los parámetros Intervalo y Número especifican que el registro debe ser escrito tantas veces (Intervalo) cada tantos segundos (Número). Si no se especifican estos parámetros, escribe un solo registro. El comando sa1 está diseñado para arrancar automáticamente con el comando cron. Si el comando sa1 no corre diariamente a través del comando cron, el comando sar muestra un mensaje sobre la inexistencia de el archivo de datos /usr/lib/sa/sa1. El comando sa2 es una variante en shell del comando sar, que escribe un reporte diario en el archivo /var/adm/sa/sardd , donde dd es el día del mes. El comando sa2 maneja todos los flags y parámetros del comando sar. El comando sa2 está diseñado para correr automáticamente a través del comando crin y se ejecuta en forma concurrente con el comando sa1. La sintaxis del comando sa2 es la siguiente: sa2
4.2.2 El comando vmstat El comando vmstat reporta estadísticas sobre kernel threads, memoria virtual, disco, traps, y actividad de CPU. Los reportes generados por el vmstat pueden ser usados para balancear la actividad de carga del sistema. Estas estadísticas (que promedian todos los procesadores) son calculadas en promedios de valores expresados como porcentajes, y como sumas en otros casos. La sintaxis del comando vmstat es la siguiente: vmstat [ -f ] [ -i ] [ -s ] [ VolumenFísico ] [ Intervalo [ Número ] ]
Si el comando vmstat es invocado sin utilizar flags, el reporte contiene un sumario de la actividad desde el reinicio del sistema. Si el flag –f es especificado, el comando vmstat reporta el número de forks desde el reinicio del sistema. El parámetro VolumenFísico especifica el nombre el volumen físico. Un ejemplo del comando vmstat sin flags: # vmstat kthr memory page faults cpu ----- ----------- ------------------------ ------------ -----------
Página 90 de 283
r b avm 0 0 15982
fre 1388 1388
re 0
pi 0
po 0
fr 8
sr 22
cy in 0 113
sy 281 281
cs us sy id wa 36 1 0 98 1
Este es un ejemplo del comando vmstat con el flag -f: # vmstat -f 51881 forks
El parámetro Intervalo especifica la cantidad de tiempo en segundos entre cada reporte. El primer reporte contiene un promedio de las estadísticas desde que se reinició el sistema. Los siguientes reportes contienen estadísticas recolectadas durante el intervalo de tiempo desde el reporte anterior. Si el parámetro Intervalo no es especificado, el comando vmstat genera un solo reporte y termina. El parámetro Número sólo puede ser especificado con el parámetro Intervalo . Si el parámetro Número es especificado, su valor determina la cantidad de reportes generados y en segundos, la frecuencia en que se recolectan datos. Si el parámetro Intervalo es especificado sin el parámetro Número , los reportes son generados continuamente. Un parámetro Número igual a 0 no es permitido. El siguiente es un ejemplo del comando vmstat con los parámetros Intervalo y Número : # vmstat 1 5 kthr memory page faults cpu ----- ----------- ------------------------ ------------ ----------r b avm fre re pi po fr sr cy in sy cs us sy id wa 0 0 15982 1388 1388 0 0 0 8 22 0 113 281 281 36 1 0 98 1 0 0 15982 1387 1387 0 0 0 0 0 0 108 4194 31 31 2 3 95 0 0 0 15982 1387 0 0 0 0 0 0 109 286 30 0 0 99 0 0 0 15982 1387 0 0 0 0 0 0 108 285 26 0 0 99 0 0 0 15982 1387 0 0 0 0 0 0 111 286 32 0 0 99 0
El kernel mantiene estadísticas de kernel threads, paginado, y actividad de interrupciones, a las que el comando vmstat accede a través del uso de la subrutina knlist y el pseudo-controlador de dispositivos /dev/kmem. Las estadísticas de I/O de disco son mantenidas por controladores de dispositivos. Para discos, el promedio de la tasa de transferencia es determinada utilizando el tiempo activo y la información sobre la cantidad de transferencia. El porcentaje de tiempo activo se obtiene computando la cantidad de tiempo que el disco esta ocupado durante el reporte. La sintaxis del comando vmstat con información adicional referida a un disco en particular es la siguiente: # vmstat hdisk1 kthr memory page faults cpu disk xfer ----- ----------- ------------------------ ------------ ----------- ----------r b avm fre re pi po fr sr cy in sy cs us sy id wa 1 2 3 4 0 0 16273 8385 0 0 0 9 22 0 115 284 39 1 1 98 1 0
Este es el significado de cada columna: kthr
Cambios de estado de los threads del kernel por segundo dentro del intervalo de muestreo. -r
Cantidad de threads del kernel puestos en la cola de ejecución.
-b
Cantidad de threads del kernel puestos en la cola de espera (esperando recursos, esperando una operación de entrada o salida)
Memory - avm
Información sobre el uso de la memoria virtual y real. Las páginas virtuales son consideradas activas si están asignadas. Una página tiene 4096 bytes. Páginas virtuales activas. Cuando un proceso se ejecuta necesita algo de memoria
Página 91 de 283
como espacio de trabajo, esta se asigna en los dispositivos de paginado. Esto puede ser utilizado para calcular la cantidad de espacio de paginado asignado a procesos en ejecución. El número en el campo avm divido por 256 resulta el número de megabytes (MB), en todo el sistema, asignados en el espacio de paginado. El comando lsps -a también provee información individual de cada espacio de paginado. Es recomendable que se configure suficiente espacio de paginado en el sistema de manera que la cantidad utilizada no se aproxime a un 100 por ciento. Cuando en los dispositivos de paginado quedan menos de 128 páginas no asignadas, el sistema comienza a matar procesos para liberar el espacio de paginado. - fre
Tamaño de la lista FREE. El sistema mantiene un buffer de memoria, llamado lista FREE, que será fácilmente accesible cuando el VMM necesite espacio. El espacio nominal de la lista FREE varía dependiendo de la cantidad de memoria real instalada. En sistemas con 64 MB de memoria o más, el valor mínimo (MINFREE) es 120 frames. Para sistemas con menos de 64 MB, el valor es dos veces el número de MB de memoria real, menos 8. Por ejemplo, un sistema con 32 MB tendrá un valor para MINFREE de 56 FREE frames. Los límites MINFREE y MAXFREE pueden verse y modificarse con el comando vmtune.
Nota Una gran parte de la memoria real es utilizada como cache de datos de file systems. No es inusual que la lista FREE sea pequeña. Page
Información sobre la actividad de paginado. Se promedia sobre el intervalo y se presenta en unidades por segundo.
- re
Lista de entrada/salida del paginador.
- pi
Páginas tomadas del espacio de paginado.
- po
Páginas enviadas al espacio de paginado.
- fr
Páginas liberadas (reemplazo de páginas).
- sr
Páginas revisadas por el algoritmo de reemplazo de páginas
- cy
Clock cycles by page-replacement algorithm.
.
Faults
Tasas porcentuales de interrupciones por segundo sobre el intervalo de muestra.
- in
Interrupciones de dispositivos.
- sy
Llamadas del sistema (system calls).
- cs
Kernel thread context switches.
CPU
Porcentaje de uso del tiempo de CPU. - us
Tiempo de usuario.
- sy
Tiempo de sistema.
Página 92 de 283
- id
Tiempo inactivo (idle).
- wa
Ciclos de CPU utilizados para determinar que el proceso está en espera y tiene pendiente una entrada/salida a disco.
Disk xfer
Provee el número de transferencias por segundo para el volumen físico especificado que ocurren durante el intervalo analizado. El parámetro VolúmenFísico puede ser utilizado para especificar de uno a cuatro nombres. Las estadísticas de transferencias son mostradas para cada disco especificado, en el orden especificado. El resultado muestra la cantidad de requerimientos al dispositivo físico. Esto no implica una cantidad determinada de datos que haya sido leído o grabado. Varios requerimientos lógicos pueden ser combinados en un requerimiento físico.
El comando vmstat, utilizando el flag -s, escribe a la standard output el contenido de la estructura sum, que contiene una cuenta absoluta de los eventos de paginado desde el reinicio del sistema. La opción -s está fuera de todas las otras opciones del comando. El siguiente es un ejemplo del comando vmstat utilizando el flag -s: # vmstat -s 8765020 4832918 2989263 19 7 0 5417148 12633 15031850 118 6086090 105808 0 0 0 2025516 3031667 3031667 24786000 77240518 0 0 191650677
total address trans. faults page ins page outs paging space page ins paging space page outs total reclaims zero filled pages faults executable filled pages faults pages examined by clock revolutions of the clock hand pages freed by the clock backtracks lock misses FREE frame waits extend XPT waits pending I/O waits start I/Os iodones cpu context switches device interrupts software interrupts traps syscalls
En los siguientes ejemplos, se muestra un sistema idle, y luego se empezará a darle carga; el resultado será analizado para investigar potenciales problemas. La siguiente es una salida del comando vmstat en un sistema sin carga: # vmstat 1 5 kthr memory page faults cpu ----- ----------- ------------------------ ------------ ----------r b avm fre re pi po fr sr cy in sy cs us sy id wa 0 0 16057 1291 1291 0 0 0 8 22 0 113 281 281 36 1 0 98 1 0 0 16057 1290 0 0 0 0 0 0 108 472 25 0 0 99 0 0 0 16057 1290 0 0 0 0 0 0 109 282 32 0 0 99 0 0 0 16057 1290 0 0 0 0 0 0 109 285 26 0 0 99 0 0 0 16057 1290 0 0 0 0 0 0 108 282 29 0 0 99 0
Página 93 de 283
La primera línea muestra el promedio desde el reinicio del sistema y puede dejarse de lado cuando se calcula la carga del sistema. El comando vmstat, sólo con los parámetros Intervalo y Número : # vmstat 1 15 kthr memory page faults cpu ----- ----------- ------------------------ ------------ ----------r b avm fre re pi po fr sr cy in sy cs us sy id wa 0 0 16299 1749 1749 0 0 0 8 21 0 113 281 281 36 1 0 98 1 1 1 16299 1529 0 0 0 0 0 0 301 8707 382 52 13 0 35 1 1 16299 1398 0 0 0 0 0 0 185 6557 238 91 8 0 1 1 1 16299 1227 0 0 0 0 0 0 225 6705 257 85 15 0 0 1 0 16299 1049 0 0 0 0 0 0 246 6587 334 71 10 0 19 1 1 16299 861 0 0 0 0 0 0 250 9051 317 72 19 0 9 0 1 16265 653 0 0 0 0 0 0 342 10304 516 37 21 0 43 4 0 16284 121 0 0 0 16 35 0 253 2432 375 36 6 43 15 0 0 16284 120 0 0 0 432 1066 0 265 302 246 31 4 54 11 1 0 16284 121 0 0 0 160 389 0 221 1184 239 8 5 77 10 0 1 16284 120 0 0 0 576 1447 0 394 2377 525 28 9 39 24 0 0 16284 122 0 0 0 232 480 0 277 1185 346 21 5 63 11 0 0 16284 122 0 0 0 384 1630 0 326 1081 400 16 12 51 21 0 0 16284 126 0 0 0 336 784 0 284 742 326 20 3 59 18 0 1 16284 126 0 0 0 761 1615 0 336 1032 420 36 4 48 12
Como se puede ver, las salidas de kthr (kernel thread), r (runnable threads), y b (waiting threads) se mantienen relativamente bajas y constantes. La columna r thread debe ser menor a 5 durante una carga de trabajo estable. Normalmente, el valor b debe permanecer cercano a cero. En la columna memory, el avm (average paging space memory o promedio de memoria del espacio de paginado) se mantiene relativamente estable, pero el valor fre (FREE memory frames) cayó de 1749 a un mínimo de 120. Si el valor fre se mantiene debajo de 120 durante un extenso período de tiempo, el sistema estará continuamente paginando, lo que supone problemas en el rendimiento del sistema. Para el área page, los valores de re, pi, po, y cy se mantienen relativamente constantes. Sin embargo, los valores de fr y sr, aumentaron substancialmente. El valor pi no debe ir más allá de cinco; sin embargo si un ocurre un page-in, necesariamente debería haber ocurrido previamente un page-out de esa página. Así también en un entorno con disponibilidad de memoria muy ajustada, cada page-in forzará un page out. Si el sistema esta tomando un importante número de páginas persistentes, se deberá ver un incremento en po, sin correspondientes incrementos en pi. Esta situación no indica necesariamente thrashing, pero obliga a investigar en los patrones de acceso a datos de las aplicaciones. La columna fr representa el número de páginas liberadas (FREE rate) y la columna sr representa el número de páginas revisadas (scan rate) por el algoritmo de reemplazo de páginas. Con memoria estable no fragmentada, sr y fr debe ser casi iguales. En sistemas con procesos múltiples utilizando muchas páginas diferentes, la páginas son mas volátiles y disjuntas. En este escenario, sr debería ser considerablemente superior a fr. Para la columna faults, los valores in, sy y cs fluctúan en diferentes intervalos. No hay un límite preciso para estos valores, y es difícil decir cuánto es excesivo. Lo único que se puede recordar es que el valor in siempre va a ser mayor a 100. Para la columna de cpu, los valores us, sy, id y wa también fluctúan en forma dramática. La salida es un porcentaje de la utilización de CPU. La columna us es el tiempo utilizado por un proceso ejecutando funciones que no utilizan recursos de sistema (kernel). La columna sy detalla la cantidad de tiempo que un proceso consume utilizando recursos de sistema (kernel). Un uso óptimo tendrá la CPU trabajando un cien por ciento del tiempo. Esto es verdadero en el caso de un sistema mono-usuario que no necesita compartir CPU. Generalmente, si el tiempo de us + sy está
Página 94 de 283
debajo del 90 por ciento, un sistema mono-usuario no es considerado saturado en CPU. Sin embargo, si el tiempo us + sy en un sistema multi-usuario supera supera el 80 por ciento, los procesos deberán perder tiempo esperando en la cola de ejecución (run queue). El tiempo de respuesta y el rendimiento en general se verá afectado. La columna id es el tiempo de CPU idle (no utilizado). La columna wa es tiempo idle con I/O de disco local pendiente. Un valor de wa superior al 40 por ciento podría indicar que el subsistema de discos no está balanceado apropiadamente, o puede ser el resultado de una gran carga de trabajo sobre disco. Los cuatro valores sumados deberán dar una utilización de CPU del 100 por ciento.
4.2.3 El comando ps En esta sección se verán los siguientes temas: • Uso del comando ps para estudiar la utilización de CPU • Use del comando ps para estudiar la utilización de memoria El comando ps determina que procesos están corriendo y los recursos que utilizan.
4.2.3.1 Uso del comando ps para estudiar la utilización de CPU Estas son las tres columnas del comando ps que reportan utilización de CPU, cada una en forma diferente.
Columna C
Valor
TIME
Tiempo total de CPU usado por el proceso desde que comenzó
%CPU
Tiempo total de CPU usado por el proceso desde que comenzó, dividido por el tiempo transcurrido. Esta es una medida de la demanda de CPU del programa.
Tiempo de CPU utilizado recientemente por proceso.
a. La columna C La columna C puede ser generada por el flag -l y el flag –f. En esta columna, es reportada la utilización de CPU de procesos o threads. El valor es incrementado cada vez que el reloj del sistema avanza (tick) y el proceso o thread es encontrado corriendo. Por lo tanto, se puede decir que es una penalidad por utilización reciente de CPU. A su vez, en cada segundo que el proceso no utiliza CPU, este valor es reducido por el scheduler dividiéndolo por 2. Valores grandes indican un proceso con uso intensivo de CPU y resultan con menor prioridad mientras que valores pequeños indican un proceso con uso intensivo de I/O y por lo tanto con una prioridad más favorable. En el siguiente ejemplo, tctestprog es un programa con uso intensivo de CPU. Otro aspecto del comando ps es el ordenamiento de la salida. En este ejemplo, por medio de los comando sort la salida es ordenada según la tercer columna, con los valores mas grandes al principio, y muestra sólo las primeras cinco líneas de la salida (comando head). # ps -ef | sort +3 -r |head -n 5 C UID PID PPID STIME
Del ejemplo previo, se puede determinar que el proceso tctestprog es el que utiliza más CPU, teniendo en cuenta el valor 101 en la columna C. La siguiente salida del vmstat muestra que la CPU es utilizada cerca de un 25 por ciento por procesos usr: # vmstat 2 3 kthr memory page faults ----- ----------- ------------------------ ------------r b avm fre re pi po fr sr cy in sy cs 0 0 26468 51691 0 0 0 0 0 0 100 91 6 1 1 26468 51691 0 0 0 0 0 0 415 35918 237 1 1 26468 51691 0 0 0 0 0 0 405 70 26
cpu ----------us sy id wa 47 0 53 0 26 2 71 0 25 0 75 0
b. La columna TIME La columna TIME en la salida del comando ps es generada por todos los flags, y muestra el tiempo total de ejecución para cada proceso. En este cálculo no se tiene en cuenta cuando se inició el proceso, como se ve en el siguiente ejemplo. El mismo programa es utilizado nuevamente, y aún cuando la columna C muestra que el proceso tomo mucho tiempo de CPU, no es el proceso con valor más alto en la columna TIME: # ps -ef | sort +3 -r |head -n 5 C UID PID PPID STIME root 18802 27028 120 15:40:28 3 15:41:38 root 9298 24618 2 15:41:38 root 15782 24618 root 24618 26172 Jun 21 2 # ps -e |head -n 1 ; TIME PID TTY 4170 - 12:01 2:07 4460 1:48 3398 1:14 18802 pts/11
TTY pts/11 pts/17 pts/17 pts/17
TIME CMD 1:10 ./tctestprog 0:00 ps -ef 0:00 head -n 5 0:03 ksh
El syncd, X, y dtsession son procesos que fueron activados en el IPL; es por eso que tienen tanto tiempo acumulado en la columna TIME. Esto no implica que sean procesos con uso intensivo de CPU.
c. La columna %CPU La columna %CPU en la salida del comando ps, es generada por los flags u o v. Muestra el portentaje de tiempo de CPU que el proceso utilizó desde que inició. El valor es calculado dividiendo el tiempo de CPU que el proceso utilizó, por el tiempo transcurrido desde que inició. En un entorno de multi-procesador, el valor es también dividido por la cantidad de CPUs disponibles, porque varios threads en el mismo proceso pueden correr en diferentes CPUs al mismo tiempo. Como la base de tiempo sobre la que estos datos son calculados varía, la suma de todos los campos %CPU pueden exceder un cien por ciento. En el siguiente ejemplo, vemos dos formas de ordenar la salida. El primer caso se incluyen los procesos kproc, por ejemplo, PID 516, que es un proceso wait. El otro, con una sintaxis más compleja, excluye dichos kproc:
Página 96 de 283
# ps auxwww |head -n 5 USER PID %CPU %MEM SZ RSS TTY STAT STIME TIME COMMAND root 18802 25.0 1.0 4140 4160 pts/11 A 15:40:28 5:44 ./tctestprog root 516 25.0 5.0 8 15136 - A Jun 15 17246:34 kproc root 774 20.6 5.0 8 15136 - A Jun 15 14210:30 kproc root 1290 5.9 5.0 8 15136 - A Jun 15 4077:38 kproc # ps gu|head -n1; ps gu|egrep -v "CPU|kproc"|sort +2b -3 -n USER PID %CPU %MEM SZ RSS TTY STAT STIME TIME root 18802 25.0 1.0 4140 4160 pts/11 A 15:40:28 7:11 imnadm 12900 0.0 0.0 264 332 - A Jun 15 0:00 root 0 0.0 5.0 12 15140 - A Jun 15 4:11 root 1 0.0 0.0 692 764 - A Jun 15 0:28 root 3398 0.0 1.0 1692 2032 - A Jun 15 1:48
De esta salida, se puede determinar que el programa tctestprog, desde que se inició, utilizó un 25 por ciento de los recursos de CPU.
4.2.3.2 Uso del comando ps para estudiar la utilización de memoria El comando ps puede proveer además información muy útil sobre la utilización de memoria. En la siguiente tabla se muestran las columnas de la salida más útiles.
Columna SIZE
Valor
RSS
El tamaño del proceso en la memoria real, en unidades de 1 KB.
%MEM
El porcentaje de memoria real utilizada por el proceso
El tamaño virtual de la sección de datos del proceso en unidades de 1 KB.
a. La columna SIZE El flag v genera la columna SIZE. Este es el tamaño virtual (en el espacio de paginado), en kilobytes, de la sección de datos del proceso (mostrado como SZ por otros flags). Este valor es igual al total de páginas de segmentos de trabajo de los procesos, multiplicado por cuatro. Si varias páginas de segmentos de trabajo son enviadas al espacio de paginado, el número resultante será mas grande que la cantidad de memoria real utilizada. SIZE incluye páginas en el segmento privado y en el segmento de datos de librerías compartidas del proceso, como en el siguiente ejemplo: # ps av |sort +5 -r |head -n 5 PID TTY STAT TIME PGIN SIZE 25298 pts/10 A 0:00 0 2924 368 13160 lft0 A 0:00 17 292 27028 pts/11 A 0:00 90 292 24618 pts/17 A 0:04 318
El flag v también produce la columna RSS, como se ve en el ejemplo anterior. Es el tamaño en kilobytes de memoria real (residente) del proceso. Este número es igual a sumar las páginas de memoria de los segmentos de trabajo y los segmentos de código multiplicado por cuatro. Se debe recordar que las páginas de memoria de los segmentos de código son compartidas por todas las instancias del programa en ejecución. Es decir, si por ejemplo, tenemos 26 procesos ksh corriendo, sólo una copia del programa ejecutable ksh estará en memoria, pero el comando ps reportará el tamaño de ese segmento de código como parte del RSS de cada instancia del programa ksh. Si se quiere ordenar la salida según los valores de la columna RSS, se puede hacer lo siguiente: # ps av |sort +6 -r |head -n 5 PID TTY STAT TIME PGIN SIZE 21720 pts/1 A 0:00 1 288 27028 pts/11 A 0:00 90 292 24618 pts/17 A 0:04 318 292 15698 pts/1 A 0:00 0 196
c. La columna %MEM La columna %MEM es generada por los flags u y v. Es calculada como la suma de páginas de memoria de los segmentos de trabajo y los segmentos de código (es decir, el valor RSS) dividido por el tamaño de la memoria real de la máquina en KB, multiplicado por 100, y redondeado al número entero más cercano. Este valor intenta dar a conocer el porcentaje de memoria real utilizada por el proceso. Desafortunadamente, y tal como el RSS, tiene a exagerar el consumo de un proceso que comparte texto del programa con otros procesos. El redondeo provoca que todos los procesos que tengan valores debajo de un 0.005 se muestren con un valor de %MEM de 0.0. El siguiente es un ejemplo de la columna %MEM del comando ps: # ps au |head -n 1; ps au |egrep -v "RSS"|sort +3 -r |head -n 5 USER root root root root root
PID %CPU %MEM SZ RSS TTY STAT STIME 22750 0.0 21.0 20752 20812 pts/11 A 17:55:51 21720 0.0 1.0 484 568 pts/1 A 17:16:14 25298 0.0 0.0 3080 12 pts/10 A Jun 16 27028 0.0 0.0 488 416 pts/11 A 14:53:27 24618 0.0 0.0 488 408 pts/17 A Jun 21
TIME 0:00 0:00 0:00 0:00 0:04
COMMAND ./tctestprog2 ksh smitty ksh ksh
Se pueden combinar todas las columnas en una salida, utilizando los flags gv. Por ejemplo: # ps gv|head -n 1; ps gv|egrep -v "RSS" | sort +6b -7 -n -r |head -n 5 PID TTY STAT 15674 pts/11 A 22742 pts/11 A 10256 pts/1 A 2064 - A 1806 - A
En la siguiente lista, se explican otras columnas de los ejemplos previos:
PGIN El número de page-ins causado por page faults. Dado que todas las operaciones de I/O son clasificadas como page faults por el comando ps este es un indicador de volumen de I/O.
TSIZ El tamaño de la imagen del texto (programa compartido). Este es el tamaño de la sección de texto de un archivo ejecutable. Las páginas de la sección de texto de un programa ejecutable son llevadas a memoria cuando son tocadas, es decir, cuando son ramificadas o cargadas. Este
Página 98 de 283
número representa sólo un límite superior de la cantidad de texto que puede ser cargado. El valor TSIZ no refleja la utilización actual de memoria. Además, el TSIZ puede obtenerse ejecutando el comando dump -ov contra el programa ejecutable (por ejemplo, dump -ov /usr/bin/ls).
TRS El tamaño del conjunto de texto residente (memoria real). Este es el número de páginas de segmentos de código multiplicado por cuatro. Este número exagera la memoria usada por programas donde corren múltiples instancias. El valor TRS puede ser mayor que el valor TSIZ, dado que otras páginas pueden estar incluidas en el segmento de código, como el encabezado XCOFF y la sección del loader.
4.2.4 El comando tprof En esta sección se verán los siguientes temas: • El uso de tprof para estudios generales de rendimiento de CPU • El uso de tprof en un programa de usuario
4.2.4.1 Usando el reporte general del tprof En el sistema operativo AIX, una interrupción ocurre periódicamente para permitir que corra una rutina del kernel del tipo housekeeping (preventiva) . Esto ocurre cien veces por segundo. Cuando es invocado, el comando tprof cuenta cada una de esas interrupciones como un tick. Esta rutina del kernel graba el ID del proceso y la dirección de la instrucción en ejecución cuando ocurre la interrupción, para ser usados por el comando tprof. El comando tprof registra además si el contador de procesos está en el espacio de direcciones del kernel, del usuario o de librerías compartidas. Siempre se produce un reporte ASCII con el sufijo .all. Si no se especifica un programa, el reporte es denominado __prof.all. Si un programa es especificado, el reporte es denominado __.all. Este reporte contiene una estimación de la cantidad de CPU utilizada en cada proceso que fue ejecutado mientras el tprof monitoreaba el sistema. También contiene una estimación de la cantidad de CPU utilizada en cada uno de los tres espacios de direcciones y la cantidad de tiempo en que la CPU estuvo idle. Los archivos que contienen los reportes son generados en el directorio de trabajo. Todos los archivos creados por el comando tprof tiene como prefijo __ (dos líneas de subrayado). En el siguiente ejemplo es generado un reporte genérico: # tprof -x sleep 30 Starting Trace now Starting sleep 30 Wed Jun 28 14:58:58 2000 System: AIX server3 Node: 4 Machine: 000BC6DD4C00 Trace is done now 30.907 secs in measured interval * Samples from __trc_rpt2 * Reached second section of __trc_rpt2
En este caso, el parámetro sleep 30 indica que el comando tprof debe correr durante 30 segúndos. La columna Total en el __prof.all es útil. La primera sección indica el uso de ticks por proceso. Process
PID
TID
Total
Kernel User Shared
Other
Página 99 de 283
======= wait tctestprg tctestprg wait wait swapper prof trace syncd tprof gil gil trace sh sleep =======
Dado que cada tick es 1/100 de segundo, 30 segundos requieren un total de 3000 ticks. Sin embargo, observando la salida, hay más de 12000 ticks en total. El resultado depende del hardware; en este caso, un F50 de cuatro procesadores, entonces los ticks disponibles son calculados de la siguiente manera: Tiempo (en segundos) x Número de CPUs x 100 En la salida anterior, se puede determinar que los dos procesos tctestprg utilizan cerca de 3200 ticks cada unos, aproximadamente un 25 por ciento del total de ticks disponibles. Esto es confirmado con la salida de ps auxwww: # ps auxwww USER PID %CPU %MEM SZ root 14020 25.0 0.0 300 root 12280 25.0 0.0 300
RSS TTY STAT STIME 320 pts/1 A 15:23:55 320 pts/1 A 15:23:57
TIME 16:45 16:43
COMMAND ./tctestprg ./tctestprg
En la segunda sección del reporte general del comando tproc, se muestra la cantidad total de ticks utilizados por un tipo específico de proceso. En esta sección, la columna Total muestra la cantidad de ticks utilizados por tipo de proceso, y la columna FREQ la cantidad de procesos para cada tipo de proceso. Process ======= wait tctestprg swapper tprof trace gil syncd sh sleep ======= Total
4.2.4.2 Utilizando el tprof en un programa El comando tprof es también una herramienta muy útil para programas escritos en C, C++, o FORTRAN que tuvieran gran consumo de CPU. Identifica las secciones de un programa que
Página 100 de 283
tengan un mayor uso de CPU. El comando tprof ejecuta un programa, y luego produce una serie de archivos con reportes. Los reportes están divididos hasta un nivel de sub-rutinas. El siguiente es un ejemplo básico; hay muchas más posibilidades mas allá de este ejemplo. # tprof ./tctestprg Starting Trace now Starting ./tctestprg Wed Jun 28 15:57:35 2000 System: AIX server3 Node: 4 Machine: 000BC6DD4C00 Trace is done now 23.258 secs in measured interval * Samples from __trc_rpt2 * Reached second section of __trc_rpt2 (The tctestprg process was manually killed)
El archivo de salida es llamado __tctestprg.all, y la salida es restringida al proceso provisto como argumento del comando. La primera sección es la misma que la de los reportes generales. Sin embargo, sólo muestra un solo proceso. # more __tctestprg.all Process PID TID ======= === === ./tctestprg 16276 16081 ======= === === Total
Total Kernel User ===== ====== ==== 2156 2156 0 2156 ===== ====== ==== 2156 0 2156
Shared ====== 0 ====== 0
Other ===== 0 ===== 0
La segunda sección es un reporte trivial de un solo proceso. Process ======= ./tctestprg ======= Total
FREQ === 1 === 1
Total ===== 21 ===== 2156
Kernel ====== 0 ====== 0
User ==== 2156 ==== 2156
Shared ====== 0 ====== 0
Other ===== 0 ===== 0
La tercera sección provee información sobre las subrutinas utilizadas en el proceso especificado, y muestra información sobre las áreas que necesitan algún ajuste u optimización. Total Ticks For ./tctestprg (USER) = 2156 Subroutine Ticks % ============= ===== ==== .main 1368 14.5 .casework 788 8.4
Source ======== case.c case.c
Address ======== 10000318 10000364
Bytes ====== 4c 54
4.2.5 El comando svmon El comando svmon es utilizado para mostrar información relativa al estado actual de la memoria. A pesar de que es un comando complicado, se debe entender en qué puede ser útil a la hora de realizar un monitoreo de rendimiento. El comando svmon genera siete tipos de reporte: • Global • Usuario • Proceso • Segmento • Segmento detallado • Comando • Clase Workload Manager
Página 101 de 283
Para correr cada uno de estos reportes, debe ser usado un flag indicador del reporte. Con la excepción de los reportes de svmon -G y svmon -D, las otras opciones de reportes utilizan los mismos flags con un uso similar. En las siguientes secciones veremos un ejemplo del comando y la salida generada. Esta no es una lista exhaustiva de funciones; en realidad es una corta demostración de la versatilidad del comando svmon.
4.2.5.1 El reporte global del svmon El reporte global es generado cuando se especifica el flag –G. El comando svmon -G tiene la siguiente sintaxis: svmon -G [ -i Intervalo [ NumIntervalos]] [ -z ]
Corriendo el comando svmon -G se genera la siguiente salida: # svmon -G memory pg space pin in use
size 131063 131072
inuse 119922 305
work 6816 21791
pers 0 98131
FREE pin 11141 6807
virtual 15924
clnt 0 0
El comando svmon -G con un intervalo y un número de intervalos, y con el flag –z para obtener la memoria máxima asignada, genera la siguiente salida: # svmon -G -i1 5 -z memory pg space pin in use memory pg space pin in use memory pg space pin in use memory pg space pin
size 131063 131072
inuse 125037 305
FREE pin 6026 6811
work 6820 21950
pers 0 103087
clnt 0 0
size 131063 131072
inuse 125847 305
FREE pin 5216 6811
work 6820 21954
pers 0 103893
clnt 0 0
size 131063 131072
inuse 126769 305
FREE pin 4294 6811
work 6820 21954
pers 0 104815
clnt 0 0
size 131063 131072
inuse 127890 305
FREE pin 3173 6811
work 6820
pers 0
virtual 15948
virtual 15949
virtual 15949
virtual 15949
clnt 0
Página 102 de 283
in use memory pg space pin in use
21954
105936
0
size 131063 131072
inuse 129092 305
FREE pin 1971 6811
work 6820 21954
pers 0 107138
clnt 0 0
virtual 15949
Maximum memory allocated = 432
En el ejemplo previo, cada encabezamiento tiene el siguiente significado:
memory
Especifica estadísticas que describen el uso de la memoria real, incluyendo: - size - inuse - FREE - pin - virtual - stolen
pg space
Especifica estadísticas que describen el uso del espacio de paginado. Estos datos son generados sólo si el flag -r no es utilizado: - size - inuse
pin
Tamaño del espacio de paginado Número de páginas en uso en el espacio de paginado
Especifica estadísticas sobre el subconjunto de la memoria real que contiene páginas pinned, incluyendo: - work - pers - clnt
in use
Número de frames de memoria real (tamaño de la memoria real) Número de frames que contienen páginas Número de frames libres Número de frames que contienen páginas pinned Número de páginas asignadas en el espacio virtual del sistema Número de frames tomados por el rmss y marcados como no utilizables por el VMM
Número de frames que contienen páginas pinned de segmentos de trabajo Número de frames que contienen páginas pinned de segmentos persistentes Número de frames que contienen páginas pinned de segmentos cliente
Especifica estadísticas sobre el subconjunto de la memoria real en uso, incluyendo: - work - pers - clnt
Número de frames que contienen páginas de segmentos de trabajo Número de frames que contienen páginas de segmentos persistentes Número de frames que contienen páginas de segmentos cliente
4.2.5.2 El reporte de usuario del svmon El reporte de usuario es generado cuando se utiliza el flag -U. El comando svmon -U tiene la siguiente sintaxis:
El svmon -U sin otras opciones produce una salida similar a la siguiente: # svmon -U =========================================================== ============================== ================================================= ==================== User root Inuse Pin Pgsp Virtual 18447 1327 175 7899 ........................................................... .............................. ................................................. .................... SYSTEM segments Inuse Pin Pgsp Virtual 3816 1269 175 3535 Vsid 0 9352 220 7a0f 502a
Para chequear la utilización de un usuario en particular, así como el total de memoria asignada, utilice el siguiente comando: # svmon -U root -z =========================================================== ============================== ================================================= ==================== User root Inuse Pin Pgsp Virtual 10980 1322 175 7913 ........................................................... .............................. ................................................. .................... SYSTEM segments Inuse Pin Pgsp Virtual 3816 1269 175 3535 Vsid 0 9352 220 7a0f 502a
Los encabezamientos tienen el siguiente significado: User
Indica el nombre del usuario.
Inuse
Indica la cantidad de páginas de memoria real que son utilizadas por el usuario.
Pin
Indica la cantidad de páginas pinned en segmentos que son utilizados por el usuario.
Página 105 de 283
Pgsp
Indica la cantidad de páginas reservadas o utilizadas en el espacio de paginado por segmentos que son utilizados por el usuario. Indica la cantidad de páginas asignadas en el espacio virtual del proceso.
Virtual
Después de mostrar los encabezamientos, el svmon muestra (si el flag -d es especificado) información sobre todos los procesos que son ejecutados por el usuario especificado. Sólo contiene los encabezamientos de la columna de los procesos, como se describe en el reporte de procesos. El svmon muestra información sobre los segmentos usados por esos procesos. Este conjunto de segmentos es separado en tres categorías. 1. Los segmentos que son marcados como segmentos del sistema, que son compartidos por todos los procesos. 2. Los segmentos que son únicamente usados por el conjunto de procesos 3. Los segmentos que son compartidos entre varios usuarios Si el flag -l es especificado, entonces muestra para cada segmento en la última categoría, la lista de identificadores de procesos que utiliza el segmento. También muestra el usuario que ejecuta el identificador de proceso.
4.2.5.3 El reporte de procesos del svmon El reporte de procesos es generado cuando se especifica el flag -P. La sintaxis del comando svmon -P es la siguiente: svmon [-P [pid1...pidn] [ -u | -p | -g | -v ] [ -n | -s ] [ -w | -f | -c] [ -t Número ] [ -i Intervalo [ NumIntervalos ] ] [ -l ] [ -z ] [ -m ] ]
El reporte de procesos generado por el comando svmon -P tiene una salida similar a la siguiente: # svmon -P | pg ----------------------------------------------------------------------------------------------------------------------------------------------------------Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 11126 backbyname 32698 1266 175 4114 N N Vsid 7162 0
Esid Type Description - pers /dev/lv00:17 0 work kernel seg
8811 c373 4823
d work shared library text - pers /dev/hd3:2061 2 work process private
2969 cdb7 6d28 5920
f 3 1 -
work pers pers pers
shared library data shmat/mmap,/dev/hd2: code,/dev/hd2:10334 /dev/hd2:32166 1
-----------------------------------------------------------------------------------------------------------------------------------------------------------Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 0 3 1 0 3 N N Vsid 780f
Esid Type Description 2 work process private
Inuse 3
Pin Pgsp Virtual Addr Range 1 0 3 65338..65535
El comando svmon -P puede ser utilizado de la siguiente manera, para determinar los diez procesos que más memoria utilizan, ordenados en forma decreciente, por el total de páginas reservadas o que están siendo utilizadas: # svmon -Pv -t 10 | pg ----------------------------------------------------------------------------------------------------------------------------------------------------------Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 10294 X 6579 1275 175 4642 N N Vsid 0
Los encabezamientos tienen el siguiente significado: Pid
Indica el ID del proceso.
Command
Indica el comando que corre el proceso.
Inuse
Indica la cantidad de páginas en memoria real de segmentos que son utilizados por el proceso.
Pin
Indica el total de páginas pinned de segmentos que son utilizados por el proceso.
Pgsp
Indica el total de páginas en el espacio de paginado usadas por segmentos que son usados por el proceso. El número es reportado sólo si no se usa el flag -r.
Virtual
Indica el número de páginas asignadas en el espacio virtual del proceso.
64-bit
Indica si el proceso es un proceso de 64-bits (Y) o un proceso de 32-bits (N).
Mthrd
Indica si el proceso es multi-thread (Y) o no (N).
4.2.5.4 El reporte de segmentos del svmon El reporte de segmentos es impreso cuando se especifica el flag -S. El comando svmon -S tiene la siguiente sintaxis: svmon [-S [sid1...sidn] [ -u | -p | -g | -v ] [ -n | -s ] [ -w | -f | -c ] [ -t Número ] [ -i Intervalo [NumIntervalos ] ] [ -l ] [ -z ] [ -m ] ]
El comando svmon -S produce la siguiente salida: # svmon -S Vsid 7162 680d 0 82b0
Esid Type Description - pers /dev/lv00:17 - work misc kernel tables - work kernel seg - pers /dev/hd2:26992
Para verificar el uso de memoria de los cinco segmentos de trabajo que utilizan más cantidad de páginas virtuales, se utiliza el siguiente comando: # svmon -S -t 5 -w -v Vsid 680d
Para mostrar estadísticas del uso de memoria de segmentos, ordenadas por la cantidad de bloques de espacio de paginado reservado: # svmon -S 680d 700e -g Vsid 700e 680d
Esid Type Description - work kernel pinned heap - work misc kernel tables
Los encabezamientos tienen el siguiente significado: Vsid
Indica el ID del segmento virtual. Identifica un único segmento en el VMM.
Esid
Indica el ID del segmento efectivo. Cuando es provisto, indica como es usado el segmento por el proceso. Si el segmento VSID es mapeado por varios procesos, pero con diferentes valores de ESID, entonces este campo contiene un “-“. En ese caso, el valor exacto de ESID puede obtenerse a través de la opción -P aplicada en cada identificador de proceso que utilice el segmento.
Type
Identifica el tipo de segmento: pers indica un segmento persistente, work indica un segmento de trabajo, clnt un segmento cliente, map indica un segmento mapeado, y rmap indica un segmento mapeado de memoria real.
Description
Especifica una descripción textual del segmento. El valor de esta columna depende del tipo de segmento. Si el segmento es un segmento persistente y no está asociado con un log, entonces muestra el nombre del dispositivo y el número de i-nodo del archivo asociado, separado por dos puntos. (El nombre del dispositivo y el i-nodo puede ser traducidos a un nombre de archivo con el comando ncheck.) Si el segmento es el segmento primario de un archivo grande, entonces las palabras “large file” son anexadas a la descripción. Si el segmento es un segmento persistente y es asociados con un log, entonces muestra la palabra “log”. Si el segmento es un segmento de trabajo entonces el comando svmon intenta determinar el rol del seg-
Página 109 de 283
mento. Por ejemplo, segmentos de trabajo especiales, tales como el kernel y librerías compartidas, son reconocidas por el comando svmon. Si el segmento es el segmento de datos privado de un proceso, entonces se muestra “private”. Si el segmento es el segmento de código de un proceso, y el reporte de segmento es generado en respuesta a un flag -P, entonces la palabra “code” es anexada a la descripción. Si el segmento es mapeado por varios procesos y utilizado de diferentes formas (por ejemplo, el segmento privado de un proceso mapeado como segmento de memoria compartida por otro proceso), entonces la descripción es vacía. La descripción exacta puede ser obtenida a través del flag -P aplicado en cada identificador de proceso que utilice el segmento. Si una descripción de segmento es muy grande y no cabe dentro del espacio de descripción, entonces es truncada. La parte truncada puede obtenerse a través del flag -S (sin -l) en dicho segmento. Inuse
Indica la cantidad de páginas en memoria real en este segmento.
Pin
Indica la cantidad de páginas pinned en este segmento.
Pgsp
Indica la cantidad de páginas utilizadas en el espacio de paginado por este segmento. Este campo es relevante sólo para segmentos de trabajo.
Virtual
Indica la cantidad de páginas asignadas por el espacio virtual del segmento. (Sólo para segmentos de trabajo). El VMM maneja este valor con fines estadísticos. No puede ser actualizado. Por lo tanto, el valor puede ser menor que los contadores inuse.
Address Range
Especifica el/los rango/s en que las páginas de segmentos fueron asignadas. El segmento de trabajo puede tener dos rangos, porque las páginas son asignadas comenzando por ambos extremos y avanzando hacia el medio. Si el flag -l está presente, se muestra la lista de identificadores de proceso que utiliza dicho segmento.
4.2.5.5 El reporte detallado de segmentos del svmon El flag -D es utilizado para obtener una lista más detalla de un segmento. La sintaxis del comando svmon -D es la siguiente: svmon [-D sid1...sidn [-b] [ -i Intervalo [ NúmIntervalos] ] [ -z ] ]
Para mostrar los frames que pertenecen a un segmento el comando es como sigue: # svmon -D 700e Segid: 700e Type: working Address Range: 0..65535 Size of page space allocation: 0 pages ( 0.0 Mb) Virtual: 1920 frames ( 7.5 Mb) Inuse: 1919 frames ( 7.5 Mb) Page 65471 65535 0 1
Para mostrar los frames que pertenecen a un segmento con el bit de estado de cada frame, se debe usar el siguiente comando: # svmon -D 700e -b Segid: 700e Type: working Address Range: 0..65535 Size of page space allocation: 0 pages ( 0.0 Mb) Virtual: 1920 frames ( 7.5 Mb) Inuse: 1919 frames ( 7.5 Mb) Page Frame Pin Ref 65471 313 Y Y 65535 311 N N 0 314 Y N 1 309 Y N 2 308 Y Y 3 305 Y Y 4 296 Y N 5 299 Y N 6 294 Y N 7 297 Y N 8 292 Y N 9 295 Y N 10 290 Y N ... 381 81019 N N 380 115074 N N 379 80725 N N 3335 57367 Y N 3336 59860 Y N 3337 107421 N N 3338 114966 N N 3339 107433 N N 3341 95069 Y N 3342 70192 Y Y
Mod Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
Este es el significado de los encabezamientos. Los encabezamientos segid, type, address range, size of page space allocation, virtual e inuse fueron explicados en el capítulo anterior, “El reporte de segmentos del svmon”. Page
Número de página relativo al espacio virtual. Este número de página puede ser mayor que el número de frames en un segmento (65532) si el espacio virtual es mayor que un segmento simple (archivo grande).
Página 111 de 283
Frame
Número de frame en la memoria real.
Pin
Indica si el frame es pinned o no.
Ref
Indica si el frame ha sido referenciado por un proceso (sólo con la opción -b).
Mod
Indica si el frame ha sido modificado por un proceso (sólo con la opción -b).
4.2.5.6 El reporte de comandos del svmon El reporte de comandos provee un sumario del consumo de comandos específicos que se encuentren corriendo. El reporte de comandos es generado cuando se especifica el flag -C. La sintaxis del comando svmon -C es la siguiente: svmon [-C cmd1...cmdn [ -u | -p | -g | -v ] [ -n | -s [ -w | -f | -c ] [ -t [ -i Intervalo [ NúmIntervalos ] ] [ -d ] [ -l ] [ -z ] [ -m ] ]
Número]
Para revisar el uso de memoria de comandos específicos, utilice el siguiente comando: # svmon -C savevg ftp # pg /tmp/file =========================================================== ============================== ================================================= ==================== Command ftp Inuse Pin Pgsp Virtual 42104 1271 175 3966 ........................................................... .............................. ................................................. .................... SYSTEM segments Inuse Pin Pgsp Virtual 3798 1270 175 3517 Vsid 0
=========================================================== ============================== ================================================= ==================== Command savevg Inuse Pin Pgsp Virtual savevg *** command does not exist ***
Si un comando no tiene un segmento de memoria, se mostrará un error, como en el ejemplo anterior. Para revisar un comando y mostrar las estadísticas de memoria de dicho comando, ingrese lo siguiente:
Los encabezamientos tienen el siguiente significado: Command
Indica el nombre del comando.
Inuse
Indica la cantidad de páginas en memoria real en segmentos que son usados por el comando (todos los procesos que corren el comando).
Pin
Indica la cantidad de páginas pinned en segmentos que son usados por el comando (todos los procesos que corren el comando).
Pgsp
Indica la cantidad de páginas reservadas o utilizadas en el espacio de paginado por segmentos que son usados por el comando.
Virtual
Indica la cantidad de páginas asignadas en el espacio virtual del comando. Después de los encabezamientos, el svmon muestra (si es especificado el flag -d) información sobre los procesos que corren el comando especificado. Sólo contiene el encabezamiento de los procesos, como se describen en un reporte de procesos. El svmon muestra información sobre los segmentos usados por esos procesos. Este conjunto de segmentos es separado en tres categorías: • Los segmentos que son marcados como del sistema que son compartidos por todos los procesos • Los segmentos que son sólo usados por el conjunto de procesos. • Los segmentos que están compartidos por diferentes comandos. Si se especifica el flag -l, por cada segmento en la última categoría, se muestra la lista de identificadores de proceso que usan el segmento. También muestra el
Página 113 de 283
nombre del comando que el identificador de proceso corre.
4.2.5.7 El reporte de clase Workload Manager del svmon El reporte de clase Workload Manager es generado cuando el flag -W es especificado. El comando svmon -W tiene la siguiente sintaxis: svmon [ -W [class1...classn] [ -u | -p | - g | -v ] [ -n | -s ] [ -w | -f | -c ] [ -t Número ] [ -i Intervalo [ NúmIntervalos ] ] [ -l ] [ -z ] [ -m ] ]
Nota El comando svmon -W debe ejecutarse cuando el Workload Manager se encuentre iniciado. Para revisar las estadísticas de clase Workload Manager, ingrese el siguiente comando: # svmon -W backup ========================================================================== Superclass Inuse Pin Pgsp Virtual backup 52833 10 0 50329 Vsid 6784 1aa18 14356 173f5 5347 c34e 1891a 14636 5327 1d83f 1e33c 10772 6a84 15457 38a1 126f0 11313 e50c b549 12e3 13351 14a16 12970 6904 a9c8 2320 1d39f 834a
Esid -
Type work work pers pers work work work work work work work work work work work work pers work work work work work work work work pers pers pers
Los encabezamientos en un reporte de clase Workload Manager son los siguientes: Class
Indica el nombre de la clase workload.
Inuse
Indica la cantidad de páginas en memoria real en segmentos que pertenecen a la clase workload.
Pin
Indica la cantidad de páginas pinned en segmentos que pertenecen a la clase workload.
Página 114 de 283
Pgsp
Indica la cantidad de páginas reservadas o utilizadas en el espacio de paginado por segmentos que pertenecen a la clase workload.
Virtual
Indica la cantidad de páginas asignadas en el espacio virtual de la clase workload.
Después de los encabezamientos, el comando svmon muestra información sobre los segmentos que pertenecen a la clase workload. Si la opción –l es especificada, muestra para cada segmento la lista de identificadores de proceso que utiliza dicho segmento. También se muestra la clase workload a la que pertenece el proceso.
Nota Un proceso pertenece a la clase workload si su thread inicial pertenece a la misma.
4.2.6 El comando topas El comando topas reporta estadísticas vitales sobre la actividad en el sistema. Requiere que esté instalado en el sistema el fileset perfagent.tools de AIX Versión 4.3.3. El comando topas recibe actualizaciones todo el tiempo, por lo que es recomendable revisar la documentación de AIX para informarse sobre nuevas características. Este comando es una especie de recopilación de comandos de diagnóstico, como son sar, vmstat, iostat y netstat. Permite ver todas las estadísticas en una pantalla, por lo que es fácil observar interacciones entre ellas. El comando está dividido en cinco subsecciones de estadísticas: • EVENTS/QUEUES
Muestra los eventos globales del del sistema seleccionados y el promedio del tamaño de los thread en ejecución y las colas wait.
• FILE/TTY
Muestra las estadísticas seleccionadas de archivos y TTY.
• PAGING
Muestra estadísticas de paginado.
• MEMORY
Muestra el tamaño de la memoria real y la distribución de su uso.
• PAGING SPACE
Muestra el tamaño y la utilización del espacio de paginado.
Página 115 de 283
En la parte izquierda de la salida, hay una sección variable dividida en subsecciones. La primera muestra la utilización de CPU en números y en un gráfico de bloques: Kernel User Wait Idle
5.0 49.7 16.1 29.0
|# |############## |##### |########
| | | |
La siguiente sección muestra estadísticas de las interfases de red: Interf tr0 en0
KBPS 1.0 0.0
I-Pack 3.3 0.1
O-Pack 2.3 0.0
KB-In 0.1 0.0
KB-Out 0.9 0.0
La siguiente es la subsección de estadísticas de discos físicos: Disk hdisk0 hdisk1 hdisk2 hdisk3
Busy% 0.0 0.0 0.0 0.0
KBPS 0.0 0.0 0.0 4056.6
TPS 0.0 0.0 0.0 96.9
KB-Read 0.0 0.0 0.0 0.0
KB-Writ 0.0 0.0 0.0 4056.6
La última subsección muestra información de procesos. La captura de esta información constituye la mayor carga del comando topas: tctestprg(15752)100.0% tctestprg(13888)100.0% topas (16022) 0.5% cp (18112) 0.0% cp (15558) 0.0% cp (13662) 0.0%
PgSp: PgSp: PgSp: PgSp: PgSp: PgSp:
0.0mb 0.0mb 0.4mb 0.1mb 0.1mb 0.1mb
root root root root root root
Mientras el topas se encuentra en ejecución, acepta subcomandos de un carácter o letra. Esta es la acción de cada subcomando: a
Muestra todas las secciones variables (red, disco, y procesos) si lo permite el espacio.
Página 116 de 283
d
Muestra información de disco. Si el número requerido de discos y el número requerido de interfases de red caben en 25 líneas, ambos serán mostrados. Si además hay lugar para mostrar al menos tres procesos, todos los procesos que quepan también serán mostrados.
h
Muestra la pantalla de ayuda.
n
Muestra información sobre interfases de red. Si el número requerido de discos y el número requerido de interfases de red caben en 25 líneas, ambos serán mostrados. Si además hay lugar para mostrar al menos tres procesos, todos los procesos que quepan también serán mostrados.
p
Muestra información de procesos. Si el número requerido de procesos deja espacio libre suficiente, también serán mostradas las interfases de red, y así mismo con los discos.
q
Sale del programa
También se pueden utilizar los siguientes flags en la línea de comando: -i
Ajusta el intervalo de monitoreo en segundos. Por defecto es dos segundos.
-n
Especifica la cantidad máxima de interfases de red a ser mostradas. Si el valor especificado es cero, no se mostrará información de red.
-p
Especifica el número máximo de procesos a ser mostrados. Si el valor especificado es cero, no se mostrará información de procesos.
Se recomienda leer la última documentación para obtener una lista completa de los subcomandos y flags disponibles.
4.2.7 El comando emstat La arquitectura PowerPC no soporta más, en hardware, 35 instrucciones POWER. Para mantener la compatibilidad con binarios más viejos (que contienen esas instrucciones eliminadas), el kernel del AIX Versión 4 incluye rutinas de emulación que proveen soporte para las instrucciones eliminadas. Intentando ejecutar una instrucción eliminada resulta en una excepción a una instrucción ilegal (illegal instruction exception). El kernel decodifica la instrucción ilegal y, si es una instrucción eliminada, corre una rutina de emulación que funcionalmente emula la instrucción. El comando emstat reporta estadísticas referidas a cuantas instrucciones debe emular el sistema. El total de instrucciones emuladas debe ser utilizado para determinar si una aplicación necesita ser recompilada para eliminar instrucciones que deben ser emuladas en 601 PowerPC, 604 PowerPC, RS64, u otros procesadores no-POWER. Si una instrucción debe ser emulada, se necesitan más ciclos de CPU para ejecutarla que con una instrucción que no hace falta emular. La mayoría de los problemas de emulación son vistos en viejos sistemas PowerPC 604. Un ejemplo típico es un sistema PowerPC 601 que fue migrado a un sistema 604. Si el rendimiento empeora en lugar de mejorar, se deberá seguramente a la emulación. La solución para la emulación es recompilar la aplicación en forma común. La plataforma de arquitectura por defecto para compilar en AIX Versión 4 es la arquitectura común. Sin embargo, la arquitectura por defecto en AIX Versión 3 era para POWER, POWER2, y PowerPC 601. Si estos binarios corrían en un PowerPC 604, algunas instrucciones debían ser emuladas.
Página 117 de 283
Para determinar si el comando emstat se encuentra instalado, corra el siguiente comando: # lslpp -l bos.adt.samples
Nota En AIX 5L, el emstat comando se encuentra en el fileset perfagent.tools. El comando emstat trabaja en forma similar al comando vmstat en cuanto se debe especificar el tiempo de intervalo en segundos, y opcionalmente, la cantidad de intervalos. El valor en la primer columna es la cuenta acumulativa desde el reinicio del sistema, mientras que el valor en la segúnda columna es la cantidad de instrucciones emuladas durante el intervalo especificado. Las emulaciones en el orden de algunos miles por segundo seguramente tendrán un impacto importante en el rendimiento: # /usr/samples/kernel/emstat 2 emstat total count emstat interval count 965 965 965 0 965 0 965 0 965 0 967 2 967 0 967 0 974 7 974 0 974 0 974 0 974 0 974 0 1284 310 2171 887 3325 1154
Una vez que se detectó emulación, el paso siguiente es determinar que aplicación está emulando instrucciones. Eso es mucho más difícil de determinar. Una forma, si la instalación lo permite, es correr una aplicación a la vez y monitorear con el comando emstat.
4.3 Herramientas de rendimiento de I/O de disco En esta sección se verán los siguientes temas: • Análisis de rendimiento del Logical Volume Manager (LVM), utilizando el comando lslv. • Herramientas para el análisis del rendimiento de Journaled File System (JFS), utilizando los comandos filemon y fileplace.
4.3.1 Revisión general Con el sistema operativo AIX, el manejo del I/O de discos es basado en diferentes niveles funcionales, como se ve en la siguiente figura:
Página 118 de 283
El nivel más bajo es el nivel físico, y consiste en los controladores de dispositivos que acceden a los discos físicos y utilizan los adaptadores correspondientes. El siguiente nivel es el nivel lógico, manejado por el Logical Volume Manager (LVM), que controla los recursos de los discos físicos. El LVM provee un mapeo lógico de los recursos de disco para el nivel de aplicaciones. El nivel de aplicaciones puede consistir tanto en los Journaled File System (JFS) o dispositivos raw, por ejemplo, utilizados por sistemas de bases de datos relacionales.
4.3.2 El comando iostat El comando iostat es una herramienta sumamente útil que provee un primer indicio ante problemas de rendimiento de I/O. El comando iostat puede reportar estadísticas de CPU, de I/O de terminales, y I/O de disco, que ayudan a identificar la carga de I/O en componentes individuales como discos rígidos. La información de los reportes del iostat pueden ser utilizados para modificar la configuración del sistema para mejorar la distribución de la carga de I/O entre discos físicos. El comando iostat extrae datos de los contadores de I/O del kernel del AIX en el espacio de direcciones del kernel, que son actualizados con cada tick del reloj (1/100 de segundo) tanto para actividad de TTY como de CPU y subsistemas de I/O. La sintaxis del comando iostat es la siguiente: iostat [-d | -t] [VolumenFísico ...] [intervalo | número]
Estos son los flags comúnmente utilizados:
Flag -d -t
Descripción Este flag muestra sólo el reporte de utilización de disco. El flag -d no se puede utilizar al mismo tiempo con el flag -t. Este flag muestra sólo el uso de TTY y CPU. El flag -t no se puede utilizar al mismo tiempo con el flag -d.
Utilizando el parámetro VolumenFísico (especificando el nombre del volumen físico del disco o CDROM), el iostat genera un reporte de I/O sólo para los PVs especificados. Si se especifica ningún PV, el comando iostat genera un reporte para todos los discos. El parámetro intervalo especifica la cantidad de tiempo en segundos entre cada reporte. El parámetro número especifica la cantidad de reportes a generar. Si el parámetro intervalo es especificado sin el parámetro número, el comando iostat genera reportes continuamente en forma indefinida. El siguiente es un ejemplo del comando iostat: # iostat 1 2
Este ejemplo muestra la salida del comando iostat actualizando cada un segundo (intervalo=1) y generando sólo dos reportes (número=2). Cada reporte es una combinación de un reporte de utilización de TTY y CPU con un reporte de utilización de disco. Este ejemplo muestra un sistema con cinco discos (hdisk0-hdisk4) y un CDROM. El primer reporte muestra el sumario de estadísticas desde el reinicio del sistema, con la suma de operaciones de I/O en cada disco. Se puede determinar que el hdisk1 es el disco más activo. El segundo reporte es la utilización de disco actual, durante un intervalo de un segundo. Durante el reporte, se ejecuto un comando copy para generar actividad de I/O de disco.
4.3.2.1 El histórico de I/O de disco En AIX Versión 4.3 el sistema por defecto no recolecta un historial de la actividad de disco, dado que algunos recursos del sistema son consumidos en esta operación. El administrador del sistema debe decidir si es necesario activar el historial de I/O de disco o no.
Nota Si el historial de I/O de disco es desactivado, el comando iostat mostrará un mensaje similar al siguiente: # iostat 1 1 tty:
tin 0.0
tout avg-cpu: % user % sys % idle 41.5 61.2 0.1 38.8 " Disk history since boot not available. "
% iowait 0.0
Recolectar el histórico de I/O de disco es una característica del sistema operativo AIX que puede ser activada o desactivada en SMIT utilizando: smit chgsys. Esta es la pantalla correspondiente de SMIT:
Página 120 de 283
Cuando el histórico de I/O de disco es activado, se debe ignorar el primer reporte si se quiere ver el comportamiento del sistema en tiempo real.
4.3.2.2 Reporte de utilización de TTY y CPU La primera sección del reporte del comando iostat contiene el reporte de utilización de TTY y CPU. Este es el significado de los encabezamientos de cada columna: tin
Muestra la cantidad de caracteres leídos por segundo por todos los dispositivos TTY.
tout
Indica la cantidad de caracteres escritos por segundo a todos los dispositivos TTY.
% user
Muestra el porcentaje de utilización de CPU a nivel usuario (aplicación).
% sys . % idle
Muestra el porcentaje de utilización de CPU a nivel sistema (kernel).
% iowait
Muestra el porcentaje de tiempo idle (durante el cual el sistema no espera un requerimiento de I/O). Muestra el porcentaje de tiempo idle durante el cual el sistema se encuentra esperando un requerimiento de I/O.
Las columnas de información sobre TTY, tin y tout, muestran la cantidad de caracteres leídos y escritos por todos los dispositivos TTY. Esto incluye tanto dispositivos TTY reales como seudo dispositivos TTY. Dispositivos TTY reales son aquello conectados a un puerto asincrónico, como terminales, módems, fax, etc. Seudo dispositivos TTY son las sesiones telnet y xterm (u otros emuladores de terminal gráficos como dtterm y aixterm). Como el procesamiento del I/O de caracteres consume recursos de CPU, es importante monitorear la relación entre el aumento de actividad de TTY y la utilización de CPU. Si dicha relación existe, deben analizarse los dispositivos TTY, junto con las aplicaciones que utilizan esos dispositivos TTY. Por ejemplo, una aplicación de fax puede ser mejorada incrementando la velocidad del puerto TTY de manera que una transferencia de archivos resulte más rápida y eficiente.
Página 121 de 283
Las columnas de estadísticas de CPU, % user, % sys, % idle, y % iowait, proveen información sobre la utilización de CPU. La misma información es reportada con el comando vmstat en las columnas us, sy, id, y wa. En general, valores altos en la columna % iowait indican que el sistema tiene escasez de memoria, debido al paginado o a una configuración ineficiente del susbsistema de I/O. Entender los cuellos de botella de I/O y optimizar la eficiencia del subsistema de I/O requiere mas datos que los que el iostat provee. Cuando el reporte del comando iostat muestra que no hay saturación de CPU, con valores altos en % idle y mas del 25 por ciento en % iowait, nos indica una posible saturación de I/O o disco. El siguiente es un ejemplo extraído de un reporte del comando iostat: ... tty: Disks: hdisk3 hdisk2 hdisk0 hdisk1 cd0 hdisk4
El ejemplo anterior muestra valores altos en % iowait debido a un cuello de botella de I/O en el hdisk4. Dependiendo del sistema actual, un valor alto de % iowait puede ser causado por exceso de paginado, por escasez de memoria real. También puede deberse a carga de disco desbalanceada, fragmentación de datos, o patrones de uso. Para una carga de disco desbalanceada, el mismo reporte del iostat provee la información necesaria. Pero para información sobre file systems o volúmenes lógicos (que son recursos lógicos) se debe utilizar una herramienta específica del AIX, como el filemon o fileplace. Alternativamente, el comando iostat puede ser usado para determinar si un problema de rendimiento está relacionado con la CPU. A pesar de que el vmstat preferentemente debería ser usado para este análisis, ante la ausencia de reportes del vmstat, el iostat puede ser usado. Un buen indicador de saturación de CPU es cuando el valor de % iowait es cero y el sistema no tiene tiempo idle (% idle = 0). Para investigar si un sistema no tiene un problema de memoria, se debe revisar si el volumen físico que es usado para el espacio de paginado no tiene carga excesiva. Se debe utilizar el comando lsps -a para determinar cual es el volumen físico del espacio de paginado.
4.3.2.3 El comando iostat en sistemas SMP El cálculo del tiempo de I/O wait en sistemas SMP (Symmetrical Multiprocessor) fue modificado para proveer una recolección mas precisa de la utilización de CPU en comandos como el vmstat y el iostat. Antes de la Versión 4.3.3 de AIX, el cálculo del tiempo de I/O wait en sistemas SMP podía resultar
Página 122 de 283
con valores exagerados (comparado con sistemas uniprocesador o UP). Esto era debido a cierta anomalía estadística en la forma en que el AIX contabilizaba el tiempo de CPU. Los comandos vmstat y iostat simplemente reportaban el uso de CPU en las cuatro categorías de usr/sys/wio/idle. A cada interrupción del reloj en cada procesador (100 veces por segundo en AIX), se realiza una determinación para decidir en qué categoría se asignan los últimos 10 ms. de tiempo. SI la CPU está ocupada en modo usuario en el momento que sucede la interrupción del reloj, se asigna este último tick del reloj a la categoría usr. Si la CPU está ocupada en el modo kernel, el tick se asignara a la categoría sys. Si la CPU no está ocupada, se verifica si hay alguna operación de I/O a disco en progreso. Si es así, el tick se asignará a la categoría wio. Si no hay actividad de I/O de disco y la CPU no esta ocupada, entonces el tic se asignará a la categoría idle. Como se puede ver, no interesa que procesador inició la operación de I/O. Esto concluye con valores de wio más elevados en sistemas SMP que en sistemas UP, en situaciones similares. A partir de AIX Versión 4.3.3, el tiempo de I/O wait no es más exagerado; no se le atribuye tiempo wait a todas las CPUs cuando un disco está ocupado y la CPU es idle. La decisión se basa en si un thread está esperando una operación de I/O en la CPU que se está midiendo. Este método puede reportar tiempos de wio más precisos cuando hay unos pocos threads realizando operaciones de I/O y por otro lado el sistema se encuentra idle.
4.3.2.4 Reporte de utilización de disco Cualquier problema potencial de rendimiento de I/O de disco debe ser analizado en primer lugar con el comando iostat. Para reportar sólo el I/O de disco, use el comando iostat -d. Además, las estadísticas de disco pueden ser limitadas a determinados discos especificando los nombres de los volúmenes físicos. El reporte de utilización de disco del iostat muestra las siguientes columnas: Disks
Muestra los nombres de los volúmenes físicos. Tanto discos como CD-ROM, seguidos por un número. Por defecto, se muestran todos los discos, menos aquellos que son especificados en la línea de comando.
% tm_act
Indica el porcentaje de tiempo en que un disco físico está activo. Un disco está activo durante transferencias de datos y procesamiento de comandos, como una buscar una nueva ubicación. Un incremento en el porcentaje de tiempo activo de un disco implica una caída del rendimiento y el tiempo de respuesta aumenta. En general, cuando la utilización excede un 40 por ciento, los procesos deben esperar más de lo necesario para completar una operación de I/O, porque la mayoría de los procesos UNIX duermen esperando que sus requerimientos de I/O se completen.
Kbps
Indica la cantidad de datos transferidos (leídos o escritos) a un disco en KB por segundo. Esta es la suma de KB leídos, más KB escritos, dividido por los segundos de intervalo del reporte.
tps
Indica la cantidad de transferencias por segundo que fueron realizadas a un disco físico. Una transferencia es un requerimiento de I/O a un disco físico, a nivel controlador de dispositivos (device driver). Múltiples requerimientos lógicos pueden ser combinados en un sólo requerimiento de I/O al disco. Una transferencia es de tamaño indeterminado.
Kb_read
Muestra el total de datos (en KB) leídos del volumen físico durante el intervalo de medición.
Página 123 de 283
Kb_wrtn
Muestra el total de datos (en KB) escritos al volumen físico durante el intervalo de medición.
Cuando se analiza el reporte de utilización de disco y se utilizan las diferentes columnas de datos, es importante tener en cuenta los patrones y relaciones entre los distintos tipos de datos. Normalmente hay una relación entre la utilización del disco %tm_act y las tasas de transferencia de datos tps. Si el tasa de utilización del disco %tm_act es alta, entonces la tasa tps debería ser alta. Sin embargo, si se obtiene un tasa de utilización de disco alta y una tasa de transferencia baja, puede deberse tanto a fragmentación del volumen lógico, del file system o archivos individuales. Generalmente, es necesario preocuparse sobre altas tasas de utilización de disco cuando un disco está siendo utilizado por un solo proceso de AIX (por ejemplo, un trabajo batch). Por ejemplo, si una aplicación lee/escribe secuencialmente, se debe esperar una alta tasa de transferencias (tps) y una alta tasa de utilización (%tm_act). Kb_read y Kb_wrtn pueden aportar una mejor comprensión del comportamiento en la lectura/escritura de una aplicación. Sin embargo, no provee información sobre los patrones de acceso a datos. Un promedio de utilización de un volumen físico mayor al 25 por ciento sobre todos los discos indica un cuello de botella de I/O. La conclusión general en relación al rendimiento de discos, volúmenes lógicos y file systems es que a mayor cantidad de discos en el sistema, mejor es el rendimiento de I/O de disco. Sin embargo, hay un límite en cuanto a la cantidad de datos que pueden ser manejados por los adaptadores SCSI; por lo tanto, los adaptadores SCSI pueden ser en más de una ocasión un cuello de botella. Especialmente en sistemas RS/6000 con adaptadores SCSI-1 y SCSI-2. Para determinar si un adaptador SCSI está saturado, se deben sumar todos los valores en KB/s para los discos configurados en el mismo adaptador y comparar la suma con la velocidad del adaptador SCSI. En general, se debe tomar un 70 por ciento de la tasa de rendimiento provista por el fabricante. Este es un ejemplo de diferentes tipos SCSI y su rendimiento: • SCSI-1 tasa de rendimiento de 3.5 MB/s (70 por ciento de 5 MB/s) • SCSI-2 tasa de rendimiento de 7 MB/s (70 por ciento de 10 MB/s) • Ultra SCSI tasa de rendimiento de 28 MB/s (70 por ciento de 40 MB/s) • Ultra2 SCSI tasa de rendimiento de 56 MB/s (70 por ciento de 80 MB/s) Si se descubre un adaptador saturado, se debe solucionar el problema moviendo discos a otros adaptadores menos usados o agregando un adaptador SCSI adicional.
Nota Al igual que con el comando vmstat, iostat sólo puede dar una primera indicación sobre un cuello de botella. El administrador del sistema deberá realizar análisis más profundos con herramientas tales como el filemon para identificar el origen del problema.
4.3.3 Análisis de rendimiento del LVM utilizando el lslv Hay varios factores que afectan el rendimiento de los volúmenes lógicos (LV); por ejemplo, la posición de asignación en el disco o las opciones de espejado. Para obtener información sobre el volumen lógico, se puede utilizar el comando lslv, que provee información sobre: Atributos del LV
Lista de las características actuales del volumen lógico
Asignación del LV
Mapa de ubicación de los bloques en el disco
Página 124 de 283
Fragmentación del LV
Fragmentación de los bloques del LV
4.3.3.1 Atributos del volumen lógico Se debe utilizar el comando lslv sin flags para ver las características del volumen lógico, como muestra el siguiente ejemplo: # lslv mirrlv LOGICAL VOLUME: mirrlv LV IDENTIFIER: 000bc6fd1202118f.3 VG STATE: active/complete TYPE: jfs MAX LPs: 512 COPIES: 2 LPs: 120 STALE PPs: 0 INTER-POLICY: maximum INTRA-POLICY: inner middle MOUNT POINT: /u/mirrfs MIRROR WRITE CONSISTENCY: on EACH LP COPY ON A SEPARATE PV ?: yes
El ejemplo anterior muestra los atributos del volumen lógico mirrlv, que es un volumen lógico espejado y que pertenece al grupo de volúmenes stripvg. En cuestiones de rendimiento, los siguientes atributos deben tenerse en cuenta: COPIES
Indica la cantidad de copias físicas. Si copias es igual a 1, entonces el LV no se encuentra espejado. Valores 2 y 3 son usados para LVs espejados.
INTER-POLICY
Política de asignación entre volúmenes físicos. Permite determinar qué política utilizar para elegir los dispositivos físicos, para asignar las particiones físicas de un volumen lógico.
INTRA-POLICY
Política de asignación dentro de los volúmenes físicos. Permite determinar qué política utilizar para escoger las particiones físicas en un volumen físico.
MIRROR WRITE CONSISTENCY Consistencia de la escritura de espejado. Asegura la consistencia de los datos entre las copias espejadas de un volumen lógico durante el procesamiento de I/O normal. Para cada escritura a un volumen lógico, el LVM genera un requerimiento de escritura para cada copia espejada. La consistencia de la escritura de espejado debe ser ejecutada en la mayoría de los volúmenes lógicos espejados. WRITE VERIFY
Especifica si se debe verificar cada escritura con un inmediata lectura. Esta opción incrementa la disponibilidad pero disminuye el rendimiento.
SHED-POLICY
Especifica uno de los dos tipos de política de scheduling para la escritura (secuencial o paralela), utilizadas en los volúmenes lógicos con múltiples copias.
BB POLICY
Especifica si se debe usar el reacomodamiento de los bloques dañados (Bad Block Relocation), que redirecciona los requerimientos de I/O de un bloque de disco dañado a un bloque válido.
Página 125 de 283
RELOCATABLE
Especifica si se debe permitir el reacomodamiento del volumen lógico durante una reorganización del grupo de volúmenes.
UPPER BOUND
Especifica el número máximo de volúmenes físicos por asignación.
a. Espejado Para incrementar la disponibilidad de un volumen lógico, AIX soporta el espejado de los datos permitiendo copias múltiples de un volumen lógico en discos diferentes. Cuando se utiliza el espejado, la política de scheduling de la escritura puede ser: Secuencial Parallel
La política de escritura secuencia espera que la operación de escritura se complete en la partición física previa antes de comenzar con la siguiente operación. La política de escritura paralela comienza la operación de escritura para todas las particiones físicas de una partición lógica al mismo tiempo. La escritura se completa cuando la operación de escritura más lenta es completada.
La política de escritura paralela provee el mejor rendimiento y es la opción preferida cuando se crean los volúmenes lógicos espejados. En general, las siguientes recomendaciones proveen la mayor disponibilidad del LVM: • Utilice tres copias de la partición lógica (doble espejado) e incluya al menos tres volúmenes físicos. • La verificación de escritura debe ser activada. • La política entre discos (inter) debe ser configurada en mínimo (minimum), lo que define que las copias espejadas sean iguales al número de volúmenes físicos. • La política de asignación de discos debe ser configurada en estricto (strict), lo que establece que ninguna de las copias de las particiones lógicas estén en el mismo disco. • Los volúmenes físicos que contienen las copias deben estar conectados a buses, adaptadores y power supplies diferentes. Proveer la máxima disponibilidad, sin embargo, a veces puede tener un impacto negativo en el rendimiento del LVM; por lo tanto, se deben realizar algunas modificaciones, dependiendo de los requerimientos.
b. Política intra Las cinco políticas de intra-asignación son: inner edge , inner middle , center , outer middle , outer edge . Las posiciones del disco que corresponden a cada política son ilustradas en el siguiente gráfico:
Página 126 de 283
En general, el rendimiento de la política intra-disco es el siguiente: • La política de asignación central (center) tiene el promedio de tiempo de búsqueda más rápido en discos con menos de 4 GB de espacio. En discos más grandes, el borde externo (outer middle) tiene los tiempos de búsqueda más rápidos. • Las políticas de asignación en el medio externo (outer middle) y el medio interno (inner middle) proveen un tiempo de búsqueda razonable. Es el valor por defecto cuando se crea un volumen lógico nuevo. • El borde externo (outer edge) en discos con menos de 4 GB de espacio y el borde interno (inner edge) tiene el promedio de tiempo de búsqueda más lento.
c. Política inter Las políticas posibles para la asignación dentro del disco son mínimo (MINIMUM) y máximo (MAXIMUM). La política MINIMUM asigna las particiones físicas del volumen lógico en el mismo disco o en la menor cantidad de discos posible. La política MINIMUM provee la mejor disponibilidad. La política MAXIMUM asigna las particiones físicas del volumen lógico en la mayor cantidad de discos posible. La política MAXIMUM provee el mejor rendimiento. Para los volúmenes lógicos no espejados, la política MINIMUM indica que un volumen físico debe contener todas las particiones físicas del volumen lógico. Si el programa de asignación debe usar dos o más volúmenes físicos, utilizará la menor cantidad posible. Para los volúmenes lógicos espejados, la política MINIMUM indica que se deben utilizar tantos volúmenes físicos como copias se quieran realizar. Por otro lado, el mínimo número posible de volúmenes físicos debe ser usado para almacenar todas las particiones físicas.
d. Striping El striping está diseñado para incrementar el rendimiento de lectura y escritura de grandes archivos secuenciales, frecuentemente accedidos. Cuando un volumen lógico es creado con striping, se deben utilizar tantos discos como sea posible. Desde la versión 4.3.3 de AIX, es posible el espejado de volúmenes lógicos con striping; por consiguiente, ya no es válido el viejo concepto de que el striping no provee disponibilidad al no poder contar con espejado. Cuando se define un volumen lógico con striping, dos atributos adicionales aparecen con el comando lslv:
Página 127 de 283
STRIPE WIDTH
Cantidad de divisiones del striping.
STRIPE SIZE
El tamaño fijo de cada bloque de striping. Este tamaño puede ser cualquier potencia de 2 desde 4 KB a 128 KB, aunque generalmente es configurado en 64 KB para obtener los niveles más altos de rendimiento en operaciones de I/O secuenciales.
4.3.3.2 Fragmentación de volúmenes lógicos Para inspeccionar un volumen lógico por una posible fragmentación, se utiliza el flag –l del comando lslv, como se ve en el siguiente ejemplo: # lslv -l mirrlv mirrlv:/u/mirrfs PV hdisk2 hdisk1
COPIES 120:000:000 120:000:000
IN BAND 90% 69%
DISTRIBUTION 000:000:000:108:012 000:000:000:083:037
Este ejemplo utiliza el mismo volumen lógico que en la sección anterior. La columna PV indica que el volumen físico utiliza dos discos (hdisk1 y hdisk2). La columna COPIES indica que la cantidad total de particiones lógicas es 120, y como es un volumen lógico espejado, ambos discos tienen la misma cantidad de PPs asignadas (240 en total). La columna IN BAND indica en porcentajes, el nivel de cumplimiento con la política de intra asignación. Si el LVM no puede cumplir con el requerimiento de la política intra, elige la mejor alternativa. En el ejemplo anterior, la política intra era inner middle , pero sólo pudo cumplir con el requerimiento en un 69 por ciento en el hdisk1 y un 90 por ciento en el hdisk2. La columna DISTRIBUTION muestra cómo son asignadas las particiones físicas en cada sección de la política intra, como muestra el siguiente esquema de relación: (outer edge) : (outer middle) : (center) : (inner middle) : (inner edge)
En este ejemplo, el hdisk1 tiene 83 PPs asignadas en el requerido inner middle, y 37 en el outer edge. El hdisk2 tiene mejor asignada la política intra, y es por eso que el nivel IN BAND es mayor.
4.3.3.3 Asignación de volúmenes lógicos Para ver la asignación de volúmenes lógicos con respecto a su ubicación dentro del volumen físico, se utiliza el siguiente comando: # lslv -p hdisk1 mirrlv hdisk1:mirrlv:/u/mirrfs FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE
La salida muestra cinco secciones que representan: outer edge, outer middle, center, inner middle, e inner edge. Cada partición física es marcada con un número o una palabra: Número
Un número indica el número de partición lógica del volumen lógico.
USED
Esta palabra indica que la partición física en esta ubicación es utilizada por otro volumen lógico.
FREE
Esta palabra indica que esta partición física no está siendo utilizada por ningún volumen lógico. La fragmentación de un volumen lógico ocurre si las particiones lógicas nos son contiguas a través del disco.
STALE
Aunque no está presente en el ejemplo, la palabra STALE indica que la partición no puede ser utilizada.
Página 129 de 283
Este ejemplo muestra que la copia del mirrlv ubicada en el hdisk1 fue asignada en forma contigua. Las particiones lógicas desde la 01 a la 83 fueron asignadas en la sección inner middle, mientras que desde la 84 a la 120 fueron asignadas en la sección inner edge. Cuando los volúmenes lógicos son eliminados, las particiones físicas son liberadas y eso genera espacio tanto para nuevos volúmenes lógicos como para reorganizar volúmenes lógicos, de manera que la fragmentación de un volumen lógico es limitada. El comando del LVM reorgvg puede reorganizar volúmenes lógicos de manera que cumplan con las políticas intra. Utilizando reorgvg con el grupo de volúmenes y el nombre del volumen lógico, se otorga la máxima prioridad al grupo de volúmenes mientras realiza la reorganización. Durante la reorganización, el grupo de volúmenes es marcado y no puede usarse.
4.3.3.4 El mejor rendimiento del LVM Las siguientes recomendaciones generales pueden ser usadas para crear volúmenes lógicos con alta demanda de rendimiento. Si embargo, se debe tener en cuenta que cuando un volumen lógico es configurado para un mejor rendimiento, la disponibilidad puede verse afectada. • Sin espejado, lo que significa un número de copias igual a uno (1). • Si el espejado es requerido entonces: - Las políticas de scheduling de escritura debe configurarse en paralelo. - Política de asignación configurada en strict, lo que significa que cada copia debe realizarse en volúmenes físicos diferentes. • Verificación de escritura configurada en no. • Consistencia de la escritura de espejado (MWC) desactivada. • Políticas intra: - Center: para volúmenes lógicos muy activos - Middle: para volúmenes lógicos moderados - Edge: para volúmenes lógicos poco activos. • Política de asignación inter discos configurada en maximum, lo que implica que las operaciones de lectura/escritura son distribuidas entre los volúmenes físicos. Mejoras de rendimiento adicionales pueden ser obtenidas al crear volúmenes lógicos con striping.
4.3.4 Monitoreo del LVM y file systems Para proveer un análisis más completo del rendimiento de los file systems, la versión 4.3 de AIX provee un comando de monitoreo, filemon. Este ofrece información sobre aplicaciones específicas o la actividad de I/O del sistema, ayudando en el proceso de determinación de problemas o en la optimización del rendimiento.
4.3.4.1 El comando filemon El comando filemon monitorea y presenta información en los siguientes cuatro niveles respectivos a la utilización de file systems:
Página 130 de 283
Archivo lógico
Las operaciones de monitoreo incluyen todas las lecturas, escrituras, aperturas y las llamadas del sistema lseek, que pueden o no resultar en I/O físico, dependiendo si los archivos están en un buffer o en memoria. Las estadísticas de I/O son generadas por archivo.
Volúmenes lógicos
Las estadísticas de I/O son generadas por volumen lógico.
Volúmenes físicos
En este nivel, se obtiene la utilización de recursos físicos. Las estadísticas de I/O son generadas por volumen físico.
Sistema de memoria virtual
En este nivel, son monitoreadas todas las operaciones (es decir, el paginado) entre segmentos y sus imágenes en disco. Las estadísticas de I/O son generadas por segmento.
a. Usando el comando filemon El comando filemon está basado en las herramientas de trace de AIX para monitorear actividad de I/O durante un período específico. Es por esto que el filemon sólo puede ser ejecutado por root y no puede ser ejecutado en paralelo con otros comandos del tipo trace, como tprof y netpmon. El trace es iniciado implícitamente por el comando filemon, pero puede ser controlado con las utilidades genéricas de trace: trcstop, trcoff, y trcon. Cuando un trace es detenido con trcstop, el filemon escribe un reporte a la stdout o a un archivo especificado. Para especificar los niveles de información recolectados en todas las capas, o en capas específicas, se usa la opción de capas -O. Por defecto se recolecta información en las capas físicas, de memoria virtual y LVM. Son generados tanto los sumarios como los reportes detallados.
Nota El comando filemon sólo recolectará información para aquellos archivos abiertos después de que se inició el filemon, a menos que se especifique el flag -u. La siguiente secuencia de comandos provee un ejemplo simple del filemon en acción: # filemon -o /tmp/filemonLF.out -O lf Enter the "trcstop" command to complete filemon processing # dd count=2048 if=/dev/zero of=/u/mirrfs/testMirrorFile 2048+0 records in. 2048+0 records out. # dd count=2048 of=/dev/null if=/u/mirrfs/testMirrorFile 2048+0 records in. 2048+0 records out. # trcstop [filemon: Reporting started] [filemon: Reporting completed] [filemon: 10.666 secs in measured interval] # ls -l filemonLF.out -rw-r--r-- 1 root system 2627 Jul 07 12:51 filemonLF.out #
El comando filemon es iniciado con el flag -O, especificando que sólo se debe monitorear la infor-
Página 131 de 283
mación de archivos lógicos. Este ejemplo utiliza dos comandos dd para escribir a un archivo y para leer un archivo. Los dispositivos especiales /dev/zero y /dev/null son utilizados para obtener figuras limpias de lectura/escritura y realizar los reportes en forma transparente. En este ejemplo, el reporte de salida del comando filemon es puesto en un archivo dedicado utilizando el flag -o. Por defecto se escribe el reporte en la salida por defecto (standard output).
4.3.4.2 Análisis del reporte Los reportes generados por el filemon dependen de los niveles de salida del flag -O. Los valores posibles para los niveles de salida son: lf lv pv vm
Nivel archivo lógico Nivel volumen lógico Nivel volumen físico Nivel memoria virtual
El valor por defecto del -O es all . Sin embargo, si el -O es especificado sin un nivel, entonces el valor por defecto será lv, pv, y vm. La siguiente sección explica los reportes de salida del filemon utilizando los ejemplos de la sección anterior.
a. Reporte a nivel archivo lógico El nivel archivo lógico, como muestra el siguiente ejemplo, provee dos secciones, el reporte Most Active Files (Archivos Más Activos) con la información de los archivos activos durante el trace, y el reporte Detailed File Stats (Estadísticas Detalladas de Archivo), para una estadística detallada de archivos individuales. # cat /tmp/filemonLF.out Fri Jul 7 12:51:38 2000 System: AIX server1 Node: 4 Machine: 000BC6FD4C00 Cpu utilization: 100.0% Most Active Files -----------------------------------------------------------------------#MBs #opns #rds #wrs file volume:inode -----------------------------------------------------------------------2.0 2 2048 2048 testMirrorFile /dev/mirrlv:17 1.0 1 2048 0 zero 1.0 1 0 2048 null 0.0 3 6 0 ksh.cat /dev/hd2:23079 0.0 2 2 0 dd.cat /dev/hd2:22970 0.0 1 2 0 cmdtrace.cat /dev/hd2:22947 -----------------------------------------------------------------------Detailed File Stats -----------------------------------------------------------------------FILE: /u/mirrfs/testMirrorFile volume: /dev/mirrlv opens: 2 total bytes xfrd: 2097152 reads: 2048 (0 errs) read sizes (bytes): avg 512.0 min 512 read times (msec): avg 0.003 min 0.000 writes: 2048 (0 errs) write sizes (bytes): avg 512.0 min 512 write times (msec): avg 0.028 min 0.012 lseeks: 1 FILE: /dev/zero opens: 1 total bytes xfrd: 1048576
inode: 17
max max
512 sdev 0.084 sdev
0.0 0.005
max max
512 sdev 0.443 sdev
0.0 0.044
Página 132 de 283
reads: read sizes (bytes): read times (msec):
2048 (0 errs) avg 512.0 min avg 0.007 min
512 max 0.006 max
512 sdev 0.076 sdev
0.0 0.003
FILE: /dev/null opens: total bytes xfrd: writes: write sizes (bytes): write times (msec):
1 1048576 2048 (0 errs) avg 512.0 min avg 0.001 min
512 max 0.000 max
512 sdev 0.023 sdev
0.0 0.002
FILE: /usr/lib/nls/msg/en_US/ksh.cat volume: /dev/hd2 (/usr) inode: 23079 opens: 3 total bytes xfrd: 24576 reads: 6 (0 errs) read sizes (bytes): avg 4096.0 min 4096 max 4096 sdev 0.0 read times (msec): avg 0.033 min 0.000 max 0.085 sdev 0.036 lseeks: 15 FILE: /usr/lib/nls/msg/en_US/dd.cat volume: /dev/hd2 (/usr) inode: 22970 opens: 2 total bytes xfrd: 8192 reads: 2 (0 errs) read sizes (bytes): avg 4096.0 min 4096 max 4096 sdev 0.0 read times (msec): avg 4.380 min 0.000 max 8.760 sdev 4.380 lseeks: 10 FILE: /usr/lib/nls/msg/en_US/cmdtrace.cat volume: /dev/hd2 (/usr) inode: 22947 opens: 1 total bytes xfrd: 8192 reads: 2 (0 errs) read sizes (bytes): avg 4096.0 min 4096 max 4096 sdev 0.0 read times (msec): avg 0.000 min 0.000 max 0.000 sdev 0.000 lseeks: 8
El reporte Most Active Files contiene un sumario de información de los archivos usados más frecuentemente durante el período monitoreado, definido en la siguiente lista: #MBS
Número total de megabytes transferidos desde y hacia el archivo. Las líneas son ordenadas por este campo, en orden decreciente.
#opns
Número de veces que el archivo fue abierto durante el período de medición.
#rds
Número de llamadas del sistema para lectura realizadas contra este archivo.
#wrs
Número de llamadas del sistema para escritura realizadas contra este archivo
file
Nombre del archivo (el path completo figura en el reporte detallado).
volume:inode
Nombre del volumen que contiene el archivo, y el número de inodo del archivo. Este campo puede ser usado para asociar el archivo con su correspondiente segmento persistente. Este campo puede estar en blanco (por ejemplo, para archivos temporarios creados y borrados durante la ejecución).
El ejemplo del filemon muestra que el archivo testMirrorFile es el más activo, con operaciones de lectura de 1 MB y de escritura de 1 MB. Nótese que las operaciones de escritura y lectura fueron realizadas en unidades de 512 byte. Esto muestra que el comando dd utilizó un tamaño de bloque
Página 133 de 283
de 512 byte. Los archivos zero y null no tienen inodos porque no están conectados a ningún file system, son archivos de dispositivos especiales. Del reporte a nivel archivo del filemon, es muy evidente ver cuales archivos generan la mayor demanda de I/O. El reporte Detailed File Stats provee información sobre cada archivo activo con los siguientes detalles: FILE
Nombre del archivo. Si es posible, muestra el path completo.
volume
Nombre del volumen lógico o file system que contiene el archivo.
inode
Número de inode del archivo dentro de su file system.
opens
Número de veces que el archivo fue abierto mientras se monitoreaba.
total bytes xfrd
Número total de bytes leídos y escritos desde y hacia el archivo.
reads
Número de llamados de lectura contra el archivo.
read sizes (bytes)
Estadísticas de lectura, respecto al tamaños de las transferencias (avg, min, max, y sdev), en bytes.
read times (msec)
Estadísticas de lectura, respecto al tiempo de respuesta (avg, min, max, y sdev), en milisegundos.
writes
Número de llamados de escritura contra el archivo.
write sizes (bytes)
Estadísticas de escritura, respecto al tamaño de las transferencias.
write times (msec)
Estadísticas de escritura, respecto al tiempo de respuesta.
seeks
Cantidad de llamados a la subrutina lseek.
El reporte de nivel detallado, en el ejemplo anterior, está centrado en el archivo testMirrorFile. Aquí los tamaños de lectura y escritura de 512 bytes son aún más evidentes. Como es el único tamaño de lectura/escritura utilizado, la desviación del estándar (sdev) es 0. Los tiempos de lectura/escritura son un valor interesante en el reporte Detailed File Stats . Pueden mostrar, entre otras cosas, como se comporta el cache del file system.
b. Reporte a nivel volumen lógico El reporte a nivel volumen lógico provee dos secciones: el reporte Most Active Logical Volumes (Volúmenes Lógicos Más Activos) y el reporte Detailed Logical Volume Stats (Estadísticas Detalladas de Volumen Lógico). El siguiente es un ejemplo de un reporte a nivel volumen lógico: # filemon -o /tmp/filemonLF.out -O lv
Utilización del volumen (fracciones de tiempo ocupado). Las líneas están ordenadas por este campo, en orden decreciente.
#rblk
Cantidad de bloques de 512 bytes leídos del volumen.
#wblk
Cantidad de bloques de 512 bytes escritos en el volumen.
KB/sec
Rendimiento total de las transferencias, en kilobytes por segundo.
volume
Nombre del volumen.
description
Contenidos del volumen: tanto el nombre del archivo como el tipo de volumen lógico (paging, jfslog, boot, o sysdump). Además, indica si el file system está fragmentado o comprimido.
Esta sección del reporte a nivel volumen lógico muestra claramente que el mirrlv es el volumen lógico mas utilizado. El reporte muestra un rendimiento de transferencias de 64.5 KB/s para el mirrlv y su file system mirrfs. Se aprecia cierta actividad en el loglv00 que es el jfslog del mirrfs.
c. Reporte a nivel volumen físico El reporte a nivel volumen físico provee dos secciones: el reporte Most Active Physical Volumes (Volúmenes Físicos Más Activos) y el reporte Detailed Physical Volume Stats (Estadísticas Detalladas de Volumen Físico). El siguiente es un ejemplo de un reporte a nivel volumen físico: # filemon -o /tmp/filemonLF.out -O pv
Este es un extracto del reporte: ... Most Active Physical Volumes -----------------------------------------------------------------------util #rblk #wblk KB/s volume description -----------------------------------------------------------------------0.07 0 2096 66.4 /dev/hdisk1 N/A 0.07 0 2080 65.9 /dev/hdisk2 N/A 0.02 0 305 9.7 /dev/hdisk0 N/A ...
util
Utilización del volumen (fracciones de tiempo ocupado). Las líneas están ordenadas por este campo, en orden decreciente.
#rblk
Cantidad de bloques de 512 bytes leídos del volumen.
#wblk
Cantidad de bloques de 512 bytes escritos en el volumen.
KB/s
Rendimiento total de las transferencias, en kilobytes por segundo.
Página 135 de 283
volume
Nombre del volumen.
description
Tipo de volumen, por ejemplo, 9.1 GB disk o CD-ROM SCSI.
El reporte a nivel volumen físico del ejemplo muestra una actividad casi igual en los dos volúmenes físicos hdisk1 y hdisk2, dado que en ellos están las copias espejadas del mirrlv. Nótese que el hdisk1 tiene un bloque de escritura (#wblk) apenas más grande que el hdisk2 (y por ello, un rendimiento apenas mayor). Esto se debe a que el jfslog loglv00 está ubicado en el hdisk1.
d. Reporte a nivel memoria virtual El reporte a nivel memoria virtual provee dos secciones: el reporte Most Active Segments (Segmentos Más Activos) y el reporte Detailed VM Segment Stats (Estadísticas Detalladas de Segmentos de Memoria Virtual). El siguiente es un ejemplo de un reporte a nivel memoria virtual: # filemon -o /tmp/filemonLF.out -O vm
Este es un extracto del reporte: ... Most Active Segments -----------------------------------------------------------------------#MBs #rpgs #wpgs segid segtype volume:inode -----------------------------------------------------------------------1.0 0 252 c473 page table 0.0 0 1 fefe log ...
#MBs
Cantidad total de megabytes transferidos desde y hacia el segmento. Las líneas están ordenadas por este campo, en orden decreciente.
#rpgs
Cantidad de páginas de 4096 bytes leídas desde el disco al segmento (es decir, page in).
#wpgs
Cantidad de páginas de 4096 bytes escritas desde el segmento al disco (page out).
segid
ID interno del segmento.
segtype
Tipo de segmento: segmento de trabajo, segmento persistente, (archivo local), segmento cliente (archivo remoto), segmento de tablas paginadas, segmentos del sistema, o segmentos persistentes especiales que contienen datos del file system (log, directorio raíz, .inode, .inodemap, .inodex, .inodexmap, .indirect, .diskmap).
volume:inode
Para segmentos persistentes, el nombre del volumen que contiene el archivo asociado, y el número de inodo del archivo. Este campo puede ser asociado a segmentos persistentes con su correspondiente archivo, mostrado en los reportes de I/O de archivo. Este campo está en blanco para segmentos no-persistentes.
En el ejemplo anterior, el reporte a nivel memoria virtual no contiene información importante; es mencionado para completar el informe de las capacidades del filemon.
Página 136 de 283
4.3.4.3 Comportamiento típico del sistema AIX Cuando se utiliza el comando filemon para el análisis de rendimiento, los siguientes puntos deben tenerse en cuenta: Archivos accedidos frecuentemente: • El archivo /etc/inittab siempre es muy activo. Los daemons especificados en /etc/inittab son chequeados regularmente para determinar si requieren ser reactivados (respawn). • El archivo /etc/passwd es también muy activo, porque son verificados los permisos de archivos y directorios. Acceso a disco: • Un tiempo de búsqueda muy grande incrementa el tiempo de respuesta del I/O y disminuye el rendimiento. • Si la mayoría de las lecturas y escrituras requieren búsquedas, se tendrá archivos fragmentados o file systems demasiado activos en el mismo disco físico. • Si la cantidad de lecturas y escrituras se acerca a la cantidad de secuencias, el acceso a disco es más aleatorio que secuencial. Secuencias son cadenas de páginas que son leídas (page in) o escritas (page out) consecutivamente. El largo de las secuencias es medido en páginas. Un acceso aleatorio a un archivo puede además incluir muchas búsquedas. En este caso, no se podrá distinguir en la salida del filemon, si el acceso al archivo es aleatorio o si el archivo está fragmentado. Soluciones para la saturación de disco: • Si procesos en background con I/O intensivo están interfiriendo con los tiempos de respuesta interactivos, se puede activar el I/O pacing. • Si parece que un pequeño número de archivos son leídos una y otra vez en forma reiterada, se debe considerar si el agregado de más memoria real permitirá que esos archivos sean manejados en forma más efectiva. • Si el comando iostat indica que la carga de I/O no es distribuida equitativamente entre los discos, y la utilización de uno o mas discos es a menudo del 40-50 por ciento o más, se debe considerar una reorganización de los file systems. • Si la carga de trabajo se maneja mayormente con un patrón de acceso aleatorio, se debe considerar el agregado de más discos y la distribución entre más discos de los archivos accedidos en forma aleatoria. • Si la carga de trabajo se maneja mayormente con un patrón de acceso secuencial, e incluye múltiples discos, se debe considerar el agregado de uno o más adaptadores. Es apropiado además, crear un volumen lógico con striping para acomodar archivos secuenciales muy grandes que tengan un rendimiento crítico.
4.3.5 Rendimiento de los file systems Hay algunos factores que afectan el rendimiento de los file systems: • La asignación dinámica de recursos puede causar: - Fragmentación de archivos lógicamente contiguos - Fragmentación de volúmenes lógicos lógicamente contiguos - Bloques de archivos esparcidos • Efectos cuando los archivos son accedidos del disco:
Página 137 de 283
- El acceso secuencial deja de ser secuencial - El acceso aleatorio es afectado - Los tiempos de acceso dominados por los tiempos de búsquedas muy grandes Una vez en memoria, los efectos disminuyen.
4.3.5.1 El comando fileplace El uso de archivos y file systems, dependiendo de la aplicación, puede ser muy dinámico y puede, con el tiempo, resultar en fragmentaciones que tengan impacto en el rendimiento del file system, lo que influye a su vez en el rendimiento de la aplicación. El acceso a archivos fragmentados puede necesitar un gran número de búsquedas y mayores tiempos de respuesta de I/O. En algún punto, el administrador del sistema debe decidir reorganizar la ubicación de los archivos dentro del volumen lógico para reducir la fragmentación y obtener una distribución más pareja. El comando fileplace puede asistir en esta tarea mostrando la ubicación de los bloques en un archivo de un volumen lógico o de uno o mas volúmenes físicos. El comando fileplace espera un argumento que contenga el nombre del archivo a examinar, por ejemplo: # fileplace -iv sixMB File: sixMB Size: 6291456 bytes Vol: /dev/restlv Blk Size: 4096 Frag Size: 4096 Nfrags: 1536 Compress: no Inode: 21 Mode: -rw-r--r-- Owner: root Group: sys DOUBLE INDIRECT BLOCK: 77000 INDIRECT BLOCKS: 75321 77001 Logical Fragment ---------------0149576-0149583 0075322-0075773 0149584-0150147 0077002-0077513
1536 frags over space of 74826 frags: space efficiency = 2.1% 4 fragments out of 1536 possible: sequentiality = 99.8%
Este ejemplo muestra la fragmentación lógica de un archivo grande (sixMB). La información general que muestra el fileplace es: File
Nombre del archivo.
Size
Tamaño del archivo en bytes.
Vol
Nombre del volumen lógico del file system.
Blk Size
Tamaño de bloque físico, 4 KB.
Frag Size
Tamaño de fragmentación, también típicamente 4 KB, pero pueden especificarse valores como 512, 1 KB, 2 KB, en el momento de la creación del file system.
Nfrags
Cantidad de fragmentos utilizados por el archivo.
Compress
Compresión del file system, por defecto es no.
Página 138 de 283
Inode
El número de referencia del inodo.
Mode/Owner/Group
Información del inodo a nivel file system UNIX.
Este archivo tiene, por su tamaño, tanto bloques indirectos (75321, 77001), como bloques indirectos dobles (7700). Esta información es obtenida utilizando el comando fileplace -i. La primera columna bajo Logical Fragment muestra los números de bloques lógicos, donde están las diferentes partes del archivo. La siguiente columna muestra la cantidad de fragmentes que están contiguos y la cantidad de bytes en esos fragmentos contiguos. El último número es el porcentaje del rango de bloques comparado con el tamaño total. Finalmente, se utiliza el comando fileplace -v se calculan los valores de eficiencia de espacio y secuencialidad del espacio. Alta eficiencia de espacio implica que los archivos están menos fragmentados y probablemente ofrecerán un mejor acceso secuencial. Utilizando el comando fileplace -p, son mostrados el número de bloques físicos y el volumen o volúmenes físicos. El siguiente es un ejemplo utilizando fileplace en un volumen lógico espejado: # fileplace -p /u/mirrfs/t5 File: /u/mirrfs/t5 Size: 504320 bytes Vol: /dev/mirrlv Blk Size: 4096 Frag Size: 4096 Nfrags: 124 Compress: no Physical Addresses (mirror copy 1) Fragment ---------------------------------0320104-0320111 hdisk1 8 frags 32768 Bytes, 6.5% 0319242-0319305 hdisk1 64 frags 262144 Bytes, 51.6% 0319310-0319361 hdisk1 52 frags 212992 Bytes, 41.9% Physical Addresses (mirror copy 2) Fragment ---------------------------------0320104-0320111 hdisk2 8 frags 32768 Bytes, 6.5% 0319242-0319305 hdisk2 64 frags 262144 Bytes, 51.6% 0319310-0319361 hdisk2 52 frags 212992 Bytes, 41.9%
Este ejemplo muestra las direcciones físicas utilizadas por el archivo t5 en el volumen lógico mirrlv. El archivo está ubicado físicamente en los discos hdisk1 y hdisk2.
Nota El comando fileplace no muestra archivos NFS remotos. Si un archivo remoto es especificado, el comando fileplace devuelve un mensaje de error. El comando fileplace lee la lista de bloques del archivo directamente del volumen lógico en el disco. Si el archivo fue creado, extendido o truncado recientemente, la información puede ser que no esté en disco aún. Utilice el comando sync para guardar la información en el volumen lógico.
4.3.5.2 Desfragmentación de un file system En el tiempo de vida de un file system, un gran número de archivos es creado y eliminado. Esto deja, con el tiempo, una gran cantidad de huecos de bloques libres. Esta fragmentación tiene un
Página 139 de 283
impacto negativo en el rendimiento del file system, y los nuevos archivos son generados con una alta fragmentación. Hay una forma simple de organizar esos huecos libres. El comando defragfs incrementa el espacio libre contiguo de un file system reorganizando las asignaciones para que sean más contiguas, en lugar de que estén esparcidas por todo el disco. El comando defragfs está diseñado para file systems fragmentados y comprimidos. Sin embargo, se puede utilizar para incrementar el espacio libre contiguo en file systems no fragmentados. Otra forma simple de reorganizar el file system es recrearlo utilizando una copia de seguridad.
4.3.6 Recomendaciones generales de rendimiento de I/O Utilizando lslv, fileplace, filemon, y iostat, se pueden identificar problemas de I/O, de grupos de volúmenes y de volúmenes lógicos. Las siguientes son recomendaciones generales sobre cómo obtener un buen rendimiento en file systems y el LVM, y cuándo utilizar las herramientas descriptas. Organización de un volumen lógico para obtener el mejor rendimiento: • Ubicar los volúmenes lógicos más activos en diferentes volúmenes físicos para reducir la contención de disco. • Distribuir los volúmenes lógicos más activos sobre múltiples volúmenes físicos de manera que sea posible el acceso paralelo. • Ubicar los volúmenes lógicos más activos en el centro de los volúmenes físicos, los moderados en las partes medias y los más inactivos en los bordes, de manera que los volúmenes físicos mas utilizados tengan los mejores tiempos de acceso. • El espejado puede mejorar el rendimiento de aplicaciones de lectura intensiva, pero como las escrituras necesitan ser realizadas varias veces, puede impactar en el rendimiento de otras aplicaciones. - Si el espejado es necesario, necesario, se debe configurar la política de scheduling en paralelo y la política de asignación en strict. La política de scheduling paralelo activa la lectura desde el disco más cercano, y la política de asignación strict asigna cada copia en volúmenes físicos separados. • Crear los volúmenes lógicos contiguos para reducir los tiempos de acceso. • Configurar la política inter en maximum. Esto distribuye cada volumen lógico sobre la mayor cantidad posible de volúmenes físicos, lo que permite distribuir las lecturas y escrituras en diferentes discos. • Ubicar los volúmenes lógicos utilizados frecuentemente en posiciones cercanas, para reducir los tiempos de búsqueda. • Configurar write verify en no, de manera que no haya una inmediata lectura (similar a un chequeo de paridad) para cada escritura realizada. Striping de volúmenes lógicos: • Distribuya cada volumen lógico en tantos volúmenes físicos como sea posible. • Utilice todos los adaptadores posibles para los volúmenes físicos. • Cree un grupo de volúmenes separado para los volúmenes lógicos con striping. Recomendaciones de striping: • El tamaño de la unidad de striping debe ser igual al max_coalesce, que por defecto es 64 KB. El valor max_coalesce es el tamaño de requerimiento más grande (en términos de transmisión de datos) que puede hacer un dispositivo SCSI. • Utilice un valor de minpgahead de 2: esto dará la menor cantidad de páginas a leer cuando
Página 140 de 283
comienza una lectura. • Utilice un maxpgahead de 16, para que las lecturas se realicen en unidades de striping (64 KB) y de esta manera resulte que una unidad de striping es leída completa en cada lectura a disco. Si es posible, se recomienda modificar las aplicaciones que utilizan volúmenes lógicos para que realicen el I/O en unidades de 64 KB. • Limitaciones del striping - El espejado con striping no es posible en versiones anteriores a la 4.3.3. En AIX 4.3.3, el espejado de un volumen lógico con striping es posible utilizando la política de asignación física superstrict. - El striping de disco es mayormente efectivo para operaciones de I/O secuenciales. Con archivos accedidos en forma aleatoria no es tan efectivo. Temas relativos al rendimiento de los file systems: • Genere un log de volumen lógico adicional para separar el log de los file systems más utilizados del log por defecto. Esto incrementa la utilización de los recursos en forma paralela. Un escenario de utilización del lslv: • Determinar si un file system muy activo está mejor ubicado en un disco o distribuido en varios discos. Algunos escenarios de utilización del filemon: • Determinar si archivos muy activos son locales o remotos. • Determinar si los espacios de paginado dominan la utilización de disco. • Revisar la utilización intensa de volúmenes físicos. Determinar si el tipo de disco (SCSI-1, SCSI2, cinta, etc.) o de adaptadores SCSI provocan el cuello de botella. Algunos escenarios de utilización del fileplace: • Determinar si la aplicación realiza muchas operaciones sincrónicas (sin cache) de I/O de archivos. • Revisar la fragmentación de archivos. Determinar si los archivos más utilizados están muy fragmentados. Temas relativos al rendimiento de disco de los espacios de paginado: • Nunca agregue más de un espacio de paginado en el mismo volumen físico. • Reorganice o agregue espacio de paginado en varios volúmenes físicos. • Los espacios de paginado deben ser todos del mismo tamaño.
4.3.7 Consumo de las herramientas de rendimiento Como en toda medición de rendimiento en un sistema, cada herramienta consume algunos recursos del sistema: lslv
Este comando utiliza principalmente tiempo de CPU.
filemon
Este comando consume algo de CPU, utilice esta herramienta con discreción, y tenga en cuenta el rendimiento del sistema respecto al impacto que pueda generar la utilización de esta herramienta. En un entorno de CPU saturada con un nivel alto de transferencias a disco, el filemon disminuye el rendimiento del programa en un cinco por ciento.
fileplace
La mayoría de las veces el fileplace utiliza menos de 0.3 segundos de tiempo de CPU.
Página 141 de 283
iostat
El comando iostat agrega poca carga al sistema. Utiliza cerca de 20 milisegundos de tiempo de CPU por cada reporte generado.
Estas estimaciones son conclusiones de mediciones realizadas en una RS/6000 Modelo 320.
4.3.8 Sumario de comandos Esta es la lista de los comandos descripta en este capítulo. Para una referencia completa de los siguientes comandos, consulte la documentación de AIX.
4.3.8.1 El comando filemon El comando filemon monitorea el rendimiento de los file systems, y reporta la actividad de I/O de los archivos lógicos, segmentos de memoria virtual, volúmenes lógicos, y volúmenes físicos. El comando tiene la siguiente sintaxis: filemon [ -d ] [ -i Archivo ] [ -o Archivo] [ -O Niveles ] [ -P ] [ -T n] [ -u ] [-v ]
4.3.8.2 El comando fileplace El comando fileplace muestra la ubicación de los bloques de archivo en los volúmenes lógicos o físicos. El comando tiene la siguiente sintaxis: fileplace [ { -l | -p } [ -i ] [ -v ] ] Archivo
4.3.8.3 El comando lslv El comando lslv muestra la información sobre volúmenes lógicos. El comando tiene la siguiente sintaxis: Para mostrar información del volumen lógico: lslv [ -L ] [ -l|-m ] [ -nVolumenFísico ] VolumenLógico
Para mostrar los mapas de asignación del volumen lógico: lslv [ -L ] [ -nVolumenFísico ] -pVolumenFísico [ VolumenLógico ]
4.4 Herramientas de rendimiento de red En esta sección se verán los siguientes temas: • Visión general de los problemas de rendimiento de red • Herramientas de monitoreo de red • Herramientas de optimización de red
Página 142 de 283
4.4.1 Visión general Las herramientas de rendimiento de red que se recomienda utilizar primero son los comandos ping y netstat. Normalmente, proveen suficiente información para descubrir los problemas. Para entender las características del rendimiento del subsistema de red en AIX, se debe enten-der ante todo algo de la arquitectura fundamental. En la figura siguiente se ve el paso de los datos desde una aplicación en un sistema a otra aplicación en un sistema remoto:
La siguiente descripción corresponde al diagrama: • Como una aplicación escribe en un socket, los datos son copiados del espacio del usuario en un buffer de envíos del socket (socket send buffer) en el espacio del kernel. Dependiendo de la cantidad de datos copiados en el buffer de envíos del socket, el socket coloca los datos en mbufs o clusters. El tamaño de los buffers de la memoria virtual que son usados por la entrada es limitado por los valores: - udp_sendspace - tcp_sendspace • Una vez que los datos son copiados en el buffer de envíos del socket, la capa del socket (socket layer) llama a la capa de transporte (transport layer) (TCP o UDP), pasándole un puntero a la lista de mbufs (una cadena de mbuf). • Si el tamaño de los datos es más grande que la unidad máxima de transferencia (MTU) de la LAN, se tiene en cuenta una de las siguientes condiciones:
Página 143 de 283
- TCP divide la salida en segmentos que cumplen con el límite MTU. - UDP deja la división de la salida a la capa IP (IP layer). • Si IP recibe un paquete más grande que el MTU de la interfase, la fragmenta en paquetes y los envía al sistema remoto, que los reagrupa y regenera el paquete original. • Cuando la capa de la interfase (interface layer) recibe un paquete de IP, este adjunta el encabezamiento de la capa de enlace (link-layer header) al principio del paquete y llama a la rutina de escritura del controlador de dispositivos. • En la capa del controlador de dispositivos (device-driver layer), la cadena de mbuf conteniendo el paquete es encolada en la cola de transmisión. La cantidad máxima de buffers que pueden ser encolados es controlada por el parámetro de sistema tx_que_size. • Los paquetes entrantes son puestos en la cola de recepción del controlador de dispositivos, y pasados a través de la capa de interfase a la capa IP. La cantidad máxima de buffers entrantes que pueden ser encolados es controlada por el parámetro de sistema rx_que_size. • Si IP en el sistema receptor determina que el IP del sistema transmisor fragmentó un bloque de datos, combina los fragmentos y regenera el original y pasa los datos a TCP o UDP. Si uno de los fragmentos es perdido en la transmisión, el paquete incompleto es finalmente descartado por el receptor. El tiempo que IP espera por un fragmento perdido es controlado por el parámetro ipfragttl. - TCP ensambla los segmentos originales y ubica la entrada en el buffer de recepción del socket (socket receive buffer). - UDP simplemente pasa la entrada al buffer de recepción del socket. El tamaño máximo de las colas IP de recepción de paquetes es controlado por el parámetro ipqmaxlen, que es visualizado y modificado con el comando no. Si el tamaño de la cola de entrada alcanza el tamaño máximo, los siguientes paquetes son rechazados. • Cuando una aplicación realiza un requerimiento, los datos apropiados son copiados desde el buffer de recepción del socket en la memoria del kernel al buffer en el segmento de trabajo de la aplicación.
4.4.2 Optimización de las colas de transmisión y recepción de los adaptadores La mayoría de los controladores (drivers) de comunicación proveen una colección de parámetros configurables para controlar los recursos de transmisión y recepción. Generalmente, estos parámetros controlan los límites de las colas de transmisión y recepción, pero pueden además controlar la cantidad y tamaño de los buffers y otros recursos. Para chequear el tamaño de la cola de un adaptador ent0 utilice el comando lsattr: # lsattr -El ent0 busio busintr intr_prior intr_priority ity
0x1000100 15 3
Bus I/O address False Bus interrupt level False Interrupt Interrupt priority priority False
Para cambiar parámetros como el tamaño de cola, realice el siguiente procedimiento. Desconecte la interfase:
Página 144 de 283
# ifconfig en0 detach
Cambie el valor del parámetro apropiado: # chdev -l ent0 -a tx_que_size=128 ent0 changed
Reconecte la interfase: # ifconfig en0 up
Para ver si el tamaño de las colas se debe cambiar, ejecute el comando netstat o las utilidades de estadísticas del adaptador (entstat, tokstat u otros): # netstat -v ETHERNET STATISTICS (ent0) : Device Type: IBM PCI Ethernet Adapter (22100020) Hardware Address: 08:00:5a:fc:d2:e1 Elapsed Time: 0 days 0 hours 19 minutes 16 seconds Transmit Statistics: -------------------Packets: 19 Bytes: 1140 Interrupts: 0 Transmit Errors: 0 Packets Dropped: 0
Dos parámetros deben revisarse: • Max Packets on S/W Transmit Queue. Indica la cantidad máxima de paquetes salientes que fueron encolados simultáneamente en la cola de transmisión. Un indicativo de que el tamaño de la cola es inadecuado es que este valor sea igual al valor del parámetro tx_que_size. Esto indica que la cola estuvo llena en algún momento. • S/W Transmit Queue Overflow. Indica la cantidad de paquetes salientes que desbordaron la cola de transmisión. Un valor diferente a cero indica que deben tomarse las mismas acciones que si el Max Packets on S/W Transmit Queue alcanza el valor del parámetro tx_que_size. El tamaño de la cola de transmisión debe incrementarse.
4.4.3 Optimización de protocolos El principal objetivo en la optimización del rendimiento de red es balancear las demandas de los usuarios dentro de los límites de los recursos para asegurar un rendimiento de red aceptable. Se puede hacer siguiendo estos pasos: • Distinguir la carga de trabajo, la configuración y el ancho de banda. • Medir el rendimiento. - Utilizar herramientas, identificar cuellos de botella. - Herramientas útiles son: netstat, tcpdump, iptrace. • Ajustar los parámetros de red.
Página 145 de 283
- Realizar los ajustes. - Herramientas de optimización útiles son: no, nfso, chdev, ifconfig. El AIX asigna memoria virtual para varias tareas de TCP/IP. El subsistema de red utiliza una facilidad para el manejo de memoria llamada mbuf. Los mbufs son utilizados preferentemente para almacenar datos entrantes y salientes del tráfico de red. Tener grupos de mbuf del tamaño correcto puede tener un efecto muy positivo en el rendimiento de red. La carga de red pesada puede ser una explicación de la falta de memoria para el sistema, pero muy poca memoria virtual para uso de red puede causar pérdida de paquetes. El paquete perdido, por otro lado, puede reducir el rendimiento de las transmisiones debido al tiempo perdido en retransmisiones. El sistema operativo AIX ofrece la capacidad de configurar los grupos de mbuf en tiempo real. Hay algunos parámetros que se pueden modificar con este propósito: thewall
variable del kernel, controla la cantidad máxima de RAM (en kilobytes) que la facilidad de manejo de mbuf puede asignar desde el VMM.
tcp_sendspace
variable del kernel, asigna el tamaño del buffer de envíos del socket. Esto controla que una aplicación no sature el buffer de envíos del socket y limita la cantidad de mbufs usados por la aplicación. El valor por defecto es 16384.
tcp_recvspace
variable del kernel, asigna el tamaño del buffer de recepción del socket cuando una aplicación abre el socket de TCP. El valor por defecto es 16384.
udp_sendspace
variable del kernel, marca el límite de memoria que puede ser usada por un socket UDP como buffer de datos salientes. Si una aplicación llena el espacio de este buffer, deberá dormir hasta que una parte de los datos haya pasado a la siguiente capa en la pila de protocolos. El valor por defecto es 9216.
udp_recvspace
variable del kernel, marca el límite de memoria que puede ser usada por un socket UDP como buffer de datos entrantes. El valor por defecto es 41920.
rfc1323
Si el valor de esta variable no es cero, permite que el tamaño de ventana del TCP sea de 32 bits como máximo, en lugar de 16 bits. Esto significa que se puede configurar el tcp_recvspace y el tcp_sendspace con valores mayores a 64 KB.
sb_max
variable del kernel, controla el límite superior de todos los buffers.
ipqmaxlen
variable del kernel, controla el tamaño de la cola de entrada del IP. El valor por defecto es 100 paquetes, lo cual es suficiente para sistemas con dispositivos en una sola red. Se puede incrementar este valor para sistemas con dispositivos en varias redes. El problema generado por un tamaño de cola insuficiente es la pérdida de paquetes.
Nota Los valores de las variables tcp o udp_sendspace y tcp o udp_recvspace deben ser menores o iguales al valor del sb_max, de manera que se quiere utilizar buffers mayores o menores que el valor por defecto, se debe cambiar también el valor de la variable sb_max.
Página 146 de 283
Una aplicación de red que envía datos en forma excesiva y repentina, como un backup sobre red, puede generar un desborde de los buffers del socket. Insuficiente espacio de buffer de los sockets TCP simplemente limitará el rendimiento (throughput), pero no inhibe la operación. La ventana de TCP limita la cantidad de datos pendientes a ser aceptados y limita efectivamente el rendimiento de los sockets. El tcp_recvspace controla el tamaño de la ventana de TCP, la que no puede ser más grande que el espacio de buffer del socket. Para incrementar el rendimiento de una aplicación determinada, se debe remover el límite de tamaño de la ventana TCP, cambiando el parámetro rfc1323 a 1 e incrementando los valores tcp_sendspace y tcp_recvspace.
4.4.4 Herramientas de monitoreo del rendimiento de red Esta sección describe las herramientas de monitoreo mas comúnmente utilizadas para aislar los problemas de rendimiento de red.
4.4.4.1 El comando vmstat Se deben utilizar herramientas de monitoreo para obtener más estadísticas que ayuden a aislar un cuello de botella en la red. Cuando el comando vmstat muestra cantidades importantes de tiempo idle que no concuerdan con el problema, el sistema puede estar sufriendo problemas de red. El siguiente es un típico ejemplo de un reporte del vmstat: # vmstat 120 10 kthr memory page faults cpu ----- ----------- ------------------------ ------------ ----------r b 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
El I/O wait de disco está en la columna wa y el wait no relacionado con disco en la columna id. El wait no relacionado con disco incluye el I/O wait de red o el I/O wait de terminales. Si no hay I/O wait de terminales, entonces el sistema está esperando la finalización de una operación de I/O. Se deben correr herramientas de monitoreo de red para encontrar las razones de dicho I/O wait de red.
4.4.4.2 El comando ping Cuando se tienen problemas de conexión, la primer herramienta que se debe usar el comando ping. Se utiliza para investigar problemas básicos de conectividad punto a punto, contestando preguntas tales como si el host remoto está conectado a la red, y si la red entre los hosts es confiable. Adicionalmente, el ping puede indicar cuando un nombre de host y su dirección IP es consistente a través de diferentes máquinas. Para verificar que el host server3 está vivo, ingrese el
Página 147 de 283
siguiente comando: # ping server3 PING server3: (9.3.240.58): 56 data bytes 64 bytes from 9.3.240.58: icmp_seq=0 ttl=255 time=1 ms 64 bytes from 9.3.240.58: icmp_seq=1 ttl=255 time=0 ms ^C ----server3 PING Statistics---2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0/0/1 ms
Como muestra el ejemplo, verifica los tiempos de ida y vuelta y las estadísticas de paquetes perdidos.
4.4.4.3 El comando traceroute Si no se puede alcanzar un host que está en una red diferente, se puede verificar la conexión con el comando traceroute. Este comando muestra cada gateway que el paquete atraviesa en su camino para encontrar el host destino, y el retraso o latencia de red asociada con ese segmento. Si es posible, examine las tablas de ruteo de la última máquina mostrada en la salida del traceroute para verificar si una ruta existe para el destino de ese host. En la última máquina mostrada es en donde el ruteo se desvía de su camino. # traceroute 9.3.240.56 traceroute to 9.3.240.56 (9.3.240.56), 30 hops max, 40 byte packets 1 server4e (10.47.1.1) 1 ms 1 ms 0 ms 2 server1 (9.3.240.56) 1 ms 1 ms 1 ms
Si las conexiones se desarrollan deficientemente, la fragmentación de paquetes puede ser el problema. AIX Versión 4.3 tiene un servicio que permite el descubrimiento automático de los MTU de paso. Con el comando no se puede configurar el tamaño fijo del MTU.
4.4.4.4 El comando netstat La herramienta más común para el monitoreo de red es netstat. El comando netstat se utiliza para mostrar el estado de la red. Brinda un indicador de la confiabilidad de la interfase de red local. Tradicionalmente, es más utilizado para la determinación de problemas que para mediciones de rendimiento. Es útil para determinar la cantidad de tráfico en la red, y por lo tanto, para determinar si los problemas de rendimiento se deben a congestionamientos. Hay varias opciones para mostrar: • Sockets activos • Estadísticas de protocolos • Información sobre controladores de dispositivos • Estructuras de datos de red Para mostrar estadísticas grabadas por las rutinas de manejo de memoria, utilice el comando netstat con el flag -m. Para activar estadísticas más extensas sobre los servicios de memoria de
red (para AIX Versión 4.3.2 y superiores), se debe configurar la variable del kernel extendednetstats en 1, de la siguiente manera: # no -o extendednetstats=1
Página 148 de 283
# netstat -m 16 mbufs in use: 0 mbuf cluster pages in use 4 Kbytes allocated to mbufs 0 requests for mbufs denied
0 calls to protocol drain routines Kernel malloc statistics: ******* CPU 0 ******* By size inuse 32 97 64 124 128 111 256 152 512 32 1024 1 2048 1 4096 2 8192 2 16384 1 By type
Streams mblk statistic failures: 0 high priority mblk failures 0 medium priority mblk failures 0 low priority mblk failures
El primer párrafo de datos muestra cuánta memoria es asignada para mbufs. La cantidad total de bytes asignada para mbufs es la primera estadística que se debe revisar. En este ejemplo, hay asignados 4 KB sobre un límite posible de 16 MB. Este límite puede estar regulado por la variable del kernel thewall. La segunda estadística es llamada requerimientos para mbufs denegados (requests for mbufs denied). El valor distinto a cero indica que se debe incrementar el límite configurando el valor de thewall. Para revisar el valor del thewall, ingrese: # no -o thewall thewall = 16384
Para estadísticas de protocolos de red, utilice el comando netstat con el flag -p y el nombre del protocolo. Para recibir estadísticas del protocolo IP, utilice el comando de la siguiente manera: # netstat -p IP ip: : 59821 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length
Página 149 de 283
0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 7985 fragments received 0 fragments dropped (dup or out of space) 7 fragments dropped after timeout
3989 packets reassembled ok 55825 packets for this host .... 47289 packets sent from this host 8 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route
11000 output datagrams fragmented 22000 fragments created 0 datagrams that can't be fragmented .... 0 ipintrq overflows
Cuando el contador ipintrq overflows tiene un valor distinto a cero, se debe cambiar el tamaño de la cola de entrada de IP utilizando el comando no: # no -o ipqmaxlen=100
Utilice el siguiente comando para verificar la cantidad de paquetes que pasan a través de las interfases y la cantidad de errores de I/O: # netstat -i Name Mtu lo0 16896 lo0 16896 lo0 16896 en0 1500 en0 1500 tr0 1492 tr0 1492
4.4.4.5 El comando netpmon El comando netpmon es la herramienta utilizada para el análisis del I/O de red. Utiliza trace como una forma de recolectar estadísticas sobre eventos ocurridos en el código de la red en el kernel. El trace debe ser detenido utilizando el comando trcstop. El netpmon entonces genera todos los reportes especificados y termina. En el ambiente cliente-servidor, netpmon entrega una excelente descripción de como la red afecta el rendimiento general. El comando netpmon puede ejecutarse tanto en el cliente como en el servidor. Este comando apunta específicamente a los siguientes requerimientos físicos y lógicos: CPU Usage Network Device-Driver I/O Internet Socket Calls
Monitorea la utilización de CPU por todos los threads y los controladores de interrupciones. Estima cuánto de este uso es debido a tareas relacionadas con la red. Monitorea las operaciones de I/O a través de los controladores de dispositivos de red. Monitorea la utilización, los tamaños de las colas y los host de destino. Monitorea todas las subrutinas en los sockets IP. Monitorea las subrutinas de lectura y escritura en archivos de clientes NFS, requerimientos RPC en clientes NFS, y requerimientos de escritura o lectura en el servidor NFS
Página 150 de 283
El siguiente ejemplo muestra como la operación de red puede impactar en el rendimiento de CPU. Durante la siguiente sesión del netpmon se efectuó cierta carga de NFS. # netpmon -O cpu; sleep 10 ; trcstop on Jul 10 18:08:31 2000 System: AIX server1 Node: 4 Machine: 000BC6FD4C00 ======================================================================== Process CPU Usage Statistics: ----------------------------Network Process (top 20) PID CPU Time CPU % CPU % ----------------------------------------------------------------kproc 774 1.4956 24.896 0.000 kproc 516 1.4940 24.870 0.000 kproc 1032 1.4929 24.852 0.000 kproc 1290 1.4854 24.727 0.000 kproc 2064 0.0089 0.148 0.000 topas 14798 0.0051 0.084 0.000 netpmon 19204 0.0035 0.059 0.000 nfsd
Nótese que sólo el daemon nfsd consumió tiempo en la columna network CPU. Esta columna indica el porcentaje del tiempo total que el controlador de interrupciones utilizó para eventos relacionados con la red. Para otras estadísticas, utilice el comando netpmon con el flag -O flag y la palabra apropiada. Las palabras posibles son: cpu, dd (network device-driver I/O), so (Internet socket call I/O), nfs (NFS I/O) y all.
4.4.4.6 Los comandos tcpdump e iptrace Las herramientas explicadas previamente permiten obtener un número variado de estadísticas y eventos del tipo red en el kernel de AIX. Sin embargo, es problemático cuando los contadores de estadísticas no son suficientes para encontrar la causa del problema. Es necesario entonces ver los datos reales que van por los cables . Hay dos comandos que permiten ver todos los paquetes que entran o salen a través de una interfase: tcpdump e iptrace. El comando tcpdump muestra los encabezamientos de los paquetes capturados en una interfase de red especificada. El siguiente ejemplo muestra una sesión de telnet entre los hosts 9.3.240.59 y 9.3.240.58: # tcpdump -i tr0 -n -I -t dst host 9.3.240.58 9.3.240.59.44183 > 9.3.240.58.23: S 1589597023:1589597023(0) win 16384 [tos 0x10]
La primera línea indica que el puerto TCP 44183 en el host 9.3.240.59 envió un paquete al puerto del telnet (23) en el host 9.3.240.58. La S indica que el flag SYN fue configurado. El número de secuencia del paquete era el 1589597023 y no contenía datos. No había un campo ack, el campo de recepción disponible win era de 16384 bytes y había una opción max-segment-size (mss) requiriendo un mss de 1452 bytes. El host 9.3.240.58 contestó con un paquete similar, excepto que este incluía un campo ack para el host 9.3.240.59 SYN. El host 9.3.240.59 entonces reconoció el host 9.3.240.58 SYN. El . (punto) significa que no se colocó ningún flag. El paquete no contiene datos, por lo que no hay un número de secuencia de datos. En la undécima línea, el host 9.3.240.59 envió al host 9.3.240.58 26 bytes de datos. El flag PUSH es colocado en el paquete. En la duodécima línea, el host 9.3.240.58 dice haber recibido los datos enviados por el host 9.3.240.59 y envía 54 bytes de datos; además incluye un ack para el número de secuencia 27. El daemon iptrace graba los paquetes IP recibidos desde interfases configuradas. Flags del comando proveen un filtro de manera que el daemon retenga los paquetes que cumplen con un criterio específico. Los paquetes son rastreados únicamente entre el host local donde se invoca el daemon iptrace y el host remoto. Para formatear la salida del iptrace, utilice el comando ipreport. El siguiente ejemplo muestra la consulta del host 9.3.240.59 al servidor DNS 9.3.240.2. Aquí se muestra la salida del comando nslookup: # nslookup www.prokom.pl Server: dhcp240.itsc.austin.ibm.co dhcp240.itsc.austin.ibm.com m Address: 9.3.240.2 Non-authoritative answer: Name: mirror.prokom.pl Address: 153.19.177.201 Aliases: www.prokom.pl
Los datos fueron capturados por el comando iptrace, similar al siguiente: # iptrace -a -P UDP -s 9.3.240.59 -b -d 9.3.240.2 /tmp/dns.query
La salida del comando iptrace fue formateada por el comando ipreport, de la siguiente manera: TOK: ====( 81 bytes transmitted on interface tr0 )==== 17:14:26.406601066 TOK: 802.5 packet TOK: 802.5 MAC header: TOK: access control field = 0, frame control field = 40 TOK: [ src = 00:04:ac:61:73:f7, dst = 00:20:35:29:0b:6d] TOK: 802.2 LLC header: TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP) IP: < SRC = 9.3.240.59 > (server4f.itsc.austin.ibm.com) IP: < DST = 9.3.240.2 > (dhcp240.itsc.austin.ibm.com) IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=59, ip_id=64417, ip_off=0 IP: ip_ttl=30, ip_sum=aecc, ip_p = 17 (UDP)
Página 152 de 283
UDP: UDP: [ udp length = 39 | udp checksum = 688d ] DNS Packet breakdown: QUESTIONS: www.prokom.pl, type = A, class = IN TOK: ====( 246 bytes received on interface tr0 )==== 17:14:26.407798799 TOK: 802.5 packet TOK: 802.5 MAC header: TOK: access control field = 18, frame control field = 40 TOK: [ src = 80:20:35:29:0b:6d, dst = 00:04:ac:61:73:f7] TOK: routing control field = 02c0, 0 routing segments TOK: 802.2 LLC header: TOK: dsap aa, ssap aa, ctrl 3, proto 0:0:0, type 800 (IP) IP: < SRC = 9.3.240.2 > (dhcp240.itsc.austin.ibm.com) IP: < DST = 9.3.240.59 > (server4f.itsc.austin.ibm.com) IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=222, ip_id=2824, ip_off=0 IP: ip_ttl=64, ip_sum=7cc3, ip_p = 17 (UDP) UDP: UDP: [ udp length = 202 | udp checksum = a7bf ] DNS Packet breakdown:
QUESTIONS: www.prokom.pl, type = A, class = IN ANSWERS: -> www.prokom.plcanonical name = mirror.prokom.pl -> mirror.prokom.plinternet address = 153.19.177.201
Hay dos paquetes mostrados en la salida del ipreport (los datos importantes se muestran en negrita). Cada paquete está dividido en unas pocas partes. Cada parte describe diferentes niveles de protocolos de red. Están los token ring (TOK), IP, UDP, y las partes de aplicaciones (DNS). El primer paquete es enviado por el host 9.3.240.59 y es una pregunta sobre la dirección IP del host www.prokom.pl. La segunda es la respuesta.
4.4.5 Herramientas para el control del rendimiento de red Utilice el comando no para configurar los atributos de red. El comando no muestra o modifica los atributos actuales en el kernel. Este comando sólo actúa en el kernel en ejecución. El comando debe ejecutarse nuevamente cada vez que se reinicia el sistema o después de que se configura la red. Para que los cambios sean permanentes, realícelos en el archivo /etc/rc apropiado. Para mostrar los valores actuales de todos los parámetros que se pueden cambiar, utilice el siguiente comando: # no -a
Para cambiar el valor del parámetro thewall, de 18420 a 36840, utilice el comando no de la siguiente manera: # no -o thewall=36840
El comando ifconfig puede ser usado para asignar una dirección a una interfase de red o para configurar o mostrar la configuración actual. En asuntos de optimización, se utiliza para cambiar el tamaño MTU: # ifconfig en0 mtu 1024
Nota Los parámetros MTU tienen que ser iguales en todos los nodos de la red. El comando chdev también es utilizado para cambiar el valor de atributos del sistema. Los cambios realizados por el comando chdev son permanentes, porque son almacenados en la ODM. Para mostrar los valores actuales de los parámetros de la interfase en0, utilice el comando lsattr, de la siguiente manera: # lsattr -El en0 mtu
1500
remmtu 576 netaddr 10.47.1.6 state up arp on netmask 255.255.0.0 security none authority broadcast netaddr6 alias6 prefixlen alias4 rfc1323 tcp_nodelay tcp_sendspace tcp_recvspace tcp_mssdflt
Maximum IP Packet Size for for This Device
True
Maximum IP Packet Size for REMOTE Networks Internet Address Current Interface Status Address Resolution Protocol (ARP) Subnet Mask Security Level Authorized Users Broadcast Address N/A N/A N/A N/A N/A N/A N/A N/A N/A
Para cambiar en forma permanente el valor del parámetro MTU, ingrese: # chdev -l en0 -a mtu=1024 en0 changed
4.4.6 Resolución de nombres Si una conexión de red por momentos parece inexplicablemente lenta y por momentos razonable,
Página 154 de 283
se debe revisar la configuración de resolución de nombres del sistema. Para realizar un diagnóstico básico de la resolución de nombres, se puede utilizar tanto el comando host como el comando nslookup. # host dhcp240.itsc.austin.ibm.com dhcp240.itsc.austin.ibm.com is 9.3.240.2
La resolución de nombres puede ser brindada por el servidor DNS remoto o por servidor NIS remoto. Si uno de ambos está caído, se debe esperar hasta que ocurra un time-out de TCP. La resolución de nombres puede ser resuelta por una fuente alternativa, que puede ser un servidor de nombres secundario en el archivo local /etc/hosts. Primero revise el archivo archivo /etc/netsvc.conf o la variable de ambiente NSORDER para verificar el orden de la resolución de nombres. Luego verifique en el archivo /etc/resolv.conf la dirección IP del servidor de nombres e intente hacer un ping a éste. Si el ping es satisfactorio, entonces éste está vivo y accesible. Si no, intente utilizar un orden diferente para la resolución de nombres.
4.4.7 Optimización del rendimiento de NFS En esta sección se ven temas relacionados con el rendimiento de clientes y servidores NFS.
4.4.7.1 Rendimiento del lado del servidor NFS Cuando los problemas de rendimiento apuntan a los servidores NFS, el asunto generalmente está relacionado con paquetes perdidos. Los servidores NFS pueden perder paquetes por sobrecarga de trabajo. Un lugar donde normalmente un servidor perderá paquetes es en el buffer del socket UDP. Por defecto, en AIX Versión 4.3 se utiliza TCP para la transferencia de datos, pero UDP es aún utilizado para montar. Los paquetes perdidos aquí son contados por la capa UDP, y las estadísticas se pueden observar utilizando el comando netstat -p UDP. Por ejemplo: # netstat -p UDP udp: 89827 datagrams received 0 incomplete headers 0 bad data length fields 0 bad checksums 329 dropped due to no socket 77515 broadcast/multicast datagrams dropped due to no socket 0 socket buffer overflows
11983 delivered 11663 datagrams output (En este sistema el tamaño del buffer era suficiente)
Normalmente, los paquetes NFS serán descartados en el buffer del socket únicamente cuando un servidor tiene mucho tráfico NFS de escritura. El servidor NFS utiliza un socket UDP y un socket TCP conectados al puerto NFS, y todos los datos entrantes son alojados en esos puertos. El tamaño por defecto de ese buffer es 60000 bytes. Dividiendo ese número por el tamaño por defecto de un paquete NFS Versión 3 (32765), se puede ver que con sólo 2 paquetes simultáneos se sobrepasa el tamaño del buffer. Esto puede ser realizado por tan sólo un cliente NFS (con la configuración por defecto). No es tan fácil como parece el hecho de sobrepasar el límite del buffer durante la operación normal del sistema. Tan rápido como el primer paquete llega al socket, un nfsd estará atento para tomar los datos. Una de dos cosas debe ocurrir para que haya pérdida de paquetes. Debe haber un gran volumen de datos o una gran explosión de tráfico para que los paquetes comiencen a ser rechazados. Si
Página 155 de 283
hay un gran volumen de datos, una mezcla de muchas escrituras más otro tráfico adicional de NFS, no habrá suficientes daemons nfsd para tomar los datos del socket tan rápido como para manejar dicha cantidad (esto consumiría un nfsd dedicado para cada llamada NFS de cualquier tipo). En caso de una repentina explosión de tráfico, puede ser que hayan suficientes nfsds, pero la velocidad en que los paquetes arriban al socket es tal que los daemons nfsd no pueden procesarlos suficientemente rápido para evitar el congestionamiento. Estas dos situaciones tienen diferentes resoluciones. En el caso de un gran volumen de datos, puede ser suficiente con incrementar la cantidad de daemons nfsd corriendo en el sistema. Esto es lo primero que se debe intentar, ya que correr mas daemons en una máquina AIX no implica un gran costo operativo. Se puede realizar con el siguiente comando: # chnfs -n 16
Esto va a detener los daemons que se encuentren corriendo, modifica la base de datos SRC para cambiar el parámetro, y arranca los daemons indicados. En el caso de una explosión repentina de tráfico, la única solución es agrandar el socket con la esperanza de que con una cantidad razonable de espacio adicional sea suficiente para que los daemons nfsd tengan tiempo de manejar la explosión. La memoria dedicada a este socket no estará disponible para otro uso por lo que se debe tener en cuenta que agrandar el socket implicara memoria poco utilizada la mayor parte del tiempo. Un administrador cuidadoso observará las estadísticas de saturación del buffer del socket y en relación a los problemas de rendimiento causados determinará qué tan grande debe ser el buffer del socket. Para revisar los parámetros del kernel relacionados con NFS, utilice el comando nfso: # nfso -a portcheck= 0 udpchecksum= 1 nfs_socketsize= 60000 nfs_tcp_socketsize= 60000
Si se modifican los tamaños de nfsbuffer, se debe verificar que la variable del kernel sb_max sea mayor que el valor asignado al buffer NFS. El valor por defecto del sb_max es 1048576 en la versión 4.3.3 de AIX. Si es necesario incrementar el valor del sb_max, utilice el comando no. Se debe recordar que todas las modificaciones realizadas con los comando no y nfso son válidas hasta el siguiente reinicio, a menos que los cambios sean agregados en un script de reinicio, por ejemplo, /etc/rc.nfs.
4.4.7.2 Rendimiento del lado del cliente NFS
Página 156 de 283
El cliente NFS concentra sus problemas generalmente en la cantidad de daemons biod que utilizan. Hay una cantidad de deamons biod por defecto (seis para un montaje NFS V2, cuatro para un montaje NFS V3) que pueden operar en cualquier file system remoto montado en forma concurrente. La idea detrás de esta limitación es que permitir más de un cierto número de daemons biod operando contra un servidor al mismo tiempo pueden congestionarlo. Como esta es una regla de configuración por montaje, pueden realizarse ajustes para configurar los montajes del cliente según las capacidades del servidor. Cuando se evalúa cuanto daemons biod deben ejecutarse, se deben considerar las capacidades del servidor y la utilización normal del NFS en la máquina cliente. Si hay muchos usuarios o muchos procesos en el cliente que necesitar realizar operaciones NFS en el mismo file system NFS, se debe tener en cuenta que puede ocurrir una saturación de los servicios biod con tan sólo dos operaciones de lectura o escritura simultáneas. Hasta seis daemons biod puede trabajar en la lectura de un archivo de un file system NFS. Si comienza otra lectura en otro file system NFS, ambas lecturas intentarán utilizar los seis daemons biod. En este caso, asumiendo que el o los servidores no estén saturados, el rendimiento se puede mejorar aumentando la cantidad de biod a 12. Se puede realizar utilizando el comando chnfs: # chnfs -b 12
Por otro lado, supongamos que ambos file systems están montados desde el mismo servidor y el servidor está operando al máximo de su capacidad. Agregar seis daemons biod puede empeorar dramáticamente la respuesta debido a que el servidor comienza a descartar paquetes con los consiguientes time-outs y retransmisiones.
4.4.7.3 Opciones de montaje El comando mount tiene varias opciones específicas para NFS que pueden afectar el rendimiento. Las opciones más útiles son usadas para configurar los tamaños de las lecturas y escrituras en algún valor que concuerde con el tamaño de los paquetes de lectura/escritura que envía el servidor. Para montajes NFS Versión 3, los tamaños de lectura/escritura pueden incrementarse o disminuirse. El tamaño por defecto es 32 KB. El máximo posible en AIX es 61440 bytes (60 x 1024). Utilizando 60 KB, puede provocar una pequeña mejora de rendimiento en entornos especializados. Para incrementar los tamaños de lectura/escritura cuando tanto el servidor como el cliente son máquinas AIX requiere modificar la configuración en ambas máquinas. En el cliente, se debe realizar el montaje cambiando los tamaños de lectura/escritura con la opción -o. Por ejemplo, -o rsize=61440, wsize=61440. En el servidor, el tamaño máximo de lectura/escritura es configurado con el comando nfso utilizando los parámetros nfs_max_write_size y nfs_max_read_size. Por ejemplo: # nfso -o nfs_max_write_size=61440
NFS V3 utiliza TCP por defecto, mientras que NFS Versión 2 utiliza únicamente UDP. Esto significa que el requerimiento de montaje inicial del cliente utilizando TCP fallará. Para proveer compatibilidad con versiones anteriores el montaje es reintentado utilizando UDP, pero esto ocurre después de un time-out de algunos minutos. Para solucionar el problema, NFS V3 provee los parámetros proto y vers con el comando mount. Estos parámetros son utilizados con la opción -o para fijar el protocolo y la versión en un montaje específico. El siguiente ejemplo fuerza el uso de UDP y NFS V2 para el requerimiento de montaje:
Página 157 de 283
# mount -o proto=udp,vers=2,soft,retry= proto=udp,vers=2,soft,retry=1 1 server4:/tmp /mnt
4.4.8 Sumario de comandos Esta es la lista de los comandos descripta en este capítulo. Para una referencia completa de los siguientes comandos, consulte la documentación de AIX.
4.4.8.1 El comando netstat La sintaxis del comando netstat es la siguiente: Para mostrar sockets activos para cada protocolo o información sobre la tabla de ruteo: /bin/netstat [ -n ] [ { -A -a } | { -r -i -I Interfase } ] [ -f FamiliaDeDirecciones ] [ -p Protocolo ] [ Intervalo ] [ Sistema ]
Para mostrar los contenidos de una estructura de datos de red: /bin/netstat [ -m | -s | -ss | -u | -v ] [ -f FamiliaDeDirecciones ] [ -p Protocolo ] [ Intervalo ] [ Sistema ]
Para mostrar los contadores de paquetes en el subsistema de comunicaciones: /bin/netstat -D
Para mostrar las estadísticas de los cache de buffer de red: /bin/netstat -c
Para limpiar las estadísticas asociadas: /bin/netstat [ -Zc | -Zi | -Zm | -Zs ]
4.4.8.2 El comando tcpdump La sintaxis del comando tcpdump es la siguiente: tcpdump [ -I ] [ -n ] [ -N ] [ -t ] [ -v ] [ -c Número ] [ -i Interfase ] [ -w Archivo ] [ Expresión ]
4.4.8.3 El comando iptrace La sintaxis del comando iptrace es: iptrace [ -a ] [ -e ] [ -PProtocolo ] [ -iInterfase ] [ -pPuerto ] [ -sHost [ -b ] ] [ -dHost [ -b ] ] ArchivoLog
4.4.8.4 El comando ipreport La sintaxis del comando ipreport es: ipreport [ -e ] [ -r ] [ -n ] [ -s ] ArchivoLog
Página 158 de 283
4.5 Herramientas específicas para el manejo de rendimiento En esta sección se verán los siguientes temas: • El scheduler de AIX • El diseño de colas de ejecución múltiples (multiple run queue) de la versión 4.3.3 de AIX • El comando schedtune • Los comandos nice y renice • Introducción al Workload Manager El alcance de este capítulo se concentra en el scheduling de threads y las posibilidades de manejar prioridades de procesos con los comandos schedtune, nice, y renice. También hay un repaso de los comandos ps, bindprocessor, emstat, y tprof.
4.5.1 El scheduler de AIX La necesidad de un scheduler para la eficiencia de un sistema operativo es suprema. En cualquier sistema, hay más threads y procesos corriendo que CPUs disponibles. Es por esto que el sistema operativo utiliza el scheduler para decidir a qué thread permitirle utilizar tiempo de CPU en cada momento. El scheduler selecciona el thread a ejecutar de una lista de threads listos para correr en la cola de ejecución (run queue) . La cantidad de threads en la cola de ejecución es mostrado en negrita en la primera columna de la salida del vmstat: # vmstat 2 5 kthr memory page faults cpu ----- ----------- ------------------------ ------------ ----------r b avm fre re pi po fr sr cy in sy cs us sy id wa 0 0 16272 75548 0 0 0 0 0 0 102 21 10 1 0 99 0 2 1 16272 75547 0 0 0 0 0 0 407 1541 24 49 0 51 0 2 1 16272 75547 0 0 0 0 0 0 405 58 28 50 0 50 0 2 1 16272 75547 0 0 0 0 0 0 406 43 25 50 0 50 0 2 1 16272 75547 0 0 0 0 0 0 409 29 26 50 0 50 0
Los threads en la cola de ejecución son ordenados por prioridad, y el thread que tiene la máxima prioridad utiliza la CPU. En AIX Versión 4, los cinco valores posibles para la política de scheduling de threads es la siguiente: SCHED_FIFO Este es un esquema de scheduling sin prioridades. Luego de que el thread con esta política es agregado a la cola, corre hasta completarse a menos que sea bloqueado, que voluntariamente ceda el control de la CPU, o que un thread con mayor prioridad aparezca listo para ejecutarse. Sólo threads con prioridad fija pueden tener una política de scheduling SCHED_FIFO. SCHED_RR
Página 159 de 283
El thread tiene una prioridad fija. Si un thread SCHED_RR tiene el control, cuando termina su tiempo de CPU, se mueve al final de la cola de threads listos para ejecutarse correspondiente a su prioridad. Sólo los threads con prioridad fija pueden tener una política SCHED_RR. SCHED_OTHER Esta política está considerada por el Standard POSIX 1003.4a como definida por la implementación. En AIX Versión 4, esta política está definida para ser equivalente a la SCHED_RR, excepto que esta se aplica a threads con prioridad no fija. En cada interrupción del reloj se recalcula la prioridad de los threads en ejecución lo que implica que un thread puede perder el control porque su prioridad fue superada por la prioridad de otro thread listo para ejecutarse. SCHED_FIFO2 Esta política es igual a la SCHED_OTHER, excepto que esta permite que un thread que estuvo dormido por un corto período de tiempo sea colocado a la cabeza de la cola de ejecución cuando se despierte. Esta política sólo está disponible en AIX Versión 4.3.3 o superiores. SCHED_FIFO3 Un thread cuya política de scheduling es configurada como SCHED_FIFO3 es puesto siempre en la cabeza de la cola de ejecución. Para prevenir que un thread que pertenece a la política de scheduling SCHED_FIFO2 sea puesto delante de uno SCHED_FIFO3, los parámetros de la cola de ejecución son cambiados cuando un thread SCHED_FIFO3 es encolado, de manera que no haya ningún thread perteneciente a SCHED_FIFO2 en el tope de la cola de ejecución. Esta política sólo está disponible en AIX Versión 4.3.3 o superiores.
4.5.1.1 Cálculo de prioridad en versiones de AIX anteriores a la 4.3.2 Los valores de prioridad difieren entre las versiones de AIX previas a la 4.3.2 y la versión 4.3.2 y superiores. Generalmente, cuanto más bajo es el valor, mayor es la prioridad, con cero como el valor más bajo posible y de mayor prioridad. Por otro lado, el valor 127 es el que representa la peor prioridad. Este valor de prioridad es reservado para el proceso wait. Mientras un thread es ejecutado (utilizando CPU), la prioridad es recalculada, el valor sube, y la prioridad baja. Cuanto más tiempo un thread existe sin utilizar CPU, el valor cada vez es más bajo, y por lo tanto, mayor su prioridad. En algún momento, un thread en la cola de ejecución tendrá un valor menor (mayor prioridad) que el thread en ejecución, este es liberado, y el thread de la cola de ejecución es ejecutado. En el siguiente gráfico es simbolizada la cola de ejecución global utilizada por las versiones de AIX previas a la 4.3.2. Los threads A y B son forzados a dejar el control de las CPUs tan pronto como aparezca en la cola de ejecución un thread de mayor prioridad. En este caso, los threads C, D y E están disponibles. El thread C es elegido en primer lugar porque tiene la mayor prioridad. Los threads D y E tiene la misma prioridad y ocupan posiciones adyacentes en la cola. El thread D es el seleccionado por su posición.
Página 160 de 283
El gráfico anterior es una simplificación del siguiente gráfico. Todos los threads ejecutables de una prioridad dada ocupan posiciones consecutivas en la cola de ejecución. AIX Versión 4 mantiene 128 colas de ejecución. Estas colas de ejecución se relacionan directamente con el rango de posibles valores (0 (0 a 127) para los campos de prioridad de cada thread. Este método le facilita al scheduler la determinación de que thread es el más favorecido para correr. Sin tener que buscar en una gran cola de ejecución, el scheduler consulta una máscara de 128 bits donde un bit encendido indica la presencia de un thread listo para correr en la cola de ejecución correspondiente.
Un thread puede o no tener prioridad fija. El valor de prioridad de un thread con prioridad fija es constante, mientras que el valor de prioridad de un thread con prioridad no fija es la suma del nivel de prioridad máxima para threads de usuarios (una constante 40), el valor nice del thread (por defecto es 20 para procesos interactivos y 24 para procesos en background) y la penalidad de CPU (CPU penalty). Uno de los factores en el cálculo de prioridad es el valor de uso reciente de CPU ( Recent CPU ). Uno de los dos cálculos usados en la definición del Recent CPU usage es: usage ). Uso Reciente de CPU = Anterior Uso Reciente de CPU + 1
Página 161 de 283
Este cálculo es realizado 100 veces por segundo (con cada tick). El valor de uso reciente de CPU aumenta en 1 cada vez que el thread esté bajo el control de la CPU en el final de un tick. El valor máximo es 120. En otras palabras, los threads en ejecución tienen su valor de uso reciente de CPU recalculado (incrementado) 100 veces por segundo hasta alcanzar el límite máximo de 120. Este valor lo muestra la columna C de la salida del comando ps: # ps UID root root root root
–f PID 12948 13888 15432 15752
C PPID 0 12796 12948 111 4 12948 12948 110
STIME 14:27:07 10:08:34 11:42:56 10:08:34
TTY pts/1 pts/1 pts/1 pts/1
TIME 0:00 94:21 0:00 94:21
CMD ksh ./tctestprg ps -f ./tctestprg
Una vez por segundo, todos los threads, incluso aquellos que están dormidos, tienen su valor de uso reciente de CPU recalculado de la siguiente manera: Uso Reciente de CPU = Anterior Uso Reciente de CPU x (SCHED_D / 2) El valor por defecto del SCHED_D es 16, lo que significa que el valor de uso reciente de CPU es dividido por 2 (16 / 32 = 0.5). Esto previene que el valor de uso reciente de CPU de todos los procesos se mantenga fijo en 120. Con este valor de uso reciente de CPU, se puede calcular la penalidad de CPU (CPU penalty): Penalidad de CPU = Uso Reciente de CPU x (SCHED_R / 32) El valor por defecto del SCHED_R es 16. Con el valor de penalidad de CPU definido, finalmente se puede obtener la Prioridad , (Priority), también calculada con cada tick del reloj de la siguiente manera: Valor de Prioridad = 40 + valor nice + Penalidad de CPU En este calculo, el valor nice por defecto es 20 para procesos interactivos y 24 para procesos en background. Con estas definiciones, se observa que tres valores pueden ser manejados para la optimización del rendimiento: el valor nice, el valor SCHED_R, también llamado factor de carga, y el SCHED_D, también llamado factor de caída.
4.5.1.2 Cálculo de prioridad en AIX Versión 4.3.2 y posteriores AIX Versión 4.3.2 y posteriores agregar un par de definiciones nuevas para ser consideradas. Primero es el factor NICE, que no es el valor nice manejado con el comando nice, sino la suma de éste y el nivel de prioridad máxima para los threads del usuario. Secundariamente, el factor DEFAULT_NICE es agregado al algoritmo. Este factor es igual al nivel de prioridad máxima para un usuario, también llamado el valor base (40), más el valor nice por defecto para un proceso interactivo (20). En otras palabras, la suma es 60 para un proceso interactivo (DEFAULT_NICE - NICE = 60). El siguiente cálculo es utilizado para obtener la prioridad: Prioridad = (Uso Reciente de CPU x SCHED_R x (xnice + 4)) / (32 x (DEFAULT_NICE + 4)) + xnice donde DEFAULT_NICE = 40 + 20 (valor base mas nice por defecto). El cálculo del valor xnice es el siguiente: xnice = (NICE > DEFAULT_NICE) ? (2 * nice) - 60 : NICE
Página 162 de 283
Esto significa que si el NICE es más pequeño o igual al DEFAULT_NICE, entonces: xnice = NICE Pero si el NICE es mayor que el DEFAULT_NICE, es decir, si se modificó el thread con el comando nice para bajarle la prioridad, entonces: xnice = (2 x NICE) - 60 El valor nice tiene un impacto mucho mayor en la prioridad de un thread. Ahora está incluido en el cálculo como un múltiplo del uso reciente de CPU, en adición a su uso como factor constante. Algunos valores artificiales ayudarán a mostrar el cálculo: Recent CPU usage = 64 SCHED_R = 16 NICE = 64
Comenzando con el cálculo del XNICE: xnice = (NICE > DEFAULT_NICE) ? (2 * NICE) - 60 : nice
Como NICE es mayor que DEFAULT_NICE, entonces: xnice = (2 x 64) - 60 = 68
Ingresando los valores dados y el valor XNICE en el cálculo: Prioridad = (Uso reciente de CPU x SCHED_R x (xnice + 4)) / (32 x (DEFAULT_NICE + 4)) + xnice
El cálculo seguirá así: P = (64 x 16 x (68 + 4)) / (32 x 64) + xnice P = (73728 / 2048) + 64 P = 100
Todavía se tienen tres valores para manejar. El valor nice (como en el ejemplo), el SCHED_R, y el SCHED_D (por uso reciente de CPU). En las siguientes secciones veremos el esquema de las colas de ejecución múltiples y los comandos utilizados para cambiar estos valores.
4.5.2 Colas de ejecución múltiples con balanceo de carga en AIX Versión 4.3.3 La cola de ejecución global es la misma cola en AIX Versión 4.3.2 que en AIX Versión 4.3.1, pero en AIX Versión 4.3.3 el esquema de las colas de ejecución ha cambiado. AIX Versión 4.3.3 ofrece una mejor afinidad de cache a través del uso de colas de ejecución múltiples. El nuevo scheduler del kernel implementa una sola cola de ejecución global junto con un conjunto de colas de ejecución locales, donde cada procesador tiene su cola de ejecución local dedicada. Una vez que un thread es colocado en una cola de ejecución local, generalmente permanece allí hasta que finaliza, o hasta que es detectado un desbalanceo. Se utilizan umbrales (thresholds) para limitar la cantidad de balanceos que pueden ocurrir. Este es un diagrama de relación entre las colas de ejecución locales y globales:
Página 163 de 283
Cuando las dos colas de ejecución tienen threads esperando con la misma prioridad, la cola de ejecución local es elegida. Cuando se inician, los threads ingresan en la cola de ejecución global a través del mecanismo de balanceo de carga implementado. Una vez que una CPU atiende un thread de una cola de ejecución global, generalmente no lo devuelve a la cola global, sino a la cola que pertenece a esa CPU. El balanceo de carga es manejado por un número de algoritmos diseñados para mantener todas las colas de ejecución de un sistema aproximadamente con la misma utilización. Existen cuatro algoritmos de balanceo, que son desarrollados en las siguientes secciones.
4.5.2.1 Balanceo de carga inicial El balanceo de carga inicial es aplicado a los threads nuevos. Cuando un thread es creado como parte de un nuevo proceso (también un thread nuevo de un proceso existente), es asignado a una CPU libre (si existe). Si no hay ninguna libre, el thread será colocado en la cola global.
4.5.2.2 Balanceo de carga idle El balanceo de carga idle se aplica cuando un proceso debe quedar inactivo, ejecutando el thread waitproc (por ejemplo PID 516). Cuando el dispatcher llega a este punto en su lógica, no busca en otras colas intentando encontrar trabajo a toda costa. Es preferible permitir lo que parecen ser ciclos idle innecesarios que mover el thread y perder afinidad de cache. Los pasos seguidos por el método de balanceo de carga idle son: • Antes de ejecutar el waitproc, busca en otras colas trabajo disponible. • Para robar un thread, se debe obtener el lock de la cola de ejecución elegida. Esto es realizado por una llamada especialmente desarrollada que evita interferir con otra instancia del dispatcher. Si no puede obtener el lock, ejecuta el waitproc. • Después de obtener el lock, verifica que aún haya algún thread “robable”. Si no lo hay, ejecuta el waitproc. • Cambia la asignación de la cola de ejecución y el puntero de los threads.
4.5.2.3 Balanceo de carga periódico frecuente
Página 164 de 283
Es realizado cada N ticks del reloj. Intenta balancear las cargas en las colas locales de un nodo de forma similar al balanceo de carga idle. La idea es mover un thread de la cola de ejecución más cargada a la menos cargada, pero si en el último intervalo la menos cargada ha robado un thread por medio del balanceo de carga idle, no realiza ninguna acción. La diferencia en factores de carga entre las dos colas elegidas para el balanceo de carga periódico frecuente debe ser al menos 1.5. El balanceo de carga idle es menos costoso, por lo que en una situación ideal el balanceo de carga periódico frecuente no debería actuar.
4.5.2.4 Balanceo de carga periódico infrecuente Si un thread no ha recibido tiempo de CPU en los últimos N.5 segundos, el thread es movido a la cola de ejecución global.
4.5.3 Manejo del rendimiento del scheduler AIX ofrece varias opciones para modificar el comportamiento por defecto del sistema de scheduling para threads y procesos. En esta sección se describen los comandos schedtue, nice, y renice.
4.5.3.1 El comando schedtune El comando schedtune permite especificar el SCHED_R con el flag -r y el SCHED_D con el -d. Cuando se ejecuta el comando schedtune sin flags, muestra los valores actuales: # /usr/samples/kernel/schedtune /usr/samples/kernel/schedtune THRASH SUSP -h -p -m -w -e SYS PROC MULTI WAIT GRACE 0 4 2 1 2
FORK -f TICKS 10
SCHED
-d SCHED_D 16
-r -t SCHED_R TIMESLICE 16 1
-s MAXSPIN 16384
CLOCK -c %usDELTA 100
La optimización se realiza a través de dos flags del comando schedtune: -r y -d. Cada flag especifica un parámetro que es un entero comprendido entre 0 y 32. Los parámetros son aplicados multiplicando el valor de uso reciente de CPU por el valor del parámetro y dividiéndolo por 32. El valor por defecto de SCHED_R y SCHED_D es 16, como se aprecia en la salida anterior.
a. Primer ejemplo de schedtune El siguiente comando cofigura SCHED_R = 0 y SCHED_D = 0.5: # /usr/samples/kernel/schedtune -r 0
Esto significa que la penalidad de CPU será 0, lo que implica prioridad absoluta. Ningún proceso en background obtendrá tiempo de CPU a menos que no existan procesos interactivos ejecutables, ya que los procesos en background en ksh son iniciados sumando 4 al valor nice del shell padre. Los valores de prioridad de los threads serán constantes, a pesar de que no sean técnicamente threads de prioridad fija.
Página 165 de 283
b. Segundo ejemplo de schedtune El siguiente comando configura SCHED_R = 1 y SCHED_D = 1. # /usr/samples/kernel/schedtune -r 32 -d 32
Esto significa que los threads de larga duración alcanzarán un valor C igual a 120 y permanecerán así, compitiendo en base a sus valores nice. Los threads nuevos tendrán prioridad, a pesar de su valor nice, hasta que hayan acumulado tiempo slice suficiente como para entrar dentro de los rangos de prioridad de los threads existentes.
c. Tercer ejemplo de schedtune La razón más común por la que se manipulan los valores es para asegurar que los procesos background no compitan con procesos interactivos. Reduciendo el valor del SCHED_R, se puede restringir el rango de los posibles valores de prioridad. Por ejemplo: # /usr/samples/kernel/schedtune -r 5
(SCHED_R = 0.15625, SCHED_D = 0.5) significa que un proceso interactivo nunca tendrá que competir con un proceso en background iniciado con el comando nice -n 20. El límite de 120 porciones de tiempo (time slices) de CPU acumuladas implicarían que la penalidad máxima de CPU para los procesos interactivos sería de 18. En el siguiente gráfico se observa esta relación. Como la penalidad de CPU obtendrá un valor máximo de 18, los procesos interactivos con un valor nice de 20 obtendrán tiempo de CPU siempre que lo necesiten. Por otro lado, los procesos en background, con un valor nice de 40, utilizarán la CPU sólo cuando los procesos interactivos no necesiten CPU.
d. Lineamientos generales de SCHED_R y SCHED_D Estos son algunos lineamientos generales para tener en cuenta cuando se realiza una optimización de rendimiento utilizando SCHED_R y SCHED_D. • Valores más pequeños de SCHED_R disminuyen el rango de prioridad y el valor nice tiene más impacto en la prioridad.
Página 166 de 283
• Valores mayores de SCHED_R amplían el rango de prioridad y el valor nice tiene menos impacto en la prioridad. • Valores menores de SCHED_D disminuyen abruptamente el uso de CPU y pueden provocar que los threads con uso intensivo de CPU sean iniciados más rápidamente. • Valores mayores de SCHED_D disminuyen lentamente el uso de CPU y penaliza a los threads con uso intensivo de CPU (por lo tanto, favorece a los threads de tipo interactivo) Si se llega a la conclusión de que deben modificarse uno o ambos parámetros para acomodar la carga de trabajo, se puede ejecutar el comando schedtune con el usuario root. Los valores modificados hasta que se ejecuta nuevamente el comando schedtune, o hasta el siguiente reinicio del sistema. Los valores por defecto se pueden restaurar con el comando schedtune -D, pero se debe recordar que todos los parámetros del comando schedtune son reiniciados por el comando, incluso los parámetros de control de carga de memoria del VMM. Para realizar un cambio que se mantenga después del reinicio del sistema, se debe agregar una línea en el final del archivo /etc/inittab.
e. Sumario del comando schedtune El comando schedtune es utilizado para manipular el scheduler y el swapper. Hay algunas diferencias importantes entre el comando incluido en AIX 4.3.2 y el de AIX 4.3.3. La sintaxis del comando schedtune es: schedtune [ -D | { [ -d n ] [ -e n ] [ -f n ] [ -h n ] [ -m n ] [ -p n ] [ -r n ] [ -t n ] [ -w n] } ]
4.5.3.2 Los comandos nice y renice El comando nice puede ejecutar un proceso con una prioridad menor a la normal. Con el usuario root se puede ejecutar un proceso con prioridad mayor a la normal. La prioridad del proceso es también llamada valor nice, pero mientras que en cada tick del reloj la prioridad de un proceso es recalculada, el valor nice es estable y se manipula con los comandos nice o renice. El valor nice está comprendido entre 0 y 39, siendo 39 el de menor prioridad. Por ejemplo, si un proceso normalmente se ejecuta con un valor nice por defecto igual a 20, incrementando en 5 su valor nice, se ejecutará con menor prioridad, 25, y el proceso deberá correr más lentamente. El valor nice puede verse en la columna NI de la salida del comando ps: $ ps -lu F S 200001 A 200001 A 200001 A 200001 A
Dos comando fueron iniciados en background, como muestra el valor nice 24, mientras que el comando ps se ejecuta interactivamente con un valor nice igual a 20.
a. Ejecutando un comando con nice Cualquier usuario puede ejecutar un comando con una prioridad menos favorable que la normal utilizando el comando nice. Sólo el usuario root puede utilizar el comando nice para ejecutar un comando con una prioridad más favorable que la normal. Para el usuario root, el rango de valores del comando nice está comprendido entre -20 y 19. Con el comando nice, el usuario especifica un valor para ser sumado o restado al valor nice por defecto. El valor nice modificado es utilizado por los procesos que ejecuta el comando especifica-
Página 167 de 283
do. La prioridad de los procesos es aun no fija; esto es, el valor de prioridad es aun recalculado periódicamente en base al uso de CPU, al valor nice, y en menor medida al valor de prioridad del proceso. El usuario thomasc, que no es root, tiene disponible un rango de valores nice comprendido entre 1 y 19. Obsérvese que cuando se aplica un valor nice a un comando en background, el valor NI es 39 aún cuando el valor calculado debería ser 43 (24 + 19), como muestra el siguiente ejemplo: # id uid=15610(thomasc) gid=0(system) # nice -19 ./tprof.tctestprg & # ps -al|head -1 ; ps -al |grep tctestprg F S UID PID PPID C PRI NI ADDR 200001 A 15610 14740 15490 90 126 39 5888 240001 A 15610 15818 1 90 118 24 408b 240001 A 15610 16792 1 89 118 24 e89e
El usuario root tiene la posibilidad de disminuir el valor nice. Obsérvese la sintaxis: el primer guión (-) es sólo un marcador de opción, y el otro guión le indica al nice que debe sustraer 15 del valor por defecto de 24 (el proceso es iniciado en background). Por ejemplo: # nice --15 ./tprof/tctestprg & # ps -al|head -1 ; ps -al |grep tctestprg F S UID PID PPID C PRI NI ADDR SZ TTY TIME CMD 200001 A 15610 14740 15490 91 126 39 5888 44 pts/3 4:37 tctestprg 240001 A 15610 15818 1 92 119 24 408b 44 pts/1 54:41 tctestprg 200001 A
0 16304 12948 85
240001 A 15610 16792
1 92
84
9 c0bb 44 pts/1
0:03 tctestprg
59 -- e89e 44 pts/1 54:34 tctestprg
Otra forma de ejecutar el comando nice, para obtener los mismos resultados que en el ejemplo anterior, sería con el flag -n, de la siguiente manera: # nice -n -15 ./tprof/tctestprg &
Es únicamente en este caso, donde root reduce el valor nice, que un cambio significativo es visto en el valor de prioridad. En la salida anterior, los valores nice=39 y nice=24 generan valores de prioridad similares (columna PRI), pero el proceso 16304, iniciado por root con nice=9, tiene una ventaja significativa con un valor de prioridad igual a 84. La salida muestra además es escenario donde un proceso es ejecutado con una prioridad fija (PID 16792). En la columna PRI, la prioridad fijada es 59, y la columna NI no muestra un valor. Esto puede realizarse con la subrutina setpri. Esta subrutina fija la prioridad de scheduling de todos los threads para que sean constantes.
b. Cambiando el valor nice de un thread en ejecución El comando renice, que tiene una sintaxis similar al comando nice, permite modificar el valor nice de un proceso en ejecución. Por ejemplo, sustrayendo 5 del valor actual 9, en el PID 16304: # renice -n -5 16304 # ps -al|head -1 ; ps -al |grep tctestprg F S UID PID PPID C PRI NI ADDR 200001 A 15610 14740 15490 94 126 39 5888 240001 A 15610 15818 1 94 120 24 408b 200001 A 0 16304 12948 86 76 4 c0bb 240001 A 15610 16792 1 94 120 24 e89e
SZ 44 44 44 44
TTY pts/3 pts/1 pts/1 pts/1
TIME 17:13 67:17 12:37 67:10
CMD tctestprg tctestprg tctestprg tctestprg
El PID es utilizado para identificar qué programa (o más correctamente qué thread) debe ser manipulado.
Página 168 de 283
c. Sumario de los comando nice y renice Los comandos nice y renice son utilizados para manipular el valor nice de los threads de un proceso. La sintaxis del comando nice es la siguiente: nice [ - Incremento| -n Incremento ] Comando [ Argumento ... ]
La sintaxis del comando renice es la siguiente: renice [ -n Incremento ] [ -g | -p | -u ] ID ...
Nota No se debe manipular el scheduler sin un profundo conocimiento de los mecanismos que lo controlan.
4.5.4 El comando bindprocessor El comando bindprocessor asigna (bound) o des-asigna (unbound) los threads del kernel de un proceso, o lista los procesadores disponibles. Para asignar o des-asignar threads, requiere dos parámetros: bindprocessor Proceso NumDeProcesador
El parámetro Proceso es el identificador de proceso del proceso cuyos threads son asignados o des-asignados, y el parámetro NumDeProcesador es el número de procesador lógico del procesador a utilizar. Si el NumDeProcesador es omitido, el proceso es asignado a un procesador seleccionado aleatoriamente. Un proceso en sí mismo no es asignado, sí en cambio sus threads del kernel. Una vez que los threads del kernel son asignados, siempre serán ejecutados en el procesador escogido, a menos que sean des-asignados. Cuando un thread nuevo es creado, tiene las mismas propiedades que su creador. Esto se aplica para el thread inicial en un proceso nuevo creado por la subrutina fork: el thread nuevo hereda las propiedades de asignación del thread que llamó al fork. Cuando es llamada la subrutina exec, las propiedades del thread se mantienen sin modificarse. Para verificar que procesador está disponible, ingrese el siguiente comando: # bindprocessor -q The available processors are: 0 1 2 3
Para asignar el proceso 16792 al procesador 2, ingrese el siguiente comando: # bindprocessor 16792 2
Para verificar qué thread del kernel es asignado a cuál procesador, observe la columna BND de la salida del comando ps: # ps -mo USER root root thomasc root -
4.5.5 El comando vmtune El comando vmtune cambia parámetros operacionales del Virtual Memory Manager (VMM) y otros componentes del AIX. El comando vmtune se encuentra en el directorio /usr/samples/kernel. Es instalado con el fileset bos.adt.samples. La sintaxis del comando vmtune es la siguiente: vmtune [ -b numfsbuf ] [ -B numpbuf ] [ -c numclust ] [ -f minfree ] [ -F maxfree ] [ -k npskill ] [ -l lrubucket ] [ -M maxpin ] [ -N pd_npages ] [ -p minperm ] [ -P maxperm ] [ -r minpgahead ] [ -R maxpgahead ] [-u lvm_budcnt] [ -w npswarn ] [-W maxrandwrt]
El siguiente es un ejemplo del comando vmtune ejecutado sin flags: # /usr/samples/kernel/vmtune vmtune: current values: -p -P -r -R -f -F -N -W minperm maxperm minpgahead maxpgahead minfree maxfree pd_npages maxrandwrt 26007 104028 2 8 120 128 524288 0 -M -w -k -c -b -B -u -l -d maxpin npswarn npskill numclust numfsbufs hd_pbuf_cnt lvm_bufcnt lrubucket defps 104851 4096 1024 1 93 80 9 131072 1 -s -n -S -h sync_release_ilock nokillroot v_pinshm strict_maxperm 0 0 0 0 number of valid memory pages = 131063 maximum pinable=80.0% of real memory number of file memory pages = 102029
maxperm=79.4% of real memory minperm=19.8% of real memory numperm=77.8% of real memory
El Virtual Memory Manager (VMM) mantiene una lista de frames de páginas de la memoria real libres. Estos frames de páginas están disponibles para guardar páginas de la memoria virtual necesarias para satisfacer un page fault. Cuando la cantidad de páginas en la lista free es menor que la cantidad especificada por el parámetro minfree, el VMM comienza a robar páginas para agregarlas a la lista free. El VMM continúa robando páginas hasta que la lista free tenga al menos la cantidad de páginas especificadas por el parámetro maxfree. Si la cantidad de páginas permanentes en memoria es menor que la cantidad especificada por el parámetro minperm, el VMM roba frames de páginas computacionales o páginas permanentes, sin importar las tasas de repage. Si la cantidad de páginas permanentes es mayor que la cantidad especificada por el parámetro maxperm, el VMM roba únicamente páginas permanentes. El VMM normalmente roba únicamente páginas permanentes, pero si la tasa de repage de las páginas permanentes es mayor que la tasa de repage de páginas computacionales, éstas también son robadas. Si un proceso parece estar leyendo secuencialmente de un archivo, los valores especificados por el parámetro minpgahead determinan la cantidad de páginas a ser leídas cuando la condición es detectada por primera vez. El valor especificado por el parámetro maxpgahead indica la cantidad máxima de páginas que serán leídas, sin importar la cantidad de lecturas secuenciales precedentes. El comando vmtune puede ser ejecutado únicamente por root. Los cambios realizados permanecen hasta el siguiente reinicio del sistema. Si es necesario realizar un cambio permanente, el comando vmtune apropiado debe colocarse en el archivo /etc/inittab.
Página 170 de 283
Estos son los flags y algunas limitaciones:
-b numfsbuf
Especifica la cantidad de bufstructs de los file systems. El valor por defecto en AIX es 93 porque depende del tamaño de los bufstruct. Este valor debe ser mayor a 0. Incrementar este valor mejora el rendimiento para escrituras de gran tamaño (en dispositivos que soportan escrituras muy rápidas). Para activar este valor, se deben desmontar los file systems, cambiar el valor, y montar nuevamente los file systems.
-B numpbuf
Controla la cantidad de pbufs disponible para el controlador de dispositivos del LVM. Los pbufs son buffers de memoria pinned utilizados para contener los requerimientos de I/O relativos a un Journaled File System (JFS). En sistemas donde hay gran cantidad de operaciones de I/O secuencial, esto puede resultar en cuellos de botella de requerimientos de I/O en la capa LVM esperando que sean liberados pbufs. En AIX Versión 4, un pubf es utilizado para cada requerimiento de I/O secuencial, sin importar la cantidad de páginas de ese I/O. El valor máximo es 128.
-c numclust
Especifica la cantidad de clusters de 16 KB procesados por el algoritmo de escritura retrasada (write-behind algorithm). El valor por defecto es 1. Los valores pueden ser cualquier entero mayor a 0. Gran cantidad de clusters puede resultar en un lento rendimiento de escrituras secuenciales en dispositivos que soportan escrituras muy rápidas (RAID y otros). Configurando como valor un número muy alto, como 500000, esencialmente derrota al algoritmo de escritura retrasada. Esto puede ser beneficioso en casos como la creación de índices de bases de datos, donde las páginas que fueron escritas son leídas inmediatamente después; la escritura retrasada puede provocar que el proceso tarde más tiempo. Una sugerencia es desactivar la escritura retrasada antes de realizar los índices y activarla una vez que estos están listos. Por ejemplo, el comando mkpasswd se ejecuta significativamente más rápido cuando la escritura retrasada es desactivada.
-f minfree
Especifica la cantidad mínima de frames en la lista free. Este número está comprendido entre 8 y 204800. El valor por defecto depende de la cantidad de RAM en el sistema. El valor por defecto del minfree es la mitad del valor del maxfree: 8. El valor del maxfree es igual al minimum (la cantidad de páginas de memoria divididas por 128). El delta entre minfree y maxfree debe ser siempre igual o mayor al maxpgahead.
-F maxfree
Especifica la cantidad de frames que deben haber en la lista free para que se detenga el robo de páginas. Este número está comprendido entre 16 y 204800, pero debe ser mayor que el valor especificado para el parámetro minfree, por una diferencia al menos igual al valor del maxpgahead.
-k npskill
Especifica la cantidad de páginas libres del espacio de paginado que deben haber para que el AIX comience a matar procesos. La fórmula para determinar el valor por defecto del npskill en AIX Versión 4 es: MAX(64, cantidad-de-páginas-en-el-espacio-de-paginado/128) El valor npskill debe ser mayor que 0 y menor que la cantidad total de páginas en el espacio de paginado. El valor por defecto es 128.
Página 171 de 283
-l lrubucket
Este parámetro especifica el tamaño (en páginas de 4 KB) del bucket de reemplazo de páginas menos utilizadas recientemente (least recently used o LRU). Esta es la cantidad de frames de páginas que serán examinados al mismo tiempo por posibles pageouts cuando un frame libre es necesitado. Un número menor provoca una menor latencia cuando se busca un frame libre pero también provoca un comportamiento que no es similar al verdadero algoritmo LRU. El valor por defecto es 512 MB y el mínimo es 256 MB. No se recomienda modificar esta opción.
-M maxpin
Especifica el porcentaje máximo de memoria real que puede ser pinned. El valor por defecto es 80 por ciento. Si este valor es modificado, el nuevo valor debe asegurar que queden al menos 4 MB de memoria real no pinned para ser utilizados por el kernel. El valor del maxpin debe ser mayor a 1 y menor a 100. El valor bajo maxpin es convertido a porcentaje al final de la salida del vmtune.
-N pd_npages
Especifica la cantidad de páginas que deben ser borradas de una porción de la RAM cuando un archivo es eliminado. Cambiar este valor beneficiará únicamente a las aplicaciones de tiempo real que borran archivos. Reduciendo el valor de pd_npages, una aplicación de tiempo real puede obtener un mejor tiempo de respuesta porque será menor la cantidad de páginas eliminadas antes de que un proceso o thread sea ejecutado. El valor por defecto es el tamaño de archivo mayor posible dividido por el tamaño de página (actualmente 4096); si el tamaño de archivo máximo posible es 2 GB, entonces el pd_npages es, por defecto, 524288.
-p minperm
Especifica el punto debajo del cual las páginas permanentes son protegidas del algoritmo repage. Este valor es un porcentaje del total de frames de páginas de memoria real en el sistema. El valor especificado debe ser mayor o igual a 5. El valor por defecto del porcentaje minperm es siempre alrededor de un 17-19 por ciento de la memoria.
-P maxperm
Especifica el punto sobre el cual el algoritmo de robo de páginas roba únicamente páginas permanentes. Este valor está expresado como un porcentaje del total de frames de páginas de memoria real en el sistema. El valor especificado debe ser mayor o igual a 5. El valor por defecto del porcentaje maxperm es siempre alrededor de un 75-80 por ciento de la memoria. Un servidor puramente NFS puede obtener una mejora del rendimiento incrementando el valor del maxperm. Un sistema que accede archivos grandes (por encima del 50-75 por ciento de la cantidad de RAM en el sistema; ver el numperm para observar cuánta memoria es utilizada actualmente para el mapeo de archivos) puede beneficiarse incrementando el valor maxperm. Este parámetro puede reducirse en sistemas con grandes requerimientos de almacenamiento de trabajo (la columna AVM del vmstat comparada con el total de frames de páginas reales) para reducir o eliminar el I/O del espacio de paginado.
-r minpgahead
Especifica la cantidad de páginas con las que comienza una lectura secuencial. Este valor está comprendido entre 0 y 4096. Debe ser una potencia de 2. El valor por defecto es 2.
-R maxpgahead
Especifica la cantidad máxima de páginas que serán leídas. Este valor está comprendido entre 0 y 4096. Debe ser una potencia de 2 y debe ser mayor
Página 172 de 283
o igual al minpgahead. El valor por defecto es 8. Incrementar este número ayudará a mejorar el rendimiento de grandes lecturas secuenciales. Por otras limitaciones en el kernel y el Logical Volume Manager (LVM), el valor máximo no debe ser mayor a 128. El delta entre minfree y maxfree debe se siempre igual o mayor al maxpgahead.
-u lvm_bufcnt
Especifica la cantidad de buffers del LVM para los requerimientos de I/O raw. El valor por defecto es 9. Los posibles valores están comprendidos entre 1 y 64. Es beneficioso incrementar este valor si se realizan grandes operaciones de I/O raw (esto es, sin utilizar JFS).
-w npswarn
Especifica la cantidad de paginas libres en el espacio de paginado en las que el AIX comienza a enviar la señal SIGDANGER a los procesos. La fórmula para determinar el valor por defecto es: MAX(512, 4*npskill) El valor de npswarn debe ser mayor a 0 y menor que la cantidad total de páginas en el espacio de paginado del sistema. El valor por defecto es 512.
-W maxrandwrt
Especifica un umbral (en páginas de 4 KB) de escrituras aleatorias que se deben acumular en RAM, antes que sean sincronizadas a disco utilizando un algoritmo de escritura retrasada. La base de este umbral es por archivo. La opción –W maxrandwrt está disponible a partir de la versión 4.1.3 de AIX y posteriores. El valor por defecto es 0, lo que deshabilita la escritura retrasada aleatoria. Activándola (un valor típico podría ser 128), las aplicaciones que realizan una gran cantidad de escrituras aleatorias pueden obtener un mejor rendimiento debido a la menor dependencia del daemon sync para forzar las escrituras a disco. Algunas aplicaciones pueden empeorar su rendimiento debido a la escritura retrasada (como creación de índices de bases de datos). En estos casos, será más beneficioso desactivar la escritura retrasada antes de crea índices de bases de datos y reactivarla después de la creación de los índices.
4.5.6 Workload Manager El Workload Manager le permite al administrador del sistema dividir recursos entre procesos sin tener que particionar el sistema. WLM provee aislamiento entre comunidades de usuarios con muy diferentes comportamientos del sistema, como procesos interactivos o de poco uso de CPU, por cargas de trabajo con otras características como procesos batch o de gran uso de memoria. La configuración del WLM es mucho más simple que el particionamiento donde es requerida la reinstalación y reconfiguración. Con WLM, un solo sistema operativo maneja el sistema entero y todos los procesos; por lo tanto, sólo es administrado un sistema. WLM maneja porcentajes de tiempo de CPU en vez de CPUs. Esto permite el control sobre los recursos de CPU en un alto nivel de detalle. El tiempo de CPU, memoria y ancho de banda de I/O son manejados separadamente. Por lo tanto, pueden manejarse aplicaciones de diferentes estilos. EL AIX Workload Manager (WLM) es una facilidad del sistema operativo introducida en AIX Versión 4.3.3. Es parte del kernel del sistema operativo sin costo adicional. AIX WLM provee la facilidad básica de darle a los administradores del sistema más control sobre cómo el scheduler, el Virtual Memory Manager (VMM), y las llamadas de los controladores de dispositivos asignan CPU, memoria física, y ancho de banda de I/O a los usuarios, grupos, path de aplicaciones, tipos de proceso o etiquetas de aplicaciones basados en clases.
Página 173 de 283
Las clases pueden ser superclases o subclases. El AIX WLM se auto-regula cuando no hay trabajos en una clase o cuando una clase no utiliza todos los recursos que tiene asignados. Los recursos serán distribuidos automáticamente a otras clases para cumplir con las políticas del administrador del sistema. Como el scheduling es realizado dentro de un solo sistema operativo AIX, el manejo del sistema es menos complejo. A diferencia del LPAR, el manejo de la carga de trabajo no permite sistemas operativos múltiples, que pueden ser útiles para testing y certificación en un solo sistema físico.
4.6 Escenarios de rendimiento En este capítulo se muestra una colección de escenarios que permiten un mejor entendimiento de la relación entre las herramientas, sus salidas, y un problema que es necesario solucionar.
4.6.1 Escenario de rendimiento de CPU En esta sección, se muestra un problema de rendimiento básico relativo a CPU saturada, con conclusiones hechas en base a la salida de comandos previamente analizados.
4.6.1.1 Colección de datos El escenario consiste en una F50 de 2 procesadores con 50 clientes Netstation conectados sobre ethernet. Los usuarios utilizan una aplicación HTML como interfase para una base de datos. Ahora los usuarios se quejan porque los tiempos de respuesta son muy malos. Cuando abren una ventana del navegador en una Netstation, el inicio parece lento. Para verificar esto, el inicio del browser es ejecutado con el comando time: # time netscape real 0m16.73s user 0m0.83s sys 0m0.63s
Ejecutando time netscape, se puede verificar que el inicio fue lento, el inicio de un browser en el sistema ejemplificado debería ser por debajo de los 10 segundos. En la salida se puede ver que el sistema espera más de 15 segundos (user + sys =1.46 segundos de un total de 16.73 segundos). En muchos casos los sistemas esperan por I/O, por lo que se debe ejecutar iostat: tty:
tin 0.0
Disks: hdisk0 hdisk1 hdisk2 hdisk3 cd0 tty:
Disks: hdisk0 hdisk1
tout 328.5 % tm_act 0.0 0.0 0.0 0.0 0.0
tin 0.0
tout 332.1 % tm_act 0.0 0.0
avg-cpu: % user
100.0 Kbps 0.0 0.0 0.0 0.0 0.0
tps 0.0 0.0 0.0 0.0 0.0
Kb_read 0 0 0 0 0
avg-cpu: % user
100.0 Kbps 0.0 0.0
tps 0.0 0.0
% sys 0.0
% sys 0.0
Kb_read 0 0
% idle 0.0
% iowait 0.0
Kb_wrtn 0 0 0 0 0 % idle 0.0
% iowait 0.0
Kb_wrtn 0 0
Página 174 de 283
hdisk2 hdisk3 cd0
0.0 0.0 0.0
0.0 0.0 0.0
0.0 0.0 0.0
0 0 0
0 0 0
No hay actividad contra los discos, pero %user muestra 100.0. El problema es probablemente relativo a CPU. El siguiente paso es verificar las colas de ejecución con el comando vmstat: # vmstat 2 5 kthr memory page faults ----- ----------- ------------------------ -----------avm fre re pi po fr sr cy in sy cs r b 0 0 0 0 0 0 101 10 7 0 0 17354 15755 0 0 0 0 0 0 407 2228 101 5 1 17354 15754 0 0 0 0 0 0 413 43 93 5 1 17354 15752 0 0 0 0 0 0 405 43 92 5 1 17354 15752 0 0 0 0 0 0 407 42 90 5 1 17354 15752
cpu ----------us sy id wa 63 0 37 0 99 0 0 0 99 0 0 0 99 0 0 0 99 0 0 0
4.6.1.2 Análisis de datos Cinco procesos en la cola de ejecución no es un estado normal para este sistema. El siguiente paso será encontrar cuales procesos están causando problemas. Esto se puede hacer con el comando ps: # ps -ef |sort +3 -r UID PID PPID thomasc 15860 12948 thomasc 16312 12948 thomasc 15234 12948 thomasc 16844 12948 thomasc 17420 12948 root 14778 3420 root 17154 3420 root 13676 15080 root 15080 1 root 4980 1 root 16510 3420 root 16022 10872 root 3420 5568 root 12948 12796
|head -15 STIME C 93 10:30:49 93 10:30:39 92 10:31:13 87 10:31:00 31 10:30:26 4 10:51:10 1 10:51:10 0 15:54:12 0 15:54:11 0 15:37:42 0 10:51:10 0 Jun 29 0 Jun 28 0 Jun 28
TTY STAT STIME TIME COMMAND pts/1 A 10:30:39 26:28 ./tcprg3 - A Jun 28 9544:43 kproc pts/1 A 10:30:49 21:49 ./tcprg5 pts/1 A 10:31:13 21:20 ./tcprg1 pts/1 A 10:31:00 19:13 ./tcprg2 pts/1 A 10:30:26 16:44 ./tcprg4 - A Jun 28 2679:27 kproc - A Jun 28 1263:12 kproc - A Jun 28 1258:58 kproc - A Jun 28 8:27 /usr/sbin/syncd 60 lft0 A Jun 29 7:05 topas n - A Jun 28 2:38 kproc - A Jun 28 1:26 swapper
Página 175 de 283
Un usuario, thomasc, ha iniciado cinco programas con el prefijo tcprg que han acumulado mucho tiempo de uso de CPU reciente (columna C). Cuando se observa la salida del ps auxwww ejecutado en segundo lugar se observa en la columna %CPU (reporta cuanto tiempo de CPU utilizó el proceso desde su inicio) que esos programas utilizan una cantidad excesiva de CPU.
4.6.1.3 Recomendación Hay varias formas de revertir la sobrecarga (por ejemplo, kill PID), pero lo más apropiado es contactar al usuario thomasc y realizarle preguntas como: ¿Qué son esos procesos?, ¿Por qué están ejecutándose – pueden detenerse?, ¿Deben ejecutarse ahora, pueden programarse para otra hora? Para obtener mejores resultados en cuanto al rendimiento, probablemente la mejor opción será ejecutar los procesos en un horario con menos actividad de CPU. Si los procesos se pueden ejecutar en otro momento, se puede hacer un scheduling con el comando batch, el at, o por medio del crontab. Se debe tener en cuenta que el inicio de estos procesos no debe interferir con OLTPs. Si los procesos deben ejecutarse sí o sí en momentos que la CPU está muy activa, y deberán ser ejecutados en el futuro en condiciones similares, algunos cambios deberán ser realizados para mejorar el balance del rendimiento del sistema. Una recomendación es mover estos programas de test a un sistema de test, separado del entorno productivo. Otra solución es agregar más CPUs, la cual es apropiada si el hardware lo soporta, aunque puede mover el cuello de botella a otro recurso, por ejemplo, memoria. Limitar el uso de recursos puede ser una solución, y para ello no hay nada mejor que el Workload Manager (WLM).
4.6.2 Escenario de rendimiento de I/O En este escenario, un usuario informa que el reporte final mensual está tardando mucho tiempo para ejecutarse y el usuario no está seguro sobre cuáles son las causas. Una razón posible es que cuando el AIX crea un trabajo de impresión, el trabajo es escrito primero en el spooler de impresión. Este archivo de spool es creado en disco en el directorio /var/adm/spool. Si hay un problema de I/O donde el sistema espera para acceder al disco, entonces este archivo puede tardar mucho en generarse, especialmente si es un archivo grande.
4.6.2.1 Colección de datos En esta sección, las salidas del sistema son recolectadas por los comandos vmstat e iostat. La siguiente es la salida del comando iostat: # iostat 1 2 tty:
4.6.2.2 Análisis de datos En esta sección, serán identificados los indicadores clave de la salida y en base a éstos, se realizará una explicación.
a. Análisis de la salida del comando vmstat A pesar de que el comando vmstat es una herramienta de diagnóstico de memoria, muestra una columna de I/O. Se debe observar en la sección de cpu, la columna wa; el promedio de la salida es de un 85 por ciento (se suma toda la columna, menos la primera línea y se divide por 9). Si el valor wa es más alto que un 25 por ciento, indica un problema con el subsistema de disco. El valor alto del wa obliga a revisar dos columnas adicionales. Debajo de kthr, kernel threads, la columna b indica que hay 2-3 threads en espera por segundo. Debajo de memory, la columna fre, indica que la cantidad de frames del buffer disponibles es muy baja.
b. Análisis de la salida del comando iostat Los valores clave a verificar aquí son el % iowait y el % tm_act. Se debe recordar que la primera salida es el promedio desde el inicio del sistema. El valor %iowait El % iowait es el porcentaje de tiempo de CPU idle esperando una operación de I/O local.
Página 178 de 283
En este ejemplo, el %iowait tiene un promedio del 89.9 por ciento (sumando toda la columna, restando la primera y dividiendo por 9). Si el valor de % iowait es mayor al 25 por ciento, es aconsejable investigar el problema y realizar las acciones correctivas. El valor %tm_act El %tm_act es el porcentaje de tiempo en el que el disco está ocupado. En este ejemplo, el valor % tm_act tiene un promedio del 18.8 por ciento para el hdisk0 y un promedio del 99.7 por ciento para el hdisk1. Si el porcentaje de tiempo en que un disco está activo es muy alto, en un sistema pequeño con pocos discos será muy notable la degradación del rendimiento. Para brindar un buen rendimiento, el sistema debe registrar un promedio de actividad de disco menor al 40 por ciento. Sin embargo, esto no es posible con sistemas pequeños con pocos discos.
4.6.2.3 Recomendación Las siguientes son algunas recomendaciones que ayudan a mejorar el I/O de disco: • Se deben buscar discos inactivos en el sistema; si es posible, se deben mover los datos de discos muy activos a discos inactivos, lo que sin dudas mejorará el rendimiento. • Se debe verificar la actividad de paginado, ya que puede ser otro factor importante. Es recomendable distribuir el paginado sobre la mayor cantidad de discos posible, para dividir la carga. • Si los problemas ocurren ocasionalmente durante fin de mes, se debe revisar que otros procesos están corriendo y si pueden ejecutarse en otro momento; de esta manera, la carga estará mejor distribuida en el tiempo.
4.6.3 Escenarios de I/O adicionales Los siguientes escenarios son ejemplos de problemas de rendimiento de I/O. Los reportes de los comandos utilizados ayudarán a realizar una optimización del sistema
El reporte del vmstat es tomando durante un período de 20 minutos utilizando un intervalo de 120 segundos repetido 10 veces. Los primeros valores interesantes en este reporte son los de cpu (us/sy/id/wa). En estos valores hay algo de tiempo idle (id), pero los valores más grandes son de I/O wait (wa). El tiempo de I/O wait se incrementaba a lo largo del período analizado desde un 50 por ciento
Página 179 de 283
hasta un pico del 92 por ciento en la novena medición. El promedio de tiempo de I/O wait es del 72 %, lo que indica un cuello de botella en I/O. La columna wa especifica el porcentaje de tiempo que la CPU estuvo idle esperando un I/O local a disco. Generalmente, un valor wa superior al 25 por ciento indica que el subsistema de disco puede no estar bien balanceado, o es el resultado de una actividad intensiva de disco. Se debe revisar el valor b en la columna de thread del kernel. La columna b lista el promedio de thread del kernel que fueron puestos en la cola de espera por segundo y debería ser cercana a 0. Estos threads están esperando recursos o I/O. En este caso, el problema no se puede relacionar con la memoria, ya que los parámetros de paginado están todos en cero y la lista de páginas de memoria libres (fre) es aceptable. Para obtener más información sobre dónde ocurre el cuello de botella, se debe ejecutar el comando iostat. Este provee información sobre cómo el I/O de disco es distribuido entre los volúmenes físicos.
4.6.3.2 Distribución de I/O Este escenario devuelve las siguientes salidas de los comandos lsps y iostat: # lsps -a Page Space Physical Volume Volume Group hd6 rootvg hdisk0 # iostat 120 5 ... tty: tin tout avg-cpu: % user 47.8 1394.6 50.3 Disks: hdisk0 hdisk1 hdisk2 tty:
El comando lsps muestra que el espacio de paginado está configurado en el hdisk0. El reporte del iostat es tomado durante un período de 10 minutos cada 120 segundos de intervalo. El primer intervalo no es mostrado y se debe ignorar en un análisis en tiempo real, ya que es el promedio histórico desde el reinicio del sistema. Obsérvese el alto tiempo de I/O wait (% iowait), que aumenta desde un 5.1 por ciento a un 30 por ciento. Generalmente, si el tiempo de I/O wait excede un 25 por ciento, hay un problema relativo al I/O de disco. Hay casos donde el tiempo de I/O wait es del 0 por ciento y sin embargo hay un cuello de botella de I/O. Esto puede ocurrir cuando el sistema está realizando un extenso paginado y el dispositivo de swap está sobrecargado. En el reporte del iostat, la actividad en el hdisk0 es extremadamente alta. El % tm_act, que indica la actividad del disco en porcentajes, se mantiene entre el 97 por ciento y el 99.8 por ciento, lo que indica que está prácticamente activo en forma constante. Esto indica que el cuello de botella de I/O está en el disco hdisk0. Observando el valor Kb_wrtn, vemos que los datos escritos al disco son muy altos en comparación con los datos leídos. Esto indica que el límite de I/O del hdisk0 fue alcanzado. Para mejorar el rendimiento de I/O, los otros discos deberían utilizarse más, moviendo los archivos, file systems y volúmenes lógicos más activos a los discos menos activos. En general, una investigación más intuitiva es requerida utilizando otras herramientas como el filemon y el lslv.
4.6.3.3 Fragmentación de un volumen lógico El comando lslv es utilizado para mostrar los atributos de los volúmenes lógicos, como la fragmentación. La siguiente salida del lspv muestra un volumen lógico fragmentado: lslv -p hdisk0 lv00 hdisk0:lv00:N/A 0001 0002 0003 0011 0012 0013 0021 0022 0023 0031 0032
0004 0014 0024
0005 0015 0025
0006 0016 0026
0007 0017 0027
0008 0018 0028
0009 0019 0029
0010 0020 0030
1-10 11-20 21-30 31-32
0033 0043 0053 0063
0034 0044 0054 0064
0035 0045 0055
0036 0046 0056
0037 0047 0057
0038 0048 0058
0039 0049 0059
0040 0050 0060
0041 0051 0061
0042 0052 0062
33-42 43-52 53-62 63-64
USED USED USED USED
USED USED USED
USED USED USED
USED USED USED
USED USED USED
USED USED USED
USED USED USED
USED USED USED
USED USED USED
USED USED USED
65-74 75-84 85-94 95-95
USED FREE FREE 0068
USED FREE FREE 0069
USED FREE FREE
USED FREE FREE
USED FREE FREE
USED FREE FREE
USED FREE FREE
FREE FREE 0065
FREE FREE 0066
FREE FREE 0067
96-105 106-115 116-125 126-127
FREE USED USED USED
0070 USED USED USED
0071 USED USED
USED USED USED
USED USED USED
USED USED USED
USED USED USED
USED USED USED
USED USED USED
USED USED USED
128-137 138-147 148-157 158-159
El volumen lógico conformado por 71 particiones lógicas está fragmentado en cuatro de las cinco secciones de la política de asignación intra. Las secciones borde externo (outer edge) y medio
Página 181 de 283
externo (outer middle) están asignadas entre las particiones lógicas 01-32 y 33-64 respectivamente en similares particiones físicas contiguas. Las particiones lógicas 65-69 están asignadas en la sección medio interno y las últimas dos particiones lógicas están asignadas a la sección borde interno. Esta obvia fragmentación del volumen lógico lv00 puede inducir una disminución del rendimiento de I/O debido a mayores tiempos de búsqueda y a los cambios de cabeza del disco para una operación de lectura/escritura secuencial en la última parte del volumen lógico. Como en el volumen físico hay espacio libre, es posible realizar una reorganización del lv00. Se debe utilizar el comando reorgvg con ese fin, y esto ayudará a mejorar el rendimiento del volumen lógico.
4.6.3.4 Monitoreando el escenario utilizando filemon Teniendo en cuenta un sistema con los siguientes discos disponibles: # lspv hdisk0 hdisk1
000bc6fdc3dc07a7 000bc6fdbff75ee2
rootvg none
La siguiente salida muestra una sección de un reporte del filemon realizado para monitorear los volúmenes lógicos del sistema. El reporte fue realizado con el siguiente comando: filemon -O lv –o filemon.out
La salida muestra que el volumen lógico hd1, que contiene el file system /home, tiene por lejos la mayor utilización. Como el segundo volumen físico no es utilizado, como se ve en la salida del lspv, es posible agregar este volumen físico al rootvg y distribuir el hd1 para que utilice ambos hdsik0 y hdisk1. Esto se puede realizar configurando el volumen lógico con una política inter maximum o utilizando la opción de striping.
4.6.3.5 Asignación de volumen lógico El siguiente escenario muestra una serie de comandos que muestran el estado de un sistema con un problema de asignación en un grupo de volúmenes dedicado a una base de datos: # lsps -s Total Paging Space 100MB # lsps -a
Percent Used 37%
Page Space
Physical Volume
hd6
hdisk0
Volume Group
rootvg
Size
100MB
%Used
38
Active
yes
Auto
yes
Type
lv
Esto muestra que el espacio de paginado está definido en el hdisk0 del rootvg. La siguiente es la información del grupo de volúmenes:
Esto muestra que hay dos grupos de volúmenes definidos, rootvg en hdisk0 y datavg en hdisk1, hdisk2, y hdisk3. El hdisk0 contiene los siguientes volúmenes lógicos: # lspv -l hdisk0 hdisk0: LV NAME hd5 hd3 hd2 hd8 hd4 hd9var hd6 hd1 lv00
LPs 2 6 117 1 2 1 128 3 10
PPs 2 6 117 1 2 1 128 3 10
DISTRIBUTION 02..00..00..00..00 02..00..04..00..00 00..47..42..28..00 00..00..01..00..00 00..00..02..00..00 00..00..01..00..00 29..50..49..00..00 00..00..01..02..00 00..00..00..10..00
MOUNT POINT N/A /tmp /usr N/A / /var N/A /home /database
El rootvg en el hdisk0 contiene todos los volúmenes lógicos y file systems por defecto y un lv00 adicional que contiene el file system /database. El otro disco contiene: # lspv -l hdisk1 hdisk1: LV NAME loglv00 lv01 lv02 lv03 # lspv -l hdisk2 hdisk2: LV NAME # lspv -l hdisk3 hdisk3: LV NAME
LPs 1 10 10 10
PPs 1 10 10 10
DISTRIBUTION 01..00..00..00..00 00..00..00..00..10 00..00..00..00..10 10..00..00..00..00
MOUNT POINT N/A /db01 /db02 /db03
LPs
PPs
DISTRIBUTION
MOUNT POINT
LPs
PPs
DISTRIBUTION
MOUNT POINT
Los volúmenes lógicos del grupo de volúmenes datavg están asignados en el mismo volumen físico hdisk1, incluso el log de jfs loglv00. Además se ve que los volúmenes físicos hdisk2 y hdisk3 no son utilizados. Los siguientes son los detalles del volumen lógico datavg: # lslv lv01 LOGICAL VOLUME: lv01 LV IDENTIFIER: 0000881962b29b51.1 VG STATE: active/complete TYPE: jfs MAX LPs: 512 COPIES: 1 LPs: 1 STALE PPs: 0 INTER-POLICY: minimum INTRA-POLICY: middle MOUNT POINT: /db01 MIRROR WRITE CONSISTENCY: on EACH LP COPY ON A SEPARATE PV ?: yes # lslv lv02 LOGICAL VOLUME: lv02
Cuando se generan los volúmenes lógicos lv01, lv02, y lv03, el administrador del sistema debería haber dedicado cada uno de ellos en un volumen físico diferente. Alternativamente, se podría haber definido la política inter en maximum y limitando el upper bound en 1. De esta manera, el lv01 y el correspondiente /db01 residiría en el hdisk1, el lc02 y /db02 en el hdisk2 y el lv02 y /db02 en el hdisk3. Es posible modificar la situación actual utilizando el comando migratepv. Además, para distribuir la carga del jfslog del hdisk1 en los otros discos, se puede crear un jfslog adicional por file system. Definiendo un jfs log dedicado para el /db02 y /db03 se incrementaría el rendimiento. De esta manera, los diferentes file systems no incrementan la carga del hdisk1 para utilizar el jfs log.
4.6.4 Escenario de rendimiento del paginado En esta sección, se investigará el rendimiento del paginado. Serán descriptos los síntomas de la utilización excesiva de memoria y las posibles acciones correctivas.
4.6.4.1 Colección de datos Para coleccionar los datos serán utilizados los comandos svmon y vmstat. La siguiente salida fue tomada con el comando vmstat con el sistema inactivo: # vmstat 1 5 kthr memory page ----- ----------- -----------------------r b avm fre re pi po fr sr cy 0 0 11106 107916 0 0 0 0 0 0 0 0 11106 107915 0 0 0 0 0 0 0 0 11106 107915 0 0 0 0 0 0 0 0 11106 107915 0 0 0 0 0 0 0 0 11106 107915 0 0 0 0 0 0
faults cpu ------------ ----------in sy cs us sy id wa 125 570 66 1 4 88 7 112 397 42 0 0 98 2 107 192 23 0 0 99 0 110 280 28 0 0 99 0 109 174 27 1 0 99 0
La siguiente es la salida del comando vmstat con el sistema sufriendo una alta utilización de memoria:
La siguiente salidas realizadas con el comando vmstat serán utilizadas como referencia o comparación. La siguiente salida corresponde al comando ps: # ps gv | head -n 1; ps gv | egrep -v "RSS" | sort +6b -7 -n –r
La siguiente es la salida del comando svmon: # svmon -i 5 5 memory pg space
size 131063 131072
inuse 130936 106986
free pin 127 6946
pin in use
work 6955 104809
pers 0 26127
clnt 0 0
memory pg space
size 131063 131072
inuse 130942 108647
free 121
pin in use
work 6951 105067
pers 0 25875
clnt 0 0
memory pg space
size 131063 131072
inuse 130951 110432
pin in use
work 6955 104809
pers 0 26127
memory pg space
size 131063 131072
inuse 130942 108647
pin in use
work 6951 105067
pers 0 25875
virtual 204676
pin 6942
virtual 206567
free pin 113 6942
virtual 208406
clnt 0 0 free pin 121 6942
virtual 206567
clnt 0 0
Página 186 de 283
memory pg space
size 131063 131072
inuse 130951 110432
pin in use
work 6951 105127
pers 0 25824
free pin 113 6942
virtual 208406
clnt 0 0
La siguiente salida del svmon muestra los diez procesos que más memoria están utilizando: # svmon -Pu -t 10 -----------------------------------------------------------------------------------------------------------------------------------------------------------
Pid Command 12478 memory
Vsid
Inuse
Pin
Pgsp
Virtual
64-bit
Mthrd
92498
1259
95911
189707
N
N
Esid Type Description
Inuse
7a80 d18a 4358 0
5 3 4 0
work work work work
shmat/mmap shmat/mmap shmat/mmap kernel seg
52911 31670 4963 1522
8811 c93 e6ec 5d79 e28c 735e 767c 3e76 634c
d 8 7 6 9 a 2 f 1
work work work work work work work work pers
shared library text shmat/mmap shmat/mmap shmat/mmap shmat/mmap shmat/mmap process private shared library data code,/dev/hd3:21
maxperm=79.4% of real memory minperm=19.8% of real memory numperm=10.3% of real memory
Mostrar la cantidad de procesadores con el comando lsdev: # lsdev -Ccprocessor proc0 Available 00-00 Processor
Este es un sistema de un sólo procesador.
4.6.4.2 Análisis de los datos Tomando las salidas de la sección anterior, se pueden investigar los distintos componentes del sistema para determinar que área está causando problemas de rendimiento. Para esta investigación, la salida más utilizada será la del comando vmstat. Las demás salidas son para información y confirmación.
a. La columna kthr (kernel thread) La columna kthr provee información sobre el promedio de threads en varias colas. Tanto la columna r como la b están bajas, indicando que el sistema está ejecutando los threads en forma adecuada. La contención de los recursos de CPU es baja.
b. La columna de memoria La columna de memoria muestra información sobre el uso de la memoria real y virtual. El tamaño de una página es 4096 bytes. En la columna avm se puede ver que el promedio de páginas asignadas aumentó. El sistema seguirá asignando páginas hasta que todo el espacio de paginado disponible (ver el comando lsps -a). Cuando todo el espacio de paginado utilizado alcance un 100%, el sistema comenzará a matar procesos liberando espacio de paginado. La columna fre muestra el promedio de páginas de memoria libres. El valor MINFREE para este sistema es 120, como muestra el comando vmtune. En este ejemplo, la memoria libre ronda el valor MINFREE hasta caer debajo de 100 y Iuego casi 0. Esto es uno de los indicadores de que el sistema está sufriendo trashing.
Página 190 de 283
c. La columna page La columna page muestra información sobre los page faults y la actividad de paginado. Estos promedios son entregados por segundo. El espacio de paginado es la parte de la memoria virtual que reside en disco. Es utilizado como contendor cuando la memoria es saturada. El paginado consiste en volúmenes lógicos de paginado dedicados al almacenamiento de conjuntos de páginas activas que fueron robadas de la memoria real. Cuando un página robada es llamada por un proceso, ocurre un page fault y la página debe ser movida del espacio de paginado a la memoria real. Siempre que una página del almacenamiento activo es robada, es escrita en el espacio de paginado. Si no llamada nuevamente, permanece en el dispositivo de paginado hasta que el proceso termina o libera el espacio. Cuando un proceso termina normalmente, todo el espacio de paginado asignado para el proceso es liberado. La columna re, que indica la cantidad de páginas reclamadas, permanece en completamente en 0. La columna pi varía desde 0 hasta un alto nivel de 56 páginas movidas a memoria desde el espacio de paginado (page in). Aunque un nivel de pi no mayor a 5 es considerado aceptable, niveles mayores a 5 no son necesariamente un indicativo de problemas de rendimiento, debido a que por cada page in, necesariamente debe haber ocurrido un page out. La columna po, que refleja la cantidad de páginas movidas desde memoria al espacio de paginado (page out), se mantiene entre 183 y 445 por segundo. Con una alta tasa de paginado, el sistema debe sufrir cierta degradación del rendimiento, ya que el espacio de paginado se mantiene en disco y es accedido en forma más lenta que la RAM. La columna fr indica la cantidad de páginas liberadas por segundo. La columna sr indica la cantidad de páginas revisadas por el algoritmo de reemplazo de páginas. Si la proporción entre fr:sr es alta, implica limitación de memoria, por ejemplo, si la proporción es 1:3, esto significa que por cada página liberada, tres deben ser revisadas. En este ejemplo, la proporción es cercana a 1:2.
d. La columna faults La información debajo del encabezamiento faults muestra los promedios de traps e interrupciones por segundo. La columna in indica las interrupciones de dispositivos por segundo y siempre es mayor a 100. La columna sy indica la cantidad de llamadas del sistema y es extremadamente difícil determinar un valor apropiado. La columna cs indica la cantidad de context switches.
e. La columna cpu La información debajo del encabezamiento cpu provee un análisis del uso de CPU. La columna us indica la cantidad de tiempo utilizado en modo usuario. En este ejemplo, no supera el 5 por ciento. La columna sy indica la cantidad de tiempo utilizado en modo sistema. En este ejemplo, no baja del 92 por ciento. La columna id indica la cantidad de tiempo inactivo. En este ejemplo, la cpu nunca está inactiva. La columna wa indica la cantidad de tiempo inactivo con I/O a disco local pendiente. En este ejemplo, no supera el 7 por ciento.
Nota En un sistema uni-procesador, si us + sy es mayor al 90 por ciento, el sistema puede ser considerado saturado en CPU.
4.6.4.3 Recomendación Teniendo en cuenta todos los datos recopilados, las siguientes recomendaciones pueden implementarse para aliviar la situación:
Página 191 de 283
• Si es posible, una CPU adicional debería agregarse al sistema para intentar bajar el nivel de CPU a menos del 80 por ciento. • Añadir espacio de paginado adicional en otro disco interno. Esto es por cuestiones de velocidad y disponibilidad. Siempre es conveniente distribuir el espacio de paginado sobre múltiples discos, ya que esto mejorará el rendimiento.
• Si esta situación ocurre sólo en determinados momentos, quizás sea posible reprogramar la ejecución de los trabajos más pesados, distribuyéndolos en el tiempo, de manera que no haya conflictos entre ellos.
Página 192 de 283
5. Resolución de problemas de red TCP/IP El objetivo de este capítulo es identificar el origen de los problemas de red y resolverlos. Las determinaciones de problemas son expuestas asumiendo que las redes fueron configuradas de acuerdo a los estándares de red apropiados.
5.1 Identificar un problema genérico de red Antes de comenzar cualquier investigación en la red, una serie de preguntas deben ser formuladas para identificar el problema: • ¿El problema es en su máquina? • ¿En la red física? • ¿En los dispositivos de red? • ¿En las tablas de ruteo? • ¿El problema es con el host destino? • ¿El problema es con la resolución de nombres? • ¿El problema es con un router?
5.2 Pasos para aislar un problema de red TCP/IP Los problemas aquí listados son los más comunes de encontrar. A veces, es muy difícil de determinar exactamente dónde se encuentra el problema, dentro o fuera de la máquina. Para determinar el problema, se deben utilizar herramientas y comandos de monitoreo y un método de descarte. Si ninguno de los siguientes pasos ayuda a resolver el problema, será necesario contactar al centro de soporte.
5.2.1 Problemas de red en un host determinado Si la red en forma general funciona, pero no es posible acceder a un host particular, se debe intentar hacer un ping por dirección IP y por nombre de host. Se puede revisar la ruta seguida hasta el host con el siguiente comando: traceroute
La salida del traceroute muestra cada gateway que atraviesa el paquete en su intento por encontrar el host destino. Si es posible, se deben examinar las tablas de ruteo de la última máquina que muestra el traceroute para verificar si existe una ruta al host destino. La última máquina mostrada indica donde se desvía del camino el ruteo.
5.2.2 No hay acceso a la red Esto puede significar que hay un problema con el host utilizado o con la red en general. Primero se debe verificar que los servicios de red estén activos en el servidor: lssrc –s inetd
Página 193 de 283
Luego, se debe hacer un ping a un host conocido. Por ejemplo: ping startrek
Si el ping es satisfactorio, se trata de un problema en un host particular. Si no, se debe intentar utilizar la dirección IP del host en lugar del nombre, por ejemplo: ping 9.3.45.89
Si el ping por IP funciona y por nombre no, se trata de un problema de resolución de nombres. Si no se puede hacer un ping a un host externo tanto por dirección IP como por nombre, puede tratarse de un problema de ruteo.
5.2.3 Problemas de resolución de nombres Para intentar resolver un nombre de host, los servidores TCP/IP utilizan rutinas de resolución. Si se piensa que el problema es de resolución de nombres, primero se debe verificar el orden de la resolución de nombres y determinar si se está utilizando un servidor de nombres. El orden por defecto para la resolución de nombres en AIX V4 es: 1. Domain Name Server (DNS) 2. Network Information Service (NIS) 3. Archivo local /etc/hosts El orden puede modificarse en el archivo /etc/netsvc.conf o utilizando la variable de ambiente NSORDER. Si el archivo /etc/resolv.conf contiene una entrada para un servidor de nombres, entonces se está utilizando un DNS. Se debe intentar un ping a la dirección del servidor de nombres. Si es satisfactorio, entonces este funciona y es accesible. Si el archivo /etc/resolv.conf existe pero vacío, se debe eliminar e intentar nuevamente la resolución de nombres con un ping. Si el servidor de nombres local está funcionando, se debe verificar con el administrador de red que el daemon named está activo en el DNS con el comando lssrc –s named (si se usa un AIX como servidor de nombres). También se debe verificar que el host destino esté correctamente identificado en la base de datos de la configuración del DNS. Se debe verificar si se está utilizando Network Information Services (NIS) utilizando el comando ps -ef y buscando los procesos ypserv e ypbind. Utilice el comando ypwhich para mostrar el nombre de los servidores NIS que se están utilizando. Si se resuelven todos o algunos nombres localmente, se debe verificar que en el archivo /etc/hosts estén correctamente escritos el nombre del host destino y su dirección IP. La resolución de nombres funciona si se puede traducir el nombre del host a dirección IP y viceversa.
5.2.4 Análisis de un problema de ruteo Si no es posible realizar un ping por nombre de host o dirección IP, entonces se está frente a un problema de ruteo. Primero se deben verificar las tablas de ruteo: • Utilice el comando netstat -rn para mostrar el contenido de la tabla de ruteo local utilizando direcciones IP • Verifique la máscara de red y asegúrese que es correcta (al respecto se debe consultar al
Página 194 de 283
administrador de la red). • Si hay una ruta por defecto, intente hacerle un ping. • Si hay más de una interfase de red, intente determinar si todas las interfases funcionan bien. Si el ping al gateway por defecto no responde, puede ser que esté apagado o la conexión a la red local no funcione. Intente hacer un ping a todos los otros gateways listados en la tabla de ruteo para ver si alguna porción de la red funciona: # netstat -rn Routing tables Destination
Gateway
Flags
Refs
Route Tree for Protocol Family 2 (Internet): default 9.185.112.254 UG 1 9.185.112/23 9.185.113.7 U 26 127/8 127.0.0.1 U 5 192.168.1/24 192.168.1.10 U 0 Route Tree for Protocol Family 24 (Internet v6): ::1 ::1 UH 0 #
Use 1656 4642 424 0 0
If
PMTU
Exp
-
-
lo0 16896
-
tr0 tr0 lo0 en0
Groups
Si el ping no responde para ningún host o router, se debe intentar un ping a la interfase loopback local (lo0) con el siguiente comando: ping localhost
Si el ping es satisfactorio entonces el problema está en el adaptador, en el hardware de la red o es un problema de ruteo. Si el ping no es satisfactorio, es necesario: • Asegurarse que el proceso inetd esté activo utilizando el comando lssrc -g tcpip. Si no está activo, se debe iniciar con los comandos startsrc -s inetd o startsrc -g tcpip. • Verifique el estado de la interfase loopback (lo0) con el comando netstat -i. Si la salida muestra lo0*, verifique que en el archivo /etc/hosts no se encuentre comentada la siguiente línea: 127.0.0.1 loopback localhost # loopback (lo0) name/address
Un asterisco (*) junto al nombre del la interfase en la salida del comando netstat indica que la interfase está desactivada. Utilice el siguiente comando para reiniciar la interfase lo0: # ifconfig lo0 inet 127.0.0.1 up
5.2.5 Ruteo estático o dinámico ¿Está utilizando ruteo dinámico o estático? Se está utilizando ruteo dinámico si al ejecutar el comando ps -ef si los programas gated o routed se encuentran corriendo. En el ruteo dinámico, el programa gated se ejecuta en un servidor que publica información de ruteo. El programa routed se ejecuta en clientes. Este escucha las publicaciones y actualiza la información de ruteo en el cliente. Si se está utilizando ruteo dinámico, se debe verificar que el gateway esté listado correctamente en las tablas de ruteo del kernel, ejecutando el comando netstat -r.
Página 195 de 283
Si se está utilizando ruteo dinámico con el daemon routed: • Si el routed no puede identificar la ruta a través de preguntas, revise el archivo /etc/gateways para verificar que una ruta al host destino esté definida y que el host destino esté ejecutando el RIP (Routing Information Protocol). . • Asegúrese que los gateways responsables de enviar los paquetes al host destino se encuentren funcionando y ejecutando el RIP (routed o gated activo). De lo contrario, será necesario definir una ruta estática. • Ejecute el daemon routed utilizando la opción de depuración para registrar en el log informaciones como por ejemplo los paquetes inservibles recibidos. Invoque al daemon utilizando el siguiente comando: # startsrc -s routed -a "-d"
• Ejecute el daemon routed utilizando el flag -t, que provoca que todos los paquetes enviados o recibidos sean escritos en la standard output. Cuando routed se ejecuta en este modo, permanece bajo el control de la terminal donde se inició. Por lo tanto, una interrupción desde la terminal que lo controla, mata el daemon. Si se está utilizando ruteo dinámico con el daemon gated: • Se debe verificar que el archivo /etc/gated.conf esté configurado correctamente y que se están ejecutando los protocolos correctos. • Debe asegurarse que el gateway en la red de origen está utilizando el mismo protocolo que el gateway en la red de destino. • Debe asegurarse que la máquina desde la cual se intenta iniciar la comunicación tiene una ruta de regreso a sí misma. • Se debe verificar que los nombres de los gateways en el archivo gated.conf correspondan a los nombres de los gateways listados en el archivo /etc/networks. Si se están utilizando los protocolos RIP o HELLO, y las rutas al destino no pueden identificarse a través de consultas de ruteo, se debe revisar el archivo gated.conf para verificar que una ruta al host de destino esté definida. Se deben configurar rutas estáticas bajo alguna de las siguientes condiciones: • Que el host de destino no esté ejecutando el mismo protocolo que el host de origen, por lo que no pueden intercambiar información de ruteo. • Que el host debe ser alcanzado por un gateway distante (un gateway que está en un sistema autónomo diferente al del host de origen). El RIP puede usarse sólo contra hosts del mismo sistema autónomo. Si se está utilizando ruteo dinámico, no se deben agregar rutas estáticas a la tabla de ruteo utilizando el comando route. • Se debe consultar la información sobre gated en AIX Version 4 Files Reference, para ver cómo modificar el archivo gated.conf si se quieren agregar rutas estáticas. Se debe tener en cuenta que el AIX a partir de la Versión 4.3.2 ejecuta el gated Versión 3.5.9. La sintaxis del archivo gated.conf ha cambiado levemente desde las primeras versiones. Para utilizar la sintaxis correcta se debe leer la documentación del gated.conf o utilizar el archivo de muestra que es generado en el directorio /usr/samples/tcpip.
Página 196 de 283
Como último recurso, se debe limpiar (flush) la tabla de ruteo utilizando el comando route -f, lo que provoca que todas las rutas sean eliminadas y eventualmente remplazadas por los daemons de ruteo. Este debe realizarse en casos excepcionales, ya que cualquier conexión de red que funcionaba, estará temporalmente desactivada una vez que las rutas sean removidas. Cuando el flush se lleva a cabo, se debe tener especial cuidado de no interrumpir la actividad de otros usuarios. Si no se está utilizando ruteo dinámico, probablemente se esté utilizando el ruteo estático por defecto, el que puede tener configuradas algunas rutas directas, pero todas las otras rutas son direccionadas a la máquina gateway que maneja el envío de datos. En este caso, se pueden agregar y borrar rutas manualmente. Si hay rutas en la tabla de ruteo que son obviamente erróneas, se deben eliminar con el comando route de la siguiente manera: route delete
Las rutas pueden ser agregadas de la misma manera: route add net
Por ejemplo, para agregar una ruta por defecto: # route add default 129.35.128.1
Para eliminar una ruta por defecto: # route delete net 9.3.199 9.3.189.45
5.2.6 Problemas con las interfases de red Si aún no se pueden establecer comunicaciones, se debe analizar los problemas que puedan tener las interfases de red.
5.2.6.1 Análisis genérico de interfases Esta sección se refiere a todos los tipos de interfases TCP/IP y los pasos a seguir antes de consultar las secciones específicas de cada tipo de interfase. Si la resolución de nombres no funciona y el ping no responde en ninguna dirección de la tabla de ruteo, la interfase puede ser la culpable. El primer paso debe ser verificar el tipo y estado de adaptadores instalados utilizando los comandos lsdev -Cc adapter y lsdev -Cc if. Si todos los adaptadores e interfases utilizados son listados y disponibles, utilice el comando netstat -i buscando en la salida Ierrs (input errors o errores de entrada), Oerrs (output errors o errores de salida), y Coll (collisions o colisiones). También se deben verificar los Ipkts y Opkts (paquetes de entrada y salida) para verificar si hubo tráfico de red satisfactorio desde el último reinicio del sistema. Por ejemplo: # netstat -in Name Mtu Network Address Ipkts Ierrs Opkts Oerrs lo0 16896 link#1 2107 0 2109 0 0 lo0 16896 127 127.0.0.1 2107 0 2109 0 lo0 16896 ::1 2107 0 2109 0 en0* 1500 link#2 2.60.8c.2e.e1.c9 0 0 9 0 0 en0* 1500 192.168.1 192.168.1.10 0 0 9 0 tr0 1492 link#3 10.0.5a.a8.70.67 1102168 0 84137 406 0 tr0 1492 9.185.112 9.185.113.7 1102168 0 84137 406 at0 9180 link#4 8.0.5a.75.20.f6 2788 0 2661 0 0 at0 9180 192.168.84 192.15.15.2 2788 0 2661 0
Coll 0 0 0 0 0
Página 197 de 283
#
Se debe verificar que todas las interfases listadas tengan direcciones de red únicas, y si es así, se debe utilizar el comando ifconfig para verificar el estado de todas las interfases que tengan un asterisco junto a su nombre. En el ejemplo anterior, el comando ifconfig en0 mostrará en0 con estado down. También se debe verificar el estado de la interfase con el comando ifconfig , y si aparece en estado down, hacer un detach, luego activarla y verificar el estado nuevamente, como se muestra en el siguiente ejemplo: # ifconfig en0 en0: flags=e080862 T,GROUPRT,64BIT> inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255 # ifconfig en0 detach # ifconfig en0 inet 192.168.1.10 up # ifconfig en0 en0: flags=e080863 CAST,GROUPRT,64BIT> inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255
Si la interfase muestra las palabras UP y RUNNING, intente hacer un ping a la interfase nuevamente. Si funciona bien, intente hacer un ping a otra dirección en la misma sub red. Si el ping falla, significa que es un problema de red externo. Si la interfase no muestra las palabras UP y RUNNING, o el ping a la interfase falla, será necesario ejecutar los diagnósticos contra el adaptador para verificar que funciona bien antes de proceder. Además, se debe verificar que los parámetros del adaptador estén configurados de acuerdo a la red y que todos los cables tengan los terminadores adecuados y se encuentren bien conectados al sistema y a la red.
5.2.6.2 Problemas de interfase ethernet Algunos adaptadores ethernet pueden ser usados con el transceiver (transmisor-receptor) que se encuentra integrado a la tarjeta o un transceiver externo. Las tarjetas riser de los adaptadores ethernet que se encuentran en algunas máquinas MCA (marcadas con la sigla 2-8), tienen jumpers para especificar que interfase física de la tarjeta será utilizada. Verifique que los jumpers estén correctamente configurados (para obtener instrucciones se debe consultar el manual del adaptador). El resto simplemente es verificar que el tipo de conector sea configurado correctamente. Para esto se debe verificar que se está usando el tipo de conector apropiado (fino es BNC; grueso es DIX). Si hace falta cambiar el tipo de conector, se puede utilizar el menú rápido del Administrador del sistema basado en Web, wsm devices, o el menú rápido de SMIT, smit chgenet, para configurar el campo Apply Change to Database Only. (El campo debe ser marcado en el Administrador del sistema basado en Web o configurado en yes en SMIT.) Reinicie la máquina para aplicar los cambios.
Nota Si un sistema microchannel con una red Ethernet previamente operativa falla después del reinicio, se debe verificar el tipo de conector utilizando SMIT como se detalla más arriba.
5.2.6.3 Problemas de interfase token-ring Si no es posible la comunicación con alguna de las maquinas en la red, aún después de inicializar la interfase, las direcciones son correctamente especificadas, y la tarjeta de red fue verificada satisfactoriamente, entonces se debe realizar lo siguiente: • Se debe verificar que los hosts con los que no es posible la comunicación están en un anillo diferente. Si es así, utilice el menú rápido del Administrador del sistema basado en
Página 198 de 283
Web, wsm devices, o el menú rápido de SMIT, smit chinet, para verificar el campo Confine BROADCAST to Local Token-Ring. El campo no debe estar marcado en el Administrador basado en Web, y debe estar configurado en no en SMIT. • Se debe verificar si el adaptador token-ring está configurado para funcionar a la velocidad correcta del anillo. Si está configurado incorrectamente, se debe modificar el atributo de la velocidad del anillo del adaptador. Cuando TCP/IP es reiniciado, el adaptador tokenring tendrá la misma velocidad que el resto de la red.
Nota Si una máquina funciona con la velocidad de anillo equivocada provocará problemas a todas las máquinas en el mismo anillo.
5.2.6.4 Problemas con interfases ATM o ATMLE Si se presentan problemas de comunicación con algún dispositivo de red a través de una interfase ATM: • Verifique en las interfases la presencia de la emulación ATM LAN y las interfases IP clásicas con el comando netstat -in. Si ambas están configuradas y son necesarias, se debe verificar que cada interfase configurada tenga una única dirección IP. Un problema común es que los usuarios configuren la interfase at0 y las interfases en0 o tr0 con la misma dirección. • Si se está utilizando un switch ATM, se debe verificar que haya una apropiada conexión con el switch (normalmente indicada por la luz de un puerto del switch). Para identificar problemas en los cables, se deben buscar fallas de cableado en el log de errores con el comando errpt |grep atm. Si los conectores de los cables de fibra no están sellados o conectados con un protector plástico, intente invertir los conectores en una de las puntas. • Verifique la configuración del switch (si se está utilizando uno) con el administrador del switch dado que gran variedad de problemas ocurren cuando el switch está mal configurado. • Asegúrese que el último fileset PTF para ATM y ATMLE esté instalado en el cliente RS/6000, ya que muchos problemas de ping del switch son defectos y pueden ser solucionados levantando el nivel de los filesets con los últimos niveles de PTF. Los filesets son: el controlador de dispositivo ATM, el controlador de dispositivo ATMLE LAN y los filesets comunes de ATM. Pasos para depurar un problema de emulación ATM LAN
Si no es posible hacer un ping al switch o a un host ATMLE local, ejecute los comandos entstat –d entx o tokstat -d tokx. Estos comandos verifican si la interfase ATMLE fue registrada con el switch ATM y cuáles Emulated LAN Name (ELAN) y MAC Address están siendo utilizados. En la sección General Statistics de las salidas de los comandos entstat o tokstat, se debe verificar el campo Driver Flags para una correcta operación: • El campo Driver Flags debe ser similar al siguiente: Driver Flags: Up Broadcast Running Simplex AlternateAddress 64BitSupport
Si no están los flags Up o Running, entonces no hay contacto con el switch ATM. Si el flag Limbo está presente, significa que el cliente perdió el contacto con uno o más servidores ATMLE y está intentando reconectarse.
Página 199 de 283
Si el flag Dead está presente, indica que ocurrió una falla a nivel hardware, y el cliente ATMLE no se encuentra operacional. • Verifique el log de errores para obtener mensajes de error adicionales. Los siguientes ejemplos muestran las salidas del comando entstat tanto para una falla en el registrado como para un registro satisfactorio en el switch. El siguiente ejemplo es la salida del comando entstat -d ent0 con mensajes de error provocados por el cliente ATMLE RS/6000 al fallar el registro en el switch ATM: ATM LAN Emulation Specific Statistics: Statistics: -------------------------------------Emulated LAN Name: ZTrans_Lab_Eth Local ATM Device Name: atm0 Local LAN MAC Address: 08.00.5a.99.89.c4 Local ATM Address: 47.00.91.81.00.00.00.00.00.04.15.00.00.40.00.00.03.75.43.00 Auto Config With LECS: Yes LECS ATM Address: 00.00.00.11.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00 00.00.00.11.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00 LES ATM Address: 00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00 00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00 General Errors: 287 Address Deregistrations: 0 Control Timeout (sec): 120 LE_ARP Rsp Timeout (sec): 1 Max Unknown Frame Count: 1 Flush Timeout (sec): 4 Max Unknown Frame Time (sec): 1 Path Switch Delay (sec): 6 VCC Activity Timeout (sec): 1200 VCC Avg Rate (Kbps): 25600
Las siguientes direcciones ATM deben ser listadas: • Dirección ATM local (Local ATM Address) del cliente ATMLE RS/6000. Desde el byte 14 hasta el 19 contiene la MAC address que fue ingresada a través de SMIT. • La Lan Emulation Configuration Server (LECS) ATM Address si se está utilizando Auto Config. Esta contendrá tanto la dirección ATM con un prefijo del switch diferente (desde el byte 1 al 13), o puede contener la siguiente dirección ATM universal definida por el Forum ATM: 47.00.79.00.00.00.00.00.00.00.00.00.00.00.A0.3E.00.00.01.00
• La Lan Emulation Server (LES) ATM Address. El prefijo de trece bytes (desde el byte 1 al 13) debe coincidir con la dirección ATM local que es asignada al RS/6000 Lan Emulation Client (LEC). Si la Local ATM Address y/o la LES ATM Address contienen en su mayor parte ceros, el registro en el switch ATM ha fallado como en el ejemplo del entstat anterior. La falla al registrar puede ser provocada por las siguientes causas: • La versión UNI del adaptador ATM no coincide con la del switch. • El tamaño PDU del adaptador ATM es diferente al del switch. • La interfase RS/6000 que conecta con el switch ATM está dañada. • La LES/LECS ATM Address es falsa o ingresada incorrectamente, o si fue usada la dirección universal (el campo de la dirección ATM está en blanco), ya que el switch ATM no soporta la dirección universal. • El Emulated LAN Name no es reconocido en el switch ATM o no se ingresó el Emulated LAN Name en el menú de SMIT Add ATM LE Client, y el switch lo está esperando. El siguiente es un ejemplo de la salida del comando entstat -d ent0 como resultado de un registro satisfactorio del cliente RS/6000 ATMLE en el switch ATM: ATM LAN Emulation Specific Statistics: Statistics: --------------------------------------
Página 200 de 283
Emulated LAN Name: ZTrans_Lab_Eth Local ATM Device Name: atm0 Local LAN MAC Address: e0.00.5a.99.89.c4 Local ATM Address: 47.00.05.80.ff.e1.00.00.00.f2.0f.28.f7.08.00.5a.99.89.c4.00 47.00.05.80.ff.e1.00.00.00.f2.0f.28.f7.08.00.5a.99.89.c4.00 Auto Config With LECS: Yes LECS ATM Address: 47.00.79.00.00.00.00.00.00.00.00.00.00.00.a0.3e.00.00.01.00 47.00.79.00.00.00.00.00.00.00.00.00.00.00.a0.3e.00.00.01.00 LES ATM Address: 47.00.05.80.ff.e1.00.00.00.f2.0f.28.f7.00.20.48.0f.28.f7.e0 47.00.05.80.ff.e1.00.00.00.f2.0f.28.f7.00.20.48.0f.28.f7.e0
Si el cliente ATMLE se registra, pero falla al hacer un ping: • Se debe verificar que el nombre ELAN que es listado por los comandos entstat o tokstat coincida con la dirección de red correcta. Este problema puede ocurrir si el nombre ELAN es reconocido por el switch ATM que permite que el cliente se registre, pero el nombre es asignado a una sub red diferente. Los nombres ELAN son listados en los LECS/LES dependiendo cómo implementa el switch ATM la configuración ATMLE. Si hay otro cliente ATLML en la misma sub red, mediante un ping se debe verificar si el nombre ELAN es diferente al del cliente ATMLE problemático. • Se deben verificar en la tabla ARP las l as direcciones IP remotas y la MAC address. • Intente hacer un ping al puerto del switch en vez de hacerlo al cliente ATMLE. Si responde, el switch puede tener algún problema. • Verifique que el adaptador ATM y el controlador de dispositivo estén funcionando de la siguiente manera: # atmstat -d atm0 > /tmp/atmstat.out
Espere 10 segundos, y ejecute el comando nuevamente, direccionando la salida al mismo archivo: # atmstat -d atm0 >> /tmp/atmstat.out
Verifique en el archivo /tmp/atmstat.out los siguientes parámetros bajo la columna Receive Statistics: • Packets received y Cells received – Estos dos parámetros deben mostrar un incremento en el segundo atmstat, lo que implicaría que el adaptador y el manejador de dispositivo están funcionando. Si no se verifica un incremento en estos parámetros significa que el adaptador no puede recibir cells ATM. Esto puede deberse a que el adaptador y/o el manejador de dispositivo estén fallando. Si es posible, se debe apagar y reiniciar el servidor, para intentar corregir la falla.
Página 201 de 283
Pasos para depurar un problema de IP clásico de ATM
Los pasos para analizar un problema IP clásico dependen si la conexión es Permanent Virtual Circuit (PVC) o Switched Virtual Circuit (SVC). Para conexiones PVC, se debe verificar que se está utilizando el par Virtual Path Indicator (VPI):Virtual Channel Indicator (VCI), VPI:VCI, correcto, con el menú rápido smit lsatmpvc. Para conexiones SVC, se debe verificar que la dirección del servidor ARP esté ingresada correctamente para el cliente ARP. Los tres ejemplos siguientes del comando arp -t atm –a muestran típicas fallas de registro de un servidor ARP y la salida de un registro satisfactorio. La primera línea en la salida del arp es la dirección IP del at0 local y es una dirección ATM de 20 bytes. • La dirección IP debe corresponder con la at0 y la dirección ATM debe contener la MAC address del atm0 (o atmx) desde el byte 14 al 19. • Si la MAC address, la dirección ATM completa, o la dirección IP son ceros o incorrectas, el registro con el switch no será posible. Verifique la configuración de la at0 con el menú rápido smit chinet y asegúrese que la dirección ATM no esté ingresada incorrectamente. La segunda entrada en la salida del arp es la dirección IP y la dirección ATM del servidor ARP. Ejemplo 1: El cliente ATM no se registra con el switch. # arp -t atm -a at0(198.179.228.31) 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IP Addr VPI:VCI Handle ATM Address ?(198.179.228.6) N/A N/A 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 #
Las causas posibles de una falla al registrar son: hardware, dirección ATM mal ingresada o errónea, o la configuración del switch. Ejemplo 2: El cliente ATM puede registrarse con el switch, pero no puede contactar al servidor ARP. # arp -t atm -a at0(146.146.75.239) 39.9.85.11.11.11.11.11.11.11.11.1.1.0.4.ac.ad.28.6a.0 IP Addr VPI:VCI Handle ATM Address ?(0.0.0.0) N/A N/A 39.9.85.11.11.11.11.11.11.11.11.1.1.0.20.35.99.7.33.0 #
Las causas posibles de no poder contactar al servidor ARP son: versión UNI incorrecta o servidor ARP que no reconoce el auto-detect, el servidor ARP caído o con problemas, o tamaños diferentes de PDU. Ejemplo 3: El cliente ATM pude registrarse con el switch e hizo contacto con el servidor ARP. # arp -t atm -a at0(9.3.35.157) 47.0.5.80.ff.e1.0.0.0.f2.f.28.f7.8.0.5a.99.89.c4.0 IP Addr VPI:VCI Handle ATM Address flute.austin.ibm.com(9.3.35.150) flute.austin.ibm.com(9.3.35.15 0) 0:41 3 47.0.5.80.ff.e1.0.0.0.f2.f.28.f7.0.20.48.f.28.f7.0 horn.austin.ibm.com(9.3.35.154) 0:43 4 47.0.5.80.ff.e1.0.0.0.f2.f.28.f7.8.0.5a.99.88.cc.0
Si se obtiene una salida similar a la del ejemplo 3, intente en un Puerto diferente en el servidor ARP o en el switch ATM (verifique el LED en el puerto); también debe verificar la versión UNI y el
Página 202 de 283
tamaño de PDU utilizando smit chg_atm para asegurarse que correspondan con los del switch. Si el host remoto puede hacer un ping al cliente ATM RS/6000 a través del servidor ARP, intente agregar manualmente la entrada para el cliente ARP remoto en la tabla ARP como se muestra debajo. Para clientes SVC: arp -t atm -s svc <20 byte atm address of remote host>
Si la salida del comando arp en el cliente ATM continúa mostrando que falla el registro o que no hay contacto con el servidor ARP, ejecute el comando atmstat de la siguiente manera para verificar el adaptador y el manejador de dispositivo: # atmstat -d atm0 > /tmp/atmstat.out
Espere 10 segundos, y ejecute el comando nuevamente, direccionando la salida al mismo archivo: # atmstat -d atm0 >> /tmp/atmstat.out
Verifique en el archivo /tmp/atmstat.out los siguientes parámetros bajo la columna Receive Statistics:
• Packets received y Cells received – Estos dos parámetros deben mostrar un incremento en el segundo atmstat, lo que implicaría que el adaptador y el manejador de dispositivo están funcionando. Si no se verifica un incremento en estos parámetros significa que el adaptador no puede recibir cells ATM. Esto puede deberse a que el adaptador y/o el manejador de dispositivo estén fallando. Si es posible, se debe apagar y reiniciar el servidor, para intentar corregir la falla. Si el problema no puede ser determinado en este punto, será necesario escalar el problema o llamar al centro de soporte.
5.2.6.5 Problemas con interfases X.25 Esta sección contiene información útil para resolver problemas específicos de interfases X.25 TCP/IP, asumiendo que fueron realizados los procedimientos de las secciones “Análisis genérico de Interfases” y “Análisis de un problema de ruteo”. Para simplificar la determinación de problemas de X.25 TCP/IP, se puede encontrar útil desactivar toda resolución de nombres externa y suprimir todos los gateways por defecto. Esto evitará cualquier discrepancia que pueda haber con el /etc/hosts. Se debe tener en cuenta que el /etc/hosts siempre es utilizado por el comando x25ip cuando es ejecutado por el /etc/rc.net durante la inicialización del sistema, aún si hay un servidor de nombres. Si no funciona un ping a un host X.25 remoto, se deben seguir los siguientes pasos: 1. Utilice el comando lsx25 para ver si la interfase TCP/IP X.25 (xs0) y el puerto X.25 (sx25a0) están configurados y disponibles. Si no es así, será necesario configurarlos. Si el puerto o la interfase no pueden ser configurados, se debe utilizar el Redbook AIXLink/X.25 LPP Cookbook, SG24-4475, en la sección “X.25 Problem Determination” para obtener más información sobre la depuración de problemas de X.25 LPP. 2. Verifique con smit chinetsx25 que la entrada para el host remoto en la tabla de traducción IP-to-NUA es correcta, luego haga la misma verificación en el host remoto. 3. Refresque la tabla de traducción de X.25/IP utilizando el comando x25ip sin argumentos, luego ejecute el comando ping nuevamente. Si el ping no es satisfactorio, será necesario asegurarse que existan rutas para la interfase X.25 (por ejemplo, xs0). Si las rutas parecen correctas, será necesario monitorear el flujo del nivel de
Página 203 de 283
paquetes utilizando el comando x25mon de la siguiente manera: # x25mon -f -p -n sx25a0
En otra ventana o sesión, hacer un ping al host remoto. Si no se obtienen los resultados esperados, hay cuatro posibles escenarios: 1. No hay mensajes de error, nada transmitido. Hay un gateway que el ping utiliza para enviar paquetes. Verifique con netstat -r (no con ifconfig) que la conexión X.25 esté activa. Examine nuevamente las rutas estáticas y, si es necesario, elimine y remplace las rutas X.25 que tengan un flag G en la salida del netstat. 2. Mensaje de error, nada transmitido. Si el mensaje de error es: sendto: Network is unreachable o sendto: No route for this host
entonces hay un problema con la definición adjunta o con la ruta. Si el mensaje de error es: ping: sendto: Can't assign requested address Sendto: The socket name is not available
entonces hay un problema con la tabla de traducción x25ip. Se puede modificar con smit chinetsx25 o agregar una entrada correcta si es necesario con smit mksx25. 3. No hay mensaje de error, el trace muestra intentos para establecer un circuito virtual. Si se ven en el trace una serie de paquetes de llamados mostrando intentos fallidos para abrir un circuito virtual, entonces hay un problema del protocolo X.25. Se debe consultar la documentación de X.25 LPP o el Redbook AIXLink/X.25 LPP Cookbook , SG24-4475, en la sección “X.25 Protocol Problems”. Si el llamado entrante es rechazado por el sistema remoto con el diagnóstico 241, calling address missing, la dirección llamada no está en la tabla de traducción. Se debe agregar y utilizar x25ip en el host remoto para regenerarla. 4. No hay mensaje de error, error, datos transmitidos pero ninguno ninguno recibido. En este caso, un circuito virtual es establecido y paquetes de datos son enviados al host remoto, pero el host remoto no contesta. Los paquetes son transmitidos correctamente al host remoto, pero la dirección IP del host remoto que ellos llevan no coincide con la dirección IP actual del host remoto. Cambie la dirección IP del host remoto de manera que sea igual a la que está en el host local.
5.3 Problemas de TCP/IP más comunes Las siguientes secciones contienen algunos de los problemas más comunes que ocurren con TCP/IP y otros protocolos relacionados.
5.3.1 LED 581 Durante el reinicio de la máquina, el LED 581 es mostrado mientras el Configuration Manager configura TCP/IP y ejecuta el /etc/rc.net para configurar adaptadores, interfases y el nombre del host.
Página 204 de 283
El problema puede ser provocado por otro sistema o la red, y ocurre porque el TCP/IP espera respuestas sobre algunas interfases (token ring, por ejemplo). Si no hay respuestas, eventualmente espera un tiempo determinado y marca la interfase como desactivada. Este tiempo de espera varía y está comprendido entre tres minutos hasta un período indefinido. El siguiente procedimiento de determinación de problemas es utilizado para verificar que los métodos y procedimientos ejecutados por el /etc/rc.net están provocando la detención en el LED 581: 1. Reinicie la máquina en Modo Servicio. 2. Mueva el archivo /etc/rc.net: mv /etc/rc.net /etc/rc.net.save
3. Reinicie en Modo Normal para verificar que el sistema no se detenga en el LED 581 y permita el log in.
Nota En los pasos anteriores se asume que no han sido configurados DNS o NIS. Si se determina que algún procedimiento en el /etc/rc.net está provocando la detención, entonces el sistema continuó pasando el LED 581 luego de seguir los pasos anteriores, y el problema puede ser alguno de los siguientes: • Problemas de hardware ethernet o token-ring Ejecute diagnósticos y verifique el log de errores. • Ruta por defecto inexistente o incorrecta • La red no es accesible Verifique que los gateways, servidores de nombres, y/o masters NIS estén activos y disponibles. • Direcciones IP o máscaras erróneas Utilice los comandos iptrace e ipreport para la determinación de problemas. • ODM corrupta Remueva y regenere los dispositivos de red • Resolución de dirección IP o nombre prematura Tanto el named, ypbind/ypserv, o /etc/hosts necesita alguna corrección. • Espacios de más al final de las líneas en los archivos de configuración. Utilice el editor vi con el subcomando set list para verificar los archivos, como el archivo /etc/filesystems. • LPPs dañados Reinstale el LPP. Un caso específico de detención en el LED 581 ocurre cuando ATMLE es utilizado con un DNS. Si se está experimentando este problema, se puede solucionar el problema agregando la línea host=local,bind en el archivo /etc/netsvc.conf o agregando las siguientes líneas en el archivo /etc/rc.net de la siguiente manera: man era: ################################################################## # Part III - Miscellaneous Commands. ################################################################## # Set the hostid and uname to `hostname`, where hostname has been # set via ODM in Part I, or directly in Part II. # (Note it is not required that hostname, hostid and uname all be # the same). export NSORDER="local" <<===========LINEA NUEVA /usr/sbin/hostid `hostname` >>$LOGFILE 2>&1 /bin/uname -S`hostname|sed 's/\..*$//'` >>$LOGFILE 2>&1 unset NSORDER <<===========LINEA NUEVA ##################################################################
Página 205 de 283
5.3.2 Problemas con telnet Si el ping entre el sistema origen y el destino funciona correctamente en ambos sentidos, pero no así el telnet o rlogin, se deben seguir los siguientes pasos: 1. Asegúrese que la resolución de nombres funciona tanto en el cliente como en el servidor de telnet, utilizando el comando host de la siguiente manera: # host # host
Si ambos comandos devuelven una salida idéntica, ejecute los comandos desde el servidor al cliente. Si hay discrepancias en el par de salidas, el problema es la resolución de nombres. 2. Verifique que exista la siguiente línea en el archivo /etc/inetd.conf: telnet stream tcp6 nowait root /usr/sbin/telnetd telnetd -a
Nota La palabra tcp6 en la línea del archivo /etc/inetd.conf aparece en AIX V4.3.0 y superiores. 3. Verifique que exista la siguiente línea en el archivo /etc/services: telnet 23/tcp
4. Verifique que inetd esté funcionando de la siguiente manera: # ps -ef | grep inetd | grep -v grep root 7746 5714 0 04:56:38 - 0:00 /usr/sbin/inetd
Si el inetd no está corriendo, se debe iniciar con el comando startsrc -s inetd. 5. Ejecute el telnet a un puerto diferente: # telnet chargen
Si la conexión al puerto chargen es satisfactoria, se observará una salida similar a la siguiente: vwxyz{|}~ !"#$%&'()*+,-./0123456789:;< !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXY =>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^ Z[\]^ wxyz{|}~ !"#$%&'()*+,-./0123456789:;<= !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ >?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ [\]^_ xyz{|}~ !"#$%&'()*+,-./0123456789:;<=> !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[ ?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_` \]^_` yz{|}~ !"#$%&'()*+,-./0123456789: !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVW ;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a XYZ[\]^_`a z{|}~ !"#$%&'()*+,-./0123456789:; !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWX <=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`ab YZ[\]^_`ab {|}~ !"#$%&'()*+,-./0123456789:;< !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXY =>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abc Z[\]^_`abc |}~ !"#$%&'()*+,-./0123456789:;<= !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ >?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcd [\]^_`abcd }~ !"#$%&'()*+,-./0123456789 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUV :;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcde WXYZ[\]^_`abcde ~ !"#$%&'()*+,-./0123456789: !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVW ;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdef XYZ[\]^_`abcdef !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefg !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefgh "#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghi #$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghij $%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijk %&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijkl &'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklm
Para finalizar el telnet utilizar la secuencia de teclas Ctrl-C .
Página 206 de 283
5.3.3 Retrasos del login en sistemas AIX 4.3.x Si la red está utilizando un DNS que funciona sobre AIX 4.2.1 o anterior (o no es un sistema AIX), y se experimentan retrasos del login de alrededor de dos minutos cuando se establecen sesiones remotas, por ejemplo telnet o ftp, desde un sistema AIX 4.3.x, el problema es con la resolución de nombres. AIX 4.3.2 intenta utilizar IPv6 por defecto para la resolución de nombres; por lo tanto, si se experimenta el problema mencionado, será necesario seleccionar IPv4 para la búsqueda de nombres en el DNS. Esto se puede realizar de las siguientes dos maneras: • Crear un archivo llamado /etc/netsvc.conf que contenga la siguiente línea: hosts=local,bind4
• Exportar la variable de korn shell NSORDER de la siguiente manera: export NSORDER=local,bind4
Estos ejemplos muestran simplemente el uso del parámetro bind4 para forzar el uso del protocolo IPv4, el orden de la resolución de nombres puede variar respecto al orden utilizado en el ejemplo.
5.3.4 Problemas de DHCP (Dynamic Host Configuration Protocol) Si los clientes no pueden obtener una dirección IP u otros parámetros de configuración: • Verifique que se haya especificado una interfase para que sea configurada. Esto se puede realizar a través de la aplicación de red del Administrador del Sistema basado en Web, editando el archivo /etc/dhcpcd.ini, o con el menú rápido de SMIT smit dhcp. • Verifique que hay un servidor en la red local o un agente repetidor configurado para llevar los requerimientos fuera de la red local. • Verifique que el daemon dhcpcd esté corriendo. Si no es así, utilice el comando startsrc -s dhcpcd. Si el daemon dhcpsd no está ejecutándose: • Este error es común cuando el bootp es ejecutado bajo inetd; bootpd y dhcpsd no puede ejecutarse al mismo tiempo. El proceso dhcpsd utiliza el mismo puerto de servicio que el bootpd; sin embargo, el dhcpsd no es un sub servidor de inetd y es iniciado con el archivo /etc/rc.tcpip en lugar del /etc/inetd.conf. /etc/ inetd.conf. La línea del bootps en el /etc/inetd.conf debe ser comentada con #, y el inetd refrescado con el siguiente comando: refresh -s inetd
La línea del bootps en el /etc/services permanece tal como está: bootps 67/udp # bootp server port
5.3.5 Las teclas de función de X.25 no funcionan correctamente Cuando se utiliza telnet o rlogin sobre X.25, el sistema remoto no siempre responde correctamente al utilizar las teclas de función, especialmente si se utiliza Esc-1 en lugar de F1. La variable de ambiente ESCDELAY controla el tiempo de espera después del cual la terminal que controla las aplicaciones considerará la tecla Esc separada del posterior 1. La variable ESCDELAY sólo funciona si la aplicación está escrita para aceptar secuencias con la tecla Esc. Cuando se trabaja sobre X.25, la tecla Esc es colocada por IP en un paquete de datos
Página 207 de 283
separado de la siguiente tecla. El espacio entre los dos paquetes de datos en el sistema receptor es normalmente mayor que el tiempo de espera por defecto. El valor por defecto de ESCDELAY (o si no fue configurada) es 500. Para ver si esta es la razón por la que las teclas de función no son reconocidas, configure ESCDELAY con un valor muy alto, de la siguiente manera: 1. Inserte la siguiente línea en el archivo /etc/environment: ESCDELAY=5000
2. Finalice la sesión completamente e ingrese nuevamente al sistema para asegurarse que el nuevo valor de la variable ESCDELAY esté correctamente asignado. 3. Verifíquelo de la siguiente manera: echo $ESCDELAY
Después de concluida la verificación, se debe configurar un valor más razonable (entre 1000 y 2000) o, si el problema no es resuelto, eliminar completamente la línea del archivo /etc/environment. Si el problema no es resuelto aumentando el valor del parámetro ESCDELAY, entonces la aplicación debe ser modificada para que espere una secuencia de escape completa. Por ejemplo, el SMIT de AIX está escrito para que soporte las secuencias de escape y funciona en una red lenta sin utilizar ESCDELAY porque fue escrito para que espere indefinidamente las secuencias de escape. De esta manera, aunque la salida del comando iptrace muestre claramente la separación de la tecla Esc y el resto de la secuencia del escape, las combinaciones con la tecla Escape siempre funcionarán correctamente en SMIT.
5.4 Asuntos de configuración de TCP/IP En esta sección se mencionan algunos temas relativos a la configuración que pueden tener efecto en el rendimiento de red.
5.4.1 Maximum Transmission Unit (MTU) Cada dispositivo tiene un MTU (unidad máxima de transmisión) y no podrá transmitir paquetes más grandes que éste sin fragmentarlos. Por ejemplo: • Si los paquetes son más grandes que el MTU, serán fragmentados antes de ser enviados. • Los paquetes que atraviesan un router deben ser fragmentados para la red destino. • Las máquinas con diferentes tamaños MTU pueden tener dificultades para comunicarse. • Si el tráfico es en su mayor parte local, utilice el MTU más grande soportado por el tipo de LAN. Esto minimiza la fragmentación de paquetes, que es costosa en términos de rendimiento. El tamaño mayor para Ethernet es 1500 bytes. TCP establece un tamaño máximo de segmento (Maximum Segment Size o MSS) que los dos host aceptan durante el proceso de comunicación. Este MSS no será mayor al MTU más pequeño, y por defecto es de 512 bytes (el valor tcp_mssdflt pude verse en la opciones de red).
5.4.2 Mbufs Para verificar que haya suficiente memoria (mbufs) disponible para actividades de red, utilice los comandos netstat -m y netstat -i: • Un valor de requests for mbufs denied distinto de cero en la salida del netstat -m indica una
Página 208 de 283
posible falta de memoria para red; utilice el comando no para incrementar el valor thewall. Algunas causas posibles para un valor diferente a cero en este campo son: • Actividad pesada de red, paquetes rechazados. • Una aplicación de red con mucho consumo de memoria puede agotar el suministro de mbufs. • Es necesario asignar más memoria para mbufs o hace falta más memoria en el sistema. • Verifique en la salida del comando netstat -i la columna Oerrs: • Si el número en la columna Oerrs es mayor al 1 por ciento del número en la columna Opkts, debe ser incrementado el tamaño de la cola TRANSMIT (xmt_que_size) del adaptador. • Si la cantidad de Oerrs es mayor al 1 por ciento de los Ipkts, utilice el comando netstat -m para verificar un posible exceso de consumo de memoria. El parámetro thewall especifica la cantidad máxima de memoria que puede ser asignada para los buffers de red mbufs y mclusters.
5.5 Comandos para identificar un problema de TCP/IP Los siguientes comandos son herramientas básicas que se deben utilizar en la determinación de problemas de TCP/IP.
5.5.1 ping El comando ping es utilizado para investigar problemas básicos de conectividad punto a punto, confirmando si el host remoto está conectado a la red, y si la red entre los hosts es confiable. Adicionalmente, el ping puede indicar si el nombre y la dirección IP de un host son consistentes a través de varias máquinas. El siguiente es un ejemplo del comando ping: ping or # ping bern PING bern: (89.86.41.183): 56 data bytes 64 bytes from 89.86.41.183: icmp_seq=0 ttl=255 time=1 ms 64 bytes from 89.86.41.183: icmp_seq=1 ttl=255 time=2 ms ^C ----bern PING Statistics---4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 1/1/2 ms ping -R muestra el camino que atraviesa el paquete, se debe usar en paralelo con el comando traceroute. ping -c envía n paquetes. Se puede controlar el tamaño de los paquetes enviados con ping . El comando ping envía normalmente 56 bytes de datos más el encabezamiento IP, lo que suma un
total de 64 bytes. Utilizando diferentes valores se puede determinar si hay problemas con la fragmentación. Se deben utilizar valores apenas menores, iguales, y mayores que el tamaño MTU. El comando ping utiliza mensajes ICMP para los pedidos y respuestas, que es una parte de la capa IP, en la porción de datos de los datagramas IP. Los mensajes ICMP son usados también para indicar si el destino de un paquete es inalcanzable, si el paquete debe ser redireccionado a otro router (para un ruteo más eficiente llamado redireccionamiento ICMP), y también puede indicar otro tipo de errores.
Página 209 de 283
5.5.2 rup El comando rup consulta a un servidor cuánto tiempo hace que está levantado. El comando rup: • Utiliza por defecto la difusión de mensajes en todas las interfases. • Utiliza RPC sobre UDP. El comando rup es útil para encontrar si el servicio de nombres e interfases funcionan en un comando. Además, indica cuanto tiempo hace que están levantados y si están ocupados. Un servidor remoto responde sólo si está corriendo el daemon rstatd, que está definido en el archivo /etc/inetd.conf y es iniciado con el daemon inetd.
5.5.3 netstat El comando netstat con varios flags es útil para depurar la mayoría de los problemas de red. El netstat recolecta y muestra una gran cantidad de estadísticas relativas a la red e información de configuración, que incluye: • Sockets activos Los muestra con el comando netstat -f . Donde familia es: • inet para sockets de Internet • unix para sockets Unix • ns para sockets Xerox Network System El formato de la salida es específico a cada familia. La salida por defecto (sin flags) muestra los sockets activos para todas las familias. • Interfases El comando netstat -i muestra el estado y uso de todas las interfases configuradas, como muestra el siguiente ejemplo: # netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll lo0 16896 link#1 8114 0 8116 0 0 lo0 16896 127 loopback 8114 0 8116 0 0 lo0 16896 ::1 8114 0 8116 0 0 en0 1500 link#2 2.60.8c.2e.e1.c9 0 0 19 0 0 en0 1500 192.168.1 jumbuck 0 0 19 0 0 tr0 1492 link#3 10.0.5a.a8.70.67 3340825 0 202253 0 0 tr0 1492 9.185.112 msahanc.au.ibm.co 3340825 0 202253 0 0 sl2* 1006 link#4 0 0 0 0 0 sl2* 1006 130.130.130 130.130.130.1 0 0 0 0 0 #
Para cada interfase, netstat -i muestra: • Name: Nombre de la interfase (Nombre* indica que la interfase está caída) • MTU • Network: dirección de la capa link () • Network: red IP • Address: dirección IP o nombre • Ipkts, Ierrs: Paquetes de entrada y errores • Opkts, Oerrs: Paquetes de salida y errores • Tablas de ruteo Son mostradas con el comando netstat -r como en el siguiente ejemplo:
Página 210 de 283
# netstat -r Routing tables Destination Gateway
Flags Refs
Use
If
Route Tree for default 9.185.112/23 127/8 130.130.130.2 192.168.1/24
(Internet): UG 2 124847 U 29 82305 U 5 2011 UH 0 0 U 0 62
tr0 tr0 lo0 sl2 en0
Protocol Family 2 9.185.112.254 msahanc.au.ibm.co loopback 130.130.130.1 jumbuck
Route Tree for Protocol Family 24 (Internet v6): ::1 ::1 UH 0 #
0
PMTU Exp Groups -
-
lo0 16896
-
Es mostrado el árbol de rutas para cada protocolo. • Estadísticas de protocolos El comando netstat -s muestra estadísticas de los protocolos IP, ICMP, IGMP, TCP, y UDP. Los datos presentados incluyen información de errores, fragmentación, redireccionamientos, paquetes enviados y recibidos, y paquetes perdidos y descartados. Además, muestra las conexiones TCP establecidas, los tiempos de espera, y los datagramas UDP recibidos y enviados. Para mostrar sólo un protocolo, utilice netstat -p como muestra el siguiente ejemplo: # netstat -p udp udp: 2507220 datagrams received 0 incomplete headers 0 bad data length fields 1 bad checksum 297 dropped due to no socket 2498325 broadcast/multicast datagrams dropped due to no socket 0 socket buffer overflows 8597 delivered 3233 datagrams output
• Estadísticas de los controladores de dispositivo de adaptadores de red (device drivers) El comando netstat -v muestra las estadísticas de los controladores de dispositivo de todos los adaptadores de red instalados. Si sólo se requiere la salida para un tipo de adaptador específico, utilice los comandos stat en lugar de netstat –v. • Estadísticas del uso de memoria de red Con el comando netstat -m se puede ver la memoria de red utilizada. AIX V4.1 aumentó considerablemente la colección de estadísticas de uso de la memoria de red. Para disminuir la carga innecesaria del sistema, AIX V4.3.2 definió nuevamente como una opción configurable la colección extendida de estadísticas de servicios de memoria de red. Por defecto, la colección extendida de estadísticas está desactivada. Para activarla, utilice el siguiente comando: /usr/sbin/no -o extendednetstats=1
Para que este cambio se mantenga después de un reinicio del sistema, se deben descomentar las siguientes líneas en el archivo /etc/rc.net: ################################################################## #if [ -f /usr/sbin/no ] ; then # /usr/sbin/no -o extendednetstats=1 >>/dev/null 2>&1 #fi
Página 211 de 283
• Direcciones Protocol Control Block (PCB) El comando netstat -A es utilizado para mostrar las direcciones de cualquier PCB asociado con los sockets. El flag -A es normalmente utilizado con propósitos de depuración a bajo nivel.
5.5.4 arp Address Resolution Protocol (ARP) mapea direcciones IP a las direcciones de hardware. Por ejemplo: • Utilice el comando arp -a para mostrar el cache de transacciones ARP de la máquina local. • Las direcciones IP sólo tienen significado para IP. El nivel de enlace de datos de la capa de red Internet utiliza la dirección de hardware del mismo adaptador. Cada dirección de hardware es única. • Las tablas ARP traducen las direcciones IP a direcciones de hardware y viceversa. • Esto funciona utilizando un mecanismo de publicación que envía un llamado preguntando por el propietario de una dirección IP particular.
5.5.5 iptrace e ipreport El comando iptrace rastrea todos los paquetes que salen y entran a un sistema. Por ejemplo: • Este comando genera una salida detallada que puede verse utilizando el comando ipreport. • Esta puede ser una herramienta sumamente útil para encontrar errores de comunicación de bajo nivel necesarios para una depuración detallada de problemas de red. No es realmente necesaria para un uso general dado que la interpretación de la salida requiere un conocimiento minucioso de TCP/IP. Para limitar el problema, especifique el host origen y el destino con los flags -s y -d . Los siguientes flags son útiles para reducir la cantidad de datos capturados, simplificando bastante el análisis de la salida: • -a excluye los paquetes ARP. • -P recolecta datos sólo para un protocolo especificado. • -i recolecta datos sólo para una interfase especificada. El siguiente ejemplo ilustra cómo rastrear todo el tráfico enviado al host columbia a través de la interfase en0 y direcciona la salida formateada en un archivo: # iptrace -i en0 -d columbia /tmp/trace.raw
El comando tcpdump muestra detalladamente los encabezamientos de los paquetes para TCP: • Permite un análisis muy detallado, nuevamente útil para una depuración de red avanzada. • Permite especificar un patrón de búsqueda para limitar la información mostrada. El siguiente ejemplo mostrará todos los paquetes que arriben o partan del host firefly: # tcpdump host firefly
5.5.7 no (Network Options) El comando no cambia o muestra las opciones de red: • El comando no -a muestra los valores de todos los parámetros de red definidos en el sistema. • El comando no -o permite modificar los parámetros deseados. Permite que los cambios tengan efecto inmediatamente pero los cambios sólo permanecen hasta el siguiente reinicio del sistema. Por ejemplo, para cambiar el valor thewall a 64 MB, se debe utilizar la siguiente sintaxis del comando: # no -o thewall=65536
Para mantener los cambios después de los reinicios del sistema, los comandos no específicos deben ser añadidos al archivo /etc/rc.net de la siguiente manera: ########################################################### if [ -f /usr/sbin/no ] ; then /usr/sbin/no -o tcp_sendspace = 16384 /usr/sbin/no -o tcp_recvspace = 16384 /usr/sbin/no -o thewall=32768 fi
Los valores del sistema deben ser modificados únicamente después de observar la información sobre optimización en la documentación de AIX o bajo la dirección del personal de soporte.
5.5.8 Comandos stat En lugar de utilizar el comando netstat -v, para una interfase particular se puede usar un comando stat. Estos comandos están en el directorio /usr/sbin e incluyen los siguientes: • entstat • tokstat • atmstat
Nota Utilice el flag –d obtener datos específicos del dispositivo más detallados.
5.6 Resolución de problemas de NIS (Network Information Services) En esta sección se verán las herramientas y métodos utilizados para resolver problemas de NIS.
5.6.1 Herramientas para la resolución de problemas de NIS Página 213 de 283
La siguientes secciones contienen una selección de comandos de red que pueden ser utilizados como herramientas para la resolución de problemas de NIS.
5.6.1.1 ping El comando ping es una herramienta de uso general utilizada para investigar problemas de conectividad punto a punto. Si el comando ping no responde o tiene tiempos de respuesta muy grandes, entonces hay un problema de conectividad de bajo nivel. Esto debe ser resuelto antes de comenzar una investigación en el entorno NIS.
5.6.1.2 rpcinfo El comando rpcinfo es una analogía del ping, que busca los servidores RPC y su registro con el portmapper, y por lo tanto verifica que la máquina remota es capaz de responder a un requerimiento RPC. El comando rpcinfo puede ser usado para detectar: • Servidores caídos o que no responden debido a configuración inadecuada o a la falla de un daemon. • El número de versión del programa RPC es diferente entre el cliente y el servidor. • Servidores RPC renegados (Servidores NIS que no tienen mapas válidos para el dominio que atienden) • Problemas relacionados con broadcast. El comando rpcinfo -p toma un nombre de host remoto y busca el portmapper en el host para todos los servicios RPC registrados: • La salida del comando rpcinfo muestra el programa RPC y su versión, los protocolos soportados, los puertos IP utilizados por el servidor RPC, y el nombre del servicio RPC. • Los nombres de los servicios salen del mapa NIS rpc.bynumber. Si no es impreso ningún nombre inmediatamente después de la información de registro, el número de programa RPC no aparece en el mapa. • Si faltan nombres de servicios RPC es posible que el mapa NIS rpc.bynumber esté corrupto o incompleto. Cuando se trabaja diagnosticando cualquier programa relacionado con RPC, se debe verificar que el portmapper remoto esté vivo y devuelva registros RPC válidos. • Si el portmapper en la máquina remota está caído o no acepta conexiones por alguna razón, el rpcinfo cancela por tiempo intentando alcanzarlo y reporta el error. Esto indica un problema de bajo nivel en la red. Si se está investigando en un entorno heterogéneo y se ejecutan múltiples versiones de cada servicio RPC, es posible obtener errores de incompatibilidad en los números de versión RPC. Estos problemas afectan el NIS y el booteo de clientes sin discos; esto puede ser evitado utilizando el comando rpcinfo para emular un llamado RPC y observando las respuestas del servidor. Por ejemplo, realizar un broadcast y luego observar el orden en que las respuestas son recibidas. El comando rpcinfo -b envía un requerimiento broadcast al programa RPC y versión especificados: # rpcinfo -b ypserv 1 89.86.41.194 austin
Página 214 de 283
89.86.41.195 newyork 89.86.41.196 boston
En este ejemplo, todos los servidores NIS en la red local contestan el requerimiento broadcast del rpcinfo al procedimiento nulo del daemon ypserv. Si austin no es el servidor NIS y los clientes
se vincularan a él, la red estaría propensa a sufrir períodos de fallas intermitentes. Un servidor NIS renegado puede ser el primero que conteste un broadcast ypbind de servicio NIS. Su falta de información sobre el dominio hace que la máquina cliente sea inutilizable. Este problema lo puede causar alguna falla que saque de servicio a un host como servidor NIS (dejando vacío el mapa de directorios NIS, por ejemplo). El comando rpcinfo ayuda a determinar por qué un cliente particular no puede iniciar el servicio NIS. Si ningún host contesta a los requerimientos del comando rpcinfo, entonces el paquete de broadcast no llega a ningún servidor NIS. Si el nombre de dominio NIS y la dirección de broadcast son correctos, entonces será necesario sobrescribir la búsqueda basada en broadcast y darle al ypbind el nombre y dirección de un servidor NIS válido, utilizando el comando ypset. A veces, observando la lista de servidores que responden a un requerimiento, se puede intuir un problema si se detecta que uno de los servidores no debería contestar el broadcast. Como el ping, el comando rpcinfo provee una medición de la conectividad básica en la capa de sesión del conjunto de protocolos de red. Un ping satisfactorio a una máquina remota asegura que la red física funciona bien y que la dirección IP utilizada es correcta: utilizando el comando rpcinfo para realizar una prueba similar se verifica que la máquina remota es capaz de contestar un requerimiento RPC. Esto incluye la validación de la integridad de la red y que hay un servicio RPC registrado en la otra máquina.
5.6.1.3 ypmatch Como una herramienta de diagnóstico, el comando ypmatch puede ser utilizado para ver si una modificación en un mapa ha tenido efecto y para identificar los mapas NIS que están fuera de sincronización después de que una transferencia de mapas ha sido requerida o programada. Generalmente, al crear un mapa nuevo, se fuerza el cambio en los otros servidores con el comando yppush. Para verificar la consistencia de un mapa, utilice el comando ypmatch en varios clientes y luego en el servidor. Verifique que se obtengan los mismos resultados. Si no es así, existe una inconsistencia de mapas. Intente forzar el cambio de los mapas en los servidores con el comando yppush. A menudo, los cambios en los mapas NIS no son propagados tan rápido como es deseado, aún si el cambio fue forzado con el comando yppush.
5.6.1.4 ypwhich El comando ypwhich es utilizado para verificar el servidor NIS de un cliente, como se ve en el siguiente ejemplo: # ypwhich godzilla
Si se pasa como parámetro un nombre de host, el comando ypwhich consulta cuál es la vinculación actual del host mencionado. Si el ypwhich no puede resolver la dirección IP del nombre del servidor, reporta un error como el siguiente: # ypwhich kingkong ypwhich: can't find kingkong
Nota Una dirección IP puede ser utilizada en lugar del nombre de host.
Página 215 de 283
El comando ypwhich -x muestra la tabla de apodos: stepiii $ ypwhich -x Use passwd for map passwd.byname Use group for map group.byname Use networks for map networks.byaddr Use hosts for map hosts.byaddr Use protocols for map protocols.bynumber Use services for map services.byname Use aliases for map mail.aliases Use ethers for map ethers.byname
El comando ypwhich -m examina el nombre del servidor master NIS existente en el archivo del DBM (Database Manager) de los mapas NIS: # ypwhich -m auto.master stargate auto.src stargate rpc.bynumber stargate protocols.bynumber stargate auto.projects stargate auto.mail stargate auto.home stargate
Si se tiene conocimiento sobre datos que desaparecen de los mapas NIS, vuelque el mapa entero (incluyendo las claves) utilizando el comando makedbm -u: stargate $ /usr/etc/yp/makedbm -u ypservers stargate lazerus delli YP_LAST_MODIFIED 0706832572 YP_MASTER_NAME stargate stargate $
La información del mapa master es útil si se cambiaron los servidores master NIS y es necesario verificar que los mapas de los clientes fueron correctamente generados y sincronizados con el nuevo servidor. Consultando las vinculaciones de los clientes individualmente es útil para depurar problemas de los clientes. Además de proveer información sobre la vinculación a servidores NIS, el comando ypwhich examina la información de los mapas NIS, el servidor master de un mapa, la lista de todos los mapas, y la traducción de los apodos de un mapa.
5.6.2 Ejemplos de resolución de problemas con NIS Cuando se investiga un problema de red: • Se debe pensar sobre las causas potenciales del problema. • Se debe investigar en todas las capas de protocolos para asegurarse que no se deje de lado un posible problema de bajo nivel, que se presenta como una falla de alto nivel. Por ejemplo, si los intentos de vinculación a un servidor NIS están fallando: • Verifique la red con el comando ping. • Verifique los procesos ypserv con el comando rpcinfo. • Finalmente, verifique la vinculación a sí mismo con los comandos ypset o ypwhich.
Página 216 de 283
5.6.2.1 yppush falla al crear mapas nuevos Si el comando yppush falla al agregar nuevos mapas NIS después de que los mapas iniciales fueron transferidos a un servidor esclavo, será necesario: 1. Crear los mapas nuevos con la opción NOPUSH en 1. make NOPUSH=1
La falla al utilizar la opción NOPUSH provocará que el comando no responda. 2. Actualice los servidores esclavos ejecutando ypxfr en cada uno. Esto se realiza si el mapa nuevo no existe en el servidor esclavo.
5.6.2.2 Los broadcast de clientes no vinculan El problema más común que ocurre en un nodo cliente NIS es que un comando no responda. A veces un comando parece no responder, y un mensaje como el siguiente aparece en la consola: NIS: server not responding for domain . Still trying
Este error indica que el daemon ypbind en la máquina local no puede comunicarse con el daemon ypserv que sirve al dominio wigwam. Normalmente esta condición es temporal; el mensaje desaparece cuando la máquina del servidor NIS reinicia y es levantado el daemon ypserv, o cuando disminuye la carga en el servidor NIS y en la red. Si se obtiene el mensaje server not responding for domain, puede existir una de las siguientes situaciones: • El nombre de dominio en la máquina cliente NIS no está configurado o es incorrecto. Los clientes deben utilizar un nombre de dominio que los servidores NIS conozcan. • La red local puede no tener un servidor NIS. En esta circunstancia, todos los clientes NIS en la red local sufrirán el mismo problema o similar. • El servidor NIS no está encendido o en funcionamiento, o está sobrecargado. Si no hay un servidor de respaldo en la sub red de broadcast, todos los clientes no obtendrán respuesta a los requerimientos NIS hasta que el servidor funcione o reduzca la carga. • La mascara de broadcast puede estar configurada incorrectamente. Errores al configurar la red o la máscara de broadcast pueden evitar los broadcast que el ypbind utiliza para alcanzar un servidor. Si un servidor es inaccesible debido a una falla catastrófica, será necesario iniciar un servidor nuevo para el dominio, de manera que los clientes puedan ser ingresados con logins.
5.6.2.3 El comando ypwhich es inconsistente Cuando se utiliza el comando ypwhich repetidamente en el mismo nodo cliente, la respuesta varía
Página 217 de 283
porque el estado del servidor NIS cambia. Esto es normal. • La vinculación de los clientes NIS a los servidores NIS cambia con el tiempo en una red cargada. Cuando es posible, el sistema se estabiliza y todos los clientes obtienen de los servidores NIS tiempos de respuesta aceptables. • El origen de un servicio NIS no es importante porque un servidor NIS a menudo obtiene sus servicios NIS de otro servidor NIS de la red. Es común la inquietud cuando un servidor NIS, que es además un cliente NIS, está vinculado a algún otro servidor. Parece intuitivo que la máquina se vincule a si misma, pero normalmente no es así. El cliente no discrimina en lo que se refiere a dónde está vinculado el servidor.
5.6.2.4 Mapas muy largos no son soportados La arquitectura NIS no es muy escalable. El tamaño máximo de los mapas es 2 GB. Las bases de datos DBM muy grandes son lentas e ineficientes. Cuando el tamaño de los mapas se acerca a 2 GB, las rutinas DBM pueden fallar con errores fseek() y la creación de los mapas falla. Antes de alcanzar ese tamaño, el rendimiento normalmente se degrada al punto que la utilización de los mapas es imposible.
5.6.2.5 Routers, dispositivos de red, y vinculación NIS La vinculación NIS normalmente es realizada a través de broadcasts. De esta forma los clientes NIS se vinculan a un servidor y los esclavos NIS se vinculan a un master para realizar transferencias de mapas. Si los clientes fallan al vincularse, y hay puentes o routers entre las máquinas que intentan vincularse, el problema puede ser que el hardware no puede pasar los paquetes de broadcast necesarios para la vinculación. El comando ypset puede ayudar a solucionar esto, pero tiene la desventaja de que es poco confiable e inseguro. Para situaciones así, las mejores soluciones consisten en tener una máquina servidor que haga de puente entre las dos redes o en dividir la red en dos dominios separados (quizás un duplicado de una a otra).
5.6.2.6 Grupos incorrectos por cambios en un grupo nuevo Normalmente, este problema ocurre porque el mapa netid es incorrecto. Como contiene un mapeo de grupos por usuario, el mapa netid producirá resultados incorrectos si no es reconstruido siempre que los mapas passwd y group son modificados. Para evitar este problema, no se debe generar el mapa por sí solo.
5.6.2.7 mkdbm falla para entradas de mapas NIS muy grandes El diseño del DBM limita las entradas a 1024 bytes o menos de la siguiente manera: La suma de la clave DBM + datos debe ser < = 1024 bytes. El problema más común provocado por esto, es cuando una entrada en un grupo grande es rechazada por DBM porque hay muchos usuarios en el grupo, causando que el mkdbm falle. El problema ocurre normalmente en las entradas de los mapas de grupos y hay dos alternativas: • Hacer dos o más grupos con el mismo gid.
Página 218 de 283
• Agregar usuarios con el grupo grande como grupo primario y luego eliminar los usuarios de la entrada de grupo en /etc/group.
5.7 Resolución de problemas de NFS Antes de comenzar con la investigación en NFS, es necesario asegurarse que la red funcione correctamente. Es muy importante también asegurarse que la resolución de nombres sea funcional y consistente en toda la red y que el ruteo sea correcto en ambos sentidos.
5.7.1 Pasos generales para solucionar un problema de NFS Los pasos generales para solucionar un problema de NFS son los siguientes: 1. Verificar la correcta conectividad y configuración de la red. 2. Verificar los contenidos y permisos de los siguientes archivos de configuración de NFS en el cliente y en el servidor: • /etc/exports (servidores únicamente) • /etc/rc.tcpip • /etc/rc.nfs • /etc/filesystems (clientes únicamente) • /etc/inittab 3. Verifique que los siguientes daemons NFS estén activos en el cliente y en el servidor. Daemons requeridos en el servidor NFS: • portmap • biod • nfsd • rpc.mountd • rpc.statd • rpc.lockd Daemons del cliente NFS requeridos: • portmap • biod (estos son creados dinámicamente en AIX Versión 4.2.1 y superiores) • rpc.statd • rpc.lockd 4. Iniciar un iptrace (cliente, servidor o red), reproducir el problema, luego ver la salida del ipreport para determinar donde está el problema.
5.7.2 Problemas de montaje en NFS Los problemas de montaje caen dentro de alguna de las siguientes categorías: • File system no exportado, o no exportado para un cliente específico. • Lista de exportación correcta (/etc/exports) • Resolución de nombres diferente del nombre en la lista de exportación. Normalmente se
Página 219 de 283
debe a una de las siguientes causas: • La lista de exportación utiliza un nombre largo, pero el nombre del host cliente es resuelto sin el dominio de red. Los nombres largos no pueden ser resueltos, el permiso de montaje es denegado. Normalmente, esto ocurre después de un actividad de upgrade y puede ser solucionado exportando con las dos formas del nombre (con y sin dominio). • El cliente tiene dos adaptadores y dos nombres diferentes para los dos adaptadores y el export sólo especifica uno. Este problema puede ser solucionado exportando ambos nombres. • El servidor no puede hacer una búsqueda por nombre o por dirección en el cliente. Para resolverlo, se debe verificar que los siguientes comandos resuelvan coherentemente: • host • host • El file system fue montado en el servidor luego de que se ejecutó el exportfs. En este caso, el comando exportfs está exportando el punto de montaje y no el file system. Para corregir este problema, se debe ejecutar: /usr/etc/exportfs -ua; /usr/etc/exportfs –a
Luego corrija el archivo /etc/filesystems para que se monte el file system en el reinicio del sistema, de manera que se encuentre montado cuando el NFS es iniciado • Cambios inesperados en la lista de exportación, en los montajes, o en algún otro punto, a veces pueden provocar que el mountd quede confundido. Esto ocurre normalmente después de un montaje, una exportación, o por un conflictivo punto de montaje, etc. Para corregir esta condición, el mountd debe ser reiniciado: # stopsrc -s rpc.mountd # startsrc -s rpc.mountd
• Otro motivo que genera problemas de montaje es que la fecha y hora del sistema sean erróneas en una de las dos máquinas. Para solucionar esto se debe corregir la fecha y la hora y luego reiniciar el sistema. • Los montajes son lentos desde clientes con AIX V4.2.1 o superior (NFS Version 3) a servidores con AIX V4.1.5 o anterior y otros servidores no AIX (con NFS Version 2). La Versión 3 de NFS utiliza TCP por defecto mientras que la Versión 2 de NFS utiliza únicamente UDP. Esto significa que el requerimiento de montaje inicial del cliente utilizando TCP fallará. Para proveer compatibilidad hacia atrás, el montaje es reintentado utilizando UDP, pero esto ocurre después de un tiempo de espera de algunos minutos. Para evitar este problema, NFS V3 provee los parámetros proto y vers con el comando mount. Estos parámetros son utilizados con el flag -o para unificar el protocolo y la versión de un montaje específico. En el siguiente ejemplo se fuerza la utilización de UDP y NFS V2 para el requerimiento de montaje: # mount -o proto=udp,vers=2,soft,retr proto=udp,vers=2,soft,retry=1 y=1 platypus:/test /mnt
Nota Si el proto y el vers no coinciden con el servidor, el montaje fallará completamente.
Página 220 de 283
• Clientes no AIX antiguos pueden sufrir problemas de montaje. Si en el entorno hay este tipo de clientes, será necesario iniciar el mountd con la opción -n: # stopsrc -s rpc.mountd # startsrc -s rpc.mountd -n
• Otro problema de montaje que puede ocurrir con clientes no AIX antiguos es cuando un usuario que solicita un montaje está en más de ocho grupos. La única alternativa para este problema es disminuir la cantidad de grupos en los que está el usuario o realizar el montaje con un usuario diferente.
5.7.2.1 Montajes soft y montajes hard Cuando la red o el servidor tienen problemas, los programas que acceden a file systems remotos montados de manera hard fallan de forma diferente que los que acceden a file systems remotos montados de manera soft. Si un servidor falla y no responde al requerimiento de un montaje hard, el NFS muestra el siguiente mensaje: NFS server not responding, still trying
Los file systems remotos montados de manera hard provocan que los programas se detengan hasta que el servidor responda, porque el cliente reintenta el requerimiento hasta que sucede. Se debe utilizar el flag -bg con el comando mount cuando se realiza un montaje hard, de manera que si el servidor no responde, el cliente reintente el montaje en background. Si un servidor no responde al requerimiento de un montaje soft, el NFS muestra el siguiente mensaje: Connection timed out
Los file systems remotos montados de manera soft devuelven un error después de algunos intentos insatisfactorios. Desafortunadamente, muchos programas no verifican las condiciones de retorno en las operaciones con file systems, por lo que este error no se podrá ver cuando se acceden archivos de montajes soft. Sin embargo, este error NFS aparecerá en la consola.
5.7.3 Problemas de rendimiento de NFS Lo primero que se determina cuando hay problemas de rendimiento de NFS es si es un problema de recursos insuficientes o de demasiados recursos. Las siguientes preguntas deben responderse para comenzar la determinación: • ¿Cual es la carga del proceso en el cliente y/o servidor? • ¿Hay muchos usuarios o procesos utilizando NFS? • ¿Hay muchas operaciones de lectura/escritura simultáneas sobre NFS? Si una o ambas preguntas es verdadera, la causa probable es que la máquina sufre falta de recursos en alguna parte. • ¿Hay otras máquinas en la misma sub red sufriendo problemas? Si todos los clientes en una cierta sub red sufren problemas, y el servidor está en otra sub red, los probables sospechosos serán el hardware de la red y las configuraciones entre las sub redes.
Página 221 de 283
• ¿Hay otras máquinas que no estén en la misma sub red sufriendo problemas? El dedo acusador apunta al servidor en este caso, pero esto puede ser también un problema de red como en el punto anterior. • ¿El servidor tiene problemas? Si la máquina sólo ejecuta una prueba que copia un archivo y la copia tarda más de lo que debería, lo más probable es que algo esté saturado tanto en la red como en el servidor. Cuando se sospecha que la máquina está saturando una recurso de la red o del servidor, a veces es recomendable ejecutar la prueba de un biod . Para AIX 4.2.1 y superiores, la prueba puede realizarse desmontando y montando el file system utilizando el comando mount -o biods=1. Para sistema anteriores, simplemente ejecute el comando stopsrc -s biod; esto deja sólo un kbio corriendo. • Si la prueba funciona más rápidamente con sólo un biod o kbio, algo está siendo saturado. • Si el montaje utiliza UDP, intente utilizar un montaje TCP. Por defecto, en AIX V4.3.0 y superiores, los montajes son TCP. Si en los pasos anteriores se determina que es necesaria una optimización del sistema para proveer más recursos para un rendimiento de NFS adecuado, el siguiente paso es poner en el lugar un entorno controlado para evaluar qué efectos tienen las operaciones de optimización en el sistema. Este entorno de prueba debe ser los más parecido posible al entorno productivo, ya que las variaciones en el sistema o en la red pueden invalidar completamente los resultados. Es necesario crear una prueba fácilmente repetible, que muestre el problema. Por ejemplo, si el problema es el rendimiento de las lecturas y escrituras, la mejor manera de probar es simplemente utilizar el comando cp para copiar un archivo sobre NFS. Si se copia un archivo al cliente (probando lecturas), es mejor copiarlo al /dev/null para eliminar el tiempo de escritura a disco. Cuando se establece una prueba para evaluar el rendimiento, es necesario evaluar como la optimización del rendimiento afecta al sistema. El método más simple es calcular el tiempo que tarda en com-pletarse la prueba. El criterio simple es que si funciona más rápido, la optimización ayudó, y si funciona más lento, algo se hizo mal. El método más fácil para medir el tiempo de ejecución es utilizar el comando time como muestra el siguiente ejemplo: time cp /servera/testdir/1MBfile /dev/null
Otra forma de monitorear los resultados de la prueba es utilizar el comando nfsstat y observar los paquetes rechazados de la siguiente manera: 1. Utilice el comando nfsstat -z para poner en cero las estadísticas. 2. Ejecute la prueba. 3. Utilice el comando nfsstat -cr para ver cuántos paquetes fueron rechazados. El siguiente ejemplo muestra que doce paquetes fueron rechazados en algún punto durante un montaje UDP. A menudo, los valores retrans y timeout no son iguales, dado que todos los timeouts no necesariamente provoquen una retransmisión. # nfsstat -cr Client rpc: Connection oriented calls badcalls 61663 0 nomem cantconn 0 0
En general, se podrá observar que así como la cantidad de paquetes rechazados baja, el tiempo de finalización de la prueba disminuye. Se debe tener en cuenta que en AIX V4.2.1 y posteriores, hace falta observar las estadísticas de Connectionless (UDP) y Connection oriented (TCP) para verificar los tiempos de espera y las retransmisiones. Si hay paquetes rechazados, primero se debe asegurar que no haya problemas de recursos en el cliente. Esto se realiza verificando la salida del comando netstat. Si no hay paquetes rechazados, se deben sospechar problemas con la aplicación, o son necesarios más biods. El comando nfsstat permite monitorear las estadísticas de funcionamiento y rendimiento de NFS y RPC. Para encontrar dónde son rechazados los paquetes, utilice el comando con varias opciones como se muestra en los siguientes ejemplos: • Verifique los Oerrs en la salida del comando netstat -in: # netstat -in Name Mtu Network lo0 16896 link#1 lo0 16896 127 lo0 16896 ::1 en0 1500 link#2 en0 1500 192.168.1 tr0 1492 link#3 tr0 1492 9.185.112 #
Los Oerrs indican normalmente que es necesario incrementar el tamaño de la cola de transmisión del dispositivo. En el caso del ejemplo anterior, como hay Oerrs en la interfase tr0, será necesario cambiar el parámetro xmt_que_size del tok0 utilizando la siguiente sintaxis del comando chdev: # chdev -P -l tok0 -a xmt_que_size=120
• Verifique en la salida del netstat -s los valores diferentes a cero: El comando netstat -s reporta todas las estadísticas de red para IP, UDP, TCP, ICMP, etc. Hay unos pocos contadores que pueden ayudar a determinar si hay algún problema de configuración de la red o de un dispositivo que pueda provocar un problema de rendimiento. En la sección de estadísticas IP, éstos son los contadores bad header checksums y fragments dropped. En la sección de estadísticas UDP, los contadores bad checksum y dropped due to no socket son los que se debe revisar si son distintos a cero. • Para mostrar sólo las estadísticas distintas a cero de la sección IP, utilice el comando netstat -s -s de la siguiente forma: # netstat -s -s -p ip
Verifique la salida de los siguientes campos: • bad header checksums (problemas de red) • fragments dropped (colas del manejador de dispositivos no suficiente-
Página 223 de 283
mente grandes) • Para mostrar sólo las estadísticas distintas a cero de la sección UDP, utilice el comando netstat -s -s de la siguiente forma: : # netstat -s -s -p udp
Verifique la salida de los siguientes campos: • bad checksums (problemas de red) • dropped due to no socket (espacio para recibir insuficiente) Valores diferentes a cero en los campos mencionados puede ser un indicador de paquetes rechazados.
Nota Utilizando la forma netstat -s -s reduce considerablemente el volumen de la salida mostrando únicamente los contadores de estadísticas con valores distintos a cero. • Verifique en la salida del comando netstat -v las estadísticas de las interfases de red. El comando netstat -s reporta estadísticas para el nivel IP y superiores. Para estadísticas específicas de dispositivos de red, puede utilizarse el comando netstat -v. Para determinar si una interfase de red específica está rechazando paquetes, se deben observar si las siguientes estadísticas son distintas a cero: • transmit/receive errors • transmit/receive packets dropped Valores diferentes a cero en los campos mencionados indican que el tamaño de las colas es muy pequeño o problemas en el adaptador de red. Las estadísticas Max Packets on S/W Transmit Queue y S/W Transmit Queue Overflow pueden ser útiles para determinar el tamaño apropiado de las colas para cada configuración en particular. • Verifique en la salida del comando netstat -m el uso de memoria de red y mbufs. Hay una limitada cantidad de mbufs o memoria asignada para ser utilizada por el subsistema de red. Si el sistema tiene poca de esta memoria y se reciben paquetes, es posible que estos paquetes sean rechazados porque no hay suficiente espacio para ellos. El comando netstat –m reporta estas fallas en el contador requests for memory denied. Valores diferentes a cero en requests for mbufs denied o en el contador failed de la sección Kernel malloc statistics pueden indicar una situación provocada por el rechazo de paquetes. Si la salida del netstat -m muestra valores diferentes a cero en requests for mbufs denied, el comando no puede ser utilizado para incrementar la memoria asignada para ser usada por mbufs. • Si luego de realizar los pasos anteriores no hay indicios de paquetes rechazados, se puede intentar incrementar la cantidad de procesos biod cliente. No hay un conjunto de reglas a cerca de cuantos biods deben ejecutarse; normalmente, los valores por defecto entregan un rendimiento adecuado. Sin embargo, hay situaciones donde varios biods/kbios pueden ser consumidos en leer un archivo. Si este es el caso, y es probable que el sistema vaya a tener múltiples lecturas y escrituras en forma concurrente, el rendimiento debe ser mejorado incrementado la cantidad de biods respecto la valor por defecto.
Página 224 de 283
La cantidad por defecto de kbios o biods permitidos en un file system varía dependiendo de los niveles de AIX y NFS: • NFS V2 en versiones de AIX anteriores a 4.2.1 tienen seis biods. • AIX Versión 4.2.1 y posteriores tienen seis kbios en NFS V2 y cuatro en V3. Cualquier incremento en la cantidad de biods/kbios debe ser realizado y monitoreado en forma de prueba y error. Se debe incrementar la cantidad de biods hasta que la performance se nivele completamente o los paquetes comiencen a ser rechazados: • Para incrementar a 16 la cantidad de daemons biod en el cliente cuando se utiliza AIX Versión 4.2.0 y anteriores, utilice la siguiente sintaxis del comando: # /usr/sbin/chnfs -b 16 -B
• Para incrementar a 16 la cantidad de threads kbio en el punto de montaje de un cliente cuando se utiliza AIX Versión 4.2.1 y posteriores, se debe incluir -o biods=16 en el comando mount: # mount -o rw,intr,bg,timeo=2,biods=16 thor:/usr/tools thor:/usr/tools /usr/tools
Nota Si usted ve paquetes perdidos en la máquina, incrementar la cantidad de biods probablemente provoque una dramática degradación del rendimiento.
5.7.3.1 Empeorando el rendimiento del cliente para redes o servidores lentos Cuando el comando nfsstat muestra que la máquina debe retransmitir paquetes, y se sospecha que la máquina está sobrecargando un recurso de red o del servidor, hay dos cosas que se deben observar inicialmente: 1. Si el montaje es a través de UDP, intente utilizar TCP si tanto el servidor como el cliente lo soportan. 2. Si no funciona, a veces es útil intentar la prueba de un biod. Para realizarla en versiones de AIX anteriores a V4.2.1, se debe ejecutar el comando stopsrc –s biod. Esto dejará un kproc biod corriendo y lentificará la velocidad de lectura/escritura del cliente. Para AIX V4.2.1 y posteriores, se debe desmontar el file system remoto y montarlo nuevamente utilizando la opción -o biods=1 en el comando mount. Si cuando esto se realiza, el rendimiento del NFS aumenta, se está frente a un problema donde la máquina está configurada para correr demasiado rápido en relación a la red o al servidor. A veces, esto puede solucionarse detectando el problema (dispositivo de red o servidor) y corrigiéndolo. La solución óptima no es empeorar el rendimiento del cliente, sino arreglar cualquier cosa que sea el cuello de botella, tanto en la red o en el servidor NFS. Si esto no puede realizarse, entonces hay dos formas de empeorar el rendimiento del cliente: 1. La primera es reducir la cantidad de biods, como se hace en la prueba de un biod. 2. La segunda es reducir el tamaño de las lecturas/escrituras. Ambas opciones reducirán la carga en el servidor y la red, pero hay algunas diferencias sutiles. La primera opción puede realizarse disminuyendo la cantidad de biods disponible para correr en cada uno de los file systems, y de esta manera limitar la cantidad que puede trabajar con cada archivo. La cantidad permitida por file system es modificada utilizando el comando mount con la opción biods=X en el/los file system(s) en cuestión.
Página 225 de 283
A menudo, es mejor opción cambiar el tamaño de las lecturas/escrituras que cambiar la cantidad de biods. El tamaño por defecto de una lectura o escritura NFS en NFS Versión 2 es 8192 bytes por requerimiento de lectura/escritura RPC. Por lo tanto, cuando 8 Kb de datos de lectura o escritura es enviado por la red, con un MTU típico de alrededor de 1500 bytes, la lectura o escritura será fragmentada en seis paquetes. En NFS V3 el problema es magnificado porque el tamaño de las lecturas/escrituras es de 32 K y la cantidad de paquetes crece a 23. La pérdida de un sólo paquete genera tiempos de espera y la retransmisión, provocando que todos los paquetes sean reenviados. La idea detrás de cambiar los tamaños de lectura/escritura es reducir la cantidad de paquetes necesaria para satisfacer un requerimiento de lectura o escritura e incrementar las chances de éxito en el primer intento. Los tamaños de lectura/escritura son especificados por el comando mount para el file system en cuestión. En general, la mejor estrategia es comenzar con dos o tres kbios y tamaños de lectura/escritura de 1024 bytes. Luego los números pueden ser ajustados hacia arriba o abajo para obtener el mejor rendimiento.
5.7.4 Fallas de locking Utilice la siguiente lista de comprobación para investigar problemas de locking de NFS: • Verifique la resolución de nombres. • Utilice el comando rpcinfo para asegurarse que los daemons estén funcionando. • Inicie el daemon lock con depuración activada. Esto normalmente se debe realizar bajo la dirección del personal de soporte.
5.7.4.1 Iniciando el rpc.lockd con depuración El método para capturar la salida de la depuración del lockd cambió a partir de AIX 4.2.1. Anteriormente, la salida era dirigida directamente a la consola del sistema. Para AIX 4.2.1 y posteriores, la salida del lockd es capturada con syslogd, por lo tanto, syslog debe ser configurado modificando el archivo /etc/syslog.conf para que la salida de la depuración a un archivo. El archivo /etc/syslog.conf necesita una línea líne a similar a la siguiente: *.debug /tmp/cons.out
Esto enviará todos los mensajes de depuración severa al archivo /tmp/cons.out. Este archivo debe existir primero, porque el syslogd no lo creará. Se debe refrescar el syslog para que reinicie utilizando el nuevo archivo con el comando: # refresh -s syslogd
Una vez que se refresca el syslogd, se debe reiniciar el lockd con el flag -d1 utilizando uno de los siguientes comandos y éste comenzará a guardar los mensajes de depuración en el archivo cons.out. # rpc.lockd -d1 # startsrc -s rpc.lockd -a -d1
Nota El flag -d no está documentado. Valores entre 1 y 5 otorgan una adecuada información de depuración.
Página 226 de 283
5.7.5 Un cliente NFS se detiene durante el reinicio del sistema Cuando un cliente NFS se detiene durante el reinicio del sistema, es probable que haya especificado en el archivo /etc/filesystems un montaje automático que no se está realizando en background. Si se experimentan problemas de este tipo durante el reinicio del sistema, se deben verificar las secciones de NFS en el archivo /etc/filesystems para asegurarse que la opción bg sea especificada con el comando mount. Todos los montajes de NFS, aquellos que son realizados automáticamente en el inicio del sistema, tanto en el /etc/filesystems como en scripts de arranque, deben tener configurada la opción background. El siguiente ejemplo muestra un montaje automático incorrectamente configurado que ocasionará que el sistema se detenga durante el reinicio: # vi /etc/filesystems /usr/local: dev = /usr/local vfs = nfs nodename = thor mount = true type = bsd options = hard,intr,fg
La línea mount = true indica un montaje automático; por lo tanto, las opciones deben ser modificadas por: options = hard,intr,bg
5.8 Depuración de SLIP (Serial Line Internet Protocol) El primer paso en cualquier depuración de SLIP es verificar el enlace físico. Esto se puede realizar utilizando los comandos ate o cu; El comando ate necesita que esté instalado el fileset bos.net.ate. Para una verificación utilizando ate: 1. Conecte físicamente los modems o conecte los cables directamente en los puertos serie de ambos sistemas. 2. Se deben crear ttys en los mencionados puertos, configure Enable LOGIN en disable en el puerto que llama y en enable el puerto llamado, y FLOW CONTROL to be used en rts. 3. Ingrese el comando ate en el sistema que llama, luego: a. En el menú principal de Unconnected, Unconnected, seleccione el subcomando Alter. Configure Rate según el baud rate del modem y Device con la tty utilizada. b. En el menú principal de Unconnected, seleccione el subcomando Connect. Cuando ATE pide un número telefónico, ingrese el número telefónico del sistema a llamar y presione Enter (para conexión directa sólo presione Enter). c. En este punto, debería recibirse recibirse un login. Si es así, presione Ctrl-v para retornar a la pantalla conectada, presione t para logout, y presione q para salir del ATE.
Nota Si no se recibe un login, se debe volver al comienzo de esta sección y verificar que la configuración sea correcta. No se debe continuar con la investigación de SLIP hasta que no se obtenga el login del sistema remoto. 4. Utilice smit chgtty para cambiar la configuración Enable LOGIN a disable en la tty del
Página 227 de 283
sistema remoto. Cuando se verifica que la conexión es buena, es necesario verificar la información de tty en el archivo /etc/uucp/Devices en ambos sistemas para asegurarse que refleja la tty y los detalles de conexión correctos. El siguiente ejemplo muestra la información requerida para una conexión de 9600 baud en tty1: Direct tty1 - 9600 direct
Es necesario utilizar el menú rápido smit chinet para verificar los detalles de la red SLIP en ambos sistemas. Se debe poner atención en los siguientes campos: • Direcciones Internet de ambos sistemas • Baud rates seleccionados Verifique en el archivo /etc/hosts las direcciones mencionadas y los nombres de las interfases. Si se está utilizando sliplogin, debe asegurarse que el usuario exista en el archivo de configuración /etc/slip.hosts y que las direcciones IP y la máscara de red sean correctas. Si se está llamando a un servidor sliplogin, intente utilizar el script de ejemplo /usr/sbin/slipcall para llamar y establecer la conexión SLIP. Se puede obtener información muy útil utilizando el parámetro Debug_Level con el comando slattach. Para producir la salida se deben utilizar niveles de depuración comprendidos entre 0 y 9.
5.9 Depuración de PPP (Point-to-Point Protocol) asincrónico Esta sección contiene información sobre cliente y servidor de conexiones AIX PPP.
5.9.1 AIX como cliente PPP (llamadas salientes) Para hacer llamados con PPP, debe haber una tty definida para el puerto del modem con Enable LOGIN configurado en disable y FLOW CONTROL to be used en rts. Para verificar la tty, primero se debe asegurar que las utilidades BNU estén instaladas, verificando el fileset bos.net.uucp, y luego ejecutar el comando cu -ml ttyXX. El siguiente ejemplo del cu muestra el flujo de la sesión: john@rios:/home/john > cu -ml tty8 Connected at OK ~[rios]. The connection is ended.
Nota No se debe continuar la investigación sobre PPP hasta que el modem responda como en el ejemplo anterior. Si hace falta una depuración adicional, se puede utilizar el comando cu -dml ttyXX. Otra herramienta útil en la investigación sobre PPP es syslogd. Si no fue configurada como parte de la configuración inicial de PPP, será necesario configurarla ahora. El siguiente ejemplo puede utilizarse como guía: 1. Agregar la siguiente línea en el archivo /etc/syslog.conf: *.debug /tmp/ppp
Página 228 de 283
2. Crear el archivo /tmp/ppp y agregarle permiso de escritura: >/tmp/ppp chmod +w /tmp/ppp
3. Advertirle al syslogd que el archivo /etc/syslog.conf fue modificado. Ejecute el siguiente comando: refresh -s syslogd
Además se debe verificar que el archivo /etc/uucp/Devices contenga la siguiente línea: Direct tty## - baud_rate direct
Donde tty## es la tty creada anteriormente y baud_rate es el baud rate configurado para la tty. Intente iniciar el subsistema PPP con smit o ejecutando el siguiente comando: startsrc -s pppcontrold
Nota Cualquier cambio en la configuración requiere que el subsistema PPP (pppcontrold) sea detenido y reiniciado. Utilice SMIT o stopsrc -cs pppcontrold para detener el subsistema. Utilice los siguientes comandos para verificar que el subsistema PPP ha iniciado: • netstat -in (para verificar si las interfases de red pp# fueron creadas). Antes de que se establezca la conexión, la dirección IP de las interfases PPP será 0.0.0.0. • lssrc -s pppcontrold (para verificar si PPP está corriendo) Si PPP no está corriendo, puede haber problemas en la configuración (verifíquelo con smit ppp), o es necesaria la actualización de los filesets PPP. Para obtener información de depuración más detallada del comando pppcontrold, se puede enviar la señal 30 de la siguiente manera: lssrc -s pppcontrold
Anote el ID del proceso (PID): kill -30
Donde pppcontrold_PID es el número PID del pppcontrold retornado por el comando lssrc. Esto abrirá un mensaje indicando que la depuración fue activada para el archivo /tmp/ppp que fue creado con la configuración del syslogd. La información de diagnóstico puede ser desactivada más tarde utilizando el comando kill -31 . Si el la conexión no es establecida cuando se ejecuta el comando pppattachd: • Verifique las tablas de ruteo en ambos sistemas • Asegúrese que el contenido del script de conversación (Chat Script) coincide con los requerimientos del modem. El comando pppattachd llama al programa pppdial que utiliza el script de conversación para realizar el llamado. El siguiente es un ejemplo de un comando que realiza un llamado: /usr/sbin/pppattachd client tty8 connect "/usr/sbin/pppdial -v -f CHAT_SCRIPT_FILE"
Página 229 de 283
• Luego de ejecutar el comando pppattachd, el progreso del llamado puede ser observado ejecutando el siguiente comando: tail -f /tmp/ppp
Donde /tmp/ppp es el archivo creado en la configuración del syslogd al que fue direccionada la información de depuración. Los siguientes archivos de configuración también contienen datos útiles para la determinación de problemas de conexión: • /etc/ppp/if_conf Contiene la configuración de la interfase PPP IP. • /etc/ppp/lcp.conf Contiene la información de configuración de los paneles de configuración LCP. • /etc/ppp/if_link.map Contiene la correlación de interfases con bloques de conexión de red LCP. • /etc/ppp/attXXX.pid Contiene archivos de los ID de procesos para los attachments asincrónicos.
5.9.1.1 Chat scripts (scripts de conversación) El programa pppdial llamado por el comando pppattachd utiliza una conversación UUCP para establecer la conexión con el sistema remoto. El siguiente ejemplo muestra un script de conversación con notas explicativas para asistir a la resolución de problemas de PPP: '' ATDT555-5555 CONNECT '' in: myuserid word: mypassword
Línea a línea, el significado del script es el siguiente: • Espera nada. • Envía al ATDT555-5555 ATDT555-5555 (para que el modem disque este número). • Espera CONNECT del modem. • Envía nada. • Espera [log]in: (el login enviado por el sistema remoto). • Envía el userid. • Espera [pass]word: (el requerimiento de password enviado por el sistema remoto). • Envía la passwd.
5.9.1.2 Problemas de autenticación La razón específica de una falla en la autenticación, cuando se utilizan los protocolos de autenticación PAP o CHAP, es normalmente mostrada en el archivo de log del syslogd (/tmp/ppp en los ejemplos utilizados).
Página 230 de 283
Si se está utilizando autenticación CHAP, se debe tener en cuenta que Microsoft utiliza un algoritmo CHAP diferente del de AIX. El protocolo CHAP de Windows 95/Windows NT es incompatible con AIX. Si se utiliza PAP, use el siguiente procedimiento de configuración simplificado para verificar que la autenticación funcione. En el panel de SMIT de Autenticación PAP: • El nombre del host remoto es el nombre del autenticador desde la perspectiva del par. • A * como nombre del host remoto indica cualquier autenticador. En la máquina servidor: smitty ppp PAP Authentication Add a User User name Remote host name Password
[david] [*] [david]
Para verificar que el usuario pap fue creado: vi /etc/ppp/pap-secrets
Busque david * david en el archivo: cd /home/goliath
Donde goliath es el usuario creado para ingresar al servidor vi .profile
Agregue la siguiente línea: exec /usr/sbin/pppattachd server authenticate pap 2>/dev/null
En la máquina cliente: smitty ppp PAP Authentication Add a User User name Remote host name Password
[david] [*] [david]
Utilice el siguiente comando para conectarse como cliente: /usr/sbin/pppattachd client /dev/tty# peer pap USERNAME connect "/usr/sbin/pppdial -v -f CHAT_SCRIPT_FILE"
Donde USERNAME es el nombre del usuario PAP y CHAT_SCRIPT_FILE es el nombre completo del script de conversación. Disque desde el cliente, establezca la conexión, y la autenticación debería funcionar. Si no es así, verifique el archivo de salida del syslog.
5.9.2 AIX como servidor PPP (llamadas entrantes) Para aceptar llamadas entrantes con PPP, debe haber una tty definida para el puerto del modem con Enable LOGIN configurado en enable, delay, o share, y FLOW CONTROL to be used en rts. Además, se debe configurar syslogd de la misma forma que en la sección de cliente. Verifique que el subsistema PPP esté activo en este servidor con los siguientes comandos:
Página 231 de 283
• lssrc -s pppcontrold Esto debería mostrarlo activo. • ps –ef | grep ppp Debe haber un proceso pppcontrold corriendo. • ifconfig pp0 La interfase pp0 debería mostrar la dirección IP correcta. Si no es posible el login después de establecer la conexión, verifique que el usuario es miembro del grupo UUCP. Además, se debe verificar que la primera línea del .profile del usuario sea la siguiente (para ksh): exec /usr/sbin/pppattachd server 2>/dev/null
Página 232 de 283
6. Resolución de problemas de impresión El objetivo de este capítulo es proveer al administrador de algunas herramientas y recomendaciones que lo ayuden a convertir el arte de la resolución de problemas en una ciencia. Los problemas de impresión pueden ser menores como pequeñas manchas en la hoja o mayores como comprobar que la impresión no se realizó. Dónde buscar los problemas depende de factores como el tipo de impresora, el tipo de archivo a imprimir, y la forma en que la impresora está conectada al servidor. Este capítulo se divide en tres secciones: • Técnicas para resolver problemas comunes • Resolución de problemas específicos del subsistema System V • Resolución de problemas específicos del subsistema PowerPC El procedimiento para determinar el problema puede ser reducido a unos pocos pasos: 1. Aislar el problema - Determine el sistema y el subsistema donde existe el problema. - Determine si el problema es de hardware o software. - Determine si el problema es local o remoto. - ¿Llegan los datos a la impresora? 2. Identificar la causa del problema - ¿La impresora está conectada correctamente? - ¿Los datos están formateados correctamente por los filtros adecuados? - ¿Se están utilizando los flags adecuados? - ¿La impresora está configurada correctamente? 3. Mejorar la situación - Pruebe con una impresora, un adaptador o un cable diferentes. - Use una impresora virtual o un tipo de impresora mas apropiado. - Use flags de impresión diferentes. 4. Pruebe la solución - Pruebe con otros archivos de impresión. - Que otros usuarios intenten imprimir. - Asegúrese de que no creó nuevos problemas. El resto del capítulo lista algunos de los problemas de impresión más comunes, y provee información que ayuda a aislar el problema, identificar el problema, mejorar la situación y probar la solución.
Página 233 de 283
6.1 Pasos a seguir para resolver problemas comunes En esta sección se detallan problemas que ocurren típicamente cuando se intenta imprimir documentos. En cada caso, serán exploradas las áreas comunes para ambos subsistemas de impresión.
6.1.1 Pasos a seguir en problemas de impresión local La siguiente lista es un resumen de cosas que se pueden verificar si los trabajos no son impresos en impresoras locales: • ¿La impresora está lista? - ¿La impresora está encendida? - ¿La impresora tiene mensajes en la pantalla o luces parpadeantes? - ¿Puede imprimir una página de prueba? - ¿Se puede imprimir desde otros sistemas? - ¿Los cables están ajustados, son del tipo correcto y del largo correcto? - ¿El cable está bien? Verifíquelo en otro sistema. • ¿Es correcta la configuración del dispositivo? - Redireccione la salida directamente al archivo del dispositivo. - En una conexión serial ¿Son correctos el baud rate, la comunicación y el número de puerto? - Intente en un puerto diferente del ordenador. • ¿La impresora o impresora virtual está configurada correctamente? - ¿La impresora corresponde con el data stream y los tipos definidos en la configuración de la impresora o cola de impresión? - ¿La impresora apunta al dispositivo correcto? - ¿El usuario tiene permitido imprimir en la impresora? (System V) - ¿Son válidos los flags de impresión para la impresora virtual o el script de la interfase? - ¿La impresora está activada y aceptando trabajos? Use lpstat con los flags correctos. - ¿El nombre de la impresora está escrito correctamente en el comando de impresión? - ¿Se obtienen mensajes en la línea de comandos, por correo, o en el log de errores? • ¿El qdaemon (PowerPC) o lpsched (System V) está corriendo? Para verificarlo, utilice: - System V: lpstat -r - PowerPC: lssrc -s qdaemon
6.1.2 Pasos a seguir en problemas de impresión remota La siguiente lista es un resumen de cosas que se pueden verificar si los trabajos no son impresos en impresoras remotas: • ¿lpd o lpNet están corriendo en el servidor? Para verificarlo, utilice: - System V: lpstat -r - PowerPC: lssrc -s lpd
Página 234 de 283
• ¿El cliente tiene correctamente especificados el nombre del servidor y de la cola remota? • Existen el nombre del servidor y del cliente en un DNS o en los respectivos archivos /etc/hosts? • ¿El cliente tiene permiso para imprimir en el servidor? - System V: Verifique el archivo Systems en el cliente y el servidor. - PowerPC: Verifique el nombre del sistema en el archivo /etc/hosts.lpd del servidor. - En nombre en este archivo coincide con el del DNS? Verifique la dirección IP, y los nombres cortos y largos (nombre + dominio). • ¿El usuario en el cliente tiene permiso para imprimir en la impresora? • System V: Verifique el archivo users.allow o use lpstat -p printer –l para ver los permisos correctos. Use all!all para todos los usuarios remotos. • PowerPC: Use rembak y las funciones de depuración de lpd. • System V: Verifique el log /etc/lp/logs/lpNet. • Use iptrace para ver como viaja un trabajo a través de la red. • Desactive la cola del servidor - Asegúrese que el trabajo está encolado en el servidor mientras la cola está desactivada. - Revise el JDF (Job Description File) o el log del requerimiento para ver los flags de la línea de comandos. • Si es encolado, pero no se imprime cuando la cola es activada: - Haga una copia del archivo y utilice procedimientos locales. - Utilice los flags en el JDF o en el log del requerimiento para imprimir.
6.1.3 Revise lo obvio Revise lo obvio: • Asegúrese que la impresora esté encendida y en línea. • Asegúrese que el cable esté conectado a la impresora y al ordenador. • Asegúrese que los cables LAN estén conectados en el servidor de impresión y en la impresora, y que la red esté funcionando correctamente.
6.1.4 Nada se imprime en impresoras locales Una de las cosas más frustrantes es imprimir un trabajo, ir hasta la impresora, y encontrar que no salió la impresión. ¿Qué se debe hacer?
6.1.4.1 Mi trabajo se perdió, pero otros son impresos El problema puede no estar relacionado con la impresora. Alguien puede haber tomado accidentalmente el papel impreso. Esto ocurre muy a menudo cuando no se utilizan banners, o cuando el
Página 235 de 283
banner es del mismo color que las impresiones. Colas múltiples con una desactivada o caída ¿Es posible que la cola esté retrasada con una gran cantidad de trabajos, o un solo trabajo muy grande? A veces un trabajo grande provocará que la cola se caiga, o se desactive. Cuando se configuran colas o impresoras virtuales múltiples para que impriman en la misma impresora, es posible que una de esas colas sea deshabilitada mientras otras siguen imprimiendo. ¿Se está imprimiendo texto en una impresora PostScript? Mientras algunas impresoras pueden intuir el tipo de data stream y automáticamente seleccionan el mecanismo interno de impresión adecuado, muchas veces si se le dice a una impresora que el trabajo es PostScript, y se le envía un archivo de texto ASCII o un trabajo PostScript que no está formateado apropiadamente, no imprime absolutamente nada. Verifique la impresora para ver que los archivos que son impresos son trabajos PostScript válidos. ¿Qué tan grande es el trabajo que falla? Si el trabajo que no se imprime es mucho más grande que los trabajos que sí se imprimen, puede haber varias razones por las que el trabajo falla. Algunas de estas razones son: • El trabajo fue puesto en el spool de impresión, y en éste no hay suficiente espacio. • El trabajo fue enviado a un servidor de impresión de red que no tiene un buffer suficientemente grande. Si se está utilizando un dispositivo para impresión en red, como Axis, HP JetDirectEX, o Intel NetPort, el espacio de buffer interno de estos dispositivos puede limitar el tamaño del archivo que se quiere imprimir. Verifique si el trabajo puede imprimirse en una impresora conectada a un puerto paralelo o serie local. Si se determina que el trabajo es muy grande, se debe intentar imprimirlo por partes. • La memoria de la impresora no es suficientemente grande para manejar el trabajo de impresión. Si el file system del AIX es suficientemente grande y se pueden imprimir trabajos pequeños, el problema debe estar en la impresora. Verifique si se puede dividir el trabajo en partes más pequeñas. Intente establecer los límites de la impresora probando con archivos de tamaños diferentes. Puede que sea posible agregar más memoria a la impresora. ¿El trabajo es accesible para el servicio de impresión? Los archivos de impresión AFS/DFS que son accesibles para el usuario, a veces no son accesibles para el servicio de impresión. Si se intenta imprimir archivos que están en un file system remoto y no se imprimen aún si archivos similares que están en el sistema local se imprimen correctamente, intente mover los archivos al /tmp e imprimirlos desde ahí. Si funciona, se deberá realizar siempre de esta manera, o se deberán modificar los permisos al ser exportados por el servidor. ¿Se envió el trabajo a la cola o impresora correcta? A veces, los nombres de las impresoras pueden confundir y ser parecidos entre sí. Asegúrese que está imprimiendo en la cola correcta y que la impresora esté ubicada físicamente en donde se buscan las impresiones.
6.1.4.2 Nada se imprime, pero las luces en la impresora parpadean o cambian. Con este síntoma, se puede asegurar que algo llega a la impresora, pero por alguna razón, rechaza los trabajos.
Página 236 de 283
¿La impresora soporta el data stream del archivo de impresión? Como se mencionó anteriormente, una de las causas más comunes por las que se presenta este problema, es imprimir archivos de texto ASCII en una cola de impresión PostScript. Muchos usuarios tienen el concepto erróneo de que las impresoras láser pueden imprimir automáticamente cualquier tipo de archivo que se les envía. ¿El trabajo de impresión es muy grande para la impresora? Este caso fue mencionado anteriormente; sin embargo, es posible que el trabajo esté en el primer lugar de la cola, y bloquee todos los otros trabajos. Si se configuró la cola para que reintente automáticamente, se podrá ver al spooler intentar una y otra vez enviar el trabajo a la impresora sin éxito. ¿Está dañado el cable de la impresora? A veces, un cable dañado deja pasar algunas señales a la impresora. En alguno de estos casos los cables son muy largos, o alguno de los cables no deja pasar alguna señal necesaria para una comunicación perfecta. ¿Los puertos están configurados correctamente? Las impresoras que están conectadas a través de cables serie pueden provocar problemas que son difíciles de detectar cuando la configuración del puerto serial del ordenador y del puerto serial de la impresora no coincide completamente. Parámetros típicos son el baud rate, la cantidad de bits de datos, la paridad, y la cantidad de bits de detención. A menudo, cuando el baud rate es erróneo, se obtiene basura como signos de pregunta impresos, y a veces no se imprime nada. Algunas impresoras, como las impresoras Printronix y la serie IBM 6400, tienen una llave en la impresora para determinar el significado de algunas de las líneas seriales. En estas impresoras: • Se debe verificar que RTS (Ready To Send) sea siempre TRUE. • Se debe verificar que DTR (Data Terminal Ready) sea controlado por BUFFER FULL.
6.1.4.3 Nada llega a la impresora Hay situaciones donde no hay evidencia de que el trabajo de impresión haya llegado a la impresora. Para impresoras conectadas localmente, esto puede ser difícil de determinar, porque algunas impresoras no dan indicios de que no pueden manejar el trabajo de impresión cuando este arriba. Para impresoras de red, siempre se debe utilizar alguna técnica de rastreo de la red. ¿El trabajo aún está en la cola de impresión? Si lpstat muestra que los trabajos están aún en la cola de impresión, hay normalmente dos posibilidades: 1. El trabajo es el primero de la lista, pero la cola está caída, desactivada, corriendo, o en un estado de espera. Si la cola o impresora está caída o desactivada, esto indica que el sistema de impresión tiene problemas para enviar el trabajo a la impresora. Las causas comunes son: - Cable mal conectado. - Permisos erróneos en archivos o directorios. - Incompatibilidad en protocolos de red. - Archivos a imprimir muy grandes. - La impresora está apagada, o fuera de línea. - No se especificó el tamaño de papel adecuado. Los pasos a seguir para diagnosticar los síntomas son: - Verifique si puede copiar el archivo directamente al dispositivo o impresora de
Página 237 de 283
red. Esto separa si el problema es del dispositivo o del spooler. Si encuentra que el problema está en el dispositivo o en la conexión de red, entonces no hace falta que realice el resto de los pasos de diagnóstico listados aquí. Se debe continuar la investigación reparando el cable, el dispositivo o los problemas que tenga la impresora. - Verifique si root puede imprimir el archivo. Esto prueba algunos problemas de permisos, pero no todos. Si root puede imprimir, entonces será necesario revisar los permisos de archivos. Utilice tcbck, pero se debe tener cuidado de no utilizar el flag de reparación automática, ya que puede generar más problemas que los que soluciona. - Asegúrese que el servidor de impresión remoto esté utilizando los mismos números de puerto. Un error común es configurar una impresora de red utilizando el protocolo JetDirect cuando ésta espera el protocolo remoto LPR/LPD. Otro problema puede ser utilizar el número de puerto equivocado para un servidor de terminales que acepta trabajos de impresión. Un truco para impresoras que soportan el protocolo JetDirect es hacer un telnet al puerto 9100 y tipear datos para ver si estos se imprimen cuando se hace un exit presionando los caracteres correspondientes (generalmente Ctrl-]). - Verifique el tamaño del archivo y el tamaño del file system utilizando df y ls -l. 2. El trabajo no es el primero en la lista. Es posible que otro trabajo esté causando el problema. En este caso, utilice el mismo procedimiento, pero probando con el trabajo que provoca el problema. ¿La impresora está conectada apropiadamente al ordenador? Primero, asegúrese que la impresora y el ordenador estén conectados por un cable. Asegúrese que el mismo tipo de interfase es utilizado en el ordenador y en la impresora. Un error muy común es asumir que como la impresora y la caja de salida del ordenador (como un RAN de 128 puertos) tienen conectores RJ-45 se pueden conectar entre si directamente. Desafortunadamente, el RJ-45 de la impresora usualmente es un conector ethernet, mientras que el del RAN es un conector serial, y entre ellos no pueden comunicarse. El mismo error se suele cometer conectando cables serie y paralelos. ¿Qué tipo de cable se está utilizando? Como muchos edificios son cableados con cables de red CAT 5, se asume en general que pueden ser utilizados para conectar impresoras serie. El estándar RS/232 dice que se deben utilizar cables blindados de par trenzado para las comunicaciones serie; los cables CAT 5 no cumplen con este requerimiento. Si se insiste en utilizar estos cables, se debe asegurar que los pares de cables apropiados son trenzados juntos para evitar interferencias. Esto se refiere especialmente a las señales de tierra con las señales de datos. Obtener los pines de salida apropiados es un ejercicio muy frustrante. Por ejemplo, el adaptador IBM de 64 puertos, el adaptador de 128 puertos, y el servidor de terminales 7318 utilizan conectores RJ-45, pero cada uno de ellos utilizando diferentes pines de salida. Se debe verificar que se están utilizando los pines de salida apropiados consultando las guías de referencia del dispositivo. Algunas impresoras usan la línea SSD (el pin 11 en un conector db25 en modo DTE) para realizar el control de flujo por hardware. Esta línea debe ser conectada a DCD en el puerto adaptador del RS/6000. Algunas impresoras (por ejemplo, Epson FX1050, HP Laserjet 4M, HP LaserJet 4plus, y HP DeskJet) tratan la señal RTS como señal de control de flujo. Esta señal normalmente es conectada a la línea CTS de los RS/6000 o pSeries. AIX requiere que la señal CTS sea un signo de que la impresora está encendida y funcional. Si esta señal se vuelve falsa cuando se está imprimiendo, la cola PowerPC se caerá. Para estas impresoras, son necesarios cables especiales para llevar la señal RTS al CTS del ordenador. El largo y la calidad del cable tendrán un gran efecto en la capacidad de imprimir. Si la impresora y el adaptador soportan RS/232D, entonces un cable de buena calidad puede permitir que la impresora esté a más de 60 metros del ordenador. Si en cambio, sólo soportan RS/232C, entonces la
Página 238 de 283
distancia estará limitada a 15 metros. Para impresión paralela, el estándar recomienda cables de 2 metros como máximo. Se debe tener en cuenta que los cables comercializados pueden exceder el estándar. ¿Los parámetros del puerto son correctos? Los parámetros del puerto, como baud rate, bits de datos, bits de detención, y método de control de flujo, pueden ser modificados durante la configuración de la impresora y el dispositivo del ordenador. Se debe verificar que los parámetros coincidan en ambos lados. ¿Existe el dispositivo de la impresora? Si por alguna razón el dispositivo de la impresora es eliminado, a veces un archivo común puede ser creado en el directorio /dev. Cuando esto ocurre, los trabajos de impresión pueden ir llenando el archivo en lugar de ser direccionados a la impresora. Para ver si este es el caso, utilice el comando ls -l /dev/lp* para verificar que los permisos de cada archivo comiencen con el carácter c, de dispositivo especial. Para identificar el archivo de dispositivo especial que está asociado con una cola de impresión tradicional en AIX, utilice el comando lsque para encontrar el nombre del dispositivo de la cola y el comando lsquedev para encontrar el archivo especial asociado. Luego utilice el comando ls -l en el archivo, de la siguiente manera: $ lsque -q asc asc: device = lp0 $ lsquedev -q asc -d lp0 lp0: file = /dev/lp0 header = never trailer = never access = both backend = /usr/lib/lpd/piobe $ ls -l /dev/lp0 crw-rw-rw- 1 root system 24, 0 Oct 19 09:56 /dev/lp0
Si el listado del archivo no comienza con crw, entonces se puede estar seguro que el dispositivo no está creado apropiadamente. Esto requerirá borrar el archivo y recrear el dispositivo. Para la impresora de un subsistema System V, utilice el comando lpstat con el flag -t: $ lpstat -t | grep ps1 device for ps1: /dev/lp0 $ls -l /dev/lp0 crw-rw-rw- 1 root system 24, 0 Oct 19 09:56 /dev/lp0
El siguiente es un ejemplo de una situación incorrecta con un archivo normal en lugar del archivo especial del dispositivo: -rw-rw-rw 1 lp lp 53455 Oct 19 09:57 /dev/lp1
¿La impresora está conectada al dispositivo correcto? En la última sección, pudo encontrar el dispositivo conectado a la cola o impresora. Es importante asegurarse que el dispositivo está en el adaptador y puerto correctos. Para encontrar la ubicación de un dispositivo, utilice el comando lsdev, de la siguiente manera: # lsdev -Cc printer lp0 Available 01-D0-00-00 Lexmark Optra laser printer lp1 Available 00-00-0P-00 HP LaserJet 4m $ lsque -q asc asc: device = lp0
Página 239 de 283
En este caso, el número de ubicación del lp0 comienza con 01. Esto indica que el dispositivo es uno de los que están en bus 01 del ordenador. El dispositivo de impresión lp1 indica que está conectado al puerto paralelo principal. El código de ubicación varía entre los modelos, pero puede ser utilizado siempre para encontrar la ubicación del adaptador y el puerto. Se debe verificar que la impresora esté en el puerto correcto. En algunos casos, se puede encontrar que la salida de la impresión fue a la pantalla de la terminal de otro usuario o a una impresora diferente. Esto puede ocurrir cuando se restaura un mksysb en un sistema con adaptadores de 128 puertos y las RANS son asignadas en distinto orden. En este caso, la mejor solución es borrar y reconfigurar los adaptadores uno a uno. ¿Se puede imprimir directamente al dispositivo de impresión? Una forma de separar el problema entre el servicio de impresión y el lado del hardware es hacer un copy o un cat del archivo directamente al archivo del dispositivo. Si la impresora es de texto ASCII o PCL, redirecione el comando lptest a la impresora de la siguiente manera: # splp -p+ lp0 # lptest 10 10 > /dev/lp0
Si la impresora es una PostScript, utilice el comando cat con un archivo PostScript pequeño que sea correcto. Nuestra sugerencia es que se utilice uno de los archivos de encabezamiento, como el H.ps: # cat /usr/lib/lpd/pio/burst/H.ps > /dev/lp0
Si esto imprime, significa que el problema está en el servicio de impresión. Si el comando demora unos instantes y luego devuelve el siguiente mensaje, entonces presione Ctrl-C: ksh: /dev/lp0: 0403-005 can’t create the specified file
Esto indica que la impresora no está encendida o que hay un problema en el cable. Con impresoras seriales, esto indica que no hay señal de la impresora en el pin CTS del ordenador.
6.1.4.4 ¿Hay espacio suficiente en el file system del spool? Para verificar si hay espacio suficiente en el file system del spool, se debe verificar que el archivo sea más pequeño que el espacio libre en el /var. Si no es suficiente el espacio, se debe incrementar el file system utilizando el menú rápido smitty chjfs. Los comandos para verificar el tamaño del file system y del archivo son: # df -k # ls -l full-path-name-to-file
El asunto del espacio es muy importante en dos casos: 1. Cuando se envían archivos al spool de impresión. Cuando esto ocurre, se realiza una copia del archivo antes de enviarlo a la impresora. Para el subsistema PowerPC, los archivos son copiados en /var/spool/lpq/qdaemon, mientras que para el subsistema System V, son copiados en /var/spool/lp/tmp. Si se esperan muchos archivos grandes, es recomendable que se genere un file system separado y se haga un link al directorio de spool. Esto otorga la ventaja de que reducir el tamaño de ese file system es mucho más fácil que reducir el tamaño del /var. 2. Cuando el servidor recibe archivos de un cliente remoto. Los archivos recibidos por el daemon lpd en un subsistema PowerPC son recibidos en el /var/spool/lpd y almacenados hasta que son impresos. Si se reciben muchos archi-
Página 240 de 283
vos, o si estos son muy grandes, se puede acabar el espacio libre en este directorio. En este caso es más difícil hacer un link, ya que el subsistema PowerPC guarda sus archivos permanentes en subdirectorios que pertenecen a este directorio.
6.1.4.5 Nada se imprime, pero se obtiene un mensaje de error Los mensajes de error que se obtienen del comando de impresión normalmente son diferentes en los dos subsistemas de impresión. Para continuar la investigación, se debe consultar la sección correspondiente a cada uno.
6.1.5 La salida es basura o está incompleta El objetivo de esta sección es ayudar a solucionar problemas una vez que hay algo de tinta en el papel. Esto es, tanto cuando hay texto legible y hay pequeños detalles de formato, como cuando hay unos pocos caracteres basura en la página.
6.1.5.1 ¿Los parámetros del puerto son correctos? Si todo lo que se ven son unos pocos signos de pregunta y otros caracteres que poco tienen que ver con el texto real, quiere decir que el baud rate está mal especificado si es una conexión serie. Se debe verificar que el baud rate sea el correcto en la impresora y en el ordenador. Si se atraviesa un modem o un multiplexer, entonces se deberá verificar también el baud rate con estos dispositivos.
6.1.5.2 ¿Los tabuladores están configurados correctamente? Este problema se observa más a menudo en documentos de texto con tablas. Se puede confirmar este problema creando un par de líneas de texto con columnas de diferente ancho separadas por tabulaciones. Si la impresión no es correcta, entonces se puede cambiar la configuración de los tabuladores de la impresora virtual, o de la impresora física. En algunas impresoras seriales, será necesario utilizar el comando stty -tabs.
6.1.5.3 ¿Se imprime únicamente la primera línea o líneas escalonadas? Este problema ocurre más a menudo cuando se configura para imprimir PCL o texto en modo directo (passthrough) y ni la impresora ni el subsistema de impresión están configurados para añadir los retornos de carro a los avances de línea. Para probar si este es el problema, utilice el comando lptest para generar un pequeño archivo y enviarlo al comando de impresión. # lptest 5 5 | lp -d text01 !"#$% "#$%& #$%&' $%&'( %&'()
Si la salida es escalonada como en el ejemplo anterior, entonces será necesario configurar el spooler de impresión, el filtro, o la impresora para que que añadan los retornos de carro. Con la impresora virtual se puede estar seguro que el comando que fija el control de carro le dice a la impresora que añada los retornos de carro. Las líneas en la parte superior de la página o en zig-zag hacia abajo indican que no hay retornos
Página 241 de 283
de carro al final de la línea. Normalmente esto significa que el archivo fue impreso sin formato o utilizando el modo directo. Para impresoras PCL, la solución más rápida es agregar el comando a la configuración para que le diga a la impresora que añada sus propios retornos de carro. En el subsistema PowerPC configure lo siguiente con el atributo de la impresora virtual: ct=/033&k2g
En el subsistema System V configure lo siguiente en el script de la interfase: echo “\033*k2g”
La mejor respuesta para impresoras PCL es configurar la impresora con tipo de contenido pcl (contents=pcl), y utilizar el /usr/lib/lp/bin/pcl. Registre la impresora con: # lpfilter -f pcl -F /etc/lp/fd/pcl.fd
Una vez que se hace esto, el filtro pcl añadirá el retorno de carro a los avances de línea.
6.1.5.4 ¿La impresora funciona bien por un tiempo y luego mal? Hay dos casos donde se verá a la impresora imprimir bien por un tiempo, luego saltear algunas páginas y luego imprimir bien nuevamente por un tiempo. El primer caso es cuando el flujo de control no está configurado apropiadamente entre el ordenador y la impresora. Este es un problema únicamente con las impresoras conectadas por RS/232, ya que por RS/422, paralelo e impresión remota, todo el flujo de control está dentro del protocolo o el hardware. Para las impresoras conectadas por RS/232, es recomendable utilizar flujo de control por hardware siempre que sea posible. Con control de flujo por hardware, cuando el buffer de impresión en la impresora alcanza el límite máximo, la señal de la impresora en una línea tal como DTR cae. Cuando esto ocurre, si esta línea de señal está conectada a la señal DCD del AIX, el ordenador suspenderá el envío de datos hasta que la línea se levante nuevamente. Como esto es manejado por hardware, el envío de impresiones se detiene inmediatamente. Tan rápido como la impresora vacía el buffer (imprimiendo su contenido) hasta un límite determinado, la señal DTR se levanta y el AIX comienza a enviar datos nuevamente. La consideración importante en el control de flujo por hardware es reconocer qué línea de señal es utilizada por la impresora para indicar el nivel del buffer y asegurarse que la línea esté conectada a la línea DCD en el lado del AIX. En casos raros cuando se configura una impresora como dispositivo TTY, debe utilizarse el flujo de control RTSCTS. Cuando el ordenador y la impresora son configurados con control de flujo por software (también llamado control de flujo XON/XOFF), la impresora señala que el buffer alcanzó el límite máximo enviando un carácter XOFF en la línea TxD de la impresora, que es recibida en la línea RxD del ordenador. El ordenador debe continuar enviando de a un carácter por vez hasta que recibe una cantidad de caracteres XOFF antes de detener el flujo de datos. Una vez que el buffer de la impresora es vaciado hasta el límite mínimo, la impresora envía una señal XON para decirle al ordenador que continúe el envío de datos. Este procedimiento tiene un retraso interno, y con impresoras lentas se pueden provocar saturaciones del buffer y pérdida de datos. Se pueden cambiar el tamaño del buffer de salida de la impresora en el controlador de dispositivos o cambiar los parámetros para reducir el retraso en la respuesta del XOFF, pero es recomendable que se cambie a control de flujo por hardware si es posible. Para cambiar la cantidad de caracteres XOFF que el manejador espera, se debe utilizar el menú rápido smitty devices y cambiar el parámetro RECEIVE trigger level de la impresora de 3 a 1 El segundo caso se da cuando el retraso está mal para impresoras paralelas, o el tamaño del
Página 242 de 283
buffer del controlador de dispositivos es muy grande para la impresora. Para plotters e impresoras paralelas lentas, hay un parámetro llamado Microseconds to delay between characters que puede ayudar a evitar este tipo de problemas. Para cambiar el tamaño del buffer de transmisión de una impresora serial, utilice smitty devices y modifique el TRANSMIT buffer count de la impresora.
6.1.5.5 ¿Hay problemas imprimiendo gráficos? Si se está intentando imprimir archivos de gráficos directamente, será necesario encontrar un filtro que convierta los gráficos a PCL o PostScript, o utilizar un programa como un navegador o xv para visualizar el gráfico e imprimirlo desde ahí. Esta es una buena solución para imprimir en impresoras PostScript. Si los gráficos están en un documento PostScript, entonces es probable que el problema sea una incompatibilidad entre la aplicación que creó los datos y la impresora, o se pasó el archivo PostScript a través de un filtro de texto ASCII que dividió el archivo en base al ancho o agregó caracteres extra. Si el archivo es un PCL formateado, el problema más común es que cuando el archivo es impreso a través de una cola de texto ASCII, el ancho de línea sea truncado por el filtro de texto. Es importante imprimir estos archivos en modo directo y decirle a la impresora que añada los retornos de carro a los avances de línea.
6.1.5.6 ¿El tipo de impresora es el correcto? Imprimir con el tipo de impresora erróneo para el data stream puede causar varios diferencias. Es un error común creer que todas las impresoras láser son impresoras PostScript. No es así. PostScript es generalmente una opción para una impresora láser o de otro tipo. ¿La impresión PostScript es similar al archivo visto por pantalla? Si la salida en la impresora es similar al archivo visto con los comandos pg o more, entonces el problema es que la impresora no soporta PostScript, o se envió un archivo PostScript a una impresora o cola de impresión ASCII, que a su vez le envió a la impresora comandos para que imprima texto. Se puede solucionar el primer caso utilizando una impresora PostScript, o en algunos casos, utilizar un filtro como GhostScript para convertir PostScript a PCL u otro formato. En el segundo caso, se puede solucionar creando una cola PostScript para trabajos de impresión PostScript. ¿Hay símbolos inesperados en la salida? En este caso, la mayor parte de la impresión es correcta, pero hay caracteres de control en el principio o a lo largo del texto. Los caracteres de control para una impresora pueden ser impresos como símbolos en otra impresora. Un buen ejemplo sería imprimir un archivo creado para una impresora Epson injet en un impresora HP injet. Esto es especialmente verdadero si el archivo fue creado en una aplicación Windows donde a veces los caracteres son impresos como gráficos. En archivos creados en AIX, si se utiliza una impresora virtual equivocada en un subsistema PowerPC, o el tipo de impresora equivocado en un subsistema System V, los caracteres de control definidos para inicializar la impresora pueden exhibir este comportamiento.
6.1.6 El espaciado es incorrecto La salida contiene el texto esperado y puede ser legible, pero el texto aparece en un formato inesperado, como:
Página 243 de 283
• Espaciado doble • Sin margen izquierdo
6.1.6.1 Espaciado doble Si la salida tiene espaciado doble, esto indicar que se imprimió un archivo que contiene retornos de carro en una impresora virtual o impresora de System V que añade los retornos de carro en los avances de línea. La solución es imprimir en modo directo, o utilizar un filtro para quitar los retornos de carro antes de encolar el trabajo para que sea impreso.
6.1.6.2 Sin margen izquierdo Si se imprime un archivo que comienza con tabulados al principio de algunas líneas, pero estas líneas son impresas en el margen izquierdo, entonces los tabulados no son convertidos a espacios o no son manejados apropiadamente por la impresora. Este problema es improbable que ocurra en un subsistema PowerPC, porque por defecto convierte los tabulados en ocho espacios. En un subsistema System V, si los tabulados de la impresora no son correctos, deben ser fijados cada ocho espacios. Se puede forzar que el servicio de impresión de System V no envíe los tabulados, utilizando la opción -tabs stty de la siguiente manera: # lpadmin -p printer-name -o stty=-tabs
6.1.7 La impresión con una fuente incorrecta El tamaño y tipo de fuente depende de varios puntos: • ¿El archivo es PostScript o PCL formateado? • ¿Cual es la fuente por defecto de la impresora? • ¿Que fuentes están instaladas en la impresora? • ¿El programa interfase o el backend de impresión fijan la fuente? • ¿Como está configurada la variable LANG?
6.1.7.1 ¿El archivo es PostScript o PCL formateado? Con archivos PostScript o PCL formateados, las fuentes son especificadas dentro del documento. Es posible que la fuente requerida no esté disponible en la impresora. Las alternativas son cambiar la fuente en el documento, bajando la fuente a la memoria flash en forma semi-permanente, o bajar la fuente con el trabajo de impresión. Para fuentes PostScript, la fuente es especificada de la siguiente manera: /Times-BoldItalic findfont
Como los archivos PostScript contienen sólo texto ASCII, se pueden cambiar con un editor por la fuente disponible en la impresora.
6.1.7.2 ¿Cuál es la fuente por defecto de la impresora? Si el programa interfase o el backend de impresión no fijan la fuente, entonces será utilizada la fuente por defecto de la impresora. El método para ver la fuente por defecto difiere según la impresora. Se debe revisar el manual de referencia de la impresora para más detalles. Otra opción es agregar un comando para fijar la fuente en el script interfase o en el programa backend. Cuando se utiliza el subsistema System V, esto se puede realizar con comandos echo en el script interfase,
Página 244 de 283
similares a los siguientes: echo “\033(s3T” echo “\033(s15H
Para el subsistema de impresión PowerPC, cuando se utilizan impresoras virtuales, la configuración de la fuente es una parte de la configuración de la impresora virtual. Normalmente, hay una selección limitada de fuentes disponibles. Para impresoras PCL, las fuentes disponibles son utilizadas definidas por el atributo mU, eP, o eT de la impresora virtual. Siempre es posible añadir un comando de fuente al final del atributo de inicialización de la impresora ci.
6.1.7.3 ¿Qué fuentes están instaladas en la impresora? En las secuencias de configuración o prueba de la mayoría de las impresoras, hay un método para imprimir las fuentes disponibles. En las impresoras actuales, hay normalmente una gran selección de más de 60 fuentes disponibles, y cubren la mayoría de las necesidades. Cuando una fuente requerida no está disponible en la impresora, se debe usar alguno de los métodos para bajar fuentes, según el subsistema de impresión utilizado.
6.1.7.4 ¿El programa interfase o el backend de impresión fijan la fuente? En los subsistemas de impresión de UNIX, los conjuntos de caracteres, estilos y fuentes pueden ser fijados una vez al comienzo por el programa interfase o el backend de impresión. En System V, las fuentes son fijadas por el script interfase. Para el script interfase estándar, la variable de ambiente CHARSET es utilizada para determinar el conjunto de caracteres requerido. Si CHARSET es activada, es pasada al filtro lp.set como el quinto parámetro. El lp.set verifica si el conjunto de caracteres existe en la base de datos terminfo de la impresora, y si está, enviará desde la base de datos el comando para inicializar la impresora. Esto sólo funcionará con tipos TERM donde el conjunto de caracteres es definido. Cuando se utilizan scripts o interfases del fabricante de la impresora basadas en el script /usr/lib/hpnp/hpnpIS.model, el conjunto de caracteres es elegido haciendo un echo de una secuencia de comandos. Por ejemplo, en el script hpnpIS.model, las siguientes líneas seleccionan el conjunto de caracteres: echo “\033)0B\c”
El comando utilizado para fijar el pitch (cantidad de caracteres por pulgada) en 12 es: echo “\033(s12H\033)s12H\c”
Para realizar cambios en los conjuntos de caracteres no soportados por el script, se deberán agregar cambios al script interfase. En este caso, el usuario elige el pitch con el comando lp -o pitch=condensed o similar. En las impresoras virtuales PowerPC, la impresora es inicializada por las secuencias del atributo ci. Estas son fijadas desde SMIT, desde el Administrador del Sistema basado en Web, o con el comando lsvirprt. Los usuarios pueden seleccionar el estilo y pitch de la impresión con qprt -s estilo –p pitch. Para que soporte tamaños o estilos de fuente no soportados por la impresora virtual hace falta una adaptación especial. Para impresoras PCL, esto se hace con el atributo mU.
6.1.7.5 ¿Qué fija la variable LANG? Para el subsistema de impresión PowerPC utilizando impresoras virtuales, la variable de instalación LANG fijará la tabla de traducción de entrada para una impresora virtual en particular. Esto muestra el contenido del atributo _X:
Página 245 de 283
# lsvirprt -q asc -d lp0 -a X Name Description Value _X CODE PAGE of print file ISO8859-1
El código de página por defecto para Estados Unidos es ISO8859-1. Uno de los problemas que se experimenta es que los archivos con caracteres de líneas no se imprimen correctamente cuando se utiliza este código de página. Para imprimir archivos ASCII de texto que contienen caracteres que dibujan líneas, especifique el código de página IBM850 para cambiar el atributo X, o utilice el siguiente comando: $ qprt -XIBM850 -Ptext /tmp/testfile
6.1.8 El trabajo de impresión pide un tamaño de papel equivocado Para impresoras PCL u otras impresoras ASCII, se debe revisar que el tamaño del papel por defecto sea fijado correctamente en la impresora virtual o en el script interfase. Luego, se debe verificar que el comando para el tamaño del papel no esté incluido en el archivo. Para archivos PostScript, el tamaño del papel a menudo es definido dentro del archivo de impresión, y poco se puede hacer en la impresora virtual o script interfase para cambiarlo. Se debe volver a la aplicación que generó el archivo.
6.1.9 El trabajo de impresión por red falla Cuando se imprime por servidores de impresión de red e impresoras de red, el objetivo en la resolución de problemas es aislar el problema entre el cliente y el servidor y luego realizar una determinación de problema local.
6.1.9.1 Los trabajos de impresión quedan encolados en la cola local Como el trabajo está aún encolado en la cola local (cliente), se puede asumir que el trabajo fue rechazado por el sistema remoto (servidor), o que el trabajo no llegó. ¿El cliente puede comunicarse con el servidor? Antes de buscar problemas específicos de impresión, se debe verificar que hay una buena conexión de red entre el cliente y el servidor. Se debe poder hacer un ping al servidor desde el cliente por dirección IP y por nombre. Si el ping no es satisfactorio por dirección y nombre, entonces la impresora no funcionará. Si el ping no responde siquiera por dirección, entonces se debe solucionar el problema de red o asegurarse que el cliente y el servidor estén encendidos y conectados a la red. ¿Hay problemas de resolución de nombre? Como el cliente rembak y el servidor lpd pueden hacer un llamado por nombre, es importante que tanto el cliente como el servidor puedan reconocer al otro no sólo por dirección IP sino también por nombre. Si se está utilizando DNS, entonces use el comando nslookup para verificar la resolución por dirección y por IP. Si no se está utilizando DNS, entonces se debe usar el comando host en lugar del nslookup. Si los resultados no son apropiados, o si no se obtiene una respuesta, entonces se debe cambiar o añadir los nombres al DNS o al archivo /etc/hosts. ¿El daemon lpd está activo en el servidor? Si el servidor es un sistema AIX utilizando un subsistema de impresión PowerPC, entonces se
Página 246 de 283
puede verificar que el lpd esté activo utilizando el siguiente comando: # lssrc -s lpd
Si no está activo, se puede iniciar con: # startsrc -s lpd
o desde el menú de SMIT para manejo de subsistemas de impresión remota. Si el servidor es un sistema AIX utilizando un subsistema de impresión System V, entonces verifique primero que el scheduler esté activo con el comando lpstat: # lpstat -r
Si está activo, entonces utilice el comando ps de la siguiente manera: # ps -ef | grep lpNet
En otros servidores, se debe revisar que el servidor lpd acepte trabajos. ¿El cliente tiene permisos para imprimir en el servidor? Para servidores PowerPC, esto significa que el archivo /etc/hosts.lpd en el servidor contiene un línea para el cliente, o tiene el símbolo + para permitir todos los clientes. Para otros servidores de impresión, verifique el manual del servidor para configurar los permisos de clientes. Para los subsistemas PowerPC, el allow=all sólo permite usuarios locales. Para permitir todos los usuarios remotos, configure el valor allow con all!all. ¿Coinciden los protocolos de red? Si el servidor es una impresora de red, se debe verificar que soporte impresión LPD, o que se esté utilizando el tipo de impresión en AIX que soporte el protocolo que conversa con la impresora. Recolecte mensajes de error y logs Se deben buscar mensajes de error que indiquen un problema. En el subsistema de impresión PowerPC se puede activar el log con rastreo remoto (logging with remote computing) para ayudar a solucionar estos problemas. Se puede hacer un trace en la red para ver si hay algún mensaje de error identificable en la salida. ¿Los flags son compatibles? Algunos servidores de impresión pueden soportar flags adicionales como el flag –o y otros no. Los subsistemas PowerPC de impresión remota utilizan una cantidad de flags no-estándar que pueden ser ignorados, rechazados o utilizados incorrectamente por otros servidores de impresión. Es importante fijar el tupo de servidor a BSD o ATT si no se utiliza un servidor de impresión remota AIX PowerPC. Para imprimir desde PowerPC a System V, utilice el valor ATT. Verifique si el usuario recibió un correo electrónico o un mensaje El texto del correo a menudo contiene la información necesaria para diagnosticar el problema. ¿El archivo de control es enviado en el orden correcto? En AIX 4.3, el sistema de impresión introduce la capacidad de enviar el archivo de control LPD antes del trabajo de impresión. Esta capacidad no es soportada por todos los servidores, pero puede ayudar con la velocidad de impresión de alguno de ellos. Cuando se configura una impresora remota, se debe verificar que este valor este fijado correctamente. ¿Hay suficiente espacio en el servidor?
Página 247 de 283
Algunos trabajos son rechazados por el servidor porque no hay suficiente lugar para almacenar el archivo. En este caso, el archivo puede ser tan grande que un trace es casi imposible. Este problema es fácilmente identificable si sólo los trabajos de impresión muy grandes no son movidos al servidor remoto. ¿Los permisos para LPD son correctos en el servidor? Ocurre a menudo que los permisos del daemon lpd o del directorio de spool son cambiados por error y el daemon no puede guardar archivos. Verifique el usuario que ejecuta el lpd, y los permisos de archivo en el daemon y el directorio /var/spool/lpd. ¿iptrace muestra mensajes de error? A veces el servidor devuelve un mensaje de error, que puede ser visto en el archivo iptrace y que ayudará a identificar la causa del problema. ¿El iptrace muestra mensajes de aceptación negativos? Después de cada requerimiento del cliente, el servidor debe devolver un byte con un valor cero. Esto puede ser visto en la salida del iptrace. Si este valor es distinto a cero, entonces el servidor está enviando un mensaje de error, a veces llamado aceptación negativa (negative acknowledgement o NACK), al cliente. El subsistema de impresión PowerPC asume que el servidor no está listo, y cambiará el estado a DOWN. El subsistema System V reintentará después de un período de espera especificado, una cantidad de veces según los valor fijados en el archivo Systems.
6.1.9.2 ¿Está configurado el tiempo de espera para la impresión remota con System V? Cuando se utiliza la impresión remota con el subsistema de impresión System V, se debe verificar que esté configurado el tiempo de espera (timeout) para el sistema en el que se está imprimiendo con el comando psystem. Para fijar el timeout en 2 minutos: # lpsystem -T 2 -p printer-name
6.1.9.3 Los trabajos de impresión quedan en la cola remota Si los trabajos de impresión quedan en la cola remota, entonces la conexión entre el cliente y el servidor fue satisfactoria. En este caso, se debe buscar un problema local en el sistema servidor.
6.1.9.4 Los trabajos de impresión desaparecen Quizás el problema más frustrante es cuando el trabajo parece simplemente desaparecer. Esto puede ser causado por flags que son aceptados por el lpd del sistema remoto, pero son incompatibles con la impresora o la impresora virtual en el servidor, o un archivo que es incompatible con la impresora en el servidor. Desactivar la cola en el sistema remoto Desactivando la cola en el sistema remoto, se puede descubrir algunas cosas. Primero se debe verificar que el trabajo de impresión fue encolado en el servidor. Si no es así, entonces se puede utilizar iptrace para verificar que haya salido del cliente. Si fue transferido, pero no quedó encolado, entonces el daemon lpd tiene algunos problemas pasando el trabajo al subsistema de impresión. Si el rastreo muestra que el trabajo nunca salió del cliente, entonces el problema queda limitado al cliente. Si el archivo es encolado en el servidor, entonces se puede verificar si los flags pasados al servidor son válidos, y si el archivo se imprime cuando es encolado localmente.
Página 248 de 283
¿Los flags son correctos? Hay dos lugares en donde se pueden encontrar los flags. El primero es el archivo de control en el iptrace. El segundo depende del subsistema de impresión. En el subsistema PowerPC, se puede encontrar en el archivo de descripción del trabajo en /var/spool/lpd/qdir. En System V, los flags pueden encontrarse en el archivo /var/spool/lp/tmp/printer-name/printid-0. ¿El archivo se puede imprimir localmente en el servidor? El nombre de la copia del archivo en el servidor AIX puede encontrarse en el mismo archivo de descripción mencionado en el punto anterior. Se debe copiar este archivo a /tmp/testfile. Luego active la cola en el servidor. El trabajo de impresión desaparecerá nuevamente, o se habrá descubierto un problema de tiempos. Ahora imprima una copia del archivo guardado en /tmp/testfile sin flags. Si imprime bien, entonces el problema no está en el archivo y se puede intentar imprimir con los flags encontrados en el paso anterior. A menudo, será necesario utilizar el flag -o con enq o lp para utilizar los flags capturados. Si el archivo no es impreso, entonces hay un problema de impresión local con el archivo, y se podrán utilizar los pasos para determinar problemas de impresión locales.
6.2 Técnicas de resolución de problemas comunes Esta sección describe alguna de las técnicas de resolución de problemas más comunes que se pueden utilizar en AIX.
6.2.1 Utilizando lptest para generar archivos de impresión El comando lptest es una excelente herramienta para generar una salida conocida que pueda ser impresa. Genera un modelo de prueba por la salida estándar y puede ser usado direccionando la salida a un comando de impresión, o redireccionándolo a un dispositivo. La sintaxis del comando es: $ lptest columnas líneas
Por ejemplo, para generar un archivo de 20 columnas de ancho por 5 líneas de largo, se debe utilizar el siguiente comando: $ lptest 20 5 !"#$%&'()*+,-./01234 "#$%&'()*+,-./012345 #$%&'()*+,-./0123456 $%&'()*+,-./01234567 %&'()*+,-./012345678
Este comando es útil para asegurar que una impresora tenga configurados el ancho de impresión y largo de página correctos, porque se pueden generar exactamente la cantidad de filas y columnas que quepan en una página. En otros casos, se puede generar una pequeña cantidad de filas cortas para verificar si hay un efecto de escalera en la impresora. Para imprimir la prueba, utilice pipe para dirigir la salida del comando al comando de impresión: $ lptest 10 5 | lp -d laser1
Para direccionar la salida a un dispositivo de impresión, utilice el siguiente comando: $ lptest 15 5 > /dev/lp17
Página 249 de 283
6.2.2 Use enscript para generar PostScript El comando enscript debe ser instalado con el fileset bos.txt.ts. Este comando genera archivos PostScript desde archivos de texto ASCII. Se puede combinar la salida del comando lptest con el enscript para probar impresoras PostScript. Use el flag -d para especificar la cola de impresión. $ lptest 10 10 | enscript -d ps1
El comando enscript puede brindar capacidades adicionales, como título de página, fuentes especiales, e impresión 2-up.
6.2.3 Use splp para ver los dispositivos especiales El comando splp muestra las características de un dispositivo de impresión. Para una impresora serial, muestra además las características del puerto, como el baud rate. Si hay problemas con archivos volcados directamente al puerto, se debe intentar configurar el controlador de dispositivo para que no altere los archivos (modo passthrough) de la siguiente manera: # splp -p+ lp0
Ejemplo de la salida de splp para una impresora paralela: # splp lp0 device = /dev/lp0 (+ yes ! no) CURRENT FORMATTING PARAMETERS (ignored Note: -p + causes the other formatting -p ! pass-through? -l 64 page length (lines) -w 80 page width (columns) -i 0 indentation (columns) -W ! wrap long lines? -C ! convert to upper case? CURRENT ERROR PROCESSING PARAMETERS -T 300 timeout value (seconds)
by qprt, lpr, and lp commands) parameters to be ignored. -c + send carriage returns? -n + send line feeds? -r + carriage rtn after line feed? -t ! suppress tab expansion? -b + send backspaces? -f + send form feeds? -e ! return on error?
6.2.4 Imprimiendo a un archivo Imprimir a un archivo es una de las técnicas más útiles para probar como modifican un archivo de impresión los programas interfase, los backends y los filtros. Como en cada subsistema de impresión se realiza de distinta forma, es tratado en forma separada.
6.2.5 Imprimiendo directamente al archivo del dispositivo especial Si la cola continuamente se cae o se desactiva, el problema puede estar en el cableado o en el controlador de dispositivo. Para imprimir un archivo directamente al dispositivo, se puede utilizar el comando cat y redireccionar la salida al dispositivo de la siguiente manera: # cat /etc/hosts > /dev/lp32
Si falla, entonces la conexión con la impresora es incorrecta, o está dañada. Si se presiona Ctrl-C, y el mensaje en pantalla hace referencia a Can’t create device, es un indicio de que la conexión serie no está recibiendo una señal de la línea CTS del ordenador. Intente unir RTS y CTS con un jumper para ver si soluciona el problema. Si es así, entonces se debe arreglar el cableado. Si se obtiene un mensaje de que el dispositivo está ocupado, utilice el comando fuser para encontrar el
Página 250 de 283
proceso que dejó la impresora abierta, de la siguiente manera: # fuser /dev/lp12
Cuando se imprimen archivos formateados directamente al dispositivo, será necesario utilizar splp para fijar el controlador en modo directo (passthrough), como se describe en el punto anterior. Algunas aplicaciones abren el archivo /dev/lp## directamente e imprimen el archivo. Esto seguramente funcionará bien, pero probablemente ponga un lock en el archivo, por lo que el scheduler no podrá utilizar el dispositivo de impresión.
6.2.6 Imprimiendo directamente en impresoras de red 6.2.6.1 Imprimiendo directamente en una impresora conectada a LPD Se puede usar rembak para imprimir directamente al LPD en otro sistema, pero sólo con el usuario root o un miembro del grupo printq. Guarde el archivo que se quiere imprimir, y utilice el flag -S para designar la dirección IP del servidor y el flag -P para especificar el nombre de la impresora en el servidor. El comando rembak no puede actuar como un filtro ya que no acepta standard input. Por ejemplo, para imprimir en el servidor net27 en una cola llamada ASCII, sólo root puede usar el siguiente comando: # /usr/lib/lpd/rembak -S net27 -P ASCII /tmp/testfile
6.2.6.2 Imprimiendo directamente en una impresora conectada a HP JetDirect AIX tiene dos comandos para imprimir a impresoras HP JetDirect. En el subsistema PowerPC, se usa el comando /usr/lib/lpd/pio/etc/piohpnpf para enviar trabajos a la impresora. En el subsistema System V, el comando es /usr/lib/hpnp/hpnpf. El único flag necesario necesario para pruebas es el -x, que especifica el nombre o dirección IP de la impresora o puerto 0 de la caja JetDirect. Esto enviará datos al puerto 9100. El siguiente ejemplo muestra los comandos de cada subsistema de impresión: # lptest 10 10 | /usr/lib/lpd/pio/etc/piohpn /usr/lib/lpd/pio/etc/piohpnpf pf -x laser42.biguys.myco.com # lptest 20 10 | /usr/lib/hpnp/hpnpf -x laser42.bigguys.myco.com
6.2.6.3 Telnet a impresoras JetDirect Para impresoras o servidores de impresión HP JetDirect, se puede ingresar por telnet al puerto 9100 (o el número que corresponda). No hace falta usuario, y se puede escribir texto directamente. Una vez que termina, se debe topear la secuencia de escape (normalmente Ctrl-[) y la impresora imprimirá el texto. Por ejemplo: # telnet 150.1.1.4 9100 # Trying... Connected to 150.1.1.4 Escape character is ‘^]’ Testing to see if this prints Line two ^] – Presiona la tecla ctrl-] telnet> quit Connection closed
Debería imprimir lo siguiente:
Página 251 de 283
Testing to see if this prints Line two
6.2.7 Utilizando iptrace para rastrear una impresión de red Las dos herramientas de rastreo de red más usadas en AIX son iptrace y tcpdump. Mientras tcpdump es útil para determinar los protocolos y la cantidad de datos que pasa por la red, iptrace es el más útil para asuntos de impresión porque se pueden ver tanto el proceso de inicio de la comunicación (handshaking), como los datos tal como pasan entre el cliente y el servidor. Es además la única herramienta que puede ser usada para capturar el archivo de control LPR enviado al servidor. Para usar iptrace en temas de impresión, primero se debe saber cual es el puerto TCP/IP que la transferencia utiliza. Cuando se usa impresión remota estándar, el puerto usual es el 515. Para el protocolo HP JetDirect, el puerto es el 9100, excepto para las cajas JetDirect EX con múltiples puertos, que utilizan los puertos 9101 y 9102. Para los servidores de terminal, se puede ver el puerto durante la configuración. El formato del comando iptrace que se debe usar para rastrear impresiones es: # iptrace -p puerto -a -b -s cliente -d servidor archivo.trc
Intente imprimir con un trabajo lo más pequeño posible (para reducir el tamaño de la muestra) y observe el problema. Una vez que el trabajo de prueba fue transferido, verifique que el archivo aumento su tamaño más allá de los 11 bytes que tenía al principio. Si no aumentó de tamaño, entonces es posible que haya múltiples adaptadores de interfase y será necesario utilizar el flag -i para especificar un adaptador en particular. Asumiendo que el archivo aumentó su tamaño, encuentre el id del proceso iptrace, y luego use ipformat para formatear la salida. El siguiente ejemplo muestra un ejemplo de la captura de la impresión remota estándar entre los servidores prtsrv y netprt01: # iptrace -p 515 -a -b -s prtsrv -d netprt01 /tmp/test.trc print from the users application # ps -ef | grep iptrace # kill PIDnumber # ipreport -n /tmp/test.trc > /tmp/test.rpt # pg /tmp/test.rpt
6.2.8 Capturando archivos Los archivos pueden ser capturados en varios lugares a lo largo del camino entre el que emite el trabajo de impresión y la impresora. Esto es necesario para encontrar dónde ocurren los errores.
6.2.8.1 Capturando el archivo antes de que pase por la cola Frecuentemente, es importante saber si los problemas están en el archivo, en los parámetros de impresión o en la impresora virtual. El usuario puede no saber cómo es el archivo. Esto es así especialmente si el trabajo fue creado por una aplicación que lo envía a la impresora. Estos pasos muestran como capturar el archivo: 1. Desactive la cola: # disable testq
2. Envíe el trabajo a la cola. Esto generalmente se hace desde una aplicación. Por
Página 252 de 283
ejemplo, usted usaría el siguiente comando en Netscape: # lpr -P testq
Verifique que el trabajo está encolado: # lpstat -vtestq Queue Dev Status Job Files User PP % Blks Cp Rnk ------- ----- --------- --- ------------------ ---------- ---- -- ---testq lpx DOWN QUEUED 66 STDIN.76636 root 1 1 1
3. Encuentre el nombre del archivo encolado observando el archivo de descripción del trabajo: # ls /var/spool/lpd/qdir n0root:local$#@!iXyb n0root:testq$#@!kRMc [email protected]:kristin$#@!iGUb
4. Haga un tail del archivo qdir para obtener el nombre del archivo encolado: # tail /var/spool/lpd/qdir/n0r00t /var/spool/lpd/qdir/n0r00t:test* :test* -Ptestq STDIN.76636 root rs9220b 0 /var/spool/qdaemon/t0lkRMa 2
5. Copie el archivo a /tmp/testfile. La última línea del archivo contiene el nombre: # cp /var/spool/qdaemon/t0lkRMa /tmp/testfile
Examine el archivo e imprímalo con diferentes flags. Si la impresión es remota, será necesario compararlo con el archivo que arriba al servidor.
6.2.8.2 Capturando un archivo después de que pasó por la cola Para capturar el archivo después de que pasó por la cola, imprima a un archivo.
6.2.8.3 Capturando un archivo tal como va por la red El comando iptrace puede utilizarse para capturar el archivo y los flags tal como van por la red desde el cliente hasta el servidor. Esto puede ayudar a determinar si el archivo está siendo enviado entero al servidor, y qué flags son enviados.
6.2.8.4 Capturando un archivo en el sistema remoto Si el sistema remoto o servidor es un AIX, entonces se puede desactivar la cola en el sistema remoto, y capturar el archivo de la misma forma que en la sección “Capturando un archivo antes de que pase por la cola”. Si es un servidor de otro tipo, se deberán utilizar herramientas apropiadas para ese servidor, o simplemente utilizar iptrace para observar como llega al servidor.
Página 253 de 283
6.2.9 Capturar el flag A menudo, un flag que no es compatible con el sistema puede provocar que un archivo simplemente desaparezca. Esto ocurre cuando se imprime desde aplicaciones, desde métodos de impresión de mainframe en VMS y OS/400, o desde clientes lpr de PC. Para capturar los flags, desactive la cola e imprima el archivo. Luego observe el archivo de control del trabajo.
6.2.9.1 Flags de System V En System V, los flags pueden encontrarse en /var/spool/lp/tmp/hostname/printid-0, en el archivo del requerimiento: # disable junk # lp -d junk -m -L C -o land /etc/motd # ls /var/spool/lp/tmp/aix4prt/264 /var/spool/lp/tmp/aix4prt/264-0 -0 /var/spool/lp/tmp/aix4prt/264-0 # cat /var/spool/lp/tmp/aix4prt/26 /var/spool/lp/tmp/aix4prt/264-0 4-0 C 1 D junk F /etc/motd N M O land locale=C flist='/etc/motd:880' P 20 t simple U heidi s 0000
Los flags pueden ser interpretados de la siguiente manera: • C: Cantidad de copias a imprimir • D: La cola de impresión elegida • F: El archivo a imprimir • N: Correo de confirmación cuando se imprime • O: Las opciones -o y otras • P: Prioridad de la impresión • t: Tipo de contenido • U: Usuario que envía el trabajo
6.2.9.2 Flags de PowerPC En PowerPC los flags pueden encontrarse en el archivo de descripción del trabajo ubicado en /var/spool/lpd/qdir: # qprt -z+ -T"This title" -p12 -Pjunk /etc/motd # ls -l /var/spool/lpd/qdir total 3 -rw-rw---1 root printq 1304 Nov 13 09:56 n0root:junk$#@!nP7b # cat /var/spool/lpd/qdir/n0r* -TThis title-Pjunk This title root aix4prt 0 $#@!-z $#@!+ $#@!-p $#@!12 /etc/motd 0
Página 254 de 283
Los flags que son listados debajo de las variables de ambiente son flags que son definidos por el comando enq. En este ejemplo, son el título y la cola de impresión: -TThis title-Pjunk
Los otros flags son aquellos enviados a través del enq como las opciones –o. Estos se ven en las líneas que comienzan con $#@!. En este ejemplo, son: $#@!-z $#@!+ $#@!-p $#@!12
Este comando es equivalente a: enq -o -z -o + -o p -o 12 -T”This title” –Pjunk
El otro método para capturar flags es utilizar iptrace o la función de log del lpd, en el lpd PowerPC. En este caso, es necesario entender los flags que son soportados por el LPD RFC-1179. Los flags siempre aparecen en el archivo de control del trace. Los flags no definidos por el estándar son manejados como opciones -o para los tipos de trace BSD y ATT, o flags especiales de AIX únicamente para las impresiones de AIX. El siguiente es un ejemplo del archivo de control: 00000000 00000010 00000020 00000030 00000040 00000050 00000060 00000070 00000080 00000090 000000a0
Los primeros flags del archivo son flags del estándar: • Haix4prt: Nombre del host cliente • Proot: Usario que generó el trabajo • fdfA466aix4prt: Nombre del archivo temporal para guardar datos - f: Identifica el archivo como Texto Plano o Archivo Formateado - dfA: Identifica que éste es el archivo de datos - 466: Número de trabajo en el cliente - aix4prt: Nombre del host cliente • UdfA466aix4pr: Desvincular este archivo cuando termina (es un archivo temporal) Los otros flags en el archivo de control están divididos entre, por ejemplo, los flags que comienzan con -o, y los flags enq. Los flags enq son aquellos que se encuentran dentro de man enq. Muchos de los flags -o y otros flags son de la impresora virtual, o del qprt cuando son usados entre dos sistemas AIX. Pero son transferidos como otros flags, porque el LPD en el servidor pasa los flags al enq para comenzar el proceso de impresión en el servidor AIX. De la siguiente manera son cargados los flags en el log, cuando el log del lpd es activado: lpd[56734] lpd[56734] lpd[56734] lpd[56734] lpd[56734] lpd[56734]
doit: doit: doit: doit: doit: doit:
cfn=[cfA929tesch.972600121]. cfn=[cfA929tesch.972600121] . get a line [Htesch]. get a line [Proot]. get a line [fdfA929tesch]. get a line [UdfA929tesch]. get a line [NSTDIN.6404].
Página 255 de 283
6.2.10 Utilizando script para capturar las entradas del usuario Cuando se usa cualquier comando desde la línea de comandos cuya salida es más grande que lo que entra en una pantalla, se puede utilizar el comando script para capturar lo que se teclea y la salida del programa. Esto es muy útil si se está ejecutando un script de instalación de impresora como el /usr/lib/hpnp/hpnpcfg. Para usar el shell script, se deben seguir las siguientes instrucciones: 1. Ejecute el shell script y designe un archivo de log: # script /tmp/hpnpcfg.log
2. Ejecute el comando que se quiere diagnosticar: # /usr/lib/hpnp/hpnpcfg
3. Luego de que termina el programa, salga del script tipeando exit: # exit Script command is complete on Mon Oct 23 19:17:23 CST 2000
4. Imprima el log o véalo en pantalla: # lp -d net12 /tmp/hpnpcfg.log
6.2.11 Utilizando fuser para encontrar procesos El comando fuser muestra una lista de los ID de procesos que están asociados con un archivo. Como los controladores de dispositivo en UNIX son representados por archivos, es posible encontrar el proceso que está imprimiendo actualmente en un dispositivo utilizando fuser, de la siguiente manera: # fuser /dev/lp0 /dev/lp0: 12808 45590 # ps -ef | grep 12808 root 12808 7756 0 13:46:36 - 0:00 /usr/lib/lpd/piobe /etc/motd root 45590 12808 0 13:46:36 - 0:00 /usr/lib/lpd/pio/etc/pioout
Esto puede ser útil cuando se intenta liberar una cola de impresión que dejó de funcionar.
6.2.12 Utilizando el comando echo en scripts shell La mayoría de las impresiones en System V son realizadas a través de scripts shell, y scripts shell simples pueden ser escritos para impresiones PowerPC para diagnosticar cosas como por ejemplo flags erróneamente pasados. Como la salida del script shell es enviada generalmente a la impresora o a destinos desconocidos, cuando se utiliza el comando echo, se debe dirigir a un archivo conocido.
6.3 Resolución de problemas en el subsistema de impresión System V Esta sección lista las técnicas de resolución de problemas que se aplican únicamente al subsistema de impresión System V en AIX.
Página 256 de 283
6.3.1 Problemas de permisos en archivos Algunos de los permisos importantes que se deben verificar son: • ¿Los permisos de lpsched y lpNet son ---s--x--- y pertenecen a root:lp? • ¿Los filtros por defecto en /usr/lib/lp/bin son ejecutables? • ¿El programa interfase es ejecutable? • ¿Los permisos del archivo del dispositivo permiten que los usuarios impriman?
6.3.2 ¿El servicio de impresión está activo? Para verificar que el scheduler esté activo, use el comando lpstat con el flag -r: # lpstat -r scheduler is running
Para imprimir en servidores remotos, verifique que el lpNet haya sido iniciado: # ps -ef | grep lpNet
Si el scheduler no está activo, intente reiniciarlo con: # /usr/lib/lp/lpsched
No se debe iniciar separadamente el lpNet, ya que el lpsched lo inicia automáticamente. Antes de hacer cambios mayores, desactive el scheduler con lpshut. Si los daemons no están activos, verifique bien los permisos en los archivos, y asegúrese que se verifico todo cambio realizado desde que estaban activos.
6.3.3 ¿La impresora tiene los atributos correctos? Es importante que la configuración de la impresora tenga los atributos correctos tanto para el dispositivo de impresión local como para los atributos del spooler de impresión.
6.3.3.1 Dispositivo de impresión Verifique que los atributos de comunicaciones de los controladores de dispositivos serie o paralelo coinciden con los atributos configurados en la impresora.
6.3.3.2 Atributos de la impresora definidos en System V Los atributos en System V que deben coincidir con la impresora incluyen: • Tipo de impresora • Interfase de la impresora • Tipo de contenido Otros atributos de la impresora que se deben revisar son los permisos para la impresora y para los formularios configurados con los flags de permitido y denegado en lpadmin. El permitido por defecto para una impresora es all, pero esto sólo sirve para usuarios locales. Se deben revisar las
Página 257 de 283
páginas del man del lpadmin para manejar permisos de usuarios remotos. El valor para todos los usuarios de todos los sistemas es all!all.
6.3.4 Logs y archivos de estado Hay una cierta cantidad de lugares en los que se deben buscar los logs.
6.3.4.1 Revise el correo Revise su casilla de correo para ver si recibió algún mensaje del usuario lp. Este puede orientar por donde comenzar a investigar el problema. Un ejemplo de un mensaje de error es el siguiente: From lp Tue Oct 24 09:33:01 2000 Received: (from lp@localhost) by rs9220b.itsc.austin.ibm.com (AIX5.0/8.9.3/8.9.3) id JAA61332 for root@rs9220b; Tue, 24 Oct 2000 09:33:01 -0600 Date: Tue, 24 Oct 2000 09:33:01 -0600 From: lp Message-Id: <200010241533.JAA61332@rs92 <[email protected]> 20b.itsc.austin.ibm.com> To: [email protected][email protected] bm.com Content-Length: 173 Status: RO Subject: Status of lp request hp1-357 Your request hp1-357 destined for hp1 encountered an error while printing on printer hp1. Printing stopped with an exit code of 1.
En este caso, el problema es una variable LANG no soportada y el mensaje no ayuda mucho, pero en otros casos, este mensaje puede ser muy útil.
6.3.4.2 Revise los logs en /var/lp/logs Hay tres archivos en este directorio: • requests • lpsched • lpNet El archivo request se actualiza cada vez que alguien intenta imprimir. Contiene los flags por defecto, y otra información, como muestra este ejemplo: = z C D F O P t U r s
Esto muestra los id del usuario que imprimió, la fecha y hora en que fue impreso el trabajo, el id del trabajo, la prioridad, y el tipo de contenido. No dice mucho sobre qué está mal, aunque dice cómo fue ejecutado. Por ejemplo, este comando lp usó el flag -r cuando fue ejecutado. El log lpsched informa cuándo fue iniciado y detenido el lpsched, y todo error que haya ocurrido manejando procesos hijo o ejecutando scripts interfase: Thu Oct 12 18:55:36 2000: UX:lpsched: INFO: Print services stopped. Thu Oct 12 18:55:44 2000: UX:lpsched: INFO: Print services started. Thu Oct 12 23:12:30 2000: UX:lpsched: ERROR: 0920-281 Received unexpected signal 33; terminating. Fri Oct 13 08:39:32 2000: UX:lpsched: INFO: Print services started. Fri Oct 13 11:08:28 2000: UX:lpsched: ERROR: 0920-271 Failed to fork child process (Resource temporarily unavailable). Thu Oct 12 18:55:36 2000: UX:lpsched: INFO: The network process has terminated.
El log lpNet muestra cuando programas de red como lpNet son llamados, y cuando las conexiones son establecidas con sistemas remotos. Este log muestra eventos cuando se intenta cancelar un trabajo que no se estaba imprimiendo en un sistema remoto: 10/24/00 10:37 c 12972 rs1230a.myco.com lpd retrying connection to rs1230a.myco. com 10/24/00 10:45 c 58614 rs1230a.myco.com ERROR: class=Fatal, type=Unix, trace=(contimeout/setjmp), Interrupted system call 10/24/00 10:45 c 58614 rs1230a.myco.com Abnormal process termination. 10/24/00 10:47 p 61398 Got a hit. 10/24/00 10:47 p 61398 Got a hit. lpExec 10/24/00 10:47 p 61398 Started child for rs1230a.myco.com, pid = 50990 10/24/00 10:47 p 61398 Into Polling loop. 10/24/00 10:47 c 50990 rs1230a.myco.com lpd starting (active)
6.3.4.3 Verificando el archivo pstatus El archivo /var/spool/lp/system/pstatus contiene una sección de estado para cada una de las impresoras. A menudo, este archivo tiene una línea con la última falla, como en este ejemplo: ========== net12 enabled accepting 972671048 971311069 NAK'd by remote lpd: waiting auto retry new destination
6.3.5 ¿La variable LANG está configurada correctamente? Un error interesante que puede ocurrir en algunas versiones de AIX, es que el único valor para la variable LANG que funcione es el C locale. Cuando se imprime con LANG=en_US, el comando devuelve el siguiente error: # lptest 10 10 | lp -d hp1 UX:lp: ERROR: 0920-054 There is no filter to convert the file content. TO FIX: Use the lpstat -p -l command to find a printer that can handle the file type directly, or consult with your system administrator.
Sin embargo, si se añade el flag -L C, el archivo es impreso sin errores: # lptest 10 10 | lp -L C -d hp1 request id is hp1-362 (standard input)
Página 259 de 283
6.3.6 Trabajos remotos cancelados quedan encolados Cuando se usa una impresora remota, y por alguna razón deja de imprimir cuando se cancela un trabajo, el trabajo estará visible para el lpstat pero en estado cancelado, como se ve en el siguiente ejemplo: # lpstat -o all net12-359 root 110 Tue Oct 24 10:16:50 2000 canceled
En este caso, la solución más probable será detener el scheduler y reiniciarlo, aunque puede ser posible matar el comando lpNet que esté inutilizando el puerto.
6.3.7 Imprimiendo en un archivo Direccionando la impresión a un archivo, se puede ver exactamente qué agregó la impresora virtual al archivo que está siendo impreso. Con el comando lpadmin se puede especificar un archivo de salida con la opción -v. El siguiente procedimiento explica como se puede utilizar esto para diagnosticar un problema: 1. Crear un archivo en el directorio /dev. El archivo debe tener permisos para el usuario que realiza la prueba; por lo que se pueden fijar los permisos consecuentemente. # touch /dev/lpx # chmod 600 /dev/lpx # chown lp:lp /dev/lpx
2. Crear una impresora a un archivo utilizando el tipo de impresora, el tipo de interfase y el tipo de conexión que se quiere diagnosticar: # lpadmin -m standard -T hplaserjet -I simple -p fileq -v /dev/lpx
Esto puede dar un error u otra cosa si el permiso de lpx es fijado en 777, pero no es un problema. Para colas PostScript, será necesario especificar el tipo PS-b, porque éste utiliza lp.cat, mientras que PS utiliza postio, que no imprime a un archivo, sólo a una impresora: # lpadmin -m PS -T PS-b -I PS -p fileps -v /dev/lpx
3. Ejecute los comandos para que la impresora acepte trabajos y active la impresora. # accept fileq UX:accept: INFO: destination "fileq" now accepting requests # enable fileq UX:enable: INFO: printer "fileq" now enabled
4. Imprima en la impresora fileq con un trabajo de prueba y asegúrese que hay datos en el archivo: # lptest 5 5 | lp -d fileq -L C request id is fileq-594 (standard input) # ls -l /dev/lpx -rw-rw-rw- 1 lp lp 222 Nov 01 12:34 /dev/lpx # cat /dev/lpx
Página 260 de 283
Cuando se revise el archivo, será mejor utilizar vi y el comando od para poder ver las secuencias de escape.
6.3.8 Limpiando y comenzando de nuevo No debería ser una necesidad limpiar todas las colas y empezar nuevamente, pero es posible que esto sea necesario si se está clonando un sistema.
6.3.8.1 Reiniciar los números de trabajo del subsistema de impresión El número de trabajo para los trabajos locales es almacenado en /spool/tmp/host-name/.SEQF y contiene cuatro campos separados por dos puntos, de la siguiente manera: 1:999:1:598
Los primeros dos número son los límites de los números de trabajo. El siguiente número muestra donde comienza la secuencia de trabajo, y el último (598) es el número del siguiente requerimiento de impresión. Para cambiar el número de secuencia, simplemente se debe cambiar el último valor, y reciclar el subsistema de impresión con lpshut y lpsched.
6.3.8.2 Limpiando archivos de impresión viejos Si se están sufriendo algunos problemas, se puede comenzar limpiando los archivos de requerimientos de trabajo. Primero, verifique el nombre de los trabajos y luego cancélelos, de la siguiente manera: # lpstat -o # cancel fileps-124
Si no se pueden cancelar los trabajos, elimine los archivos individuales de los siguientes directorios: /spool/tmp/host-name y /var/spool/lp/requests/host-name.
6.3.8.3 Limpiando impresoras viejas Intente utilizar primero el lpadmin para borrar las colas utilizando el flag -x: # lpadmin -x fileps
Verifique si el archivo fue borrado, y si no es así, elimine los archivos del directorio y el programa interfase: # lpstat -p fileps -l # rm -R /etc/lp/printers/fileps # rm /etc/lp/interfacers/fileps
6.3.8.4 Elimine los archivos temporales Los archivos de mensajes temporales a veces se acumulan en los directorios /var/spool/lp/tmp y /var/spool/lp/temp y subsiguientes subdirectorios. Utilice ls -lR /var/spool/lp/tmp para ver qué archivos están de más.
Página 261 de 283
6.3.8.5 Elimine archivos de log viejos Los archivos de log son almacenados en /var/lp/logs. Es conveniente hacer una copia de respaldo de los logs y luego copiar /dev/null sobre cada uno de los archivos para vaciarlos, o simplemente redireccionándoles nada, de la siguiente manera: # > /var/lp/logs/lpNet # > /var/lp/logs/lpsched # > /var/lp/logs/requests
6.3.9 Desactivando los banners En el subsistema System V, los banners (carteles) son controlados por el script interfase, la configuración de la impresora y los flags de la línea de comandos.
6.3.9.1 Configuración de los banners Cuando se crea una impresora, no especifique banners. Si está creando o modificando una impresora con lpadmin, utilice el flag -o nobanner para especificar que no se desean banners. El archivo de configuración en /etc/lp/printers/printer-name/configuration debe mostrar: Banner: on:Always
El Always fuerza una página banner sin importar lo que el usuario especifique en el comando lp. Después de ejecutar lpadmin -o nobanner, esta línea cambiará por: Banner: on
Esto no desactiva los banners, pero permite que el usuario seleccione no usar banners por medio del flag -o nobanner del comando lp.
6.3.9.2 Evitando los banners por línea de comando Si el administrador activó la selección de banners para los usuarios con -o nobanner como se describe en el punto anterior, entonces el usuario puede evitar el uso de banners con el flag -o nobanner del comando lp, de la siguiente manera: $ lp -o nobanner -d finetext
Por defecto, el comando lpr enviará un flag de la línea de comando para que haya un encabezamiento de páginas. Para evitarlo, se puede utilizar lpr -h.
6.3.9.3 Evitando los banners con el archivo interfase Para las impresoras locales, encuentre la interfase en /var/spool/lp/admins/lp/interfaces que tiene el mismo nombre de las impresoras. El script debe tener una línea que comienza con nobanner=”no”. Para encontrarla fácilmente en vi, utilice el comando find de la siguiente manera: /^nobanner nobanner=”no”
Página 262 de 283
Modifíquelo por: nobanner=”yes”
6.3.10 Resolviendo problemas de scripts interfase en System V Muchos de los programas interfase de System V son scripts. Esto facilita la investigación de problemas utilizando el comando echo, así como determinar el orden de los eventos en los programas locales, o determinar donde pueden ocurrir errores de formateo. Cada impresora local tiene un programa interfase en /etc/lp/interfaces basado en uno de los scripts modelo. Por ejemplo, si la impresora se llama hp1, la interfase será /etc/lp/interfaces/hp1. Para verificar si el script hp1 es llamado, edite el script, y después de la línea que comienza con la palabra trap, ingrese estas dos líneas: date >> /tmp/hp1.log echo "entered hp1" >> /tmp/hp1.log
Cambie los permisos de /tmp/hp1.log, para que todos los usuarios puedan escribir: # chmod 755 /tmp/hp1.log
Ahora imprima en la cola hp1, y revise el log: Fri Oct 27 13:33:40 CST 2000 entered hp1
Esto muestra que el script es invocado. Ahora se puede intentar utilizar esto para encontrar problemas que puedan ocurrir. Por ejemplo, si se obtiene el siguiente error, será útil saber si el problema está en el comando lp o en el script interfase: # lp -o cpi=17 -d hp1 /etc/motd UX:lp: ERROR: 0920-056 The following options can't be handled: -o cpi= TO FIX: The printer(s) that otherwise qualify for printing your request can't handle one or more of these options. Try another printer, or change the options.
Revisando el log, se verá que el comando no fue registrado, por lo que el problema ocurre antes de ejecutar el script interfase, y por lo tanto parece que terminfo no fue revisado. Se puede usar este método para verificar los argumentos pasados al script por línea de comando o para verificar las variables de ambiente que fueron fijadas y pasadas por lpsched. Agregando las líneas en negrita al script puede ayudar a mostrar la información pasada: ## Check arguments ########### echo "Arguments are $*" >> /tmp/hp1.log parse () { echo "`expr \"$1\" : \"^[^=]*=\(.*\)\"`" echo "`expr \"$1\" : \"^[^=]*=\(.*\)\"`" >> /tmp/hp1.log
y printer=`basename $0` request_id=$1 user_name=$2 title=$3 copies=$4 option_list=$5
Los siguientes comandos echo ayudarán a diagnosticar problemas con los parámetros enviados a lp.set y pueden ser puestos en la subrutina internal_lpset: internal_lpset () { echo "Inside internal_lpset" >> /tmp/hp1.log echo "LPSET parms are $1:$2:$3:$4:$5" >> /tmp/hp1.log echo "LPSET parms are cpi:lpi:width:length:character set" >> /tmp/hp1.log
Revise las variables de ambiente en cualquier lugar del script con: env >> /tmp/hp1.env
o set >> /tmp/hp1.env
Estas herramientas pueden extenderse hasta encontrar los problemas. La mayoría de los scripts interfase también escribe a un archivo log, pero este log es eliminado cuando el script finaliza. Si se continúa teniendo problemas, se puede comentar la línea que elimina el log temporal, y luego de imprimir, revisar este archivo de log. Por ejemplo, en el backend JetDirect, se debe comentar la línea que dice: rm -f $LOGFILE
6.3.11 Revise los tiempos de espera en el archivo Systems para las colas remotas Los tiempos de espera (timeouts) por defecto en versiones anteriores al AIX 5L V5.0 provocaban que las impresiones remotas quedaran indefinidamente esperando cuando había saturación en el servidor de impresión remoto. Verifique los tiempos de espera de las colas remotas revisando el archivo /etc/lp/Systems. Si no hay tiempos de espera configurados, la salida será similar a la siguiente: rs1230a.itsc.austin.ibm.com:x:-:bsd:-:-:-:-:-:
El siguiente archivo muestra un tiempo de espera de 1 minuto con 2 reintentos: rs1230a.itsc.austin.ibm.com:x:-:bsd:-:1:2:-:-:
Si no está configurado el tiempo de espera, se puede fijar con lpsystem, de la siguiente manera: # lpsystem -T 2 rs1230a.itsc.austin.ibm.com
6.3.12 ¿Está bien ingresado el nombre del servidor en el archivo /etc/lp/Systems? El archivo /etc/lp/Systems debe contener el nombre completo que el comando lpNet obtiene cuando solicita el nombre de un host. Haciendo pruebas, se verifica que si se coloca la dirección IP en este archivo se pueden enviar archivos al sistema, pero no recibirlos. Sólo después de ingresar
Página 264 de 283
el nombre completo (con el dominio) se pueden recibir trabajos de impresión. Esta es la línea en el archivo Systems. La primera línea, fue reemplazada por la segunda: rs1290a:x:-:bsd:-:1:2:-:-:ibm4312 rs1290a.itsc.austin.ibm.com:x:-:bsd:-:1:2:-:-:ibm4312
Se pueden ver algunos parámetros específicos de Systems con lpsystem: # lpsystem -l rs1290b System: rs1290b Type: bsd Connection timeout: 1 minutes Retry failed connections: after 1 minutes Comment: jetdir
6.3.13 Ejemplos: solucionando problemas de impresión remota Esta sección muestra ejemplos de resolución de problemas para trabajos de impresión LPD entrantes y salientes.
6.3.13.1 Ejemplo: desaparecen trabajos de impresión de red salientes Síntomas: Los trabajos para la impresora remota están encolados, pero continúan en estado de ejecución. Cuando se intenta cancelarlos, permanecen en la salida del lpstat, pero en estado cancelado. Ejecutando el comando lpstat -o net12 para la impresora net12, hay un retraso de algunos segundos, y nada es impreso. Después de detener el scheduler y reiniciarlo, se limpió el flag /etc/lp/logs/lpNet, y se ejecutó nuevamente el comando lpstat -o net12. Esta es la salida del log lpNet: 10/27/00 11:12 p 7888 Got a hit. 10/27/00 11:12 p 7888 Got a hit. lpExec 10/27/00 11:12 p 7888 Started child for rs1230a.itsc.austin.ibm.com, pid = 19322 10/27/00 11:12 p 7888 Into Polling loop. 10/27/00 11:12 c 19322 rs1230a.itsc.austin.ibm.com lpd starting (active)
Cuando se revisa la tabla de procesos para el proceso 19322, se ve lo siguiente: # ps -ef | grep 19322 root 19322 7888 0 11:12:19 - 0:00 lpNet
Este es un proceso hijo, generado por el lpNet padre, como muestra el ps: # ps -ef | grep lpNet root 7888 45298 0 10:59:18 - 0:00 lpNet root 19322 7888 0 11:12:19 - 0:00 lpNet
El lpNet padre pertenece al proceso 45298 que es el scheduler: # ps -ef | grep 45298 root 7888 45298 0 10:59:18 - 0:00 lpNet root 45298 1 0 10:59:18 - 0:00 /usr/lib/lp/lpsched
Revisando el archivo /etc/lp/Systems para ver si el servidor fue ingresado: $ cat /etc/lp/Systems 9.19.129.12:x:-:bsd:-:3:10:-:-: rs1230a.itsc.austin.ibm.com:x:-:bsd:-:1:2:-:-:
Página 265 de 283
Se revisa el archivo de configuración para verificar que el nombre del servidor coincida: $ cat /etc/lp/printers/net12/conf* Banner: on:Always Content types: simple Printer type: hplaserjet Remote: rs1230a.itsc.austin.ibm.co rs1230a.itsc.austin.ibm.com!TEXT m!TEXT Range: 3,8 Form feed: on
Comparando se verifica que el nombre del servidor es el mismo en ambos archivos. Se debe revisar la conexión al servidor: $ ping rs1230a 0821-062 ping: host name rs1230a NOT FOUND
Revisando la lista de servidores se ve que el nombre del servidor fue modificado por rs1290a, por lo que se debe utilizar el comando lpadmin para modificar el nombre del servidor, pero se recibe el siguiente mensaje: UX:lpadmin: ERROR: 0920-195 System "rs1290b" does not exist. TO FIX: Use the "lpsystem -l" command to list all known systems.
Por lo tanto, se debe ejecutar el comando lpsystem para agregar el nuevo servidor, y ejecutar nuevamente el lpadmin para cambiar el servidor. # lpadmin -s rs1290a -p net12!TEXT
Después de realizar esta modificación, el comando lpstat -o net12 tiene una respuesta inmediata, pero el archivo no es impreso. Se recicla el servicio de impresión con lpshut y lpsched, pero el archivo todavía no se puede imprimir. Se intenta desactivar la impresora, pero se obtiene un mensaje que dice que la impresora ya estaba desactivada. Luego de activar la impresora, el trabajo es impreso.
6.3.13.2 Ejemplo: se pierde un trabajo de impresión remoto entrante Síntoma: Un trabajo es impreso desde un servidor AIX 4.3.3 a la cola System V de un servidor AIX 5L, pero desaparece sin ser impreso. El lpd del AIX 4.3.3 muestra que el trabajo fue enviado satisfactoriamente, y el archivo /etc/lp/logs/netLP muestra: 11/01/00 11/01/00 11/01/00 11/01/00 11/01/00 11/01/00
14:42 14:42 14:42 14:42 14:42 14:42
p p p c c c
19414 Got a hit. 19414 Got a hit. listenBSD 19414 Into Polling loop. 9190 matt.dfw.com lpd starting (passive) 9190 matt.dfw.com matt.dfw.com requests recv job hp1 9190 matt.dfw.com lpd exiting, status=0
Esto parece indicar que el trabajo fue recibido satisfactoriamente por la cola hp1, pero nada aparece en la impresora, en los logs de la interfase, y en los archivos /var/lp/logs/lpsched y /var/lp/logs/requests. El comando lpstat -o muestra que no hay trabajos encolados. Desactivamos la cola, y se repite la prueba desde el cliente remoto, pero nuevamente nada es encolado. Sospechando un problema con locale, ya que en algunos casos se debió utilizar el flag lp -L C para imprimir, se intenta reiniciar el lpsched con el locale configurado en C en lugar de en_US, de la siguiente manera: # lpshut # export LANG=C # /usr/lib/lp/lpsched
Página 266 de 283
Esto no resolvió ni modificó el problema de ninguna forma. Revisando el archivo /var/spool/lp/system/pstatus: ========== hp1 disabled accepting 973111581 972921654 unknown reason
Testing the printer
El usuario test en el cliente recibe este mensaje de correo: Subject: printer job Your printer job could not be printed. Reason for failure: UX:lpd: ERROR: 0920-053 You are not allowed to use the destination "hp1". TO FIX: Use the lpstat -p command to list all known printers; you can use those marked "available".
El comando lpstat -p muestra la cola hp1 disponible: # lpstat -p | grep hp1 printer hp1 disabled since Wed Nov 1 14:46:21 2000. available.
Se revisa el archivo allow de la impresora: # cat /etc/lp/printers/hp1/users.a /etc/lp/printers/hp1/users.allow llow all
El comando lpadmin dice que para recibir archivos de sistemas remotos la configuración de este archivo debe ser all!all. Para modificar el archivo: # lpadmin -u allow:all!all -p hp
Reciclamos el scheduler y ahora los trabajos remotos del cliente son impresos.
6.3.14 Resolviendo problemas de impresión de HP JetDirect Cuando se utiliza una impresora con el protocolo de impresión HP JetDirect, hay algunas herramientas por defecto útiles para investigar.
6.3.14.1 Permisos de archivo erróneos en el script interfase El primer problema que se puede encontrar con la impresión JetDirect en System V es causado por un error en el Administrador del Sistema basado en Web en las primeras versiones adoptadas en AIX 5L. El script interfase que es creado no tiene los permisos correctos y cuando se intenta imprimir, se obtiene un error por correo que dice que el programa interfase no pudo ser ejecutado: From lp Mon Oct 23 18:43:21 2000 Date: Mon, 23 Oct 2000 18:43:20 -0600 From: lp To: susieq Content-Length: 572 Subject: Problem with printer hplj4m-net
Página 267 de 283
The printer hplj4m-net has stopped printing for the reason given below. Fix the problem and bring the printer back on line. Printer has stopped, but will be restarted in a few minutes; issue an enable command if you want to restart sooner. Unless someone issues a change request lp -i hplj4m-net-788 The reason it stopped The interface program could not be executed.
Para solucionar el problema, se deben cambiar los permisos del programa interfase en el archivo /etc/lp/interfaces, de la siguiente si guiente manera: # cd /etc/lp/interfaces # chmod 775 hplj4m-net # chown lp:lp hplj4m-net
Se debe asegurar que hplj4m-net es reemplazado con el nombre de la cola. Luego se debe activar la cola, y liberar el trabajo de impresión.: # enable hplj4m-net # lp -i hplj4m-net-788
6.3.14.2 Revise los archivos de log /tmp/hpnpf.* Revise los archivos de log /tmp/hpnpf.* con el siguiente comando: # ls -l /tmp/hpnpf.* -rw-r--r-1 lp lp 280 Nov 15 16:40 /tmp/hpnpf.41480 # cat /tmp/hpnpf.41480 wsm1-331 /etc/lp/interfaces/model.orig/wsm1 /etc/lp/interfaces/model. orig/wsm1 | /usr/lib/hpnp/hpnpf -x rs1290b wsm1-331 Do not have access wsm1-331 Do not have access wsm1-331 Do not have access wsm1-331 Do not have access wsm1-331 Do not have access wsm1-331 5 errors logged for wsm1-331; errors no longer logged
El mensaje Do not have access es un indicador de que la impresora puede estar fuera de línea. El protocolo JetDirect no utiliza la información del lpsystem de ninguna forma. En este punto, revise si la impresora está disponible con un ping. Luego realice un telnet al puerto 9100. Si se obtiene el siguiente error, se debe revisar la impresora: # telnet 9.3.240.52 9100 Trying... telnet: connect: A remote host refused an attempted connect operation.
6.3.14.3 Salida escalonada en impresoras PCL La impresora por defecto que se crea con el tipo simple imprimirá la salida escalonada. La clave para solucionarlo en impresoras PCL es fijar el tipo de contenido en pcl y registrando el filtro pcl. Para registrar el filtro pcl, utilice el siguiente comando: # lpfilter -f pcl -F /etc/lp/fd/pcl.fd
Página 268 de 283
6.4 Resolución de problemas en el subsistema de impresión PowerPC Esta sección lista las técnicas de resolución de problemas que se aplican únicamente al subsistema de impresión PowerPC.
6.4.1 Problemas de permisos de archivos En el único caso en el que puede haber problemas de permisos de archivos es cuando un administrador del sistema ha realizado cambios manualmente o alguien ejecutó el comando tcbck sin flags para que corrija problemas automáticamente. Los síntomas del problema son: • Sólo root puede imprimir • No se puede imprimir desde algunos directorios Utilice tcbck para encontrar aquellos archivos que tengan permisos equivocados, y cámbielos manualmente.
6.4.2 ¿El servicio de impresión está activo? Para determinar si el qdaemon y el lpd están activos, se puede usar el comando lssrc de la siguiente manera: # lssrc -s qdaemon # lssrc -s lpd
6.4.2.1 Iniciando los servicios de impresión Para reiniciar cualquier daemon, utilice el comando startsrc: # startsrc -s qdaemon # startsrc -s lpd
Revise nuevamente para asegurarse que los daemons permanezcan activos.
6.4.2.2 El qdaemon no permanece activo Un problema frecuente que ocurre cuando los administradores modifican a mano el archivo /etc/qconfig es que el qdaemon encuentra errores en el archivo y no permanece activo. En este caso, se debe realizar una copia de respaldo del /etc/qconfig, y luego comenzar a eliminar colas desde el final, una por vez. Intente reiniciar el qdaemon después de eliminar cada cola. Una cola consiste en dos párrafos de información. El párrafo de la cola apunta al párrafo del dispositivo de la cola. Debe asegurarse que hay un dispositivo de cola por cada párrafo de cola. Se debe verificar que todas las líneas comiencen con un tabulado, excepto las líneas que definen el nombre de la cola o del dispositivo de la cola; estas deben comenzar en la columna cero. Archivos extraños en qdir Otro problema que puede causar errores y problemas con el qdaemon son archivos extraños en el directorio /var/spool/lpd/qdir. Si hay otros archivos además de los archivos de descripción de trabajos de las colas activas, esos archivos deben ser eliminados.
Página 269 de 283
El dispositivo de cola falso Cuando los dispositivos de colas son eliminados mientras hay trabajos encolados, a veces quedan colas con dispositivos falsos. Para remediarlo, se debe borrar el párrafo del /etc/qconfig, y eliminar todos los archivos de la impresora virtual, los archivos de estado, y los archivos de descripción de trabajo asociados con esta cola.
6.4.3 ¿La impresora tiene los atributos correctos? Configurar una impresora con los atributos erróneos puede provocar problemas con el control de flujo y el formateo. Es importante comparar la impresora con una de similares características en AIX. Tanto los atributos de la impresora, como los de la impresora virtual son importantes.
6.4.3.1 Impresora Cuando se agrega una impresora que está ubicada localmente y se conecta utilizando interfases RS/232 o paralelas, hay una cierta cantidad de atributos que deben ser configurados. Impresoras conectadas por RS/232 Para las impresoras conectadas por RS/232, el baud rate, la cantidad de bits de datos, la paridad, y la cantidad de bits de detención configurados deben coincidir con los de la impresora. Además, el tamaño del buffer puede ser importante, porque con algunas impresoras lentas los datos pueden ser enviados más rápido que lo que pueda aceptar la impresora y tan rápido que no puede fijar el control de flujo. Algo que también debe coincidir es el control de flujo. Aunque es recomendable el control de flujo por hardware, puede usarse tanto el control de flujo de hardware como de software. Lo importante es que sea configurado de igual manera en la impresora y en el dispositivo del ordenador. Impresoras conectadas por el puerto paralelo El único parámetro que puede afectar el funcionamiento de las impresoras conectadas a través del puerto paralelo es el retraso con que la impresora responde en el proceso de comunicación. Para plotters e impresoras lentas, el valor Delay between characters puede ser incrementado en la sección de dispositivos de impresión.
6.4.3.2 Impresoras virtuales Mientras los atributos del dispositivo pueden determinar si algo puede imprimirse, los atributos de la impresora virtual tendrán un gran efecto en la salida impresa. Como la impresora virtual realiza la inicialización de la impresora con comandos que son específicos del data stream soportado por la impresora, es importante que se seleccione una impresora virtual que utilice los mismos data streams que espera la impresora. Por ejemplo, si se instala una impresora Epson Injet, que utiliza una secuencia de control Epson, utilizando una impresora virtual HP Injet, que utiliza una secuencia de control PCL, ininteligible. Otra cosa que debe coincidir es el ancho y largo de página, especialmente cuando se imprimen archivos de texto.
6.4.4 Logs y archivos de estado Cuando se tienen problemas relativos a impresión, hay mensajes y archivos de log que pueden ayudar a resolver el problema. En esta sección se describen algunos lugares que se deben revisar para obtener información de diagnóstico.
Página 270 de 283
6.4.4.1 Mensajes de error por línea de comando Cuando se imprime, la primera oportunidad de obtener un error aparece utilizando flags inválidos o valores erróneos de esos flags. Un ejemplo del uso de un flag inválido es el siguiente: # cd /tmp # cat cmderr.txt # lp -p69 -P3130pcl /etc/motd lp: illegal option -- p usage: lp [-cmsw] [-dDestination] [-nNumber] [-oOption] [-tTitle] [-] File ... Prints a file in a format suitable for sending to a line printer.
6.4.4.2 Mensajes por correo Muchas veces, tanto el qdaemon como el backend piobe enviarán un mensaje de correo al usuario que emitió el trabajo y al usuario root, describiendo el problema que ocurrió.
6.4.4.3 Mensajes en la consola A veces, los mensajes de colas caídas, u otros errores son impresos en la terminal del usuario.
6.4.4.4 Archivos de mensajes de error de las impresoras virtuales Cuando ocurre un error con parámetros o flags en la impresora virtual, un archivo de errores es creado en /var/spool/lpd/pio/@local. Los archivos comienzan con msg, luego un número, un punto y el nombre de la cola y del dispositivo. Por ejemplo, este comando con un pitch ilegal: # qprt -p15 -P3130pcl /etc/motd
produce el siguiente mensaje de error en msg1.3130pcl:@aus3130b: ----------------------------------------------------------Thu Oct 26 13:23:07 2000 (root) ----------------------------------------------------------=====> MESSAGE FROM PRINT JOB 1062 (/etc/motd) <===== 0782-598 The value 1 specified in the validate op V in the limits field for _p attribute indicates failure
6.4.4.5 Logs de impresiones remotas Tanto rembak como lpd tiene capacidad para usar archivos de log. Esto puede proveer información sobre que tipo de errores puede haber ocurrido. Utilizando archivos de log de rembak Cuando se crea una cola, se puede configurar lo siguiente: To turn on debugging, specify output file pathname [/tmp/rem1.log]
Después, un flag -D archivo.log es agregado en el /etc/qconfig, de la siguiente manera: backend = /usr/lib/lpd/rembak -D /tmp/remback.log
Página 271 de 283
Normalmente, esto se realiza modificando un dispositivo de cola desde smit. La salida contiene mucha información, y puede evitar el uso de un trace. La parte de la salida que muestra cómo es enviado el archivo enviado es la siguiente # grep sendjob rem1.log rembak[56708] sendjob: sendjob starts, jobname=STDIN.46218, current time=9725985 26. rembak[56708] sendjob: datafn[0]=dfA069rs9220b, fakedfn=dfA069rs9220b. rembak[56708] sendjob: ctrlfname=/tmp//rembak0FTy ctrlfname=/tmp//rembak0FTyqa, qa, fakecfn=cfA069rs9220b. rembak[56708] sendjob: State machine starts..... rembak[56708] sendjob: State 1 - send the "Receive a Print Job" request. rembak[56708] sendjob: state 3 - Send data file(s), dfcount=1. rembak[56708] sendjob: realfn=/var/spool/qdaemon realfn=/var/spool/qdaemon/t0nJiEa, /t0nJiEa, fakefn=dfA069rs9220b, filter=/usr/lib/lpd/aixshort. rembak[56708] sendjob: State 2 - send control file, ctrlfname=/tmp//rembak0FTy ctrlfname=/tmp//rembak0FTyqa qa , fakecfn=cfA069rs9220b. rembak[56708] sendjob: State 5 - end of job #69 (STDIN.46218). rembak[56708] sendjob: Delete control file /tmp//rembak0FTyqa.
Utilizando archivos de log de lpd Cuando se reciben archivos, el daemon lpd puede crear logs de la actividad. Para activar el log en lpd, se debe detener y reiniciar el qdaemon de la siguiente manera: # stopsrc -s lpd # startsrc -s lpd -a “-D /tmp/lpddebug”
La salida de este comando es útil ya que provee información sobre el archivo de control pasado al AIX, y el comando enq que genera el lpd. Esta es una parte de la salida: lpd[56734] doit: cfn=[cfA929tesch.972600121] cfn=[cfA929tesch.972600121]. . lpd[56734] doit: get a line [Htesch]. lpd[56734] doit: get a line [Proot]. lpd[56734] doit: get a line [fdfA929tesch]. lpd[56734] doit: get a line [UdfA929tesch]. lpd[56734] doit: get a line [NSTDIN.6404]. lpd[56734] doit: exec enq cmd=[/usr/bin/enq -P3130pcl -r -troot@tesch -Zroot@tes ch.aix.dfw.ibm.com -N1 -TSTDIN.6404 /var/spool/lpd/dfA929tesch.972600121 ].
6.4.4.6 Archivos de descripción del trabajo El archivo de descripción del trabajo (job description file o JDF) puede ayudar a encontrar información sobre el archivo que se está imprimiendo, el entorno de usuarios, y los flags que son pasados. En muchos casos, la información al final del archivo es la más útil. Por ejemplo, el siguiente JDF muestra los flags enq, los otros flags, y el archivo que es impreso: -Ttesting-Ptestq testing root rs9220b 0 $#@!-d $#@!p $#@!-p $#@!17 $#@!-z $#@!+ $#@!-f $#@!1 /var/spool/qdaemon/t6FLT7a 2
Página 272 de 283
Esta es la descripción de cada línea: • La línea con -Ttesting-Ptestq muestra cual de los flags estándar del enq son pasados del qprt al enq. • Las líneas del medio muestran que el título es testing, y es impreso por root en el sistema rs9220b. • Las líneas que comienzan con $#@! son flags de formateo del qprt, o lp -o que son tratados como otros flags por el enq. Son normalmente flags de formateo de la impresora virtual y son útiles para diagnosticar problemas donde flags inválidos son enviados y el archivo desaparece. Se deben probar estos flags individualmente con enq -o. Un problema común es el flag -fl; si es usado, se debe verificar que la impresora virtual tenga un atributo fl configurado para %ip. • La línea final en el archivo es el nombre del archivo impreso. El archivo fue encolado localmente, ya que está en /var/spool/qdaemon. Para trabajos locales que no son encolados, en esta línea se muestra el nombre original del archivo. En trabajos recibidos de clientes remotos, los archivos estarán en /var/spool/lpd.
6.4.4.7 Archivos de estado Los archivos de estado son usados por lpstat y qchk para mostrar el estado de un archivo. Los archivos están en /var/spool/lpd/stat, y comienzan con s.; sin embargo, los archivos están en formato binario y no pueden accederse directamente. El archivo PID en este directorio guarda el ID de proceso del qdaemon, y los archivos que comienzan con p. contienen los ID de procesos iniciados por el qdaemon, por ejemplo, antes de que un dispositivo cancele por tiempo en lp0 porque la impresora estaba apagada. El archivo p.textq.lp0 contiene el valor 12808. Para ver que procesos están asociados con que cola, use el comando ps de la siguiente manera: # cat plocal.txt # ps -ef | grep 12808 root 12808 7756 0 13:46:36 root 45590 12808 0 13:46:36 -A0 -B880 -C14688 -F\14\15 root 46824 14270 1 13:50:52
pts/1
0:00 /usr/lib/lpd/piobe /etc/motd 0:00 /usr/lib/lpd/pio/etc/pioou /usr/lib/lpd/pio/etc/pioout t 0:00 grep 12808
Esto muestra que el comando pioout fue llamado por piobe. El comando pioout es el filtro que escribe en el puerto del dispositivo local.
6.4.5 Imprimiendo en un archivo con el subsistema PowerPC Imprimiendo en un archivo, se puede ver exactamente lo que la impresora virtual añadió al archivo antes de imprimirlo. En AIX 5L, existe la posibilidad de agregar impresoras a archivos del directorio /dev. El siguiente procedimiento explica como aprovechar esto para diagnosticar un problema: 1. Cree un archivo en el directorio /dev. El archivo debe tener permisos para el usuario que realiza el procedimiento. # touch /dev/lpx # chmod 666 /dev/lpx
2. Cree una cola de impresión a un archivo utilizando el tipo de impresora que se quiere diagnosticar: # smitty mkpq Choose: file File in the /dev directory
Página 273 de 283
Choose the printer manufacturer Choose the model of printer Name of existing file in the /dev directory [lpx] Enter the queue name testq and press [Enter]
3. Intente imprimir en la cola: # lptest 5 5 | qprt -P testq
4. Examine el archivo con vi u od. ^[%-12345X@PJL SET RESOLUTION = 300 @PJL SET LPAPERSOURCE = TRAY1 @PJL SET PAPER = LETTER @PJL SET LTRAY1PAPERTYPE = NORMAL @PJL ENTER LANGUAGE = PCL ^[(s17H^M ^[(s0S^[(s0B^[(s3T^[&l1O^[&k0G^[&l8.00C^[(8U!"#$%^M "#$%&^M #$%&'^M $%&'(^M %&'()^M ^[E^[(s17H^[&l1O^[&k0G^[&l6D^[%-12345X
5. Compare la salida con el manual de referencia de la impresora: ^[ is an escape character ^[%-12345X is a printer reset to start PJL commands @PJL commands are usually obvious ^[(s17H sets the pitch in characters per inch ^[(s0S sets to simple non-italics style ^[(s0B sets to normal, not-bold ^[(s3T sets the type style to courier ^[&k0G tells the printer not to add carriage returns. ^M is a carriage return
Esta es una técnica útil para ver donde coloca la impresora virtual los avances de línea utilizando lptest 200 1 para imprimir una sola línea de 200 caracteres de largo. Esto también es útil para ver como diferentes flags afectan al comando dirigido a la impresora.
6.4.6 Limpiando y comenzando de nuevo A veces se llega a un nivel punto donde los trabajos parecen detenidos sin motivo y el qdaemon no puede iniciar. En estos casos, es recomendable ver primero si se puede detectar el problema encontrando el proceso conflictivo.
6.4.6.1 Primero se debe encontrar la causa El ID de los procesos que fueron llamados por el qdaemon son almacenados en archivos que comienzan con la letra p en el directorio /var/spool/lpd/stat. Se debe comenzar deteniendo el qdaemon y verificando los archivos de estado de procesos en este directorio. Si existen, se debe hacer un kill -9 de los números de procesos contenidos en los archivos. En muchos casos, esto soluciona el problema. Luego, utilice el comando fuser para ver si hay algún proceso aún activo en el dispositivo que está fallando. Por ejemplo, si hay trabajos que parecen detenidos sin motivo en lp17, entonces verifique los procesos con: # fuser /dev/lp17
Si algún proceso está activo en este puerto, este proceso mostrará el ID. Verifique si hay algún otro
Página 274 de 283
proceso que comience con qd o pio aún activo: # ps -ef | grep qd # ps -ef | grep pio # kill -9 PIDnumbers
Otra cosa que puede provocar que el qdaemon falle es la presencia de archivos extraños en /var/spool/lpd/qdir. Se debe verificar que los archivos en este directorio tengan el formato de archivo de descripción de trabajo (JDF). Un archivo no JDF puede causar que el lpstat devuelva un error sobre un cola dañada. En este punto, será necesario cancelar todos los trabajos que crearon el problema y reiniciar el qdaemon.
6.4.6.2 Último recurso: limpiar el sistema de impresión Cuando todo falla y no se puede resolver el problema, con trabajos que están detenidos sin motivo aparente, se puede limpiar totalmente el sistema de impresión. Este procedimiento elimina todos los trabajos de impresión y estos deben ser emitidos nuevamente. Es necesario ser root para realizar esta tarea. Los pasos son los siguientes: 1. Detenga el qdaemon y los procesos procesos asociados: # stopsrc -s qdaemon
2. Mate todos los procesos asociados con el qdaemon. Estos normalmente son procesos que comienzan con qd, como qdfork, o con pio como pioformat o pioout. # ps -ef | grep qd # ps -ef | grep pio # kill -9 PIDnumbers
Si los procesos no pueden matarse con kill -9, será necesario hacer un reboot del sistema. 3. Limpie los archivos de estado de las colas. Esto reiniciará los números de trabajo, a menos que se preserve el archivo /var/spool/lpd/stat/numfile. # rm /var/spool/lp/stat/*
6.4.7 Revisando los flags para enq En el subsistema PowerPC, todos los comandos como qprt, lp, lpr, lpd, dtprint, etc., envían su salida a través de enq. Una forma de revisar esto es montar el comando echo sobre el enq, de la siguiente manera: # mount /bin/echo /bin/enq
Página 275 de 283
Ahora imprima desde los comandos y verifique qué es lo que recibe el enq: $ qprt -p17 -Ttitle -v8 -Pasc /etc/motd -o -p -o 17 -T title -o -v -o 8 -P asc /etc/motd # lp -m -djunk -o land /etc/motd -C -n -P junk -o land -j -- /etc/motd # lpr -P junk /etc/motd -P junk -c -Bgn /etc/motd
Se debe tener en cuenta que cuando se hace esto, nadie podrá imprimir hasta que se desmonte el echo de la siguiente manera: # unmount /bin/enq
6.4.8 Desactivando los banners En el subsistema PowerPC los banners (carteles) pueden controlarse con los flags de los comandos de impresión, con la configuración de la cola, o modificando el archivo de la impresora virtual.
6.4.8.1 Configuración de los banners Los banners son soportados por las impresoras virtuales en los subsistemas PowerPC. Cuando se crea o modifica una impresora virtual, se puede especificar si se desean páginas de encabezamiento (header), páginas de finalización (trailer), páginas de separación, alguna combinación, o ningún banner. Para cambiar el banner, utilice el menú rápido smitty chpq, seleccione la impresora, y luego seleccione Change / Show Default Print Job Attributes. Busque el campo Separator Pages y presione F4. Elija None para desactivar los banners. Esto será reflejado en el archivo /etc/qconfig, en el párrafo del dispositivo de la cola como header y trailer, como se ve en el siguiente ejemplo para la cola asc cuyo dispositivo es lp0: # lsquedev -q asc -d lp0 lp0: file = /dev/lp0 header = never trailer = never access = both backend = /usr/lib/lpd/piobe
6.4.8.2 Evitando los banners por línea de comando Los usuarios pueden omitir la selección de banners establecida en el archivo de configuración. Para desactivar el uso de banners desde la línea de comando con enq o qprt, se debe utilizar el flag -Bnn, como se ve en el siguiente ejemplo: $ enq -Bnn -P lj24 /tmp/testfile $ qprt -Bnn -P lj24 /tmp/testfile
El comando lpr imprime una página de encabezamiento por defecto. Para desactivarla, utilice el flag -h: $ lpr -h -P lj24 /tmp/testfile
Página 276 de 283
6.4.8.3 Evitando los banners con la impresora virtual A veces, las aplicaciones utilizan el comando lpr, o el administrador no tiene control sobre los usuarios que utilizan el comando lpr sin flags. Se pueden desactivar todos las páginas banner desde la impresora virtual, eliminando el programa generador de banners del atributo sh de la impresora virtual. Utilice el comando lsvirprt para modificar la impresora virtual de esta forma: 1. Inicie lsvirprt: # lsvirprt
2. Seleccione la impresora deseada. 3. Fije nada para sh, de la siguiente manera: 4050n lpx hplj-4050 (PCL) To LIST attributes, enter AttributeName1 ... (* for all attributes) To CHANGE an attribute value, enter AttributeName=NewValue To FORMAT and EDIT an attribute value, enter AttributeName~v To EDIT the attribute file, enter ~v To terminate, press Enter: sh Name sh
LIST attributes, enter AttributeName1 ... (* for all attributes) CHANGE an attribute value, enter AttributeName=NewValue FORMAT and EDIT an attribute value, enter AttributeName~v EDIT the attribute file, enter ~v terminate, press Enter: sh=
Name sh
Description Pipeline for Header Page
Value
6.5 Errores comunes y soluciones Esta sección describe problemas comunes que ocurren configurando los subsistemas de impresión de AIX o imprimiendo archivos.
6.5.1 Problemas agregando una segunda impresora local en el mismo dispositivo Una vez que se agrega una impresora al dispositivo lp0, si se intenta agregar otra impresora virtual utilizando el menú rápido smitty mkpq, se obtendrá el siguiente mensaje de error: Command: failed stdout: yes stderr: no Before command completion, additional instructions may appear below. Method error (/usr/lib/methods/cfgpp): 0514-031 A device is already configured at the specified location.
Este problema puede solucionarse agregando una impresora a un archivo del directorio /dev, y especificando el nombre de archivo como lp0 (o el nombre de dispositivo que se quiere utilizar).
Página 277 de 283
6.5.2 No se pueden cambiar los atributos porque el dispositivo está ocupado Cuando se intenta cambiar los atributos de la impresora, se obtiene este error: Command: failed stdout: yes stderr: no Method error (/usr/lib/methods/chggen): 0514-062 Cannot perform the requested function because the specified device is busy.
Primero, desactive la cola, y si el comando sigue fallando, utilice el comando fuser para ver qué proceso mantiene el dispositivo abierto: # fuser /dev/lp0 /dev/lp0: 12808 45590
Luego mate los procesos con kill.
6.5.3 Los trabajos remotos desaparecen después de activar la cola de impresión Un problema común cuado trabajos remotos desaparecen es que pasan flags que no son válidos para la impresora virtual. El problema más común es con el flag -fl. El síntoma es que si se desactiva la cola, el trabajo queda encolado, pero cuando esta se activa, el trabajo desaparece. Si se captura el archivo en el servidor y se imprime localmente, la impresión funciona correctamente. Mientras el trabajo está encolado, revise el archivo de descripción del trabajo en /var/spool/lpq/dir. Si se ve una línea que contiene el siguiente texto al final del archivo: $#@!-fl seguramente el problema es que el cliente está pasando el flag -fl, y el servidor no tiene definido el atributo fl en la impresora virtual. Para solucionar el problema, utilice lsvirprt, seleccione la impresora virtual e ingrese: fp=%ip Presione Enter para guardar los cambios y reintente el trabajo.
6.5.4 Bad mandatory environment variable Cuando se imprime en un cola de impresión PostScript, con un tipo de contenido PS y un tipo de interfase PS, pero con un tipo de impresora hplaserjet, el siguiente error es enviado por correo al usuario: Subject: Status of lp request wsm3-336 ... Reason for failure:
UX:lp: ERROR: Bad mandatory environment variable. TO FIX: Consult your system administrator.
Revisando el programa interfase de la impresora se ve que este error es generado cuando el tipo TERM no es uno de los tipos TERM PostScript dePS, PS-b, PS-r, PS-br, o PSR. Para solucionar el problema, utilice lpadmin para cambiar el tipo de impresora por PS-b: # lpadmin -p wsm3 -T PS-b
Página 278 de 283
Después de realizar el cambio, se debería poder imprimir.
6.5.5 LOG: is read only Cuando se configuran impresoras JetDirect con el script /usr/lib/hpnp/hpnpcfg utilizando el estándar hpnp.model, el siguiente error es enviado por correo a los usuarios que intentan imprimir en la cola: Printing stopped with an exit code of 1. Reason for failure: /etc/lp/interfaces/wsm2[44]: LOG: is read only
Examinando el scrip /etc/lp/interfaces/wsm2, la línea 44 contiene el siguiente asignación: LOG=/tmp/$PERIPH.$$
Una reexaminación más profunda indica que el problema no es con los permisos de archivo, sino con los permisos de las variables de ambiente. Si la línea se cambia por: LOG1=/tmp/$PERIPH.$$
el problema aún provocará que las impresoras JetDirect que antes funcionaban, ahora no lo hagan. La razón es que el script hpnpcfg fija la variable de ambiente LOG antes de reiniciar lpsched. Cuando lpsched ejecuta el programa interfase, la variable es configurada en modo sólo lectura. La solución es detener el scheduler, asegurarse que LOG no está configurada en el ambiente root y reiniciar el scheduler: # lpshut # unset LOG # /usr/lib/lp/lpsched
Aunque el script hpnpcfg no está documentado ni soportado, una solución permanente al problema es modificar este script; pero hpnpcfg llama a /usr/lib/hpnp/cfg/option6 para crear la impresora, y esto es lo que detiene al scheduler. El lpadmin es llamado para agregar la impresora, y lpsched es llamado para detener la impresora. Si se comentan las líneas de manera que el scheduler no sea detenido y reiniciado, las impresoras funcionarán sin intervención manual. El siguiente ejemplo muestra las líneas comentadas en el script option6: STARTLP=0 #echo /usr/sbin/lpshut | tee -a -- $LOG #/usr/sbin/lpshut #if [ $? -eq 0 ] #then # STARTLP=1 #fi
6.5.6 No hay suministro de papel luego de la página de encabezamiento Cuando se agrega una impresora con el script hpnpcfg, si no se especifica el tipo como pcl, no se verán más páginas luego del encabezamiento. Esto es porque el tipo simple es un tipo directo de impresión que no modifica el archivo. Esto puede solucionarse cambiando el tipo de contenido a pcl y verificando que el filtro pcl esté instalado de la siguiente manera: # lpadmin -p printer-name -I pcl # lpfilter -f pcl -F /etc/lp/fd/pcl.fd
Una vez que se realiza el cambio, los archivos de texto serán impresos correctamente, pero no habrá alimentación de papel después de la página de encabezamiento. Para agregar el suministro
Página 279 de 283
de papel, simplemente cambie el tipo de impresora por hplaserjet, de la siguiente manera: # lpadmin -p printer-name -T hplaserjet
Si esta no es una impresora PCL, elija el tipo de terminfo apropiado.
Página 280 de 283
Lista de abreviaturas AC ACL AIX ANSI APAR ARP ASCI ASCII ATE ATM ATMLE BFF BI BIND CAE CD CDE CD-ROM CE CPI CPU CSS CTS DAR DAR2 DBM DE DFS DHCP DMA DNS DSI DSIRR DSISR DTE DTR EC ELAN ESCON FDDI FTP HACMP HiPPI HiPS
Alternating Current Access Control List Advanced Interactive eXecutive American National Standards Institute Authorized Program Analysis Report Address Resolution Protocol Accelerated Strategic Computing Initiative American National Standards Code for Information Interchange Asynchronous Terminal Emulator Asynchronous Transfer Mode ATM LAN Emulation Backup File Format Business Intelligence Berkeley Internet Name Daemon Computer-Aided Engineering Compact Disc Common Desktop Environment Compact Disc Read Only Memory Customer Engineer Characters Per Inch Central Processing Unit Communication Subsystems Support Clear To Send Data Address Register Secondary Data Address Register Database Manager Dual-Ended Distributed File System Dynamic Host Configuration Protocol Direct Memory Access Domain Name Server Data Storage Interrupt Data Storage Interrupt Reason Register Data Storage Interrupt Status Register Data Terminal Equipment Data Terminal Ready Engineering Change Emulated LAN Enterprise Systems Connection (Architecture, IBM System/390) Fiber Distributed Data Interface File Transfer Protocol High Availability Cluster Multi Processing High Performance Parallel Interface High Performance Switch
HP HPF HTTP I/O IAR IBM ICMP ID IDE IDS IGMP IP IPL JDF JFS LAN LECS LED LES LP LPD LPP LR LUM LV LVCB LVDD LVID LVM MAC MCA MSS MST MTU NFS NIS NUA ODM OEM OLTP PAP PCI PCL PDU PID PJL POSIX POST POWER PP
Hewlett-Packard High Performance FORTRAN Hypertext Transfer Protocol Input/Output Instruction Address Register International Business Machines Corporation Internet Control Message Protocol Identification Integrated Device Electronics Intelligent Decision Server Internet Group Management Protocol Internet Protocol Initial Program Load Job Description File Journaled File System Local Area Network LAN Emulation Configuration Server Light Emitting Diode LAN Emulation Server Logical Partition Line Printer Daemon Protocol Licensed Program Product Link Register Licence Use Management Logical Volume Logical Volume Control Block Logical Volume Device Driver Logical Volume Identifier Logical Volume Manager Medium Access Control Micro Channel Architecture Maximum Segment Size Machine State Save Area Maximum Transfer Unit Network File System Network Information Service Network User Address Object Data Manager Original Equipment Manufacturer Online Transaction Processing Password Authentication Protocol Peripheral Component Interface Printer Control Language Power Distribution Unit Program Identification Printer Job Language Portable Operating Interface for Computing Environments Power-On Self-Test Performance Optimization with Enhanced RISC (Architecture) Physical Partition
Point-to-Point Protocol Program Temporary Fix Physical Volume Permanent Virtual Circuit Physical Volume Identifier Redundant Array of Independent Disks Random Access Memory Remote Asynchronous Node Reliability, Availability, and Serviceability Request For Comments Remote Input Output Routing Information Protocol Remote Procedure Call Ready To Send Small Computer System Interface Serial Link Internet Protocol System Management Interface Tool Symmetric Multiprocessing Scalable POWER Parallel SP Switch System Resource Controller Segment Register Value Serial Storage Architecture Switched Virtual Circuit Transmission Control Protocol Transmission Control Protocol/Internet Protocol UNIX Datagram Protocol Universal Resource Locator UNIX-to-UNIX Communication Protocol Virtual Channel Indicator Video Electronics Standards Association Volume Group Volume Group Descriptor Area Volume Group Identifier Volume Group Save Area Virtual Memory Manager Virtual Path Indicator
Página 282 de 283
Bibliografía - AIX 5L Performance Tools Handbook, SG24-6039. - AIX Logical Volume Manager from A to Z: Troubleshooting and Commands, SG24-5433. - AIX Performance Tuning Guide, Versions 3.2 and 4, SC23-2365. - AIX Version 4.3 Commands Reference - AIX Version 4.3 Kernel Extensions and Device Support Programming Concepts. - IBM Certification Study Guide AIX Performance and System Tuning, SG24-6184. - IBM Certification Study Guide AIX Problem Determination Tools and Techniques, SG24-6185. - IBM SAP Technical Brief, SAP/ORACLE/AIX Performance Tuning Tips - Learning Practical TCP/IP for AIX V3.2/V4.1 Users: Hints and Tips for Debugging and Tuning, SG24-4381. - Performance Management Guide - Printing for Fun and Profit under AIX 5L, SG24-6018. - Problem Solving and Troubleshooting in AIX Version 4.3, SG24-5496. - RS/6000 AIXLink/X.25 Cookbook, SG24-4475. - RS/6000 Performance Tools in Focus, SG24-4989.
