Download pdf - Soporte Aix

Resolución de problemas y soporte

avanzado de AIX

Andrés Córdoba

Resolución de problemas y soporte avanzado de AIX Andrés Córdoba

Página 2 de 283

Índice 1. Introducción a la resolución de problemas ....................................................................... 11

1.1 Proceso de determinación de problemas .................................................................... 11 1.1.1 Definiendo el problema ................................................................................................... 11 1.1.2 Recolectando información del usuario ............................................................................ 11 1.1.3 Recolectando información del sistema ............................................................................ 12 1.1.4 Resolviendo el problema ................................................................................................. 13 1.1.5 Obteniendo parches de software...................................................................................... 13 1.1.6 Otra documentación relevante ......................................................................................... 13

1.2 Evitar los problemas ................................................................................................... 14 1.2.1 Verificaciones preventivas .............................................................................................. 14

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).......................................................................................... 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................................................................................................ 18 2.2.3 Re-sincronización de la ODM ......................................................................................... 18 2.2.4 Entendiendo los problemas del importvg ........................................................................ 19

2.2.4.1 Nivel de versión de AIX......................................................................................................... 19 2.2.4.2 PVID inválido ........................................................................................................................ 19 2.2.4.3 Modificación de algún disco mientras el grupo de volúmenes estaba exportado................... 20 2.2.4.4 Entorno de discos compartidos .............................................................................................. 20

2.2.5 Extendiendo la cantidad máxima de particiones físicas .................................................. 20 2.3 Reemplazo de discos .................................................................................................. 21

2.3.1 Reemplazando un disco ................................................................................................... 21 2.3.1.1 Eliminando un disco defectuoso............................................................................................. 23 2.3.1.2 Agregando un disco nuevo..................................................................................................... 23

2.3.2 Recuperando un disco removido incorrectamente........................................................... 25 2.4 EL JFS en AIX ........................................................................................................... 26

2.4.1 Creando un JFS................................................................................................................ 26 2.4.2 Aumentando el tamaño del file system............................................................................ 27 2.4.3 Verificación y recuperación de file systems.................................................................... 27

2.4.3.1 Reparando un superbloque dañado......................................................................................... 28 2.4.4 Asignación de archivos sparse (esparcidos) .................................................................... 28 2.4.5 Problemas desmontando file systems .............................................................................. 29 2.4.6 Eliminando file systems .................................................................................................. 30

2.5 Espacio de paginado ................................................................................................... 30 2.5.1 Recomendaciones para crear o extender los espacios de paginado ................................. 31 2.5.2 Cómo determinar si hace falta más espacio de paginado ................................................ 31 2.5.3 Cómo disminuir el espacio de paginado por defecto (hd6) ............................................. 32

3. Dumps del sistema............................................................................................................ 35 3.1 Configuración de los dispositivos de dump................................................................ 35

3.1.1 Estimar el tamaño de un posible dump............................................................................ 35 3.1.2 Seleccionando el dispositivo de dump............................................................................. 35


Página 3 de 283

3.1.3 Creando un dispositivo de dump ..................................................................................... 36 3.1.4 Cambiando el tamaño del dispositivo de 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 .......................................................................................... 39 3.2.2 Códigos de estado de un dump ........................................................................................ 39 3.2.3 Log de errores.................................................................................................................. 40

3.3 Core dump .................................................................................................................. 42 3.3.1 Revisando un core dump ................................................................................................. 42 3.3.2 Localizando el core dump................................................................................................ 43 3.3.3 Determinando qué programa provocó el core dump ....................................................... 43 3.3.4 Verificando el dump ........................................................................................................ 43

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?............................................................................................................ 45 3.4.3 Examinando un dump del sistema ................................................................................... 45 3.4.4 Subcomandos básicos del crash....................................................................................... 45

3.4.4.1 El subcomando stat ................................................................................................................ 47 3.4.4.2 El subcomando trace –m ........................................................................................................ 47 3.4.4.3 El subcomando proc............................................................................................................... 50 3.4.4.4 El subcomando thread ............................................................................................................ 51 3.4.4.5 El subcomando od ................................................................................................................. 52 3.4.4.6 Revisando el log de errores .................................................................................................... 52 3.4.4.7 El subcomando le ................................................................................................................... 53 3.4.4.8 El log de errores del VMM .................................................................................................... 53

3.4.5 Manejando la salida del crash.......................................................................................... 54 3.4.6 Tipo de caídas.................................................................................................................. 55

3.4.6.1 Kernel panic o trap ................................................................................................................. 55 3.4.6.2 Addressing exception o data storage interrupt ....................................................................... 55 3.4.6.3 Bloqueo del sistema (System hang) ....................................................................................... 55

3.4.7 Información requerida por el centro de soporte............................................................... 55 3.5 Observación y análisis de algunos ejemplos .............................................................. 56

3.5.1 Ejemplo 1......................................................................................................................... 56 3.5.2 Ejemplo 2......................................................................................................................... 65 3.5.3 Ejemplo 3......................................................................................................................... 66

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....................................................................................................... 69 4.1.1.1 Procesos y threads .................................................................................................................. 69 4.1.1.2 Time slice ............................................................................................................................... 69 4.1.1.3 Modo kernel y modo usuario.................................................................................................. 69 4.1.1.4 Rendimiento en SMP ............................................................................................................. 70

a. Coherencia de cache (Cache coherency) .................................................................................................... 70 b. Afinidad de procesador (Processor affinity)............................................................................................... 70 c. Locking ...................................................................................................................................................... 71

4.1.2 Rendimiento de memoria................................................................................................. 72 4.1.2.1 Advertencia inicial ................................................................................................................. 72 4.1.2.2 Segmentos de memoria .......................................................................................................... 72

a. La lista libre (Free list) ............................................................................................................................... 73 b. Reemplazo de páginas (Page replacement) ................................................................................................ 73 c. Mecanismo de control de la carga de memoria .......................................................................................... 74

4.1.2.3 Espacio de paginado............................................................................................................... 74


Página 4 de 283

a. Ajustando el umbral del espacio de paginado ............................................................................................ 75 4.1.2.4 Pérdidas de memoria (Memory leaks).................................................................................... 76 4.1.2.5 Memoria compartida .............................................................................................................. 76

4.1.3 Rendimiento de I/O de disco ........................................................................................... 76 4.1.3.1 Advertencia inicial ................................................................................................................. 77 4.1.3.2 El diseño del subsistema de disco .......................................................................................... 77 4.1.3.3 Consideraciones de rendimiento relativas al ancho de banda ................................................ 78 4.1.3.4 Diseño del disco ..................................................................................................................... 78

a. Tiempo de acceso del disco........................................................................................................................ 79 b. Discos por bus o loop (lazo) del adaptador ................................................................................................ 80 c. Buffers físicos de disco .............................................................................................................................. 80

4.1.3.5 Conceptos del Logical Volume Manager (LVM)................................................................... 81 4.1.4 Rendimiento de red.......................................................................................................... 82

4.1.4.1 Protocolos TCP/IP.................................................................................................................. 83 4.1.4.2 Modificación de los parámetros de red .................................................................................. 83 4.1.4.3 Optimización de los buffers de red......................................................................................... 84

4.2 Herramientas de rendimiento de CPU y memoria...................................................... 85 4.2.1 El comando sar ................................................................................................................ 85

4.2.1.1 Ejemplos del uso del comando sar ......................................................................................... 85 4.2.1.2 Sumario del comando sar ....................................................................................................... 89 4.2.1.3 El comando sadc .................................................................................................................... 89 4.2.1.4 Los comandos sa1 y sa2 ......................................................................................................... 90

4.2.2 El comando vmstat .......................................................................................................... 90 4.2.3 El comando ps ................................................................................................................. 95

4.2.3.1 Uso del comando ps para estudiar la utilización de CPU....................................................... 95 a. La columna C ............................................................................................................................................. 95 b. La columna TIME...................................................................................................................................... 96 c. La columna %CPU..................................................................................................................................... 96 U

4.2.3.2 Uso del 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 Usando el reporte general del tprof ........................................................................................ 99 4.2.4.2 Utilizando el tprof en un programa ...................................................................................... 100

4.2.5 El comando svmon ........................................................................................................ 101 4.2.5.1 El reporte global del svmon ................................................................................................. 102 4.2.5.2 El reporte de usuario del svmon........................................................................................... 103 4.2.5.3 El reporte de procesos del svmon......................................................................................... 106 4.2.5.4 El reporte de segmentos del svmon...................................................................................... 108 4.2.5.5 El reporte detallado de segmentos del svmon ...................................................................... 110 4.2.5.6 El reporte de comandos del svmon....................................................................................... 112 4.2.5.7 El reporte de clase Workload Manager del svmon............................................................... 114

4.2.6 El comando topas .......................................................................................................... 115 4.2.7 El comando emstat ........................................................................................................ 117

4.3 Herramientas de rendimiento de I/O de disco .......................................................... 118 4.3.1 Revisión general ............................................................................................................ 118 4.3.2 El comando iostat .......................................................................................................... 119

4.3.2.1 El histórico de I/O de disco .................................................................................................. 120 4.3.2.2 Reporte de utilización de TTY y CPU ................................................................................. 121 4.3.2.3 El comando iostat en sistemas SMP..................................................................................... 122 4.3.2.4 Reporte de utilización de disco ............................................................................................ 123

4.3.3 Análisis de rendimiento del LVM utilizando el lslv...................................................... 124 4.3.3.1 Atributos del volumen lógico ............................................................................................... 125


Página 5 de 283

a. Espejado ....................................................................................................................................................126 b. Política intra..............................................................................................................................................126 c. Política inter ..............................................................................................................................................127 d. Striping .....................................................................................................................................................127

4.3.3.2 Fragmentación de volúmenes lógicos .................................................................................. 128 4.3.3.3 Asignación de volúmenes lógicos ........................................................................................ 128 4.3.3.4 El mejor rendimiento del LVM............................................................................................ 130

4.3.4 Monitoreo del LVM y file systems................................................................................ 130 4.3.4.1 El comando filemon ............................................................................................................. 130

a. Usando el comando filemon......................................................................................................................131 4.3.4.2 Análisis del reporte .............................................................................................................. 132

a. Reporte a nivel archivo lógico...................................................................................................................132 b. Reporte a nivel volumen lógico ................................................................................................................134 c. Reporte a nivel volumen físico..................................................................................................................135 d. Reporte a nivel memoria virtual................................................................................................................136

4.3.4.3 Comportamiento típico del sistema AIX.............................................................................. 137 4.3.5 Rendimiento de los file systems .................................................................................... 137

4.3.5.1 El comando fileplace............................................................................................................ 138 4.3.5.2 Desfragmentación de un file system .................................................................................... 139

4.3.6 Recomendaciones generales de rendimiento de I/O...................................................... 140 4.3.7 Consumo de las herramientas de rendimiento ............................................................... 141 4.3.8 Sumario de comandos.................................................................................................... 142

4.3.8.1 El comando filemon ............................................................................................................. 142 4.3.8.2 El comando fileplace............................................................................................................ 142 4.3.8.3 El comando lslv.................................................................................................................... 142

4.4 Herramientas de rendimiento de red......................................................................... 142 4.4.1 Visión general................................................................................................................ 143 4.4.2 Optimización de las colas de transmisión y recepción de los adaptadores.................... 144 4.4.3 Optimización de protocolos........................................................................................... 145 4.4.4 Herramientas de monitoreo del rendimiento de red ...................................................... 147

4.4.4.1 El comando vmstat ............................................................................................................... 147 4.4.4.2 El comando ping .................................................................................................................. 147 4.4.4.3 El comando traceroute.......................................................................................................... 148 4.4.4.4 El comando netstat ............................................................................................................... 148 4.4.4.5 El comando netpmon............................................................................................................ 150 4.4.4.6 Los comandos tcpdump e iptrace ......................................................................................... 151

4.4.5 Herramientas para el control del rendimiento de red..................................................... 153 4.4.6 Resolución de nombres.................................................................................................. 154 4.4.7 Optimización del rendimiento de NFS .......................................................................... 155

4.4.7.1 Rendimiento del lado del servidor NFS ............................................................................... 155 4.4.7.2 Rendimiento del lado del cliente NFS.................................................................................. 156 4.4.7.3 Opciones de montaje ............................................................................................................ 157

4.4.8 Sumario de comandos.................................................................................................... 158 4.4.8.1 El comando netstat ............................................................................................................... 158 4.4.8.2 El comando tcpdump............................................................................................................ 158 4.4.8.3 El comando iptrace............................................................................................................... 158 4.4.8.4 El comando ipreport ............................................................................................................. 158

4.5 Herramientas específicas para el manejo de rendimiento ........................................ 159 4.5.1 El scheduler de AIX ...................................................................................................... 159

4.5.1.1 Cálculo de prioridad en versiones de AIX anteriores a la 4.3.2 ........................................... 160 4.5.1.2 Cálculo de prioridad en AIX Versión 4.3.2 y posteriores .................................................... 162

4.5.2 Colas de ejecución múltiples con balanceo de carga en AIX Versión 4.3.3 ................. 163 4.5.2.1 Balanceo de carga inicial...................................................................................................... 164


Página 6 de 283

4.5.2.2 Balanceo de carga idle.......................................................................................................... 164 4.5.2.3 Balanceo de carga periódico frecuente................................................................................. 164 4.5.2.4 Balanceo de carga periódico infrecuente.............................................................................. 165

4.5.3 Manejo del rendimiento del scheduler........................................................................... 165 4.5.3.1 El comando schedtune.......................................................................................................... 165

a. Primer ejemplo de schedtune.....................................................................................................................165 b. Segundo ejemplo de schedtune .................................................................................................................166 c. Tercer ejemplo de schedtune .....................................................................................................................166 d. Lineamientos generales de SCHED_R y SCHED_D................................................................................166 e. Sumario del comando schedtune ...............................................................................................................167

4.5.3.2 Los comandos nice y renice ................................................................................................. 167 a. Ejecutando un comando con nice ..............................................................................................................167 b. Cambiando el valor nice de un thread en ejecución ..................................................................................168 c. Sumario de los comando nice y renice ......................................................................................................169

4.5.4 El comando bindprocessor............................................................................................. 169 4.5.5 El comando vmtune....................................................................................................... 170 4.5.6 Workload Manager ........................................................................................................ 173

4.6 Escenarios de rendimiento........................................................................................ 174 4.6.1.1 Colección de datos ............................................................................................................... 174 4.6.1.2 Análisis de datos .................................................................................................................. 175 4.6.1.3 Recomendación .................................................................................................................... 176

4.6.2 Escenario de rendimiento de I/O ................................................................................... 176 4.6.2.1 Colección de datos ............................................................................................................... 176 4.6.2.2 Análisis de datos .................................................................................................................. 178

a. Análisis de la salida del comando vmstat ..................................................................................................178 b. Análisis de la salida del comando iostat....................................................................................................178

4.6.2.3 Recomendación .................................................................................................................... 179 4.6.3 Escenarios de I/O adicionales........................................................................................ 179

4.6.3.1 I/O wait de CPU y threads del kernel................................................................................... 179 4.6.3.2 Distribución de I/O............................................................................................................... 180 4.6.3.3 Fragmentación de un volumen lógico .................................................................................. 181 4.6.3.4 Monitoreando el escenario utilizando filemon ..................................................................... 182 4.6.3.5 Asignación de volumen lógico ............................................................................................. 182

4.6.4 Escenario de rendimiento del paginado......................................................................... 184 4.6.4.1 Colección de datos ............................................................................................................... 184 4.6.4.2 Análisis de los datos............................................................................................................. 190

a. La columna kthr (kernel thread) ................................................................................................................190 b. La columna de memoria............................................................................................................................190 c. La columna page .......................................................................................................................................191 d. La columna faults......................................................................................................................................191 e. La columna cpu .........................................................................................................................................191

4.6.4.3 Recomendación .................................................................................................................... 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.2.6.1 Análisis genérico de interfases ............................................................................................. 197 5.2.6.2 Problemas de interfase ethernet............................................................................................ 198 5.2.6.3 Problemas de interfase token-ring........................................................................................ 198 5.2.6.4 Problemas con interfases ATM o ATMLE .......................................................................... 199


Página 7 de 283

5.2.6.5 Problemas con interfases X.25 ............................................................................................. 203 5.3 Problemas de TCP/IP más comunes......................................................................... 204

5.3.1 LED 581 ........................................................................................................................ 204 5.3.2 Problemas con telnet...................................................................................................... 206 5.3.3 Retrasos del login en sistemas AIX 4.3.x ...................................................................... 207 5.3.4 Problemas de DHCP (Dynamic Host Configuration Protocol) ..................................... 207 5.3.5 Las teclas de función de X.25 no funcionan correctamente .......................................... 207

5.4 Asuntos de configuración de TCP/IP ....................................................................... 208 5.4.1 Maximum Transmission Unit (MTU) ........................................................................... 208 5.4.2 Mbufs............................................................................................................................. 208

5.5 Comandos para identificar un problema de TCP/IP................................................. 209 5.5.1 ping................................................................................................................................ 209 5.5.2 rup.................................................................................................................................. 210 5.5.3 netstat............................................................................................................................. 210 5.5.4 arp .................................................................................................................................. 212 5.5.5 iptrace e ipreport............................................................................................................ 212 5.5.6 tcpdump ......................................................................................................................... 212 5.5.7 no (Network Options).................................................................................................... 213 5.5.8 Comandos stat ............................................................................................................... 213

5.6 Resolución de problemas de NIS (Network Information Services) ......................... 213 5.6.1 Herramientas para la resolución de problemas de NIS.................................................. 213

5.6.1.1 ping....................................................................................................................................... 214 5.6.1.2 rpcinfo .................................................................................................................................. 214 5.6.1.3 ypmatch................................................................................................................................ 215 5.6.1.4 ypwhich................................................................................................................................ 215

5.6.2 Ejemplos de resolución de problemas con NIS ............................................................. 216 5.6.2.1 yppush falla al crear mapas nuevos...................................................................................... 217 5.6.2.2 Los broadcast de clientes no vinculan.................................................................................. 217 5.6.2.3 El comando ypwhich es inconsistente.................................................................................. 217 5.6.2.4 Mapas muy largos no son soportados................................................................................... 218 5.6.2.5 Routers, dispositivos de red, y vinculación NIS................................................................... 218 5.6.2.6 Grupos incorrectos por cambios en un grupo nuevo ............................................................ 218 5.6.2.7 mkdbm falla para entradas de mapas NIS muy grandes....................................................... 218

5.7 Resolución de problemas de NFS............................................................................. 219 5.7.1 Pasos generales para solucionar un problema de NFS .................................................. 219 5.7.2 Problemas de montaje en NFS....................................................................................... 219

5.7.2.1 Montajes soft y montajes 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................................ 225 5.7.4 Fallas de locking............................................................................................................ 226

5.7.4.1 Iniciando el rpc.lockd con depuración.................................................................................. 226 5.7.5 Un cliente NFS se detiene durante el reinicio del 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 5.9.1.1 Chat scripts (scripts de conversación) .................................................................................. 230 5.9.1.2 Problemas de autenticación.................................................................................................. 230

5.9.2 AIX como servidor PPP (llamadas entrantes) ............................................................... 231 6. Resolución de problemas de impresión.......................................................................... 233

6.1 Pasos a seguir para resolver problemas comunes..................................................... 234


Página 8 de 283

6.1.1 Pasos a seguir en problemas de impresión local............................................................ 234 6.1.2 Pasos a seguir en problemas de impresión remota ........................................................ 234 6.1.3 Revise lo obvio .............................................................................................................. 235 6.1.4 Nada se imprime en impresoras locales ........................................................................ 235

6.1.4.1 Mi trabajo se perdió, pero otros son impresos...................................................................... 235 6.1.4.2 Nada se imprime, pero las luces en la impresora parpadean o cambian............................... 236 6.1.4.3 Nada llega a la impresora ..................................................................................................... 237 6.1.4.4 ¿Hay espacio suficiente en el file system del spool?............................................................ 240

6.1.5 La salida es basura o está incompleta ............................................................................ 241 6.1.5.1 ¿Los parámetros del puerto son correctos? .......................................................................... 241 6.1.5.2 ¿Los tabuladores están configurados correctamente? .......................................................... 241 6.1.5.3 ¿Se imprime únicamente la primera línea o líneas escalonadas? ......................................... 241 6.1.5.4 ¿La impresora funciona bien por un tiempo y luego mal? ................................................... 242 6.1.5.5 ¿Hay problemas imprimiendo gráficos?............................................................................... 243 6.1.5.6 ¿El tipo de impresora es el correcto?.................................................................................... 243

6.1.6 El espaciado es incorrecto ............................................................................................. 243 6.1.6.1 Espaciado doble ................................................................................................................... 244 6.1.6.2 Sin margen izquierdo ........................................................................................................... 244

6.1.7 La impresión con una fuente incorrecta......................................................................... 244 6.1.7.1 ¿El archivo es PostScript o PCL formateado?...................................................................... 244 6.1.7.2 ¿Cuál es la fuente por defecto de la impresora? ................................................................... 244 6.1.7.3 ¿Qué fuentes están instaladas en la impresora?.................................................................... 245 6.1.7.4 ¿El programa interfase o el backend de impresión fijan la fuente? ...................................... 245

6.1.8 El trabajo de impresión pide un tamaño de papel equivocado ...................................... 246 6.1.9 El trabajo de impresión por red falla ............................................................................. 246

6.1.9.1 Los trabajos de impresión quedan encolados en la cola local .............................................. 246 6.1.9.2 ¿Está configurado el tiempo de espera para la impresión remota con System V? ............... 248 6.1.9.3 Los trabajos de impresión quedan en la cola remota............................................................ 248 6.1.9.4 Los trabajos de impresión desaparecen ................................................................................ 248

6.2 Técnicas de resolución de problemas comunes........................................................ 249 6.2.1 Utilizando lptest para generar archivos de impresión.................................................... 249 6.2.2 Use enscript para generar PostScript ............................................................................. 250 6.2.3 Use splp para ver los dispositivos especiales ................................................................ 250 6.2.4 Imprimiendo a un archivo.............................................................................................. 250 6.2.5 Imprimiendo directamente al archivo del dispositivo especial...................................... 250 6.2.6 Imprimiendo directamente en impresoras de red........................................................... 251

6.2.6.1 Imprimiendo directamente en una impresora conectada a LPD........................................... 251 6.2.6.2 Imprimiendo directamente en una impresora conectada a HP JetDirect .............................. 251 6.2.6.3 Telnet a impresoras JetDirect ............................................................................................... 251

6.2.7 Utilizando iptrace para rastrear una impresión de red ................................................... 252 6.2.8 Capturando archivos...................................................................................................... 252

6.2.8.1 Capturando el archivo antes de que pase por la cola............................................................ 252 6.2.8.2 Capturando un archivo después de que pasó por la cola ...................................................... 253 6.2.8.3 Capturando un archivo tal como va por la red ..................................................................... 253 6.2.8.4 Capturando un archivo en el sistema remoto ....................................................................... 253

6.2.9 Capturar el flag .............................................................................................................. 254 6.2.9.1 Flags de System V................................................................................................................ 254 6.2.9.2 Flags de PowerPC ................................................................................................................ 254

6.2.10 Utilizando script para capturar las entradas del usuario .............................................. 256 6.2.11 Utilizando fuser para encontrar procesos .................................................................... 256 6.2.12 Utilizando el comando echo en scripts shell................................................................ 256

6.3 Resolución de problemas en el subsistema de impresión System V ........................ 256


Página 9 de 283

6.3.1 Problemas de permisos en archivos............................................................................... 257 6.3.2 ¿El servicio de impresión está activo?........................................................................... 257 6.3.3 ¿La impresora tiene los atributos correctos? ................................................................. 257

6.3.3.1 Dispositivo de impresión...................................................................................................... 257 6.3.3.2 Atributos de la impresora definidos en System V ................................................................ 257

6.3.4 Logs y archivos de estado.............................................................................................. 258 6.3.4.1 Revise el correo.................................................................................................................... 258 6.3.4.2 Revise los logs en /var/lp/logs.............................................................................................. 258 6.3.4.3 Verificando el archivo pstatus.............................................................................................. 259

6.3.5 ¿La variable LANG está configurada correctamente?................................................... 259 6.3.6 Trabajos remotos cancelados quedan encolados ........................................................... 260 6.3.7 Imprimiendo en un archivo............................................................................................ 260 6.3.8 Limpiando y comenzando de nuevo.............................................................................. 261

6.3.8.1 Reiniciar los números de trabajo del subsistema de impresión ............................................ 261 6.3.8.3 Limpiando impresoras viejas................................................................................................ 261 6.3.8.4 Elimine los archivos temporales........................................................................................... 261 6.3.8.5 Elimine archivos de log viejos ............................................................................................. 262

6.3.9 Desactivando los banners .............................................................................................. 262 6.3.9.1 Configuración de los banners ............................................................................................... 262 6.3.9.2 Evitando los banners por línea de comando ......................................................................... 262 6.3.9.3 Evitando los banners con el archivo interfase ...................................................................... 262

6.3.10 Resolviendo problemas de scripts interfase en System V ........................................... 263 6.3.11 Revise los tiempos de espera en el archivo Systems para las colas remotas ............... 264 6.3.12 ¿Está bien ingresado el nombre del servidor en el archivo /etc/lp/Systems? .............. 264 6.3.13 Ejemplos: solucionando problemas de impresión remota ........................................... 265

6.3.13.1 Ejemplo: desaparecen trabajos de impresión de red salientes ............................................ 265 6.3.13.2 Ejemplo: se pierde un trabajo de impresión remoto entrante ............................................. 266

6.3.14 Resolviendo problemas de impresión de HP JetDirect................................................ 267 6.3.14.1 Permisos de archivo erróneos en el script interfase............................................................ 267 6.3.14.2 Revise los archivos de log /tmp/hpnpf.* ............................................................................ 268 6.3.14.3 Salida escalonada en impresoras PCL................................................................................ 268

6.4 Resolución de problemas en el subsistema de impresión PowerPC......................... 269 6.4.1 Problemas de permisos de archivos............................................................................... 269 6.4.2 ¿El servicio de impresión está activo?........................................................................... 269

6.4.2.1 Iniciando los servicios de impresión .................................................................................... 269 6.4.2.2 El qdaemon no permanece activo......................................................................................... 269

6.4.3 ¿La impresora tiene los atributos correctos? ................................................................. 270 6.4.3.1 Impresora ............................................................................................................................. 270 6.4.3.2 Impresoras virtuales ............................................................................................................. 270

6.4.4 Logs y archivos de estado.............................................................................................. 270 6.4.4.1 Mensajes de error por línea de comando.............................................................................. 271 6.4.4.2 Mensajes por correo ............................................................................................................. 271 6.4.4.3 Mensajes en la consola......................................................................................................... 271 6.4.4.4 Archivos de mensajes de error de las impresoras virtuales .................................................. 271 6.4.4.5 Logs de impresiones remotas ............................................................................................... 271 6.4.4.6 Archivos de descripción del trabajo ..................................................................................... 272 6.4.4.7 Archivos de estado ............................................................................................................... 273

6.4.5 Imprimiendo en un archivo con el subsistema PowerPC .............................................. 273 6.4.6 Limpiando y comenzando de nuevo.............................................................................. 274

6.4.6.1 Primero se debe encontrar la causa ...................................................................................... 274 6.4.6.2 Último recurso: limpiar el sistema de impresión.................................................................. 275

6.4.7 Revisando los flags para enq ......................................................................................... 275


Página 10 de 283

6.4.8 Desactivando los banners .............................................................................................. 276 6.4.8.1 Configuración de los banners ............................................................................................... 276 6.4.8.2 Evitando los banners por línea de comando ......................................................................... 276 6.4.8.3 Evitando los banners con la impresora virtual ..................................................................... 277

6.5 Errores comunes y soluciones .................................................................................. 277 6.5.1 Problemas agregando una segunda impresora local en el mismo dispositivo ............... 277 6.5.2 No se pueden cambiar los atributos porque el dispositivo está ocupado....................... 278 6.5.3 Los trabajos remotos desaparecen después de activar la cola de impresión.................. 278 6.5.4 Bad mandatory environment variable............................................................................ 278 6.5.5 LOG: is read only .......................................................................................................... 279 6.5.6 No hay suministro de papel luego de la página de encabezamiento.............................. 279

Lista de abreviaturas........................................................................................................... 281 Bibliografía......................................................................................................................... 283


Página 11 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 12 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 13 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 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 14 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 15 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 16 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 17 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.<num>, donde <num> 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 18 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 19 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 rootvg hdisk1 000bc6fdbff75ee2 testvg hdisk2 000bc6fdbff92812 testvg hdisk3 000bc6fdbff972f4 None hdisk4 None None # chdev -l hdisk4 -a pv=yes hdisk4 changed # lspv hdisk0 000bc6fdc3dc07a7 rootvg hdisk1 000bc6fdbff75ee2 testvg hdisk2 000bc6fdbff92812 testvg hdisk3 000bc6fdbff972f4 None hdisk4 000bc6fd672864b9 None


Página 20 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 21 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 aproximada-mente. 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:


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 TYPE LPs PPs PVs LV STATE MOUNT POINT lvdb01 jfs 500 1000 2 open/ /u/db01 syncd lvdb02 jfs 500 1000 2 open/stale /u/db02 loglv00 jfslog 1 1 1 open/syncd 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 0713121400 U S LVDD PHYSICAL PARTITION MARKED STALE F7DDA124 0713121400 U H LVDD PHYSICAL VOLUME DECLARED MISSING 41BF2110 0713121400 U H LVDD MIRROR WRITE CACHE WRITE FAILED 35BFC499 0713121400 P H hdisk4 DISK OPERATION ERROR 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


Página 23 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 COPIES IN BAND DISTRIBUTION hdisk3 500:000:000 21% 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 LPs PPs PVs LV STATE MOUNT POINT lvdb01 jfs 500 1000 2 open/syncd /u/db01 lvdb02 jfs 500 500 1 open/syncd /u/db02 loglv00 jfslog 1 1 1 open/syncd 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 30-58-00-8,0 16 Bit SCSI Disk Drive hdisk1 Available 30-58-00-9,0 16 Bit SCSI Disk Drive hdisk2 Available 10-60-00-8,0 16 Bit SCSI Disk Drive hdisk3 Available 10-60-00-9,0 16 Bit SCSI Disk Drive 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 24 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 30-58-00-8,0 16 Bit SCSI Disk Drive hdisk1 Available 30-58-00-9,0 16 Bit SCSI Disk Drive hdisk2 Available 10-60-00-8,0 16 Bit SCSI Disk Drive hdisk3 Available 10-60-00-9,0 16 Bit SCSI Disk Drive hdisk4 Available 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 LPs PPs PVs LV STATE MOUNT POINT lvdb01 jfs 500 1000 2 open/syncd /u/db01 lvdb02 jfs 500 1000 2 open/stale /u/db02 loglv00 jfslog 1 1 1 open/syncd 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 LPs PPs PVs LV STATE MOUNT POINT lvdb01 jfs 500 1000 2 open/ /u/db01 syncd lvdb02 jfs 500 1000 2 open/syncd /u/db02 loglv00 jfslog 1 1 1 open/syncd N/A

El sistema volvió nuevamente a la normalidad.


Página 25 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 30-58-00-8,0 16 Bit SCSI Disk Drive hdisk1 Available 30-58-00-9,0 16 Bit SCSI Disk Drive hdisk2 Available 10-60-00-8,0 16 Bit SCSI Disk Drive hdisk3 Available 10-60-00-9,0 16 Bit SCSI Disk Drive Esta era la asignación de volúmenes físicos antes de que el disco fuese removido: # lspv hdisk0 000bc6fdc3dc07a7 rootvg hdisk1 000bc6fdbff75ee2 volg01 hdisk2 000bc6fdbff92812 volg01 hdisk3 000bc6fdbff972f4 volg01 Los volúmenes lógicos en el grupo de volúmenes: # lsvg -l volg01 volg01: LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT logvol01 jfs 1000 1000 2 open/syncd /userfs01 loglv00 jfslog 1 1 1 open/syncd N/A La distribución de volúmenes lógicos en los volúmenes físicos era la siguiente: # lslv -l logvol01 logvol01:/userfs01 PV COPIES IN BAND DISTRIBUTION hdisk1 542:000:000 19% 109:108:108:108:109 hdisk3 458:000:000 23% 109:108:108:108:025 El sistema después de ser reiniciado tiene los siguientes volúmenes físicos: # lspv hdisk0 000bc6fdc3dc07a7 rootvg hdisk1 000bc6fdbff75ee2 volg01 hdisk3 000bc6fdbff972f4 volg01 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.


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:

Página 26 de 283


Página 27 de 283

# lsjfs /u/testfs MountPoint:Device:Vfs:Nodename:Type:Size:Options:AutoMount:Acct:OtherOptio ns:LvSize:FsSize:FragSize:Nbpi:Compress:Bf:AgSize: /u/testfs:/dev/lv03:jfs:::425984:rw:yes:no::425984:425984:4096:4096:no:fal se:8: 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 atributo 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 28 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 29 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 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 30 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 LV STATE MOUNT POINT loglv00 jfslog 1 1 1 open/syncd N/A lv02 jfs 2 2 1 open/syncd /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 LV STATE MOUNT POINT loglv00 jfslog 1 1 1 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 31 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 32 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 (posible-mente 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 lslv. El disco de inicio es

mostrado en la columna PV1 de la salida. Ingrese:

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 33 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 (<tamaño en particiones lógicas> es el número de PP a asignar al hd6):

rmps hd6 mklv -y hd6 -t paging rootvg <tamaño en particiones lógicas >

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 34 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 35 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 /dev/hd6 secondary /dev/sysdumpnull copy directory /var/adm/ras forced copy flag TRUE always allow dump 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 36 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 directa-mente 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 37 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 IDENTIFIER: 00017d37a4155bbc VG STATE: active PP SIZE: 8 megabyte(s) VG PERMISSION: read/write TOTAL PPs: 537 (4296 megabytes) MAX LVs: 256 FREE PPs: 218 (1744 megabytes) LVs: 10 USED PPs: 319 (2552 megabytes) OPEN LVs: 8 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

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 VOLUME GROUP: rootvg LV IDENTIFIER: 00017d37a4155bbc.2 PERMISSION: read/write VG STATE: active/complete LV STATE: opened/syncd TYPE: paging WRITE VERIFY: off MAX LPs: 512 PP SIZE: 8 megabyte(s) COPIES: 1 SCHED POLICY: parallel LPs: 256 PPs: 256 STALE PPs: 0 BB POLICY: non-relocatable INTER-POLICY: minimum RELOCATABLE: yes INTRA-POLICY: middle UPPER BOUND: 32 MOUNT POINT: N/A LABEL: None 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 38 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 39 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 [off] + Surveillance Time Interval, in minutes [5] # Surveillance Delay, in minutes [10] # Changes are to take effect immediately [yes] + F1=Help F2=Refresh F3=Cancel F4=List F5=Reset F7=Commit F10=Exit -------------------------------------------------------------------------------------------------------------------------------------------------

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 almacena-miento 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 40 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 supe-riores, 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: SYSDUMP_SYMP IDENTIFIER: 3573A829 Date/Time: Tue May 4 19:17:15 Sequence Number: 205 Machine Id: 000126774C00 Node Id: sp5i Class: S


Página 41 de 283

Type: UNKN Resource Name: CMDCRASH 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 42 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 T C RESOURCE_NAME DESCRIPTION ... C60BB505 0705101400 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATED ... En el reporte anterior se puede ver que el error tiene un identificador C60BB505. Un reporte detalla-do 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 43 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 7FFFFFFF FFFFFFFF |................| 000006C0 00000000 000007D0 7FFFFFFF FFFFFFFF |................| 000006D0 00120000 137084E0 00000000 00000016 |.....p..........| 000006E0 6E657473 63617065 5F616978 34000000 |netscape_aix4...| 000006F0 00000000 00000000 00000000 00000000 |................| 00000700 00000000 00000000 00000000 0000085E |...............^| 00000710 00000000 00000F5A 00000000 00000776 |.......Z.......v| 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, utili-zando la siguiente sintaxis: crash <dump> <unix>. 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 44 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 45 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 46 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 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 47 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.


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:00000000:00000000:00000000) (intpri=3) IAR: .[atmle_dd:atmle_ready_ind]+d8 (01b05cb0): tweqi r5,0x0 LR: .[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:00000000:00000000:00000000)(intpri=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


Página 49 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 procesa-miento 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 50 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 PID PPID PGRP UID EUID TCNT NAME 0 a 0 0 0 0 0 1 swapper FLAGS: swapped_in no_swap fixed_pri kproc Links: *child:0xe3000170 *siblings:0x00000000 *uidl:0xe3001fa0 *ganchor:0x00000000 *pgrpl:0x00000000 *ttyl:0x00000000 Dispatch Fields: pevent:0x00000000 *synch:0xffffffff lock:0x00000000 lock_d:0x01390000 Thread Fields: *threadlist:0xe6000000 threadcount:1 active:1 suspended:0 local:0 terminating:0 Scheduler Fields: fixed pri: 16 repage:0x00000000 scount:0 sched_pri:0 *sched_next:0x00000000 *sched_back:0x00000000 cpticks:0 msgcnt:0 majfltsec:0 Misc: adspace:0x0001e00f kstackseg:0x00000000 xstat:0x0000 *p_ipc:0x00000000 *p_dblist:0x00000000 *p_dbnext:0x00000000 Signal Information: pending:hi 0x00000000,lo 0x00000000 sigcatch:hi 0x00000000,lo 0x00000000 sigignore:hi 0xffffffff,lo 0xfff7ffff Statistics: size:0x00000000(pages) audit:0x00000000 accounting page frames:0 page space blocks:0 pctcpu:0 minflt:1802 majflt:7 Los campos en las primeras líneas de la salida son los siguientes:


Página 51 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 PRI CPU EVENT PROCNAME 0 s 3 0 unbound FIFO 10 78 swapper t_flags: wakeonsig kthread Links: *procp:0xe3000000 *uthreadp:0x2ff3b400 *userp:0x2ff3b6e0 *prevthread:0xe6000000 *nextthread:0xe6000000, *stackp:0x00000000 *wchan1(real):0x00000000 *wchan2(VMM):0x00000000 *swchan:0x00000000 wchan1sid:0x00000000 wchan1offset:0x00000000 pevent:0x00000000 wevent:0x00000001 *slist:0x00000000 Dispatch Fields: *prior:0xe6000000 *next:0xe6000000 polevel:0x0000000a ticks:0x0139 *synch:0xffffffff result:0x00000000 *eventlst:0x00000000 *wchan(hashed):0x00000000 suspend:0x0001 thread waiting for: event(s) Scheduler Fields: cpuid:0xffffffff scpuid:0xffffffff pri: 16 policy:FIFO affinity:0x0003 cpu:0x0078 lpri: 0 wpri:127 time:0x00 sav_pri:0x10 Misc: lockcount:0x00000000 ulock:0x00000000 *graphics:0x00000000 dispct:0x000000e4 fpuct:0x00000001 boosted:0x0000 userdata:0x00000000 Signal Information: cursig:0x00 *scp:0x00000000 pending:hi 0x00000000,lo 0x00000000 sigmask:hi 0x00000000,lo 0x00000000 Los campos en la salida del subcomando thread son los siguientes:


Página 52 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 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 00006003 00000000 00008004 000bde58: 00200000 00000012 0000000d 00000200 000bde68: 00080000 00000017 00078c93 00066320 000bde78: 00000ab2 00020000 00002870 > od 0xbde48 15 a 000bde48: 00002001 00006003 00000000 00008004 |.. ...`.........| 000bde58: 00200000 00000012 0000000d 00000200 |. ..............| 000bde68: 00080000 00000017 00078c93 00066320 |..............c | 000bde78: 00000ab2 00020000 00002870 |..........(p| 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


Página 53 de 283

Resource Name: SYSVMM 42000000 007fffff 80000000 fffffffa > 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 54 de 283

Offset Significa 0x14 Data Storage Interrupt Status Register (DSISR) 0x1C Dirección que falla 0x20 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 retorna-

do 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 interrupcio-nes 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 55 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-700-0cx. 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 <dump> <unix> > 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 56 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 implementation: 604 version: 604 width: 0x00000020 ncpus: 0x00000002 cache_attrib: 0x00000001 cach_cong: 0x00000000 icache_size: 0x00008000 dcache_size: 0x00008000 icache_asc: 0x00000004 dcache_asc: 0x00000004


Página 57 de 283

icache_block: 0x00000020 dcache_block: 0x00000020 icache_line: 0x00000020 dcache_line: 0x00000020 L2_cache_size: 0x00040000 L2_cache_asc: 0x00000001 itlb_size: 0x00000080 dtlb_size: 0x00000080 itlb_asc: 0x00000002 dtlb_asc: 0x00000002 tlb_attrib: 0x00000001 resv_size: 0x00000020 priv_lck_cnt: 0x00000000 prob_lck_cnt: 0x00000000 rtc_type: 0x00000002 virt_alias: 0x00000000 model_arch: 0x00000003 model_impl: 0x00000006 Xint: 0x00077359 Xfrac: 0x00004F28 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:00000000: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 TSLOT PID PSLOT STOPPED PROC_NAME 0 104d 16 d46 13 yes errdemon 1 1945 25 1740 23 yes 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 NAME 23 a 1740 c4e 1740 0 0 1 inetd FLAGS: swapped_in orphanpgrp execed Links: *child:0x00000000 *siblings:0xe3002100 *uidl:0xe3002100 *ganchor:0xe3002280 *pgrpl:0x00000000 *ttyl:0x00000000 Dispatch Fields: pevent:0x00000000 *synch:0xffffffff lock:0x00000000 lock_d:0x00000000 Thread Fields: *threadlist:0xe6001900 threadcount:1


Página 58 de 283

active:1 suspended:0 local:0 terminating:0 Scheduler Fields: nice: 20 repage:0x00000000 scount:0 sched_pri:0 *sched_next:0x00000000 *sched_back:0x00000000 cpticks:0 msgcnt:0 majfltsec:15 Misc: adspace:0x000071e7 kstackseg:0x00000000 xstat:0x0000 *p_ipc:0x00000000 *p_dblist:0x00000000 *p_dbnext:0x00000000 Signal Information: pending:hi 0x00000000,lo 0x00000000 sigcatch:hi 0x00000000,lo 0x00082001 sigignore:hi 0x7fffffff,lo 0xfff29efe Statistics: size:0x00000000(pages) audit:0x00000038 accounting page frames:37 page space blocks:0 pctcpu:10 minflt:1509 majflt:15 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 23 (fw) SAVED MACHINE STATE curid:0x00001428 m/q:0x00000000 iar:0x000357c8 cr:0x20442822 msr:0x00001030 lr:0x000357c8 xer:0x00000000 kjmpbuf:0x00000000 backtrack:0x00 tid:0x00000000 fpeu:0x01 excp_type:0x00000000 ctr:0x00000000 *prevmst:0x00000000 *stackfix:0x2ff3b1b0 intpri:0x00 o_iar:0x00000000 o_toc:0x00000000 o_arg1:0x00000000 excbranch:0x00000000 o_vaddr:0x00000000 msr flags: ME IR DR cr flags: | = | | > | > | = |< | = | = | Exception Struct 0x103c8cf8 0x4000d030 0x6000d12d 0x103c8cf8 0x00000107 MST Segment Regs 0:0x00000000 1:0x0000d00d 2:0x0000c16c 3:0x007fffff 4:0x007fffff 5:0x0000e00e 6:0x007fffff 7:0x0000b00b 8:0x00017017 9:0x00018018 10:0x00019019 11:0x007fffff 12:0x007fffff 13:0x60015015 14:0x00004004 15:0x007fffff alloc flags: 0xe5ef0000 (Seg Regs: 0, 1, 2, 5, 7, 8, 9, 10, 12, 13, 14, 15) General Purpose Regs 0:0x00000000 1:0x2ff3b1b0 2:0x00209df0 3:0x00000000 4:0x00000002 5:0x2ff3b400 6:0x00000000 7:0x00000000 8:0x00000000 9:0x00000000 10:0x2ff3b220 11:0x00000000 12:0x00001030 13:0x00000001 14:0x00000008 15:0x00000003 16:0x00000000 17:0x00000000 18:0x42228820 19:0x20000000 20:0x00000001 21:0x11000001 22:0x00000003 23:0x00000001 24:0x00000000 25:0x00000004 26:0x00000000 27:0xe600179c 28:0x2a222824 29:0xe3001e00 30:0xe6001700 31:0x00000010 Kernel stack address: 0x2ff3b400 SYSTEM CALL STATE error code:0x00 *kjmpbuf:0x00000000 PER-THREAD TIMER MANAGEMENT Real/Alarm Timer (ut_timer[TIMERID_ALRM]) = 0x0 Virtual Timer (ut_timer[TIMERID_VIRTUAL]) = 0x0 Prof Timer (ut_timer[TIMERID_PROF]) = 0x0 Posix Timer (ut_timer[POSIX0]) = 0x0


Página 59 de 283

Posix Timer (ut_timer[POSIX1]) = 0x0 Posix Timer (ut_timer[POSIX2]) = 0x0 Posix Timer (ut_timer[POSIX3]) = 0x0 Posix Timer (ut_timer[POSIX4]) = 0x0 SIGNAL MANAGEMENT *sigsp:0x0 oldmask:hi 0x0,lo 0x80000 code:0x0 MISCELLANOUS FIELDS: fstid:0x00000000 ioctlrv:0x00000000 selchn:0x00000000 link:0x00000000 loginfo:0x00000000 fselchn:0x500042a0 selbuc:0x00000000 sigssz:0x00000000 User msr:0x0000d030 *context:0x00000000 **errnopp:0x20232a1c *stkb:0x00000000 *audsvc:0x00000000 scsave[0]:0x2ff22c24 scsave[1]:0x2ff22a18 scsave[2]:0x2022a7c4 scsave[3]:0xf012fb88 scsave[4]:0x2ff229f8 scsave[5]:0x00000002 scsave[6]:0x20041270 scsave[7]:0x200419c8 USER AREA OF ASSOCIATED PROCESS fw (SLOT 20, PROCTAB 0xe3001e00) handy_lock:0x00000000 timer_lock:0x00000000 map:0x00000000 *semundo:0x00000000 *pinu_block:0x00000000 compatibility:0x00000000 lock:0x00000000 ulocks:0xffffffff *message:0x00000000 irss:0x0000000019b65bb8 lock_word:0xffffffff *vmm_lock_wait:0x00000000 vmmflags:0x00000000 SIGNAL MANAGEMENT Signals to be blocked (sig#:hi/lo mask,flags,&func) 1:hi 0x00000000,lo 0x00000000,0x00000008,0x20051fe0 2:hi 0x00000000,lo 0x00000000,0x00000008,0x20051fe0 3:hi 0x00000000,lo 0x00000000,0x00000008,0x20051fe0 4:hi 0x00000000,lo 0x00000000,0x00000008,0x20051fe0 5:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 6:hi 0x00000000,lo 0x00000000,0x00000008,0x20051fe0 7:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 8:hi 0x00000000,lo 0x00000000,0x00000008,0x20051fe0 9:hi 0x00000000,lo 0x00000000,0x00000048,0x00000000 10:hi 0x00000000,lo 0x00000000,0x00000008,0x20051fe0 11:hi 0x00000000,lo 0x00000000,0x00000008,0x20051fe0 12:hi 0x00000000,lo 0x00000000,0x00000008,0x20051fe0 13:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 14:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 15:hi 0x00000000,lo 0x00000000,0x00000008,0x20051fe0 16:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 17:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 18:hi 0x00000000,lo 0x00000000,0x00000000,0x00000001 19:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 20:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 21:hi 0x00000000,lo 0x00000000,0x00000000,0x00000001 22:hi 0x00000000,lo 0x00000000,0x00000000,0x00000001 23:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 24:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 25:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 26:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 27:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 28:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 29:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 30:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 31:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 32:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 33:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 34:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000


Página 60 de 283

35:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 36:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 37:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 38:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 39:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 40:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 41:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 42:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 43:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 44:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 45:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 46:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 47:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 48:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 49:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 50:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 51:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 52:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 53:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 54:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 55:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 56:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 57:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 58:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 59:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 60:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 61:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 62:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 63:hi 0x00000000,lo 0x00000000,0x00000000,0x00000000 USER INFORMATION euid:0x0000 egid:0x0000 ruid:0x0000 rgid:0x0000 luid:0x00000000 suid:0x00000000 ngrps:0x0000 *groups:0x2ff20ab8 compat:0x00000000 ref:0x00000002 pag:0x00000000 cr_lock:0x00000000 acctid:0x00000000 sgid:0x00000000 epriv:0xffffffff ipriv:0xffffffff bpriv:0xffffffff mpriv:0xffffffff u_info: ACCOUNTING DATA start:0x3893bd8e ticks:0x00001d38 acflag:0x0001 pr_base:0x00000000_00000000 pr_size:0x00000000 pr_off:0x00000000_00000000 pr_scale:0x00000000 process times: user:0x000003d5s 0x0c845880us sys:0x00000500s 0x1a39de00us children's times: user:0x00000000s 0x00000000us sys:0x00000000s 0x00000000us CONTROLLING TTY *ttysid:0x00000000 *ttyp(pgrp):0x00000000 ttyd(evice):0x00000000 ttympx:0x00000000 *ttys(tate):0x00000000 tty id: 0x00000000 *query function: 0x00000000 RESOURCE LIMITS AND COUNTERS ior:0x00000000_00000000 iow:0x00000000_00000000 ioch:0x00000000_00000005 text:0x00000000_00472cc0 data:0x00000000_00343000 stk:0x01000000 max data:0x08000000 max stk:0x01000000 max file(blks):0xffffffff *tstart:0x00000000_100001c8 sdsize:0x00000000 *datastart:0x00000000_20000000 *stkstart0x00000000_2ff23000


Página 61 de 283

soft core dump:0x7fffffff hard core dump:0x7fffffff soft rss:0x7fffffff hard rss:0x7fffffff cpu soft:0x7fffffff cpu hard:0x7fffffff hard ulimit:0x7fffffff minflt:0x00000000_00000000 majflt:0x00000000_00000000 AUDITING INFORMATION auditstatus:0x00000000 SEGMENT REGISTER INFORMATION ADSPACE SEGSTATE Reg Value Alloc # Segs Fno/Shmptr Flags 0 0x60000000 yes 0x0000 0x00000000 AVAILABLE 1 0x6000d12d yes 0x0001 0x00000000 TEXT 2 0x6000c16c yes 0x0000 0x00000000 AVAILABLE 3 0x007fffff 0x0000 0x00000000 AVAILABLE 4 0x007fffff 0x0000 0x00000000 AVAILABLE 5 0x007fffff 0x0000 0x00000000 AVAILABLE 6 0x007fffff 0x0000 0x00000000 AVAILABLE 7 0x007fffff 0x0000 0x00000000 AVAILABLE 8 0x007fffff 0x0000 0x00000000 AVAILABLE 9 0x007fffff 0x0000 0x00000000 AVAILABLE 10 0x007fffff 0x0000 0x00000000 AVAILABLE 11 0x007fffff 0x0000 0x00000000 AVAILABLE 12 0x007fffff 0x0000 0x00000000 AVAILABLE 13 0x60015015 yes 0x0001 0x00000000 TEXT 14 0x007fffff 0x0000 0x00000000 AVAILABLE 15 0x6000e16e yes 0x0001 0x00000000 WORKING FILE SYSTEM STATE *curdir:0x13ef49a0 *rootdir:0x00000000 cmask:0x0002 maxindex:0x0004 fd_lock:0x00000000 fso_lock:0x00000000 lockflag:0x00000000 fdevent:0xffffffff FILE DESCRIPTOR TABLE *ufd: 0x2ff3c1a0 fd 0: fp = 0x10000210 flags = 0x0080 count = 0x0000 fd 1: fp = 0x10000e70 flags = 0x0080 count = 0x0000 fd 2: fp = 0x100005d0 flags = 0x0080 count = 0x0000 fd 3: fp = 0x10001200 flags = 0x0080 count = 0x0001 Rest of user area paged out. 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


Página 62 de 283

q:0x00000000 qlen:0 qlimit:1000 head:0x00000000 timeo:0 error:0 oobmark:0 pgid:0 proc/fd: 23/4 fd 5: 702fe800: type:0x0001 (STREAM) opts:0x0006 (ACCEPTCONN|REUSEADDR) state:0x0080 (PRIV) linger:0x0000 pcb:0x702fea44 proto:0x04f33f90 q0:0x00000000 q0len:0 q:0x00000000 qlen:0 qlimit:1000 head:0x00000000 timeo:0 error:0 oobmark:0 pgid:0 proc/fd: 23/5 fd 6: 702fe400: type:0x0001 (STREAM) opts:0x0006 (ACCEPTCONN|REUSEADDR) state:0x0080 (PRIV) linger:0x0000 pcb:0x702fe644 proto:0x04f33f90 q0:0x00000000 q0len:0 q:0x00000000 qlen:0 qlimit:1000 head:0x00000000 timeo:0 error:0 oobmark:0 pgid:0 proc/fd: 23/6 fd 7: 702fe000: type:0x0001 (STREAM) opts:0x0006 (ACCEPTCONN|REUSEADDR) state:0x0080 (PRIV) linger:0x0000 pcb:0x702fe244 proto:0x04f33f90 q0:0x00000000 q0len:0 q:0x00000000 qlen:0 qlimit:1000 head:0x00000000 timeo:0 error:0 oobmark:0 pgid:0 proc/fd: 23/7 fd 8: 702d6c00: type:0x0001 (STREAM) opts:0x0006 (ACCEPTCONN|REUSEADDR) state:0x0080 (PRIV) linger:0x0000 pcb:0x702d6e44 proto:0x04f33f90 q0:0x00000000 q0len:0 q:0x00000000 qlen:0 qlimit:1000 head:0x00000000 timeo:0 error:0 oobmark:0 pgid:0 proc/fd: 23/8 fd 10: 7005d800: type:0x0002 (DGRAM) opts:0x0000 () state:0x0082 (ISCONNECTED|PRIV) linger:0x0000 pcb:0x7007e880 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/10 fd 11: 702c6000: type:0x0001 (STREAM) opts:0x0006 (ACCEPTCONN|REUSEADDR) state:0x0080 (PRIV) linger:0x0000 pcb:0x702c6244 proto:0x04f33f90 q0:0x00000000 q0len:0 q:0x00000000 qlen:0 qlimit:1000 head:0x00000000 timeo:0 error:0 oobmark:0 pgid:0 proc/fd: 23/11 fd 12: 70328c00: type:0x0001 (STREAM) opts:0x0006 (ACCEPTCONN|REUSEADDR) state:0x0080 (PRIV) linger:0x0000 pcb:0x70328e44 proto:0x04f33f90 q0:0x00000000 q0len:0 q:0x00000000 qlen:0 qlimit:1000 head:0x00000000 timeo:0 error:0 oobmark:0 pgid:0 proc/fd: 23/12 fd 13: 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 14: 70328800: type:0x0001 (STREAM) opts:0x0006 (ACCEPTCONN|REUSEADDR) state:0x0080 (PRIV) linger:0x0000 pcb:0x70328a44 proto:0x04f33f90 q0:0x00000000 q0len:0 q:0x00000000 qlen:0 qlimit:1000 head:0x00000000 timeo:0 error:0 oobmark:0 pgid:0 proc/fd: 23/14 fd 15: 70328400: type:0x0001 (STREAM) opts:0x0006 (ACCEPTCONN|REUSEADDR) state:0x0080 (PRIV) linger:0x0000 pcb:0x70328644 proto:0x04f33f90 q0:0x00000000 q0len:0 q:0x7000a000 qlen:1 qlimit:1000 head:0x00000000


Página 63 de 283

timeo:0 error:0 oobmark:0 pgid:0 proc/fd: 23/15 fd 16: 70328000: type:0x0001 (STREAM) opts:0x0006 (ACCEPTCONN|REUSEADDR) state:0x0080 (PRIV) linger:0x0000 pcb:0x70328244 proto:0x04f33f90 q0:0x00000000 q0len:0 q:0x00000000 qlen:0 qlimit:1000 head:0x00000000 timeo:0 error:0 oobmark:0 pgid:0 proc/fd: 23/16 fd 17: 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 proc/fd: 23/17 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: 0 snd: cc: 0 hiwat: 0 mbcnt: 0 mbmax: 0 lowat: 0 mb:0x00000000 events:0x 0 iodone:0x00000000 ioargs:0x00000000 flags:0x0000 () rcv: cc: 0 hiwat: 0 mbcnt: 0 mbmax: 0 lowat: 0 mb:0x00000000 events:0x 0 iodone:0x00000000 ioargs:0x00000000 flags:0x0000 () 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 64 de 283


Página 65 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 PSLOT STOPPED PROC_NAME 0 811 8 60c 6 yes gil 1 254d 37 2246 34 yes squid > cpu Selected cpu number : 0 > t -mk Skipping first MST MST STACK TRACE: 0xf0000000 (excpt=d1ae3000:40000000:00011011:d1ae3000:00000106) (intpri=3) IAR: .disable_lock+68 (0000906c): lwarx r7,r0,r4 LR: .[netinet:in_pcbnotify]+e8 (051aff38) 2ef62d88: .[netinet:ip_pmtu_stop]+164 (05193cac) 2ef62dd8: .[netinet:ip_pmtu_timeout]+324 (051939e4) 2ef62e28: .rn_walktree+ec (000af4c8) 2ef62e78: .[netinet:arptimer]+148 (0519200c) 2ef62ed8: .Netintr+12c (000c31fc) 2ef62f48: .netisr_thread+18 (000c3094) 2ef62f88: .threadentry+18 (000987d4) 2ef62fc8: .low+0 (00000000) > cpu 1 > t -mk Skipping first MST MST STACK TRACE: 0x2ff3b400 (excpt=40000000:42000000:0001a91f:40000000:00000106) (intpri=3) IAR: .disable_lock+68 (0000906c): lwarx r7,r0,r4 LR: .rtalloc_gr+2c (000c2e24 2ff3b170: .[netinet:in_pcbconnect_nolock]+26c (051b1128) 2ff3b1e0: .[netinet:in_pcbconnect]+44 (051b16c8) 2ff3b230: .[netinet:tcp_usrreq]+4c4 (051cf82c) 2ff3b2a0: .soconnect+228 (000d57dc) 2ff3b300: ._connect+2d0 (000d52c4) 2ff3b370: .connext+80 (000de808) 2ff3b3c0: .sys_call_ret+0 (00003a90) IAR not in kernel segment. > u - 8 --> GPR7: 0000254d > u - 37 --> GPR7: 00000811


Página 66 de 283

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: 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:00000000:00000000:00000000) (intpri=11) IAR: .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 = 00080000 psfreeblks = 0007fe32 > od thewall


Página 67 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 68 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 (dimensio-

namiento). • 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 69 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 70 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 única-mente 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 71 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 comparti-do. 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 72 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 73 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 almacena-miento 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 74 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 75 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 76 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 sobre-carga 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 incre-menta 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 77 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 mecanis-mos 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 disponibili-dad 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 requeri-mientos de espacio de la aplicación.


Página 78 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 compo-nentes 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ís-ticas 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 79 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 reposicio-nar 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 80 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 adapta-dores 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 considerable-mente porque los procesos de I/O son suspendidos hasta que los pbufs estén disponibles nueva-mente. 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 81 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 82 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 correcta-mente. 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 sobrecar-ga 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 83 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 84 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 1492 mtu_4 1492 mtu_16 1492 mtu_100 1492 remmtu 576 netaddr 10.3.2.164 state up arp on allcast on hwloop off netmask 255.255.255.0 security none authority broadcast netaddr6 alias6 prefixlen alias4 rfc1323 0 tcp_nodelay tcp_sendspace 16384 tcp_recvspace 16384 tcp_mssdflt 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.


Página 85 de 283

Dispositivo Velocidad Mbits

MTU tcp sendspace

tcp recvspace

sb_max Rfc1323

Ethernet 10 1500 16384 16384 32768 0Ethernet 100 1500 16384 16384 32768 0Ethernet 1000 1500 131072 65536 131072 0Ethernet 1000 9000 131072 65536 262144 0Ethernet 1000 9000 262144 131072 262144 1ATM 155 1500 16384 16384 131072 0ATM 155 9180 65536 65536 131072 1ATM 155 65527 655360 655360 1310720 1FDDI 100 4352 45056 45056 90012 0SPSW - 65520 262144 262144 1310720 1SPSW2 - 65520 262144 262144 1310720 1HiPPI - 65536 655360 655360 1310720 1HiPS - 65520 655360 655360 1310720 1ESCON - 4096 40960 40960 81920 0Token Ring 4 1492 16384 16384 32768 0Token Ring 16 1492 16384 16384 32768 0Token Ring 16 4096 40960 40960 81920 0Token Ring 16 8500 65536 65536 131072 0

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 depen-diendo 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 86 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 %usr %sys %wio %idle 08:20:00 0 0 0 100 08:40:00 0 0 0 100 09:00:00 0 0 0 100 Average 0 0 0 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 %usr %sys %wio %idle 09:14:58 54 18 28 0 09:14:59 0 2 40 0 09:15:00 44 19 38 0 09:15:01 82 14 4 0 09:15:02 66 16 18 0 09:15:03 45 12 43 0 09:15:04 60 17 23 0 09:15:05 47 16 37 0 09:15:06 65 12 23 0 09:15:07 48 8 44 0 Average 55 15 30 0

El comando sar -a reporta el uso de las rutinas del sistema para acceso a archivos, especifican-do 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 iget/s lookuppn/s dirblk/s 09:28:45 0 1169 277 09:28:46 0 15 0 09:28:47 0 50 0 09:28:48 0 559 19 09:28:49 0 390 20 09:28:50 0 1467 137 09:28:51 0 1775 153 09:28:52 0 2303 74 09:28:53 0 2832 50 09:28:54 0 883 44 Average 0 1144 77

El comando sar -c reporta llamadas del sistema (system calls).

# sar -c 1 10

AIX server2 3 4 000FA17D4C00 06/30/00

09:33:04 scall/s sread/s swrit/s fork/s exec/s rchar/s wchar/s 09:33:05 1050 279 118 0.00 0.00 911220 5376749 09:33:06 186 19 74 0.00 0.00 3272 3226417 09:33:07 221 19 79 0.00 0.00 3272 3277806


Página 87 de 283

09:33:08 2996 132 400 0.00 0.00 314800 2284933 09:33:09 3304 237 294 0.00 0.00 167733 848174 09:33:10 4186 282 391 0.00 0.00 228196 509414 09:33:11 1938 109 182 1.00 1.00 153703 1297872 09:33:12 3263 179 303 0.00 0.00 242048 1003364 09:33:13 751 172 258 0.00 0.00 155082 693801 09:33:14 2827 187 285 0.00 0.00 174059 1155239 Average 2273 162 238 0.10 0.10 235271 1966259

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 device %busy avque r+w/s blks/s avwait avserv 10:08:24 hdisk0 0 0.0 0 4 0.0 0.0

hdisk1 0 0.0 0 3 0.0 0.0 cd0 0 0.0 0 0 0.0 0.0

10:08:29 hdisk0 44 1.0 366 3569 0.0 0.0 hdisk1 36 0.0 47 2368 0.0 0.0 cd0 0 0.0 0 0 0.0 0.0

10:08:34 hdisk0 84 2.0 250 1752 0.0 0.0 hdisk1 16 1.0 19 950 0.0 0.0 cd0 0 0.0 0 0 0.0 0.0

Average hdisk0 42 1.0 205 1775 0.0 0.0

hdisk1 17 0.3 22 1107 0.0 0.0 cd0 0 0.0 0 0 0.0 0.0

El comando sar -q reporta estadística de colas.

# sar -q 1 10

AIX server2 3 4 000FA17D4C00 06/30/00

11:08:33 runq-sz %runocc swpq-sz %swpocc 11:08:34 1.0 100 11:08:35 1.0 100 11:08:36 1.0 100 11:08:37 1.0 100 11:08:38 1.0 100 1.0 100 11:08:39 1.0 100 1.0 100 11:08:40 1.0 100 1.0 100 11:08:41 1.0 100 11:08:42 1.0 100 11:08:43 1.0 100 Average 1.0 50 1.0 80

El comando sar -r reporta estadísticas de paginado. # sar -r 1 10 AIX server2 3 4 000FA17D4C00 06/30/00 11:16:11 slots cycle/s fault/s odio/s 11:16:12 130767 0.00 472.82 66.02 11:16:13 130767 0.00 989.00 800.00 11:16:14 130767 0.00 44.00 1052.00 11:16:15 130767 0.00 43.00 1040.00 11:16:16 130767 0.00 47.00 1080.00 11:16:17 130767 0.00 43.00 808.00 11:16:18 130767 0.00 40.00 860.00


Página 88 de 283

11:16:19 130767 0.00 46.00 836.00 11:16:20 130767 0.00 47.00 852.00 11:16:21 130767 0.00 48.00 836.00 Average 130767 0 183 821 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 06/30/00 11:12:39 proc-sz inod-sz file-sz thrd-sz 11:12:40 49/262144 229/42942 315/511 59/524288 11:12:41 46/262144 221/42942 303/511 56/524288 11:12:42 45/262144 220/42942 301/511 55/524288 11:12:43 45/262144 220/42942 301/511 55/524288 11:12:44 45/262144 220/42942 301/511 55/524288 El comando sar -y reporta la actividad por segundo de dispositivos TTY. # sar -y 1 10 AIX server2 3 4 000FA17D4C00 06/30/00 11:48:36 rawch/s canch/s outch/s rcvin/s xmtin/s mdmin/s 11:48:37 0 0 104 63 60 0 11:48:38 0 0 58 9 60 0 11:48:39 0 0 58 69 61 0 11:48:40 0 0 58 68 60 0 11:48:41 0 0 58 69 3 0 11:48:42 0 0 58 68 52 0 11:48:43 0 0 58 69 60 0 11:48:44 0 0 58 25 60 0 11:48:45 0 0 58 42 23 0 11:48:46 0 0 58 68 9 0 Average 0 0 63 55 45 0 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 06/30/00 11:48:56 rawch/s canch/s outch/s rcvin/s xmtin/s mdmin/s slots cycle/s fault/s odio/s 11:48:57 0 0 147 67 3 0 130767 0.00 3.96 0.00 11:48:58 0 0 102 69 58 0 130767 0.00 0.00 0.00 11:48:59 0 0 102 68 60 0 130767 0.00 0.00 0.00 11:49:00 0 0 102 69 17 0 130767 0.00 0.00 0.00 11:49:01 0 0 102 68 3 0 130767 0.00 1.00 4.00 Average 0 0 111 68 28 0

Average 130767 0 1 1


Página 89 de 283

4.2.1.2 Sumario del comando sar El comando sar escribe el contenido de contadores acumulativos de actividad del sistema opera-tivo 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 90 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/sadd, 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 91 de 283

r b avm fre re pi po fr sr cy in sy cs us sy id wa 0 0 15982 1388 0 0 0 8 22 0 113 281 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 0 0 0 8 22 0 113 281 36 1 0 98 1 0 0 15982 1387 0 0 0 0 0 0 108 4194 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 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.

- avm Páginas virtuales activas. Cuando un proceso se ejecuta necesita algo de memoria


Página 92 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 instala-da. 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 93 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 especifi-

cado 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 total address trans. faults 4832918 page ins 2989263 page outs 19 paging space page ins 7 paging space page outs 0 total reclaims 5417148 zero filled pages faults 12633 executable filled pages faults 15031850 pages examined by clock 118 revolutions of the clock hand 6086090 pages freed by the clock 105808 backtracks 0 lock misses 0 FREE frame waits 0 extend XPT waits 2025516 pending I/O waits 3031667 start I/Os 3031667 iodones 24786000 cpu context switches 77240518 device interrupts 0 software interrupts 0 traps 191650677 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 0 0 0 8 22 0 113 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 94 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 0 0 0 8 21 0 113 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 95 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 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 Valor C Tiempo de CPU utilizado recientemente por proceso.

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.

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 UID PID PPID C STIME TTY TIME CMD


Página 96 de 283

root 22656 27028 101 15:18:31 pts/11 7:43 ./tctestprog root 14718 24618 5 15:26:15 pts/17 0:00 ps -ef root 4170 1 3 Jun 15 - 12:00 /usr/sbin/syncd 60 root 21442 24618 2 15:26:15 pts/17 0:00 sort +3 -r 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 cpu ----- ----------- ------------------------ ------------- ----------- r b avm fre re pi po fr sr cy in sy cs us sy id wa 0 0 26468 51691 0 0 0 0 0 0 100 91 6 47 0 53 0 1 1 26468 51691 0 0 0 0 0 0 415 35918 237 26 2 71 0 1 1 26468 51691 0 0 0 0 0 0 405 70 26 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 UID PID PPID C STIME TTY TIME CMD root 18802 27028 120 15:40:28 pts/11 1:10 ./tctestprog root 9298 24618 3 15:41:38 pts/17 0:00 ps -ef root 15782 24618 2 15:41:38 pts/17 0:00 head -n 5 root 24618 26172 2 Jun 21 pts/17 0:03 ksh # ps -e |head -n 1 ; ps -e|egrep -v "TIME|0:"|sort +2b -3 -n -r|head -n 10 PID TTY TIME CMD 4170 - 12:01 syncd 4460 - 2:07 X 3398 - 1:48 dtsession 18802 pts/11 1:14 tctestprog 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 porten-taje 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 97 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 -r |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 7:11 ./tctestprog imnadm 12900 0.0 0.0 264 332 - A Jun 15 0:00 /usr/IMNSearch/ht root 0 0.0 5.0 12 15140 - A Jun 15 4:11 swapper root 1 0.0 0.0 692 764 - A Jun 15 0:28 /etc/init root 3398 0.0 1.0 1692 2032 - A Jun 15 1:48 /usr/dt/bin/dtses 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 Valor SIZE El tamaño virtual de la sección de datos del proceso en unidades

de 1 KB.

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

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 RSS LIM TSIZ TRS %CPU %MEM COMMAND 25298 pts/10 A 0:00 0 2924 12 32768 159 0 0.0 0.0 smitty 13160 lft0 A 0:00 17 368 72 32768 40 60 0.0 0.0 /usr/sbin 27028 pts/11 A 0:00 90 292 416 32768 198 232 0.0 1.0 ksh 24618 pts/17 A 0:04 318 292 408 32768 198 232 0.0 1.0 ksh b. La columna RSS


Página 98 de 283

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 RSS LIM TSIZ TRS %CPU %MEM COMMAND 21720 pts/1 A 0:00 1 288 568 32768 198 232 0.0 1.0 ksh 27028 pts/11 A 0:00 90 292 416 32768 198 232 0.0 1.0 ksh 24618 pts/17 A 0:04 318 292 408 32768 198 232 0.0 1.0 ksh 15698 pts/1 A 0:00 0 196 292 32768 52 60 0.0 0.0 ps av 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 PID %CPU %MEM SZ RSS TTY STAT STIME TIME COMMAND root 22750 0.0 21.0 20752 20812 pts/11 A 17:55:51 0:00 ./tctestprog2 root 21720 0.0 1.0 484 568 pts/1 A 17:16:14 0:00 ksh root 25298 0.0 0.0 3080 12 pts/10 A Jun 16 0:00 smitty root 27028 0.0 0.0 488 416 pts/11 A 14:53:27 0:00 ksh root 24618 0.0 0.0 488 408 pts/17 A Jun 21 0:04 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 TIME PGIN SIZE RSS LIM TSIZ TRS %CPU %MEM COMMAND 15674 pts/11 A 0:01 0 36108 6172 32768 5 24 0.6 24.0 ./tctestp 22742 pts/11 A 0:00 0 20748 20812 32768 5 24 0.0 14.0 ./backups 10256 pts/1 A 0:00 0 15628 15692 32768 5 24 0.0 11.0 ./tctestp 2064 - A 2:13 5 64 6448 xx 0 6392 0.0 4.0 kproc 1806 - A 0:20 0 16 6408 xx 0 6392 0.0 4.0 kproc 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 99 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 __<programa>.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ún-dos. 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 100 de 283

======= === === ===== ====== ==== ====== ===== wait 516 517 3237 3237 0 0 0 tctestprg 14746 13783 3207 1 3206 0 0 tctestprg 13730 17293 3195 0 3195 0 0 wait 1032 1033 3105 3105 0 0 wait 1290 1291 138 138 0 0 0 swapper 0 3 10 7 3 0 0 prof 14156 5443 6 3 3 0 0 trace 16000 14269 3 3 0 0 0 syncd 3158 4735 2 2 0 0 0 tprof 5236 16061 2 2 0 0 0 gil 2064 2839 1 1 0 0 0 gil 2064 3097 1 1 0 0 trace 15536 14847 1 1 0 0 0 sh 14002 16905 1 1 0 0 0 sleep 14002 16905 1 1 0 0 0 ======= === === ===== ====== ==== ====== ===== Total 12910 6503 6407 0 0 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 confir-mado con la salida de ps auxwww: # ps auxwww USER PID %CPU %MEM SZ RSS TTY STAT STIME TIME COMMAND root 14020 25.0 0.0 300 320 pts/1 A 15:23:55 16:45 ./tctestprg root 12280 25.0 0.0 300 320 pts/1 A 15:23:57 16:43 ./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 FREQ Total Kernel User Shared Other ======= === ===== ====== ==== ====== ===== wait 3 6480 6480 0 0 0 tctestprg 2 6402 1 6401 0 0 swapper 1 10 7 3 0 0 tprof 2 8 5 3 0 0 trace 2 4 4 0 0 0 gil 2 2 2 0 0 0 syncd 1 2 2 0 0 0 sh 1 1 1 0 0 0 sleep 1 1 1 0 0 0 ======= === ===== ====== ==== ====== ===== Total 15 12910 6503 6407 0 0 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 101 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 Total Kernel User Shared Other ======= === === ===== ====== ==== ====== ===== ./tctestprg 16276 16081 2156 0 2156 0 0 ======= === === ===== ====== ==== ====== ===== Total 2156 0 2156 0 0 La segunda sección es un reporte trivial de un solo proceso. Process FREQ Total Kernel User Shared Other ======= === ===== ====== ==== ====== ===== ./tctestprg 1 21 0 2156 0 0 ======= === ===== ====== ==== ====== ===== Total 1 2156 0 2156 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 % Source Address Bytes ============= ===== ==== ======== ======== ====== .main 1368 14.5 case.c 10000318 4c .casework 788 8.4 case.c 10000364 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 102 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 size inuse FREE pin virtual memory 131063 119922 11141 6807 15924 pg space 131072 305 work pers clnt pin 6816 0 0 in use 21791 98131 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 size inuse FREE pin virtual memory 131063 125037 6026 6811 15948 pg space 131072 305 work pers clnt pin 6820 0 0 in use 21950 103087 0 size inuse FREE pin virtual memory 131063 125847 5216 6811 15949 pg space 131072 305 work pers clnt pin 6820 0 0 in use 21954 103893 0 size inuse FREE pin virtual memory 131063 126769 4294 6811 15949 pg space 131072 305 work pers clnt pin 6820 0 0 in use 21954 104815 0 size inuse FREE pin virtual memory 131063 127890 3173 6811 15949 pg space 131072 305 work pers clnt pin 6820 0 0


Página 103 de 283

in use 21954 105936 0 size inuse FREE pin virtual memory 131063 129092 1971 6811 15949 pg space 131072 305 work pers clnt pin 6820 0 0 in use 21954 107138 0 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 Número de frames de memoria real (tamaño de la memoria real) - inuse Número de frames que contienen páginas - FREE Número de frames libres - pin Número de frames que contienen páginas pinned - virtual Número de páginas asignadas en el espacio virtual del sistema - stolen Número de frames tomados por el rmss y marcados como no utiliza-

bles por el VMM 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 Tamaño del espacio de paginado - inuse Número de páginas en uso en el espacio de paginado

pin Especifica estadísticas sobre el subconjunto de la memoria real que contiene

páginas pinned, incluyendo:

- work Número de frames que contienen páginas pinned de segmentos de trabajo

- pers Número de frames que contienen páginas pinned de segmentos per-sistentes

- clnt Número de frames que contienen páginas pinned de segmentos cli-ente

in use Especifica estadísticas sobre el subconjunto de la memoria real en uso, incluyendo:

- work Número de frames que contienen páginas de segmentos de trabajo - pers Número de frames que contienen páginas de segmentos persistentes - clnt 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:


Página 104 de 283

svmon -U [ lognm1...lognmN] [ -n | -s ] [ -w | -f | -c ] [ -t Número ] [ -u | -p | -g | -v ] [ -i Intervalo [ NumIntervalos]] [ -l ] [ -d ] [ -z ] [ -m ] 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 Esid Type Description Inuse Pin Pgsp Virtual Addr Range 0 0 work kernel seg 3792 1265 175 3511 0..32767 165475..65535 9352 - work 12 1 0 12 0..49746 220 - work 6 1 0 6 0..49746 7a0f - work 4 1 0 4 0..49746 502a - work 2 1 0 2 0..49746 ............................................................................... EXCLUSIVE segments Inuse Pin Pgsp Virtual 12551 58 0 3891 Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 7162 - pers /dev/lv00:17 6625 0 - - 0..100987 ... 2b65 - pers /dev/hd4:4294 0 0 - - 1369 - pers /dev/hd3:32 0 0 - - 1b63 1 pers code,/dev/hd2:4536 0 0 - - 0..21 5b4b 1 pers code,/dev/hd2:10545 0 0 - - 0..1 1b43 - pers /dev/hd2:32545 0 0 - - 0..0 e6ff - pers /dev/hd4:732 0 0 - - 3326 1 pers code,/dev/hd2:10553 0 0 - - 0..4 2ee6 - pers /dev/hd2:14469 0 0 - - ea9d - pers /dev/hd2:39225 0 0 - - 0..4 d67b - pers /dev/hd2:32715 0 0 - - 0..0 5668 - pers /dev/hd2:98694 0 0 - - 0..0 466a 1 pers code,/dev/hd2:98696 0 0 - - 0..4 d21a 1 pers code,/dev/hd2:10679 0 0 - - 0..1 a41 - pers /dev/hd2:32224 0 0 - - 0..1 aa15 1 pers code,/dev/hd2:10673 0 0 - - 0..0 f1fe - pers /dev/hd2:10310 0 0 - - 0..2 e9fd - pers /dev/hd2:10309 0 0 - - 0..14 c9f9 - pers /dev/hd2:32705 0 0 - - 0..3 b9f7 1 pers code,/dev/hd2:10734 0 0 - - 0..15 a1f4 1 pers code,/dev/hd2:10765 0 0 - - 0..10 3a07 1 pers code,/dev/hd2:10684 0 0 - - 0..7 2a05 1 pers code,/dev/hd2:10718 0 0 - - 0..170 59eb - pers /dev/hd2:32701 0 0 - - 0..9 e9bd 1 pers code,/dev/hd2:4123 0 0 - - 0..128 ... =============================================================================== User guest Inuse Pin Pgsp Virtual 0 0 0 0 =============================================================================== User nobody Inuse Pin Pgsp Virtual 0 0 0 0 =============================================================================== User lpd Inuse Pin Pgsp Virtual 0 0 0 0 =============================================================================== User nuucp Inuse Pin Pgsp Virtual 0 0 0 0 =============================================================================== User ipsec Inuse Pin Pgsp Virtual


Página 105 de 283

0 0 0 0 =============================================================================== User netinst Inuse Pin Pgsp Virtual 0 0 0 0

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 Esid Type Description Inuse Pin Pgsp Virtual Addr Range 0 0 work kernel seg 3792 1265 175 3511 0..32767 : 65475..65535 9352 - work 12 1 0 12 0..49746 220 - work 6 1 0 6 0..49746 7a0f - work 4 1 0 4 0..49746 502a - work 2 1 0 2 0..49746 ............................................................................... EXCLUSIVE segments Inuse Pin Pgsp Virtual 5024 53 0 3905 Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 1be3 2 work process private 580 8 0 579 0..675 : ... d9fb - pers /dev/hd9var:86 0 0 - - 0..0 c9f9 - pers /dev/hd2:32705 0 0 - - 0..3 a1f4 1 pers code,/dev/hd2:10765 0 0 - - 0..10 3a07 1 pers code,/dev/hd2:10684 0 0 - - 0..7 2a05 1 pers code,/dev/hd2:10718 0 0 - - 0..170 d9bb 1 pers code,/dev/hd2:4379 0 0 - - 0..20 c955 - pers /dev/hd3:33 0 0 - - 0..5 4168 - pers /dev/hd2:20485 0 0 - - 0..0 2965 - pers /dev/hd2:20486 0 0 - - 0..7 694d - pers /dev/hd9var:2079 0 0 - - 0..0 514a - pers /dev/hd9var:2078 0 0 - - 0..0 30a6 - pers /dev/hd9var:2048 0 0 - - 0..0 4088 - pers /dev/hd2:4098 0 0 - - 0..1 dbfb - pers /dev/hd3:21 0 0 - - ............................................................................... SHARED segments Inuse Pin Pgsp Virtual 2140 0 0 473 Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 8811 d work shared library text 2080 0 0 473 0..65535 e03c 1 pers code,/dev/hd2:4204 58 0 - - 0..58 2865 - pers /dev/hd2:32343 2 0 - - 0..1 Maximum memory allocated = 21473 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 106 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. Virtual Indica la cantidad de páginas asignadas en el espacio virtual del proceso. Después de mostrar los encabezamientos, el svmon muestra (si el flag -d es especificado) informa-ció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 Esid Type Description Inuse Pin Pgsp Virtual Addr Range 7162 - pers /dev/lv00:17 26650 0 - - 0..100362 0 0 work kernel seg 3790 1265 175 3509 0..32767 : 65475..65535 8811 d work shared library text 2030 0 0 540 0..65535 c373 - pers /dev/hd3:2061 134 0 - - 0..133 4823 2 work process private 48 1 0 48 0..47 : 65310..65535 2969 f work shared library data 22 0 0 17 0..749 cdb7 3 pers shmat/mmap,/dev/hd2: 16 0 - - 0..16 6d28 1 pers code,/dev/hd2:10334 7 0 - - 0..6 5920 - pers /dev/hd2:32166 1 0 - - 0..0 ----...

--------------------------------------------------------------------------

------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 3452 telnetd 6001 1266 175 4214 N N Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 0 0 work kernel seg 3790 1265 175 3509 0..32767 :


Página 107 de 283

65475..65535 8811 d work shared library text 2030 0 0 540 0..65535 3f24 2 work process private 106 1 0 106 0..96 : 65306..65535 fa3f f work shared library data 73 0 0 58 0..640 d67b - pers /dev/hd2:32715 1 0 - - 0..0 3406 3 work shmat/mmap 1 0 0 1 0..0 9c13 1 pers code,/dev/hd2:10763 0 0 - - 0..101 ------------------------------------------------------------------------------- ... ------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 6968 rtcmd 3794 1266 175 3513 N N Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 0 0 work kernel seg 3790 1265 175 3509 0..32767 : 65475..65535 6a0d 2 work process private 4 1 0 4 65314..65535 ------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 516 wait 3792 1266 175 3511 N N Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 0 0 work kernel seg 3790 1265 175 3509 0..32767 : 65475..65535 8010 2 work process private 2 1 0 2 65339..65535 ------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 0 3 1 0 3 N N Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 780f 2 work process private 3 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 Esid Type Description Inuse Pin Pgsp Virtual Addr Range 0 0 work kernel seg 3792 1265 175 3511 0..32767 : 65475..65535 1be3 2 work process private 580 8 0 579 0..675 : 65309..65535 8811 d work shared library text 2080 0 0 473 0..65535 f3fe f work shared library data 54 0 0 39 0..310 4c09 - work 32 0 0 32 0..32783 2be5 3 work shmat/mmap 4 2 0 4 0..32767 472b - work 2 0 0 2 0..32768 2647 - work 2 0 0 2 0..32768 e15c 1 pers code,/dev/hd2:18475 32 0 - - 0..706 4168 - pers /dev/hd2:20485 0 0 - - 0..0 2965 - pers /dev/hd2:20486 0 0 - - 0..7 694d - pers /dev/hd9var:2079 0 0 - - 0..0 514a - pers /dev/hd9var:2078 0 0 - - 0..0 9092 - pers /dev/hd4:2 1 0 - - 0..0 dbfb - pers /dev/hd3:21 0 0 - - ... Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 0 0 work kernel seg 3792 1265 175 3511 0..32767 : 65475..65535


Página 108 de 283

8811 d work shared library text 2080 0 0 473 0..65535 500a 2 work process private 122 1 0 122 0..122 : 65306..65535 20 f work shared library data 57 0 0 43 0..425 b156 - pers /dev/hd4:4286 1 0 - - 0..0 d81b 1 pers code,/dev/hd2:10393 9 0 - - 0..8 ------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 5682 sendmail: a 6081 1266 175 4136 N N Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 0 0 work kernel seg 3792 1265 175 3511 0..32767 : 65475..65535 8811 d work shared library text 2080 0 0 473 0..65535 51ea 2 work process private 107 1 0 106 0..103 : 65308..65535 29e5 f work shared library data 60 0 0 46 0..417 71ee 1 pers code,/dev/hd2:10755 38 0 - - 0..106 59eb - pers /dev/hd2:32701 4 0 - - 0..9 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 Esid Type Description Inuse Pin Pgsp Virtual Addr Range 7162 - pers /dev/lv00:17 7638 0 - - 0..100362 680d - work misc kernel tables 3819 0 0 3819 0..17054 : 63488..65535 0 - work kernel seg 3792 1265 175 3511 0..32767 : 65475..65535 82b0 - pers /dev/hd2:26992 2390 0 - - 0..2389


Página 109 de 283

8811 - work 2080 0 0 473 0..65535 ... 6be5 - pers /dev/hd2:153907 0 0 - - 0..2 67e6 - pers /dev/hd2:47135 0 0 - - 0..1 8fdc - pers /dev/hd2:22746 0 0 - - 0..0 7be1 - pers /dev/hd2:53296 0 0 - - 0..12 87de - pers /dev/hd2:69859 0 0 - - 0..0 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 Esid Type Description Inuse Pin Pgsp Virtual Addr Range 680d - work misc kernel tables 4197 0 0 4197 0..17064 : 63488..65535 0 - work kernel seg 3797 1270 175 3516 0..32767 : 65475..65535 700e - work kernel pinned heap 1919 624 0 1920 0..65535 37ad - work 770 1 0 770 0..764 : 65313..65535 a8a - work 770 1 0 770 0..927 : 65250..65535 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 Esid Type Description Inuse Pin Pgsp Virtual Addr Range 700e - work kernel pinned heap 1919 624 0 1920 0..65535 680d - work misc kernel tables 4197 0 0 4197 0..17064 : 63488..65535 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 obte-nerse 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 110 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 descrip-ció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 segmen-

to. (Sólo para segmentos de trabajo). El VMM maneja este valor con fines estadísticos. No puede ser actuali-zado. 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 asigna-

das. 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 Frame Pin 65471 313 Y 65535 311 N 0 314 Y 1 309 Y


Página 111 de 283

2 308 Y 3 305 Y 4 296 Y 5 299 Y 6 294 Y 7 297 Y 8 292 Y 9 295 Y 10 290 Y ... 381 81019 N 380 115074 N 379 80725 N 3335 57367 Y 3336 59860 Y 3337 107421 N 3338 114966 N 3339 107433 N 3341 95069 Y 3342 70192 Y 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 Mod 65471 313 Y Y Y 65535 311 N N Y 0 314 Y N Y 1 309 Y N Y 2 308 Y Y Y 3 305 Y Y Y 4 296 Y N Y 5 299 Y N Y 6 294 Y N Y 7 297 Y N Y 8 292 Y N Y 9 295 Y N Y 10 290 Y N Y ... 381 81019 N N Y 380 115074 N N Y 379 80725 N N Y 3335 57367 Y N Y 3336 59860 Y N Y 3337 107421 N N Y 3338 114966 N N Y 3339 107433 N N Y 3341 95069 Y N Y 3342 70192 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 112 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 encuen-tren 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 Número] [ -i Intervalo [ NúmIntervalos ] ] [ -d ] [ -l ] [ -z ] [ -m ] ] 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 Esid Type Description Inuse Pin Pgsp Virtual Addr Range 0 0 work kernel seg 3798 1270 175 3517 0..32767 : 65475..65535 ............................................................................... EXCLUSIVE segments Inuse Pin Pgsp Virtual 36189 1 0 148 Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 985e - pers /dev/lv00:17 35977 0 - - 0..40307 322a 2 work process private 112 1 0 109 0..83 : 65257..65535 22c f work shared library data 53 0 0 39 0..849 64e 1 pers code,/dev/hd2:4550 44 0 - - 0..57 1c88 - pers /dev/hd2:32628 3 0 - - 0..2 ............................................................................... SHARED segments Inuse Pin Pgsp Virtual 2117 0 0 301 Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 8811 d work shared library text 2117 0 0 301 0..65535 =============================================================================== 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:


Página 113 de 283

# svmon -C ftp -d =============================================================================== Command ftp Inuse Pin Pgsp Virtual 46435 1266 175 3966 ------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 2728 ftp 46435 1266 175 3966 N N ............................................................................... SYSTEM segments Inuse Pin Pgsp Virtual 3798 1265 175 3517 Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 0 0 work kernel seg 3798 1265 175 3517 0..32767 : 65475..65535 ............................................................................... EXCLUSIVE segments Inuse Pin Pgsp Virtual 40520 1 0 148 Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 985e - pers /dev/lv00:17 40308 0 - - 0..40307 322a 2 work process private 112 1 0 109 0..83 : 65257..65535 22c f work shared library data 53 0 0 39 0..849 64e 1 pers code,/dev/hd2:4550 44 0 - - 0..57 1c88 - pers /dev/hd2:32628 3 0 - - 0..2 ............................................................................... SHARED segments Inuse Pin Pgsp Virtual 2117 0 0 301 Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 8811 d work shared library text 2117 0 0 301 0..65535

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. Des-

pué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 114 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 Esid Type Description Inuse Pin Pgsp Virtual 6784 - work 27989 0 0 28017 1aa18 - work 21887 0 0 21887 14356 - pers /dev/lv_wlm1:17 1250 0 - - 173f5 - pers /dev/lv_wlm2:17 1250 0 - - 5347 - work 103 2 0 101 c34e - work 77 0 0 77 1891a - work 77 0 0 77 14636 - work 46 0 0 37 5327 - work 28 0 0 20 1d83f - work 16 0 0 18 1e33c - work 16 0 0 13 10772 - work 15 0 0 13 6a84 - work 15 0 0 13 15457 - work 14 0 0 14 38a1 - work 8 0 0 8 126f0 - work 8 0 0 8 11313 - pers /dev/hd1:26 6 0 - - e50c - work 5 2 0 5 b549 - work 5 2 0 5 12e3 - work 3 2 0 3 13351 - work 3 0 0 3 14a16 - work 3 0 0 0 12970 - work 3 0 0 5 6904 - work 2 2 0 2 a9c8 - work 1 0 0 3 2320 - pers /dev/hd1:32 1 0 - - 1d39f - pers /dev/hd2:16870 1 0 - - 834a - pers /dev/hd1:23 1 0 - - 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 115 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 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.


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 5.0 |# | User 49.7 |############## | Wait 16.1 |##### | Idle 29.0 |######## | La siguiente sección muestra estadísticas de las interfases de red: Interf KBPS I-Pack O-Pack KB-In KB-Out tr0 1.0 3.3 2.3 0.1 0.9 en0 0.0 0.1 0.0 0.0 0.0 La siguiente es la subsección de estadísticas de discos físicos: Disk Busy% KBPS TPS KB-Read KB-Writ hdisk0 0.0 0.0 0.0 0.0 0.0 hdisk1 0.0 0.0 0.0 0.0 0.0 hdisk2 0.0 0.0 0.0 0.0 0.0 hdisk3 0.0 4056.6 96.9 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% PgSp: 0.0mb root tctestprg(13888)100.0% PgSp: 0.0mb root topas (16022) 0.5% PgSp: 0.4mb root cp (18112) 0.0% PgSp: 0.1mb root cp (15558) 0.0% PgSp: 0.1mb root cp (13662) 0.0% PgSp: 0.1mb 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


Página 117 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 especifi-

cado 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 ejem-plo 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 arqui-tectura por defecto para compilar en AIX Versión 4 es la arquitectura común. Sin embargo, la arqui-tectura 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 118 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ún-da columna es la cantidad de instrucciones emuladas durante el intervalo especificado. Las emula-ciones 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 funcio-nales, como se ve en la siguiente figura:


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 proble-mas 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 Descripción -d 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.

-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 CD-ROM), 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áme-tro 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

Página 119 de 283


Página 120 de 283

tty: tin tout avg-cpu: % user % sys % idle % iowait 0.0 41.4 61.1 0.1 38.9 0.0 Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk3 0.0 0.3 0.0 258032 224266 hdisk2 0.1 1.1 0.0 258088 1658678 hdisk0 0.0 0.9 0.1 746152 725871 hdisk1 0.1 1.5 0.0 974788 1660027 cd0 0.0 0.0 0.0 0 0 hdisk4 0.0 0.2 0.0 323080 40480 tty: tin tout avg-cpu: % user % sys % idle % iowait 0.0 603.5 91.5 8.5 0.0 0.0 Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk3 16.0 2809.0 117.7 2816 0 hdisk2 16.0 2868.8 122.7 2876 0 hdisk0 91.8 8419.0 263.3 0 8440 hdisk1 21.9 2820.9 117.7 2828 0 cd0 0.0 0.0 0.0 0 0 hdisk4 0.0 0.0 0.0 0 0 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 CD-ROM. 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 tout avg-cpu: % user % sys % idle % iowait 0.0 41.5 61.2 0.1 38.8 0.0 " Disk history since boot not available. " 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:


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 Muestra el porcentaje de utilización de CPU a nivel sistema (kernel). . % idle Muestra el porcentaje de tiempo idle (durante el cual el sistema no espera un

requerimiento de I/O). % iowait Muestra el porcentaje de tiempo idle durante el cual el sistema se encuentra espe-

rando 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


Página 122 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: tin tout avg-cpu: % user % sys % idle % iowait 0.0 223.5 0.2 4.2 70.0 25.5 Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk3 2.7 163.2 20.4 1632 0 hdisk2 2.8 170.8 21.9 1708 0 hdisk0 0.0 0.0 0.0 0 0 hdisk1 2.1 175.6 17.3 1756 0 cd0 0.0 0.0 0.0 0 0 hdisk4 99.1 715.6 125.0 0 7156 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 pagi-nado, 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 nece-saria. 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 123 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 124 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 herra-mientas 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 125 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 VOLUME GROUP: stripevg LV IDENTIFIER: 000bc6fd1202118f.3 PERMISSION: read/write VG STATE: active/complete LV STATE: closed/syncd TYPE: jfs WRITE VERIFY: on MAX LPs: 512 PP SIZE: 16 megabyte(s) COPIES: 2 SCHED POLICY: parallel LPs: 120 PPs: 240 STALE PPs: 0 BB POLICY: relocatable INTER-POLICY: maximum RELOCATABLE: yes INTRA-POLICY: inner middle UPPER BOUND: 32 MOUNT POINT: /u/mirrfs LABEL: None 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 particio-nes 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 procesa-miento de I/O normal. Para cada escritura a un volumen lógico, el LVM genera un requerimiento de escritura para cada copia espejada. La consis-tencia 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 126 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 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.

Parallel 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:


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 archi-vos 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 espeja-do 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 coman-do lslv:

Página 127 de 283


Página 128 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 operacio-nes 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 coman-do lslv, como se ve en el siguiente ejemplo: # lslv -l mirrlv mirrlv:/u/mirrfs PV COPIES IN BAND DISTRIBUTION hdisk2 120:000:000 90% 000:000:000:108:012 hdisk1 120:000:000 69% 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 asigna-ció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 1-10 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 11-20 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 21-30 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 31-40 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 41-50 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 51-60 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 61-70 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 71-80 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 81-90 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 91-100 FREE FREE FREE FREE FREE FREE FREE FREE USED 101-109


Página 129 de 283

USED USED USED USED USED USED USED USED USED USED 110-119 USED USED USED USED USED USED USED USED USED USED 120-129 USED USED USED USED USED USED USED USED USED USED 130-139 USED USED USED USED USED USED USED USED USED USED 140-149 USED USED USED USED USED USED USED USED USED USED 150-159 USED USED USED USED USED USED USED USED USED USED 160-169 USED USED USED USED USED USED USED USED USED USED 170-179 USED USED USED USED USED USED USED USED USED USED 180-189 USED USED USED USED USED USED USED USED USED USED 190-199 USED USED USED USED USED USED USED USED USED USED 200-209 USED USED USED USED USED USED USED USED 210-217 USED USED USED USED USED USED USED USED USED USED 218-227 USED USED USED USED USED USED USED USED USED USED 228-237 USED USED USED USED USED USED FREE FREE FREE FREE 238-247 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 248-257 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 258-267 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 268-277 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 278-287 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 288-297 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 298-307 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 308-317 FREE FREE FREE FREE FREE FREE FREE FREE 318-325 USED USED USED USED USED USED USED USED USED USED 326-335 USED USED USED USED USED USED USED USED USED USED 336-345 USED USED USED USED USED 0001 0002 0003 0004 0005 346-355 0006 0007 0008 0009 0010 0011 0012 0013 0014 0015 356-365 0016 0017 0018 0019 0020 0021 0022 0023 0024 0025 366-375 0026 0027 0028 0029 0030 0031 0032 0033 0034 0035 376-385 0036 0037 0038 0039 0040 0041 0042 0043 0044 0045 386-395 0046 0047 0048 0049 0050 0051 0052 0053 0054 0055 396-405 0056 0057 0058 0059 0060 0061 0062 0063 0064 0065 406-415 0066 0067 0068 0069 0070 0071 0072 0073 0074 0075 416-425 0076 0077 0078 0079 0080 0081 0082 0083 426-433 0084 0085 0086 0087 0088 0089 0090 0091 0092 0093 434-443 0094 0095 0096 0097 0098 0099 0100 0101 0102 0103 444-453 0104 0105 0106 0107 0108 0109 0110 0111 0112 0113 454-463 0114 0115 0116 0117 0118 0119 0120 FREE FREE FREE 464-473 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 474-483 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 484-493 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 494-503 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 504-513 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 514-523 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 524-533 FREE FREE FREE FREE FREE FREE FREE FREE FREE 534-542

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 130 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 realizar-se 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 respecti-vos a la utilización de file systems:


Página 131 de 283

Archivo lógico Las operaciones de monitoreo incluyen todas las lecturas, escritu-

ras, 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 esta-

dí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ís-ticas 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 archi-vo especificado. Para especificar los niveles de información recolectados en todas las capas, o en capas específi-cas, 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 132 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 repor-te 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 Nivel archivo lógico lv Nivel volumen lógico pv Nivel volumen físico vm 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 inode: 17 opens: 2 total bytes xfrd: 2097152 reads: 2048 (0 errs) read sizes (bytes): avg 512.0 min 512 max 512 sdev 0.0 read times (msec): avg 0.003 min 0.000 max 0.084 sdev 0.005 writes: 2048 (0 errs) write sizes (bytes): avg 512.0 min 512 max 512 sdev 0.0 write times (msec): avg 0.028 min 0.012 max 0.443 sdev 0.044 lseeks: 1 FILE: /dev/zero opens: 1 total bytes xfrd: 1048576


Página 133 de 283

reads: 2048 (0 errs) read sizes (bytes): avg 512.0 min 512 max 512 sdev 0.0 read times (msec): avg 0.007 min 0.006 max 0.076 sdev 0.003 FILE: /dev/null opens: 1 total bytes xfrd: 1048576 writes: 2048 (0 errs) write sizes (bytes): avg 512.0 min 512 max 512 sdev 0.0 write times (msec): avg 0.001 min 0.000 max 0.023 sdev 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 medi-

ción. #rds Número de llamadas del sistema para lectura realizadas contra este archi-

vo. #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 134 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 lectu-ra/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 Detalla-das de Volumen Lógico). El siguiente es un ejemplo de un reporte a nivel volumen lógico: # filemon -o /tmp/filemonLF.out -O lv Este es un extracto del reporte: ...


Página 135 de 283

Most Active Logical Volumes ------------------------------------------------------------------------ util #rblk #wblk KB/s volume description ------------------------------------------------------------------------ 0.07 0 2016 64.5 /dev/mirrlv /u/mirrfs 0.00 0 8 0.3 /dev/loglv00 jfslog 0.00 8 0 0.3 /dev/hd2 /usr ... util Utilización del volumen (fracciones de tiempo ocupado). Las líneas están ordena-

das 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 Detalla-das 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 ordena-

das 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 136 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 (Seg-mentos Más Activos) y el reporte Detailed VM Segment Stats (Estadísticas Detalladas de Segmen-tos 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 137 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 maneja-dos 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 consi-derar 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 138 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 8 frags 32768 Bytes, 0.5% 0075322-0075773 452 frags 1851392 Bytes, 29.4% 0149584-0150147 564 frags 2310144 Bytes, 36.7% 0077002-0077513 512 frags 2097152 Bytes, 33.3% 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 gene-ral 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 especi-

ficarse 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 139 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 indirec-tos 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) Logical Fragment ---------------------------------- ---------------- 0320104-0320111 hdisk1 8 frags 32768 Bytes, 6.5% 0004168-0004175 0319242-0319305 hdisk1 64 frags 262144 Bytes, 51.6% 0003306-0003369 0319310-0319361 hdisk1 52 frags 212992 Bytes, 41.9% 0003374-0003425 Physical Addresses (mirror copy 2) Logical Fragment ---------------------------------- ---------------- 0320104-0320111 hdisk2 8 frags 32768 Bytes, 6.5% 0004168-0004175 0319242-0319305 hdisk2 64 frags 262144 Bytes, 51.6% 0003306-0003369 0319310-0319361 hdisk2 52 frags 212992 Bytes, 41.9% 0003374-0003425

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 140 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, 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 che-queo 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 141 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, SCSI-

2, 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 archi-

vos. • Revisar la fragmentación de archivos. Determinar si los archivos más utilizados están muy frag-

mentados. 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 142 de 283

iostat El comando iostat agrega poca carga al sistema. Utiliza cerca de 20 milisegun-dos 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


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


Página 144 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 encabe-

zamiento 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áme-tros 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 0x1000100 Bus I/O address False busintr 15 Bus interrupt level False intr_priority 3 Interrupt priority False tx_que_size 64 TRANSMIT queue size True

rx_que_size 32 RECEIVE queue size True full_duplex no Full duplex True use_alt_addr no Enable ALTERNATE ETHERNET address True alt_addr 0x000000000000 ALTERNATE ETHERNET address True Para cambiar parámetros como el tamaño de cola, realice el siguiente procedimiento. Desconecte la interfase:


Página 145 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: Receive Statistics: -------------------- ------------------- Packets: 19 Packets: 0 Bytes: 1140 Bytes: 0 Interrupts: 0 Interrupts: 0 Transmit Errors: 0 Receive Errors: 0 Packets Dropped: 0 Packets Dropped: 0 Bad Packets: 0 Max Packets on S/W Transmit Queue: 1 S/W Transmit Queue Overflow: 0 Current S/W+H/W Transmit Queue Length: 0 Broadcast Packets: 19 Broadcast Packets: 0 Multicast Packets: 0 Multicast Packets: 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 146 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 facili-dad 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 siste-mas 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 147 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 avm fre re pi po fr sr cy in sy cs us sy id wa 0 1 19331 824 0 0 0 0 0 0 636 1955 674 0 0 99 0 0 1 19803 996 0 0 0 0 0 0 533 7466 591 0 0 99 0 0 1 19974 860 0 0 0 0 0 0 822 4055 892 0 0 99 0 0 1 19815 860 0 0 0 0 0 0 535 4096 509 0 0 99 0 0 1 19816 855 0 0 0 0 0 0 577 4582 598 0 0 99 0 0 1 19816 737 0 0 0 0 0 0 602 2720 672 0 0 99 0 0 1 19895 724 0 0 0 0 0 0 616 3842 698 0 0 99 0 0 1 17147 724 0 0 0 0 0 0 649 6427 626 0 0 99 0 0 1 17065 720 0 0 0 0 0 0 516 3629 543 0 0 99 0 0 1 17163 720 0 0 0 0 0 0 614 9030 688 0 0 99 0 0 1 17343 720 0 0 0 0 0 0 420 8777 487 0 0 99 0 0 1 17579 712 0 0 0 0 0 0 466 2182 473 0 0 99 0 0 1 17647 712 0 0 0 0 0 0 497 3298 310 0 0 99 0 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 148 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 149 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 calls failed free hiwat freed 32 97 102 0 31 640 0 64 124 805 0 68 320 0 128 111 923 0 17 160 0 256 152 41806 0 24 384 0 512 32 231 0 16 40 0 1024 1 158 0 19 20 2 2048 1 716 0 1 10 0 4096 2 14 0 7 120 0 8192 2 133 0 2 10 0 16384 1 1 0 12 24 7 By typ inuse calls failed memuse memmax mapb mbuf 16 41218 0 4096 19712 0

e

mcluster 0 764 0 0 8192 0 socket 111 862 0 18048 18688 0 pcb 80 495 0 12480 12992 0 routetbl 8 15 0 1312 2080 0 ifaddr 7 7 0 832 832 0 mblk 66 435 0 15104 15488 0 mblkdata 2 294 0 16384 35840 0 strhead 11 48 0 3232 4256 0 strqueue 18 112 0 9216 11776 0 strmodsw 20 20 0 1280 1280 0 strosr 0 20 0 0 256 0 strsyncq 25 326 0 2688 3392 0 streams 137 245 0 14976 16256 0 devbuf 1 1 0 256 256 0 kernel table 14 15 0 45920 46432 0 temp 8 13 0 7424 15744 0 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 150 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 inter-fases y la cantidad de errores de I/O: # netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll lo0 16896 link#1 282515 0 283832 0 0 lo0 16896 127 localhost.austin. 282515 0 283832 0 0 lo0 16896 ::1 282515 0 283832 0 0 en0 1500 link#2 8.0.5a.fc.d2.e1 49995 0 27187 3929 0 en0 1500 10.47 server4_ 49995 0 27187 3929 0 tr0 1492 link#3 0.4.ac.61.73.f7 730283 0 317239 722 0 tr0 1492 9.3.240 server4f 730283 0 317239 722 0 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 Monitorea la utilización de CPU por todos los threads y los contro-

ladores de interrupciones. Estima cuánto de este uso es debido a tareas relacionadas con la red.

Network Device-Driver I/O 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.

Internet Socket Calls 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 151 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 25054 0.0026 0.044 0.044 ksh 5872 0.0010 0.016 0.000 dtterm 17910 0.0009 0.014 0.000 netpmon 22732 0.0007 0.012 0.000 trace 28206 0.0006 0.010 0.000 swapper 0 0.0005 0.008 0.000 xterm 21984 0.0004 0.007 0.001 X 4212 0.0003 0.005 0.000 trcstop 11070 0.0002 0.004 0.000 java 17448 0.0002 0.003 0.000 init 1 0.0001 0.002 0.000 dtwm 10160 0.0001 0.002 0.000 ot 27694 0.0001 0.001 0.000 ----------------------------------------------------------------- Total (all processes) 5.9933 99.767 0.045 Idle time 0.0000 0.000 = = = ============================================= /esta salida ha sido abreviada/ ====== ====== ===== =======

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 <mss 1452> [tos 0x10]


Página 152 de 283

9.3.240.58.23 > 9.3.240.59.44183: S 1272672076:1272672076(0) ack 1589597024 win 15972 <mss 1452> 9.3.240.59.44183 > 9.3.240.58.23: . ack 1 win 15972 [tos 0x10] 9.3.240.59.44183 > 9.3.240.58.23: . ack 1 win 15972 [tos 0x10] 9.3.240.59.44183 > 9.3.240.58.23: P 1:16(15) ack 1 win 15972 [tos 0x10] 9.3.240.59.44183 > 9.3.240.58.23: P 1:16(15) ack 1 win 15972 [tos 0x10] 9.3.240.59.44183 > 9.3.240.58.23: . ack 6 win 15972 [tos 0x10] 9.3.240.59.44183 > 9.3.240.58.23: . ack 6 win 15972 [tos 0x10] 9.3.240.58.23 > 9.3.240.59.44183: P 6:27(21) ack 1 win 15972 (DF) 9.3.240.59.44183 > 9.3.240.58.23: P 1:27(26) ack 27 win 15972 [tos 0x10] 9.3.240.59.44183 > 9.3.240.58.23: P 1:27(26) ack 27 win 15972 [tos 0x10] 9.3.240.58.23 > 9.3.240.59.44183: P 27:81(54) ack 27 win 15972 (DF) 9.3.240.59.44183 > 9.3.240.58.23: P 27:30(3) ack 81 win 15972 [tos 0x10] 9.3.240.59.44183 > 9.3.240.58.23: P 27:30(3) ack 81 win 15972 [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.com 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 153 de 283

UDP: <source port=49572, <destination port=53(domain) > 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: <source port=53(domain), <destination port=49572 > 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 AUTHORITY RECORDS: -> prokom.plnameserver = phobos.prokom.pl -> prokom.plnameserver = alfa.nask.gda.pl -> prokom.plnameserver = amber.prokom.pl ADDITIONAL RECORDS: -> phobos.prokom.plinternet address = 195.164.165.56 -> alfa.nask.gda.plinternet address = 193.59.200.187 -> amber.prokom.plinternet address = 153.19.177.200 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 extendednetstats = 1 thewall = 18420 sockthresh = 85 sb_max = 1048576 somaxconn = 1024 ..... lowthresh = 90 medthresh = 95 psecache = 1


Página 154 de 283

subnetsarelocal = 1 maxttl = 255 ipfragttl = 60 ipsendredirects = 1 ipforwarding = 1 udp_ttl = 30 tcp_ttl = 60 arpt_killc = 20 tcp_sendspace = 16384 tcp_recvspace = 16384 udp_sendspace = 9216 udp_recvspace = 41920 ..... Para cambiar el valor del parámetro thewall, de 18420 a 36840, utilice el comando no de la siguien-te 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 Maximum IP Packet Size for This Device True remmtu 576 Maximum IP Packet Size for REMOTE Networks True netaddr 10.47.1.6 Internet Address True state up Current Interface Status True arp on Address Resolution Protocol (ARP) True netmask 255.255.0.0 Subnet Mask True security none Security Level True authority Authorized Users True broadcast Broadcast Address True netaddr6 N/A True alias6 N/A True prefixlen N/A True alias4 N/A True rfc1323 N/A True tcp_nodelay N/A True tcp_sendspace N/A True tcp_recvspace N/A True tcp_mssdflt N/A True 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 155 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 /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 utiliza-do 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 0 socket buffer overflows

datagrams dropped due to no socket

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 156 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 razona-ble 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 nfs_setattr_error= 0 nfs_gather_threshold= 4096 nfs_repeat_messages= 0 nfs_udp_duplicate_cache_size= 0 nfs_tcp_duplicate_cache_size= 5000 nfs_server_base_priority= 0 nfs_dynamic_retrans= 1 nfs_iopace_pages= 0 nfs_max_connections= 0 nfs_max_threads= 8 nfs_use_reserved_ports= 0 nfs_device_specific_bufs= 1 nfs_server_clread= 1 nfs_rfc1323= 0 nfs_max_write_size= 0 nfs_max_read_size= 0 nfs_allow_all_signals= 0 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 157 de 283

El cliente NFS concentra sus problemas generalmente en la cantidad de daemons biod que utili-zan. 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 concurren-te. 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 disminuir-se. 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 espe-cializados. 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 compatibili-dad 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 158 de 283

# mount -o proto=udp,vers=2,soft,retry=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 159 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 160 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 implementa-ció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.


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 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ásca-ra 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 de-fecto 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 usage). Uno de los dos cálculos usados en la definición del Recent CPU usage es: Uso Reciente de CPU = Anterior Uso Reciente de CPU + 1

Página 161 de 283


Página 162 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 –f UID PID PPID C STIME TTY TIME CMD root 12948 12796 0 14:27:07 pts/1 0:00 ksh root 13888 12948 111 10:08:34 pts/1 94:21 ./tctestprg root 15432 12948 4 11:42:56 pts/1 0:00 ps -f root 15752 12948 110 10:08:34 pts/1 94:21 ./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 pro-cesos 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 163 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últi-ples. 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:


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 ejecu-ció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 instan-cia 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


Página 165 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 THRASH SUSP FORK SCHED -h -p -m -w -e -f -d -r -t -s SYS PROC MULTI WAIT GRACE TICKS SCHED_D SCHED_R TIMESLICE MAXSPIN 0 4 2 1 2 10 16 16 1 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.


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


Página 167 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 modifi-cados 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 dife-rencias 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 normal-mente 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 thomasc F S UID PID PPID C PRI NI ADDR SZ TTY TIME CMD 200001 A 15610 5204 15476 3 61 20 a655 344 pts/1 0:00 ps 200001 A 15610 15476 12948 1 60 20 5029 488 pts/1 0:00 ksh 200001 A 15610 15818 15476 120 126 24 408b 44 pts/1 0:25 tctest 200001 A 15610 16792 15476 120 126 24 e89e 44 pts/1 0:18 tctest 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 168 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 comprendi-do 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 SZ TTY TIME CMD 200001 A 15610 14740 15490 90 126 39 5888 44 pts/3 0:58 tctestprg 240001 A 15610 15818 1 90 118 24 408b 44 pts/1 51:02 tctestprg 240001 A 15610 16792 1 89 118 24 e89e 44 pts/1 50:55 tctestprg 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 84 9 c0bb 44 pts/1 0:03 tctestprg 240001 A 15610 16792 1 92 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 SZ TTY TIME CMD 200001 A 15610 14740 15490 94 126 39 5888 44 pts/3 17:13 tctestprg 240001 A 15610 15818 1 94 120 24 408b 44 pts/1 67:17 tctestprg 200001 A 0 16304 12948 86 76 4 c0bb 44 pts/1 12:37 tctestprg 240001 A 15610 16792 1 94 120 24 e89e 44 pts/1 67:10 tctestprg El PID es utilizado para identificar qué programa (o más correctamente qué thread) debe ser manipulado.


Página 169 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 contro-lan.

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 procesa-dor a utilizar. Si el NumDeProcesador es omitido, el proceso es asignado a un procesador seleccio-nado 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 THREAD USER PID PPID TID ST CP PRI SC F TT BND COMMAND root 12948 12796 - A 0 60 1 240001 pts/1 - ksh - - - 7283 S 0 60 1 400 - - - root 13704 12948 - A 3 61 1 200001 pts/1 - ps -mo THREAD - - - 19391 R 3 61 1 0 - - - thomasc 15818 1 - A 79 112 0 240001 pts/1 - ./tprof/tctestprg - - - 16077 R 79 112 0 0 - - - root 16304 12948 - A 77 72 0 200001 pts/1 - ./tprof/tctestprg - - - 17843 R 77 72 0 0 - - -


Página 170 de 283

thomasc 16792 1 - A 79 112 0 240001 pts/1 2 ./tprof/tctestprg - - - 16357 R 79 112 0 0 - 2 - 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 maxperm=79.4% of real memory maximum pinable=80.0% of real memory minperm=19.8% of real memory number of file memory pages = 102029 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 171 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 escritu-ras 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 canti-dad 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). Configu-rando 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 sugeren-cia 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 172 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 verda-dero 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 protegi-

das 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 173 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 aplica-ciones 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 174 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 tout avg-cpu: % user % sys % idle % iowait

0.0 328.5 100.0 0.0 0.0 0.0 Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk0 0.0 0.0 0.0 0 0 hdisk1 0.0 0.0 0.0 0 0 hdisk2 0.0 0.0 0.0 0 0 hdisk3 0.0 0.0 0.0 0 0 cd0 0.0 0.0 0.0 0 0 tty: tin tout avg-cpu: % user % sys % idle % iowait

0.0 332.1 100.0 0.0 0.0 0.0 Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk0 0.0 0.0 0.0 0 0 hdisk1 0.0 0.0 0.0 0 0


Página 175 de 283

hdisk2 0.0 0.0 0.0 0 0 hdisk3 0.0 0.0 0.0 0 0 cd0 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 cpu ----- -- r b avm fre re pi po fr sr cy in sy cs us sy id wa

--------- ------------------------ ------------ -----------

0 0 17354 15755 0 0 0 0 0 0 101 10 7 63 0 37 0 5 1 17354 15754 0 0 0 0 0 0 407 2228 101 99 0 0 0 5 1 17354 15752 0 0 0 0 0 0 413 43 93 99 0 0 0 5 1 17354 15752 0 0 0 0 0 0 405 43 92 99 0 0 0 5 1 17354 15752 0 0 0 0 0 0 407 42 90 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 |head -15 UID PID PPID C STIME TTY TIME CMD thomasc 15860 12948 93 10:30:49 pts/1 17:41 ./tcprg5 thomasc 16312 12948 93 10:30:39 pts/1 20:30 ./tcprg3 thomasc 15234 12948 92 10:31:13 pts/1 15:21 ./tcprg1 thomasc 16844 12948 87 10:31:00 pts/1 13:15 ./tcprg2 thomasc 17420 12948 31 10:30:26 pts/1 14:53 ./tcprg4 root 14778 3420 4 10:51:10 pts/3 0:00 ps -ef root 17154 3420 1 10:51:10 pts/3 0:00 sort +3 -r root 13676 15080 0 15:54:12 pts/5 0:00 ksh root 15080 1 0 15:54:11 - 0:00 xterm root 4980 1 0 15:37:42 - 0:00 /usr/lib/errdemon -s 2000000 root 16510 3420 0 10:51:10 pts/3 0:00 head -15 root 16022 10872 0 Jun 29 lft0 7:05 topas n root 3420 5568 0 Jun 28 pts/3 0:00 ksh root 12948 12796 0 Jun 28 pts/1 0:02 ksh # ps auxwww |head -14 USER PID %CPU MEM SZ RSS TTY STAT STIME TIME COMMAND %thomasc 16312 25.0 0.0 44 64 pts/1 A 10:30:39 26:28 ./tcprg3 root 516 24.0 3.0 264 15396 - A Jun 28 9544:43 kproc thomasc 15860 20.7 0.0 44 64 pts/1 A 10:30:49 21:49 ./tcprg5 thomasc 15234 20.6 0.0 44 60 pts/1 A 10:31:13 21:20 ./tcprg1 thomasc 16844 18.4 0.0 44 64 pts/1 A 10:31:00 19:13 ./tcprg2 thomasc 17420 15.7 0.0 44 64 pts/1 A 10:30:26 16:44 ./tcprg4 root 1032 6.7 3.0 264 15396 - A Jun 28 2679:27 kproc root 1290 3.2 3.0 264 15396 - A Jun 28 1263:12 kproc root 774 3.2 3.0 264 15396 - A Jun 28 1258:58 kproc root 3158 0.0 0.0 356 384 - A Jun 28 8:27 /usr/sbin/syncd 60 root 16022 0.0 0.0 488 640 lft0 A Jun 29 7:05 topas n root 2064 0.0 3.0 320 15452 - A Jun 28 2:38 kproc root 0 0.0 3.0 268 15400 - A Jun 28 1:26 swapper


Página 176 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 impre-sió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: tin tout avg-cpu: % user % sys % idle % iowait 0.0 41.4 61.1 0.1 38.9 0.0 Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk3 0.0 0.3 0.0 258032 224266 hdisk2 0.1 1.1 0.0 258088 1658678 hdisk0 0.0 0.9 0.1 746152 725871 hdisk1 0.1 1.5 0.0 974788 1660027 cd0 0.0 0.0 0.0 0 0 hdisk4 0.0 0.2 0.0 323080 40480 # iostat 1 10


Página 177 de 283

tty: tin tout avg-cpu: % user % sys % idle % iowait

0.9 52.6 2.7 20.1 43.3 33.9 Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk0 19.4 350.9 32.3 870967 921096 hdisk1 49.0 616.6 52.9 1267281 1881244 cd0 0.0 0.0 0.0 0 0 tty: tin tout avg-cpu: % user % sys % idle % iowait







2.0 48.0 0.0 13.0 0.0 87.0 Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk0 18.0 184.0 19.0 0 184 hdisk1 99.0 1728.0 120.0 244 1484


Página 178 de 283

cd0 0.0 0.0 0.0 0 0 tty: tin tout avg-cpu: % user % sys % idle % iowait


11.0 11.0 0.0 6.0 0.0 94.0 Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk0 23.0 200.0 23.0 0 200 hdisk1 100.0 744.0 102.0 276 468 cd0 0.0 0.0 0.0 0 0 La siguiente es la salida del comando vmstat: # vmstat 1 10 kthr memory page faults cpu ----- ----------- ------------------------- ------------ ----------- r b avm fre re pi po fr sr cy in sy cs us sy id wa 0 0 19776 121 0 1 82 225 594 0 208 658 160 3 20 43 34 0 2 19776 115 0 0 0 408 911 0 338 1160 327 0 9 0 91 0 3 19776 121 0 0 0 410 950 0 329 971 300 0 12 0 88 0 3 19776 121 0 0 0 337 724 0 335 950 360 0 9 0 91 0 3 19776 120 0 0 0 562 1136 0 341 1279 256 0 19 0 81 0 3 19776 119 0 0 0 632 1360 0 349 1230 247 1 11 0 88 0 2 19776 118 0 0 0 641 1366 0 359 1630 281 0 19 0 81 0 3 19776 121 0 0 0 1075 3353 0 362 2147 322 0 23 0 77 0 3 19776 123 0 0 0 761 1700 0 367 1225 376 3 11 0 86 0 3 19776 123 0 0 0 1170 1819 0 435 1374 390 0 21 0 79

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 179 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 4.6.3.1 I/O wait de CPU y threads del kernel El siguiente escenario provee la siguiente salida del comando vmstat: $ /usr/bin/vmstat 120 10 kthr memory page faults cpu ----- ----------- ------------------------- ------------ ----------- r b avm fre re pi po fr sr cy in sy cs us sy id wa 0 1 59903 542 0 0 0 0 0 0 451 912 478 43 11 15 31 0 2 59904 550 0 0 0 0 0 0 521 1436 650 23 19 4 50 0 3 59950 538 0 0 0 0 0 0 344 649 249 7 7 6 80 0 2 59899 578 0 0 0 0 0 0 467 1829 500 12 14 4 70 0 2 59882 589 0 0 0 0 0 0 600 1292 705 6 8 3 61 0 3 59882 420 0 0 0 0 0 0 452 952 372 11 8 1 80 0 2 59954 420 0 0 0 0 0 0 537 1979 573 13 5 10 72 0 2 59954 423 0 0 0 0 0 0 618 1413 686 15 9 6 70 0 3 59954 420 0 0 0 0 0 0 551 938 634 4 2 2 92 0 2 59954 422 0 0 0 0 0 0 460 1376 496 14 2 4 80 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 180 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 Volume Group Size %Used Active Auto Type Physical Volume hd6 hdisk0 rootvg 256MB 13 yes yes lv # iostat 120 5 ... tty: tin tout avg-cpu: % user % sys % idle % iowait

47.8 1394.6 50.3 19.6 25.0 5.1 Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk0 97.0 124.4 59.3 1924 12240 hdisk1 0.8 21.5 16.8 492 0 hdisk2 0.2 0.3 0.1 8 12 tty: tin tout avg-cpu: % user % sys % idle % iowait




33.6 875.5 18.4 41.1 10.5 30.0


Página 181 de 283

Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk0 98.9 180.5 7.5 3132 18560 hdisk1 0.2 15.6 2.9 80 808 hdisk2 0.3 0.7 0.2 12 32 ... 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 0004 0005 0006 0007 0008 0009 0010 1-10 0011 0012 0013 0014 0015 0016 0017 0018 0019 0020 11-20 0021 0022 0023 0024 0025 0026 0027 0028 0029 0030 21-30 0031 0032 31-32 0033 0034 0035 0036 0037 0038 0039 0040 0041 0042 33-42 0043 0044 0045 0046 0047 0048 0049 0050 0051 0052 43-52 0053 0054 0055 0056 0057 0058 0059 0060 0061 0062 53-62 0063 0064 63-64 USED USED USED USED USED USED USED USED USED USED 65-74 USED USED USED USED USED USED USED USED USED USED 75-84 USED USED USED USED USED USED USED USED USED USED 85-94 USED 95-95 USED USED USED USED USED USED USED FREE FREE FREE 96-105 FREE FREE FREE FREE FREE FREE FREE FREE FREE FREE 106-115 FREE FREE FREE FREE FREE FREE FREE 0065 0066 0067 116-125 0068 0069 126-127 FREE 0070 0071 USED USED USED USED USED USED USED 128-137 USED USED USED USED USED USED USED USED USED USED 138-147 USED USED USED USED USED USED USED USED USED USED 148-157 USED USED 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 182 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 000bc6fdc3dc07a7 rootvg hdisk1 000bc6fdbff75ee2 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 ... Most Active Logical Volumes ------------------------------------------------------------------------ util #rblk #wblk KB/s volume description ------------------------------------------------------------------------ 0.07 0 2016 64.5 /dev/mirrlv /u/mirrfs 0.84 105792 149280 177.1 /dev/hd1 /home 0.32 0 16800 11.9 /dev/hd8 jfslog 0.03 0 4608 3.2 /dev/hd4 / 0.02 864 55296 5.9 /dev/hd2 /usr 0.02 192 4800 3.5 /dev/hd9var /var 0.01 0 2976 2.1 /dev/hd8 jfslog ... 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 Percent Used 100MB 37% # lsps -a Page Space Physical Volume Volume Group Size %Used Active Auto Type hd6 hdisk0 rootvg 100MB 38 yes yes 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:


Página 183 de 283

# lsvg rootvg datavg # lspv hdisk0 000038744c632197 rootvg hdisk1 00002199abf65a1a datavg hdisk2 00000228b9c5d7da datavg hdisk3 00002199b40b728c datavg 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 LPs PPs DISTRIBUTION MOUNT POINT hd5 2 2 02..00..00..00..00 N/A hd3 6 6 02..00..04..00..00 /tmp hd2 117 117 00..47..42..28..00 /usr hd8 1 1 00..00..01..00..00 N/A hd4 2 2 00..00..02..00..00 / hd9var 1 1 00..00..01..00..00 /var hd6 128 128 29..50..49..00..00 N/A hd1 3 3 00..00..01..02..00 /home lv00 10 10 00..00..00..10..00 /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 LPs PPs DISTRIBUTION MOUNT POINT loglv00 1 1 01..00..00..00..00 N/A lv01 10 10 00..00..00..00..10 /db01 lv02 10 10 00..00..00..00..10 /db02 lv03 10 10 10..00..00..00..00 /db03 # lspv -l hdisk2 hdisk2: LV NAME LPs PPs DISTRIBUTION MOUNT POINT # lspv -l hdisk3 hdisk3: LV NAME 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 VOLUME GROUP: datavg LV IDENTIFIER: 0000881962b29b51.1 PERMISSION: read/write VG STATE: active/complete LV STATE: opened/syncd TYPE: jfs WRITE VERIFY: off MAX LPs: 512 PP SIZE: 8 megabyte(s) COPIES: 1 SCHED POLICY: parallel LPs: 1 PPs: 1 STALE PPs: 0 BB POLICY: relocatable INTER-POLICY: minimum RELOCATABLE: yes INTRA-POLICY: middle UPPER BOUND: 32 MOUNT POINT: /db01 LABEL: /db01 MIRROR WRITE CONSISTENCY: on EACH LP COPY ON A SEPARATE PV ?: yes # lslv lv02 LOGICAL VOLUME: lv02 VOLUME GROUP: datavg


Página 184 de 283

LV IDENTIFIER: 0000881962b29b51.3 PERMISSION: read/write VG STATE: active/complete LV STATE: opened/syncd TYPE: jfs WRITE VERIFY: off MAX LPs: 512 PP SIZE: 8 megabyte(s) COPIES: 1 SCHED POLICY: parallel LPs: 1 PPs: 1 STALE PPs: 0 BB POLICY: relocatable INTER-POLICY: minimum RELOCATABLE: yes INTRA-POLICY: middle UPPER BOUND: 32 MOUNT POINT: /db02 LABEL: /db02 MIRROR WRITE CONSISTENCY: on EACH LP COPY ON A SEPARATE PV ?: yes # lslv lv03 LOGICAL VOLUME: lv03 VOLUME GROUP: datavg LV IDENTIFIER: 0000881962b29b51.4 PERMISSION: read/write VG STATE: active/complete LV STATE: opened/syncd TYPE: jfs WRITE VERIFY: off MAX LPs: 512 PP SIZE: 8 megabyte(s) COPIES: 1 SCHED POLICY: parallel LPs: 1 PPs: 1 STALE PPs: 0 BB POLICY: relocatable INTER-POLICY: minimum RELOCATABLE: yes INTRA-POLICY: middle UPPER BOUND: 32 MOUNT POINT: /db03 LABEL: /db03 MIRROR WRITE CONSISTENCY: on EACH LP COPY ON A SEPARATE PV ?: yes 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 faults cpu ----- ----------- ------------------------ ------------ ----------- r b avm fre re pi po fr sr cy in sy cs us sy id wa 0 0 11106 107916 0 0 0 0 0 0 125 570 66 1 4 88 7 0 0 11106 107915 0 0 0 0 0 0 112 397 42 0 0 98 2 0 0 11106 107915 0 0 0 0 0 0 107 192 23 0 0 99 0 0 0 11106 107915 0 0 0 0 0 0 110 280 28 0 0 99 0 0 0 11106 107915 0 0 0 0 0 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:


Página 185 de 283

# 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 204340 72 0 0 5 8 25 0 108 249 29 0 1 98 1 3 4 204649 124 0 31 422 449 912 0 347 4796 350 5 95 0 0 1 3 204988 112 0 56 183 464 1379 0 339 14144 382 4 96 0 0 9 0 205292 122 0 24 251 369 988 0 352 598 403 4 94 0 2 3 1 205732 119 0 0 409 520 771 0 313 780 293 1 99 0 0 3 1 206078 123 0 0 445 496 602 0 336 706 298 2 98 0 0 3 1 206460 120 0 0 343 504 1210 0 305 719 271 1 99 0 0 2 1 206897 119 0 0 320 512 981 0 311 660 288 0 99 0 0 3 1 207186 126 0 1 369 504 929 0 331 718 292 1 99 0 0 3 1 207491 120 0 1 428 504 844 0 319 763 262 1 99 0 0 4 0 207964 119 0 0 275 520 791 0 296 632 283 0 99 0 0 4 0 208354 119 0 2 373 513 816 0 328 664 297 1 99 0 0 4 0 208715 87 0 4 383 464 753 0 330 1480 261 4 96 0 0 3 1 209006 4 0 12 282 504 630 0 350 1385 286 2 98 0 0 3 2 209307 10 0 0 316 488 685 0 320 635 287 1 92 0 7 La siguiente salidas realizadas con el comando vmstat serán utilizadas como referencia o compa-ración. La siguiente salida corresponde al comando ps: # ps gv | head -n 1; ps gv | egrep -v "RSS" | sort +6b -7 -n –r PID TTY STAT TIME PGIN SIZE RSS LIM TSIZ TRS %CPU %MEM COMMAND 12478 pts/4 A 2:05 91 742240 362552 32768 2 4 50.8 69.0 ./tmp/me 1032 - A 0:56 0 64 6144 xx 0 6088 0.0 1.0 kproc 774 - A 0:01 0 16 6104 xx 0 6088 0.0 1.0 kproc 7484 - A 0:00 6 16 6104 32768 0 6088 0.0 1.0 kproc 10580 - A 0:00 1 16 6104 32768 0 6088 0.0 1.0 kproc 0 - A 0:20 7 12 6100 xx 0 6088 0.0 1.0 swapper 516 - A 3920:23 0 8 6096 xx 0 6088 98.7 1.0 kproc 2076 - A 0:00 0 16 6096 xx 0 6088 0.0 1.0 kproc 3622 - A 0:00 0 16 6096 xx 0 6088 0.0 1.0 kproc 7740 - A 0:00 0 16 6096 32768 0 6088 0.0 1.0 kproc 4994 pts/5 A 0:00 24 440 708 32768 198 220 0.0 0.0 ksh /usr/ 15434 pts/5 A 0:00 0 368 396 32768 198 220 0.0 0.0 ksh /usr/ 4564 pts/0 A 0:00 0 308 392 32768 198 220 0.0 0.0 -ksh 15808 pts/2 A 0:00 292 304 388 32768 198 220 0.0 0.0 ksh 5686 pts/0 A 0:00 320 280 348 32768 198 220 0.0 0.0 -ksh 11402 pts/1 A 0:00 225 296 336 32768 198 220 0.0 0.0 -ksh 2622 - A 0:39 469 3208 324 xx 2170 112 0.0 0.0 /usr/lpp/ 16114 pts/0 A 0:00 0 240 324 32768 52 60 0.0 0.0 ps gv 16236 pts/5 A 0:00 12 360 252 32768 198 220 0.0 0.0 ksh /usr/ 11982 pts/4 A 0:00 160 304 240 32768 198 220 0.0 0.0 -ksh 13934 pts/2 A 0:00 234 304 236 32768 198 220 0.0 0.0 -ksh 14462 pts/3 A 0:00 231 308 232 32768 198 220 0.0 0.0 -ksh 16412 pts/5 A 0:00 129 304 232 32768 198 220 0.0 0.0 -ksh 1 - A 0:07 642 760 224 32768 25 36 0.0 0.0 /etc/init 6708 - A 0:02 394 728 212 32768 337 80 0.0 0.0 /usr/sbin 6212 - A 0:00 567 644 208 32768 327 64 0.0 0.0 sendmail: 3124 - A 5:22 340 1152 204 xx 40 0 0.1 0.0 dtgreet 17316 pts/0 A 0:00 71 88 196 32768 43 68 0.0 0.0 svmon -i 17556 pts/0 A 0:00 1 148 196 32768 16 24 0.0 0.0 egrep -v 12886 pts/3 A 1:53 30625 228 192 32768 10 12 9.8 0.0 cp -r /u/ 16960 pts/0 A 0:00 40 132 184 32768 15 20 0.0 0.0 vmstat 1 13104 pts/1 A 0:00 63 132 156 32768 15 20 0.0 0.0 vmstat 1 13466 pts/5 A 0:00 0 104 136 32768 2 4 0.0 0.0 /usr/bin/ 4774 - A 0:00 217 284 124 32768 30 28 0.0 0.0 /usr/sbin 13796 pts/5 A 0:00 4 80 76 32768 18 24 0.0 0.0 dd conv=s


Página 186 de 283

14856 pts/5 A 0:01 0 72 64 32768 18 24 1.1 0.0 dd conv=s 5440 - A 0:00 228 292 60 32768 25 20 0.0 0.0 /usr/sbin 9292 - A 0:00 183 128 60 32768 53 20 0.0 0.0 /usr/sbin 1920 - A 0:50 16272 96 36 xx 2 4 0.0 0.0 /usr/sbin 14198 - A 0:00 274 740 20 32768 313 4 0.0 0.0 telnetd - 2516 - A 0:00 0 656 16 32768 313 4 0.0 0.0 telnetd - 8000 - A 0:00 51 656 16 32768 313 4 0.0 0.0 telnetd - 8780 - A 0:00 19 120 16 32768 3 0 0.0 0.0 /usr/sbin 11614 - A 0:00 9 180 16 32768 18 0 0.0 0.0 /usr/lpp/ 12788 - A 0:00 102 740 16 32768 313 4 0.0 0.0 telnetd - 14710 - A 0:00 350 740 16 32768 313 4 0.0 0.0 telnetd - 15298 - A 0:00 0 740 16 32768 313 4 0.0 0.0 telnetd - 2874 - A 0:00 29 288 12 xx 100 0 0.0 0.0 /usr/dt/b 3402 0 A 0:00 5 180 12 xx 34 0 0.0 0.0 slattach 3900 - A 0:00 442 460 12 xx 56 0 0.0 0.0 /usr/lib/ 4134 - A 0:00 26 400 12 xx 100 0 0.0 0.0 dtlogin < 5176 - A 0:00 44 456 12 32768 31 0 0.0 0.0 /usr/sbin 5938 - A 0:00 37 280 12 32768 36 0 0.0 0.0 /usr/sbin 6450 - A 0:00 99 304 12 32768 25 0 0.0 0.0 /usr/sbin 6966 - A 0:00 52 428 12 32768 190 0 0.0 0.0 /usr/sbin 7224 - A 0:00 56 500 12 32768 191 0 0.0 0.0 /usr/sbin 8260 - A 0:00 1 96 12 32768 2 0 0.0 0.0 /usr/sbin 8522 - A 0:00 13 292 12 32768 21 0 0.0 0.0 /usr/sbin 9040 - A 0:00 3 36 12 32768 5 0 0.0 0.0 /usr/sbin 9554 - A 0:00 5 220 12 32768 12 0 0.0 0.0 /usr/sbin 9808 - A 0:00 12 312 12 32768 64 0 0.0 0.0 /usr/bin/ 10838 lft0 A 0:00 17 372 12 32768 40 0 0.0 0.0 /usr/sbin 11094 - A 0:00 13 256 12 32768 22 0 0.0 0.0 /usr/IMNS La siguiente es la salida del comando svmon: # svmon -i 5 5 size inuse free pin virtual memory 131063 130936 127 6946 204676 pg space 131072 106986 work pers clnt pin 6955 0 0 in use 104809 26127 0 size inuse free pin virtual memory 131063 130942 121 6942 206567 pg space 131072 108647 work pers clnt pin 6951 0 0 in use 105067 25875 0 size inuse free pin virtual memory 131063 130951 113 6942 208406 pg space 131072 110432 work pers clnt pin 6955 0 0 in use 104809 26127 0 size inuse free pin virtual memory 131063 130942 121 6942 206567 pg space 131072 108647 work pers clnt pin 6951 0 0 in use 105067 25875 0


Página 187 de 283

size inuse free pin virtual memory 131063 130951 113 6942 208406 pg space 131072 110432 work pers clnt pin 6951 0 0 in use 105127 25824 0 La siguiente salida del svmon muestra los diez procesos que más memoria están utilizando: # svmon -Pu -t 10 ------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 12478 memory 92498 1259 95911 189707 N N Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 7a80 5 work shmat/mmap 52911 0 222 53058 0..65285 d18a 3 work shmat/mmap 31670 0 33881 65535 0..65535 4358 4 work shmat/mmap 4963 0 60572 65535 0..65535 0 0 work kernel seg 1522 1258 1076 3897 0..32767

65475..65535 8811 d work shared library text 274 0 24 393 0..65535 c93 8 work shmat/mmap 244 0 12 256 0..65288 e6ec 7 work shmat/mmap 240 0 16 256 0..65287 5d79 6 work shmat/mmap 234 0 22 256 0..65286 e28c 9 work shmat/mmap 232 0 24 256 0..65289 735e a work shmat/mmap 200 0 55 255 0..65034 767c 2 work process private 4 1 3 5 65314..65535 3e76 f work shared library data 3 0 4 5 0..709 634c 1 pers code,/dev/hd3:21 1 0 - - 0..2 ------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 13796 dd 2829 1260 1100 4303 N N Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 0 0 work kernel seg 1522 1258 1076 3897 0..32767 :

65475..65535 dc53 - pers /dev/hd3:45 1011 0 - - 0..1010 8811 d work shared library text 274 0 24 393 0..65535 edae 2 work process private 8 1 0 8 0..20 :

65310..65535 83b0 1 pers code,/dev/hd2:4164 6 0 - - 0..5 dbb3 f work shared library data 5 0 0 2 0..797 949a 3 work shmat/mmap 1 1 0 1 0..0 ac7d 4 work shmat/mmap 1 0 0 1 0..0 ac5d 5 work shmat/mmap 1 0 0 1 0..0 ------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 14856 dd 2826 1260 1100 4301 N N Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 0 0 work kernel seg 1522 1258 1076 3897 0..32767 :

65475..65535 dc53 - pers /dev/hd3:45 1011 0 - - 0..1010 8811 d work shared library text 274 0 24 393 0..65535 83b0 1 pers code,/dev/hd2:4164 6 0 - - 0..5 6ce5 2 work process private 6 1 0 6 0..19 :

65310..65535 5cc3 f work shared library data 4 0 0 2 0..797


Página 188 de 283

949a 3 work shmat/mmap 1 1 0 1 0..0 ac7d 4 work shmat/mmap 1 0 0 1 0..0 ac5d 5 work shmat/mmap 1 0 0 1 0..0 ------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 4994 ksh 1975 1259 1100 4400 N N Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 0 0 work kernel seg 1522 1258 1076 3897 0..32767 :

65475..65535 8811 d work shared library text 274 0 24 393 0..65535 7b7c 2 work process private 98 1 0 96 0..115 :

65310..65535 e03c 1 pers code,/dev/hd2:4204 55 0 - - 0..58 c72a f work shared library data 24 0 0 14 0..797 2865 - pers /dev/hd2:32343 2 0 - - 0..1 4b89 - pers /dev/hd2:10340 0 0 - - 0..10 ------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 15434 ksh 1897 1259 1100 4328 N N Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 0 0 work kernel seg 1522 1258 1076 3897 0..32767 :

65475..65535 8811 d work shared library text 274 0 24 393 0..65535 e03c 1 pers code,/dev/hd2:4204 55 0 - - 0..58 92c3 2 work process private 29 1 0 28 0..94 :

65310..65535 30f7 f work shared library data 15 0 0 10 0..797 2865 - pers /dev/hd2:32343 2 0 - - 0..1 536a - pers /dev/hd2:4522 0 0 - - 0..7 c91 - pers /dev/hd3:29 0 0 - - ------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 16728 -ksh 1897 1259 1103 4324 N N Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 0 0 work kernel seg 1522 1258 1076 3897 0..32767 :

65475..65535 8811 d work shared library text 274 0 24 393 0..65535 e03c 1 pers code,/dev/hd2:4204 55 0 - - 0..58 ef7a 2 work process private 24 1 2 23 0..83 :

65310..65535 8717 f work shared library data 18 0 1 11 0..382 2865 - pers /dev/hd2:32343 2 0 - - 0..1 a2f4 - pers /dev/hd4:792 1 0 - - 0..1 f96d - pers /dev/hd3:40 1 0 - - 0..0 ------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 15808 ksh 1896 1259 1166 4366 N N Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 0 0 work kernel seg 1522 1258 1076 3897 0..32767 :

65475..65535 8811 d work shared library text 274 0 24 393 0..65535 e03c 1 pers code,/dev/hd2:4204 55 0 - - 0..58 cec9 2 work process private 25 1 54 62 0..91 :

65310..65535 1752 f work shared library data 17 0 12 14 0..797


Página 189 de 283

2865 - pers /dev/hd2:32343 2 0 - - 0..1 e35c - pers /dev/hd1:19 1 0 - - 0..0 ------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 2622 X 1888 1268 1889 5132 N N Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 0 0 work kernel seg 1522 1258 1076 3897 0..32767 :

65475..65535 8811 d work shared library text 274 0 24 393 0..65535 8971 2 work process private 52 8 712 763 0..825 :

65309..65535 9172 1 pers code,/dev/hd2:18475 28 0 - - 0..706 fa9f - work 9 0 32 32 0..32783 3987 3 work shmat/mmap 2 2 2 4 0..32767 b176 f work shared library data 1 0 39 39 0..310 e97d - pers /dev/hd2:20486 0 0 - - 0..7 d97b - pers /dev/hd3:25 0 0 - - 3186 - work 0 0 2 2 0..32768 180 - pers /dev/hd2:20485 0 0 - - 0..0 4168 - pers /dev/hd9var:2079 0 0 - - 0..0 1963 - pers /dev/hd9var:2078 0 0 - - 0..0 90b2 - work 0 0 2 2 0..32768 9092 - pers /dev/hd4:2 0 0 - - 0..0 ------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 11402 -ksh 1882 1259 1166 4364 N N Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 0 0 work kernel seg 1522 1258 1076 3897 0..32767 :

65475..65535 8811 d work shared library text 274 0 24 393 0..65535 e03c 1 pers code,/dev/hd2:4204 55 0 - - 0..58 6b0d 2 work process private 18 1 52 59 0..83 :

65310..65535 4328 f work shared library data 11 0 14 15 0..382 2865 - pers /dev/hd2:32343 2 0 - - 0..1 3326 - pers /dev/hd4:605 0 0 - - 0..1 ------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 5686 -ksh 1872 1259 1106 4304 N N Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range 0 0 work kernel seg 1522 1258 1076 3897 0..32767 :

65475..65535 8811 d work shared library text 274 0 24 393 0..65535 e03c 1 pers code,/dev/hd2:4204 55 0 - - 0..58 72ee 2 work process private 12 1 5 12 0..82 :

65310..65535 6aed f work shared library data 6 0 1 2 0..382 2865 - pers /dev/hd2:32343 2 0 - - 0..1 a2f4 - pers /dev/hd4:792 1 0 - - 0..1 Varias muestras del espacio de paginado en diferentes momentos utilizando el comando lsps -a: # lsps -a Page Space Physical Volume Volume Group Size %Used Active Auto Type hd6 hdisk0 rootvg 512MB 95 yes yes lv


Página 190 de 283

# lsps -a Page Space Physical Volume Volume Group Size %Used Active Auto Type hd6 hdisk0 rootvg 512MB 97 yes yes lv # lsps -a Page Space Physical Volume Volume Group Size %Used Active Auto Type hd6 hdisk0 rootvg 512MB 9 yes yes lv Salida del comando vmtune: # 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 maxperm=79.4% of real memory maximum pinable=80.0% of real memory minperm=19.8% of real memory number of file memory pages = 13516 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 191 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 192 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 193 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 determi-nar 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 inten-tar 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 <nombre de host> 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 194 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 195 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 Use If PMTU Exp Groups Route Tree for Protocol Family 2 (Internet): default 9.185.112.254 UG 1 1656 tr0 - - 9.185.112/23 9.185.113.7 U 26 4642 tr0 - - 127/8 127.0.0.1 U 5 424 lo0 - - 192.168.1/24 192.168.1.10 U 0 0 en0 - - Route Tree for Protocol Family 24 (Internet v6): ::1 ::1 UH 0 0 lo0 16896 - # 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 196 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 infor-

maciones 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 197 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 <red destino> <dirección de la ruta> Las rutas pueden ser agregadas de la misma manera: route add net <red destino> <dirección de la ruta> 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 Coll lo0 16896 link#1 2107 0 2109 0 0 lo0 16896 127 127.0.0.1 2107 0 2109 0 0 lo0 16896 ::1 2107 0 2109 0 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 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 0 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 0


Página 198 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 <interfase>, 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<BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,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<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,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 199 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 token-ring 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 200 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: -------------------------------------- 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 LES ATM Address: 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: --------------------------------------


Página 201 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 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 LES ATM Address: 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 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 202 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) 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 203 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 argumen-tos, 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 204 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 espera-dos, 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, datos transmitidos pero 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 205 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: ################################################################## # 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 206 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 <telnet server system host name> # host <IP address returned from previous command>

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 <hostname> chargen

Si la conexión al puerto chargen es satisfactoria, se observará una salida similar a la siguiente:

vwxyz{|}~ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^ wxyz{|}~ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ xyz{|}~ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_` yz{|}~ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_à z{|}~ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_àb {|}~ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_àbc |}~ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_àbcd }~ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_àbcde ~ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_àbcdef !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_àbcdefg !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_àbcdefgh "#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_àbcdefghi #$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_àbcdefghij $%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_àbcdefghijk %&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_àbcdefghijkl &'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_àbcdefghijklm

Para finalizar el telnet utilizar la secuencia de teclas Ctrl-C.


Página 207 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. 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 208 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 envia-dos.

• 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 209 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 <host name> or <address> # 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 <n> envía n paquetes. Se puede controlar el tamaño de los paquetes enviados con ping <host> <tamaño>. 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 redireccio-namiento ICMP), y también puede indicar otro tipo de errores.


Página 210 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 <familia>. 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 (<línea 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 211 de 283

# netstat -r Routing tables Destination Gateway Flags Refs Use If PMTU Exp Groups Route Tree for Protocol Family 2 (Internet): default 9.185.112.254 UG 2 124847 tr0 - - 9.185.112/23 msahanc.au.ibm.co U 29 82305 tr0 - - 127/8 loopback U 5 2011 lo0 - - 130.130.130.2 130.130.130.1 UH 0 0 sl2 - - 192.168.1/24 jumbuck U 0 62 en0 - - Route Tree for Protocol Family 24 (Internet v6): ::1 ::1 UH 0 0 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, redireccio-namientos, paquetes enviados y recibidos, y paquetes perdidos y descartados. Además, muestra las conexiones TCP establecidas, los tiempos de espera, y los datagra-mas UDP recibidos y enviados. Para mostrar sólo un protocolo, utilice netstat -p <protocolo> 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 212 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 <origen> y -d <destino>. 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 <protocolo> recolecta datos sólo para un protocolo especificado. • -i <interfase> 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 Reproduce el problema: # ps -ef | grep iptrace # kill <iptrace PID> # ipreport -rns /tmp/trace.raw > /tmp/trace.out

5.5.6 tcpdump


Página 213 de 283

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 avanza-

da. • 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 espe-cí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 <ent#> • tokstat <tok#> • atmstat <at#>

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 214 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 investiga-ció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 requerimien-to 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é co-rrupto 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 215 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 inconsis-tencia 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 vincula-ció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 216 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 217 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 <nombre_del_mapa_nuevo> 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 <wigwam>. 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 siguien-tes 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 obten-drá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 218 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 transferen-cias 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 recha-zada 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 219 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 220 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 adaptado-

res y el export sólo especifica uno. Este problema puede ser solucionado expor-tando 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 <name> • host <ip_addr>

• 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,retry=1 platypus:/test /mnt

Nota Si el proto y el vers no coinciden con el servidor, el montaje fallará completamente.


Página 221 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 <hostname> 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 222 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 pro-blema 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 coman-do 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 (proban-do 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 badxids timeouts newcreds badverfs timers 61663 0 0 0 0 0 0 nomem cantconn interrupts 0 0 0


Página 223 de 283

Connectionless calls badcalls retrans badxids timeouts newcreds badverfs 2851 0 12 0 12 0 0 timers nomem cantsend 0 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 necesa-rios 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 Address Ipkts Ierrs Opkts Oerrs Coll lo0 16896 link#1 2107 0 2109 0 0 lo0 16896 127 127.0.0.1 2107 0 2109 0 0 lo0 16896 ::1 2107 0 2109 0 0 en0 1500 link#2 2.60.8c.2e.e1.c9 24068 0 819 0 0 en0 1500 192.168.1 192.168.1.10 24068 0 819 0 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 0 # 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 interfa-se 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 224 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ís-ticas 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 subsis-tema 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 225 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 perfor-mance 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 /usr/tools

Nota Si usted ve paquetes perdidos en la máquina, incrementar la cantidad de biods probable-mente 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 corri-gié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 226 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 poste-riores, la salida del lockd es capturada con syslogd, por lo tanto, syslog debe ser configurado modi-ficando 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 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 utili-zando 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 depura-ción.


Página 227 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 especifica-do 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 modifi-cadas 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, 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 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 228 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 229 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 <pppcontrold_PID> 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 <pppcontrold_PID>. 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 230 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 direccio-nada 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 conversa-ció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 (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 autentica-ción PAP o CHAP, es normalmente mostrada en el archivo de log del syslogd (/tmp/ppp en los ejemplos utilizados).


Página 231 de 283

Si se está utilizando autenticación CHAP, se debe tener en cuenta que Microsoft utiliza un algorit-mo 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 [david] Remote host name [*] Password [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 [david] Remote host name [*] Password [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 232 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 233 de 283

6. Resolución de problemas de impresión

El objetivo de este capítulo es proveer al administrador de algunas herramientas y recomendacio-nes 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 compro-bar 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 informa-ción que ayuda a aislar el problema, identificar el problema, mejorar la situación y probar la solución.


Página 234 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 docu-mentos. En cada caso, serán exploradas las áreas comunes para ambos subsistemas de impre-sió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 configu-

ració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 impre-

sión? - ¿Se obtienen mensajes en la línea de comandos, por correo, o en el log de erro-

res?

• ¿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 235 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 servi-

dor. - 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 accidental-mente el papel impreso. Esto ocurre muy a menudo cuando no se utilizan banners, o cuando el


Página 236 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 suficiente-mente 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, recha-za los trabajos.


Página 237 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 auto-má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 impre-sora. 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 posi-bilidades:

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 238 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úme-ros 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 servi-dor 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 impre-sora esté a más de 60 metros del ordenador. Si en cambio, sólo soportan RS/232C, entonces la


Página 239 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 impre-sora 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 240 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 impreso-ras 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 incremen-tar 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 241 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 impre-soras 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 añadan los retornos de carro. Con la impre-sora 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 242 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 RTS-CTS. 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 243 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 impor-tante 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 ines-perado, como:


Página 244 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 impre-sora. 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 245 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 configura-ció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 utiliza-das 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 instala-ció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 246 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 247 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 verifi-que 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 impreso-ra remota, se debe verificar que este valor este fijado correctamente. ¿Hay suficiente espacio en el servidor?


Página 248 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 proble-ma 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 incompa-tibles 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 249 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á des-cubierto 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 impre-sió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 250 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 by qprt, lpr, and lp commands) Note: -p + causes the other formatting parameters to be ignored. -p ! pass-through? -c + send carriage returns? -l 64 page length (lines) -n + send line feeds? -w 80 page width (columns) -r + carriage rtn after line feed? -i 0 indentation (columns) -t ! suppress tab expansion? -W ! wrap long lines? -b + send backspaces? -C ! convert to upper case? -f + send form feeds? CURRENT ERROR PROCESSING PARAMETERS -T 300 timeout value (seconds) -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 impre-sió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 251 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 segura-mente 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 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 impre-sión: # lptest 10 10 | /usr/lib/lpd/pio/etc/piohpnpf -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 252 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 253 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: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 254 de 283

6.2.9 Capturar el flag A menudo, un flag que no es compatible con el sistema puede provocar que un archivo simple-mente 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-0 /var/spool/lp/tmp/aix4prt/264-0 # cat /var/spool/lp/tmp/aix4prt/264-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 255 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 48616978 34707274 0a50726f 6f740a66 |Haix4prt.Proot.f| 00000010 64664134 36366169 78347072 740a5564 |dfA466aix4prt.Ud| 00000020 66413436 36616978 34707274 0a4e2f76 |fA466aix4prt.N/v| 00000030 61722f74 6d702f70 696f726c 66625f31 |ar/tmp/piorlfb_1| 00000040 36393534 0a2d6f2d 640a2d6f 700a2d6f |6954.-o-d.-op.-o| 00000050 2d6a0a2d 6f300a2d 6f2d4a0a 2d6f300a |-j.-o0.-o-J.-o0.| 00000060 2d6f2d5a 0a2d6f30 0a2d4e31 0a2d5a72 |-o-Z.-o0.-N1.-Zr| 00000070 6f6f7440 61697834 7072740a 2d74726f |[email protected]| 00000080 6f744061 69783470 72740a2d 542f7661 |[email protected]/va| 00000090 722f746d 702f7069 6f726c66 625f3136 |r/tmp/piorlfb_16| 000000a0 3935340a |954. | 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] doit: 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].


Página 256 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 instruccio-nes:

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 encon-trar 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 impre-sora 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 subsiste-ma de impresión System V en AIX.


Página 257 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 258 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: <[email protected]> To: [email protected] 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: = hp1-357, uid 0, gid 0, lid 0, size 110, Tue Oct 24 09:32:59 2000 z hp1 C 1 D hp1 F /var/spool/lp/tmp/rs9220b/357-1 O locale=en_US flist=':110' P 20 t simple U root r s 0x0100


Página 259 de 283

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 <none> Got a hit. 10/24/00 10:47 p 61398 <none> Got a hit. lpExec 10/24/00 10:47 p 61398 <none> Started child for rs1230a.myco.com, pid = 50990 10/24/00 10:47 p 61398 <none> 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 260 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 diag-nosticar 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 261 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 requeri-mientos 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 directo-rios: /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 262 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 confi-guració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 impre-sora 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 encabeza-miento 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 263 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 proble-mas 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 proble-mas 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 "èxpr \"$1\" : \"^[^=]*=$.*$\"`" echo "èxpr \"$1\" : \"^[^=]*=$.*$\"`" >> /tmp/hp1.log y printer=`basename $0` request_id=$1 user_name=$2 title=$3 copies=$4 option_list=$5


Página 264 de 283

echo “printer: $printer” >> /tmp/hp1.log echo “request_id: $request_id” >> /tmp/hp1.log echo “user_name: $user_name” >> /tmp/hp1.log echo “title: $title” >> /tmp/hp1.log echo "Number of copies: $copies" >> /tmp/hp1.log echo “#options: $option_list” >> /tmp/hp1.log shift 5 files="$*" echo “Filenames: $files” >> /tmp/hp1.log 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 265 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 entran-tes 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 <none> Got a hit. 10/27/00 11:12 p 7888 <none> Got a hit. lpExec 10/27/00 11:12 p 7888 <none> Started child for rs1230a.itsc.austin.ibm.com, pid = 19322 10/27/00 11:12 p 7888 <none> 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 266 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.com!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 satis-factoriamente, y el archivo /etc/lp/logs/netLP muestra: 11/01/00 14:42 p 19414 <none> Got a hit. 11/01/00 14:42 p 19414 <none> Got a hit. listenBSD 11/01/00 14:42 p 19414 <none> Into Polling loop. 11/01/00 14:42 c 9190 matt.dfw.com lpd starting (passive) 11/01/00 14:42 c 9190 matt.dfw.com matt.dfw.com requests recv job hp1 11/01/00 14:42 c 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 267 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.allow 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 herra-mientas 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 268 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 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 | /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 269 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 subsiste-ma 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 adminis-trador 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 si-guiente 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 270 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 271 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 informa-ció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 272 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//rembak0FTyqa, 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/t0nJiEa, fakefn=dfA069rs9220b, filter=/usr/lib/lpd/aixshort. rembak[56708] sendjob: State 2 - send control file, ctrlfname=/tmp//rembak0FTyqa , 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]. 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 informa-ció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 273 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 encola-dos, 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 - 0:00 /usr/lib/lpd/piobe /etc/motd root 45590 12808 0 13:46:36 - 0:00 /usr/lib/lpd/pio/etc/pioout -A0 -B880 -C14688 -F\14\15 root 46824 14270 1 13:50:52 pts/1 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 274 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 275 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 archi-vo 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 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/*

4. Elimine los trabajos encolados:

# rm /var/spool/lpd/qdir/* # rm /var/spool/lpd/qdaemon/* # rm /var/spool/lpd/df*

5. Reinicie el qdaemon:

# startsrc -s qdaemon

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 276 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 coman-dos 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 encabeza-miento (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 277 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 Description Value sh Pipeline for Header Page %Ide/pioburst %F[H

] %Idb/H.ascii | % Ide/pioformat -@ % Idd/%Imm -!%Idf/pi ofpcl -J+ -L! %IsH -u%IuH

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 Description Value sh Pipeline for Header Page 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 278 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 desacti-va 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 279 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 280 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 281 de 283

Lista de abreviaturas AC Alternating Current ACL Access Control List AIX Advanced Interactive eXecutive ANSI American National Standards Institute APAR Authorized Program Analysis Report ARP Address Resolution Protocol ASCI Accelerated Strategic Computing Initiative ASCII American National Standards Code for Information Interchange ATE Asynchronous Terminal Emulator ATM Asynchronous Transfer Mode ATMLE ATM LAN Emulation BFF Backup File Format BI Business Intelligence BIND Berkeley Internet Name Daemon CAE Computer-Aided Engineering CD Compact Disc CDE Common Desktop Environment CD-ROM Compact Disc Read Only Memory CE Customer Engineer CPI Characters Per Inch CPU Central Processing Unit CSS Communication Subsystems Support CTS Clear To Send DAR Data Address Register DAR2 Secondary Data Address Register DBM Database Manager DE Dual-Ended DFS Distributed File System DHCP Dynamic Host Configuration Protocol DMA Direct Memory Access DNS Domain Name Server DSI Data Storage Interrupt DSIRR Data Storage Interrupt Reason Register DSISR Data Storage Interrupt Status Register DTE Data Terminal Equipment DTR Data Terminal Ready EC Engineering Change ELAN Emulated LAN ESCON Enterprise Systems Connection (Architecture, IBM System/390) FDDI Fiber Distributed Data Interface FTP File Transfer Protocol HACMP High Availability Cluster Multi Processing HiPPI High Performance Parallel Interface HiPS High Performance Switch

HP Hewlett-Packard HPF High Performance FORTRAN HTTP Hypertext Transfer Protocol I/O Input/Output IAR Instruction Address Register IBM International Business Machines Corporation ICMP Internet Control Message Protocol ID Identification IDE Integrated Device Electronics IDS Intelligent Decision Server IGMP Internet Group Management Protocol IP Internet Protocol IPL Initial Program Load JDF Job Description File JFS Journaled File System LAN Local Area Network LECS LAN Emulation Configuration Server LED Light Emitting Diode LES LAN Emulation Server LP Logical Partition LPD Line Printer Daemon Protocol LPP Licensed Program Product LR Link Register LUM Licence Use Management LV Logical Volume LVCB Logical Volume Control Block LVDD Logical Volume Device Driver LVID Logical Volume Identifier LVM Logical Volume Manager MAC Medium Access Control MCA Micro Channel Architecture MSS Maximum Segment Size MST Machine State Save Area MTU Maximum Transfer Unit NFS Network File System NIS Network Information Service NUA Network User Address ODM Object Data Manager OEM Original Equipment Manufacturer OLTP Online Transaction Processing PAP Password Authentication Protocol PCI Peripheral Component Interface PCL Printer Control Language PDU Power Distribution Unit PID Program Identification PJL Printer Job Language POSIX Portable Operating Interface for Computing Environments POST Power-On Self-Test POWER Performance Optimization with Enhanced RISC (Architecture) PP Physical Partition


Página 282 de 283

PPP Point-to-Point Protocol PTF Program Temporary Fix PV Physical Volume PVC Permanent Virtual Circuit PVID Physical Volume Identifier RAID Redundant Array of Independent Disks RAM Random Access Memory RAN Remote Asynchronous Node RAS Reliability, Availability, and Serviceability RFC Request For Comments RIO Remote Input Output RIP Routing Information Protocol RPC Remote Procedure Call RTS Ready To Send SCSI Small Computer System Interface SLIP Serial Link Internet Protocol SMIT System Management Interface Tool SMP Symmetric Multiprocessing SP Scalable POWER Parallel SPSW SP Switch SRC System Resource Controller SRV Segment Register Value SSA Serial Storage Architecture SVC Switched Virtual Circuit TCP Transmission Control Protocol TCP/IP Transmission Control Protocol/Internet Protocol UDP UNIX Datagram Protocol URL Universal Resource Locator UUCP UNIX-to-UNIX Communication Protocol VCI Virtual Channel Indicator VESA Video Electronics Standards Association VG Volume Group VGDA Volume Group Descriptor Area VGID Volume Group Identifier VGSA Volume Group Save Area VMM Virtual Memory Manager VPI Virtual Path Indicator


Página 283 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.