Resolución de Problemas y Soporte Avanzado en AIX v5

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

Resolución de problemas y soporte avanzado de AIX Andrés Córdoba Rossi
Indice
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 12
1.1.3 Recolectando información del sistema 12
1.1.4 Resolviendo el problema 13
1.1.5 Obteniendo parches de software (PTFs) 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 El disco cambió mientras el grupo de volúmenes estaba exportado 20
2.2.4.4 Entorno de discos compartidos 20
2.2.5 Extendiendo el número máximo de particiones físicas (Insuficiente
cantidad de PPs cuando se añade un nuevo volumen físico) 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 reparación de file systems (comando fsck) 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
Andrés Córdoba Página 2 de 287

2.5.1 Recomendaciones para crear o extender espacios de paginado 31

2.5.2 Como determinar si es necesario extender el espacio de paginado 31
2.5.3 Como reducir el tamaño del hd6 (Espacio de paginado por defecto) 32
3. System Dumps 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 dump 35
3.1.3 Creando un dispositivo de dump 37
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 40
3.2.3 Log de errores 40
3.3 Core dumps 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 Uso 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 46
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 53
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 comando 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 64
3.5.3 Ejemplo 3 65
4. Performance Tuning 67
4.1 Introducción al monitoreo y tuning de performance en AIX 67

4.1.1 Performance de CPU 68

4.1.1.1 Procesos y threads 68

4.1.1.2 Time slice 68
4.1.1.3 Modo kernel y modo usuario 68
4.1.1.4 Performance en SMP 69
a. Coherencia de cache (Cache coherency) 69
b. Afinidad de procesador (Processor affinity) 69
c. Locking 70
4.1.2 Performance de memoria 71
4.1.2.1 Advertencia inicial 71
4.1.2.2 Segmentos de memoria 71
a. La lista libre (Free list) 72
b. Reemplazo de páginas (Page replacement) 72
c. Mecanismo de control de carga de memoria 73
4.1.2.3 Espacio de paginado 73
a. Ajustando el umbral del espacio de paginado 74
4.1.2.4 Pérdidas de memoria (Memory leaks) 75
4.1.2.5 Memoria compartida 75
4.1.3 Performance de I/O de disco 75
4.1.3.1 Advertencia inicial 76
4.1.3.2 El diseño del subsistema de disco 76
4.1.3.3 Consideraciones de performance relativa al ancho de banda 77
4.1.3.4 Diseño del disco 77
a. Tiempo de acceso del disco 78
b. Discos por bus o loop (lazo) del adaptador 79
c. Buffers físicos de disco 79
4.1.3.5 Conceptos del Logical Volume Manager (LVM) 80
4.1.4 Performance de red 81
4.1.4.1 Protocolos TCPI/IP 82
4.1.4.2 Modificación de los parámetros de red 82
4.1.4.3 Tuning de los buffers de red 83
4.2 Herramientas de performance de CPU y memoria 84

4.2.1 El comando sar 84
4.2.1.1 Ejemplo del uso del comando sar 84
4.2.1.2 Sumario del comando sar 88
4.2.1.3 El comando sadc 89
4.2.1.4 Los comandos sa1 y sa2 89
4.2.2 El comando vmstat 90
4.2.3 El comando ps 94
4.2.3.1 Uso del comando ps para estudiar la utilización de CPU 94
a. La columna C 95
b. La columna TIME 95
c. La columna %CPU 96
4.2.3.2 Uso del comando ps para estudiar la utilización de memoria 96
a. La columna SIZE 97
b. La columna RSS 97
c. La columna %MEM 97
4.2.4 El comando tprof 98
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 101
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 performance de I/O de disco 119

4.3.1 Revisión general 119
4.3.2 El comando iostat 119
4.3.2.1 El histórico de I/O de disco 121
4.3.2.2 Reporte de utilización de TTY y CPU 121
4.3.2.3 El comando iostat en sistemas SMP 123
4.3.2.4 Reporte de utilización de disco 123
4.3.3 Análisis de performance del LVM utilizando el lslv 125
4.3.3.1 Atributos del volumen lógico 125
a. Espejado 126
b. Política intra 127
c. Política inter 127
d. Striping 128
4.3.3.2 Fragmentación de volúmenes lógicos 128
4.3.3.3 Asignación de volúmenes lógicos 129
4.3.3.4 La mejor performance del LVM 130
4.3.4 Monitoreo del LVM y file systems 131
4.3.4.1 El comando filemon 131
a. Usando el comando filemon 131
4.3.4.2 Análisis del reporte 132
a. Reporte a nivel archivo lógico 133
b. Reporte a nivel volumen lógico 135
c. Reporte a nivel volumen físico 136
d. Reporte a nivel memoria virtual 137
4.3.4.3 Comportamiento típico del sistema AIX 137
4.3.5 Performance de los file systems 138
4.3.5.1 El comando fileplace 138
4.3.5.2 Desfragmentación de un file system 140
4.3.6 Recomendaciones generales de performance de I/O 141
4.3.7 Consumo de las herramientas de performance 142
4.3.8 Sumario de comandos 142
4.3.8.1 El comando filemon 143
4.3.8.2 El comando fileplace 143
4.3.8.3 El comando lslv 143
4.4 Herramientas de performance de red 143

4.4.1 Visión general 143
4.4.2 Tuning de las colas de transmisión y recepción de los adaptadores 145
4.4.3 Tuning de protocolos 146
4.4.4 Herramientas de monitoreo de la performance de red 148
4.4.4.1 El comando vmstat 148
4.4.4.2 El comando ping 148
4.4.4.3 El comando traceroute 149
4.4.4.4 El comando netstat 149
4.4.4.5 El comando netpmon 151
4.4.4.6 Los comandos tcpdump e iptrace 152
4.4.5 Herramientas para el manejo de la performance de red 154
4.4.6 Resolución de nombres 156
4.4.7 Tuning de la performance de NFS 156
4.4.7.1 Performance del lado del servidor NFS 156
4.4.7.2 Performance del lado del cliente NFS 158
4.4.7.3 Opciones de montaje 158
4.4.8 Sumario de comandos 159
4.4.8.1 El comando netstat 159
4.4.8.2 El comando tcpdump 160
4.4.8.3 El comando iptrace 160
4.4.8.4 El comando ipreport 160
4.5 Herramientas específicas para el manejo de performance 160

4.5.1 El scheduler de AIX 160

4.5.1.1 Cálculo de prioridad en versiones de AIX anteriores a la 4.3.2 161
4.5.1.2 Cálculo de prioridad en AIX Versión 4.3.2 y posteriores 163
4.5.2 Colas de ejecución múltiples con balanceo de carga en AIX Versión 4.3.3 164
4.5.2.1 Balanceo de carga inicial 165
4.5.2.2 Balanceo de carga idle 165
4.5.2.3 Balanceo de carga periódico frecuente 166
4.5.2.4 Balanceo de carga periódico infrecuente 166
4.5.3 Manejo de la performance del scheduler 166
4.5.3.1 El comando schedtune 166
a. Primer ejemplo de schedtune 166
b. Segundo ejemplo de schedtune 167
c. Tercer ejemplo de schedtune 167
d. Lineamientos generales de SCHED_R y SCHED_D 168
e. Sumario del comando schedtune 168
4.5.3.2 Los comandos nice y renice 168
a. Ejecutando un comando con nice 169
b. Cambiando el valor nice de un thread en ejecución 169
c. Sumario de los comandos nice y renice 170
4.5.4 El comando bindprocessor 170
4.5.5 El comando vmtune 171
4.5.6 Workload Manager 174
4.6 Escenarios de performance 175

4.6.1 Escenario de performance de CPU 175
4.6.1.1 Colección de datos 175
4.6.1.2 Análisis de datos 176
4.6.1.3 Recomendación 177
4.6.2 Escenario de performance de I/O 177
4.6.2.2 Análisis de datos 179
a. Análisis de la salida del comando vmstat 180
b. Análisis de la salida del comando iostat 180
4.6.3 Escenarios de I/O adicionales 180
4.6.3.1 I/O wait de CPU y threads del kernel 180
4.6.3.2 Distribución de I/O 181
4.6.3.3 Fragmentación de un volumen lógico 182
4.6.3.4 Monitoreando el escenario utilizando filemon 183
4.6.3.5 Asignación de volumen lógico 184
4.6.4 Escenario de performance del paginado 186
4.6.4.2 Análisis de los datos 192
a. La columna kthr (kernel thread) 192
b. La columna de memoria 192
c. La columna page 192
d. La columna faults 193
e. La columna cpu 193
5. Resolución de problemas de red TCP/IP 194
5.1 Identificar un problema genérico de red 194
5.2 Pasos para aislar un problema de red TCP/IP 194

5.2.1 Problemas de red en un host determinado 194
5.2.2 No hay acceso a la red 194
5.2.3 Problemas en la resolución de nombres 195
5.2.4 Análisis de un problema de ruteo 195

5.2.5 Ruteo estático o dinámico 196

5.2.6 Problemas con las interfases de red 198
5.2.6.1 Análisis genérico de interfases 198
5.2.6.2 Problemas de interfase enthernet 199
5.2.6.3 Problemas de interfase token-ring 200
5.2.6.4 Problemas con interfases ATM o ATMLE 200
5.2.6.5 Problemas con interfases X.25 204
5.3 Problemas de TCP/IP más comunes 205

5.3.1 LED 581 206
5.3.2 Problemas con telnet 207
5.3.3 Retrasos del login en sistemas AIX 4.3.x 208
5.3.4 Problemas de DHCP (Dynamic Host Configuration Protocol) 208
5.3.5 Teclas de función de X.25 no funcionan correctamente 209
5.4 Asuntos de configuración de TCP/IP 209

5.4.1 Maximum Transmission Protocol (MTU) 209
5.4.2 Mbufs 210
5.5 Comandos para identificar un problema de TCP/IP 210

5.5.1 ping 210
5.5.2 rup 211
5.5.3 netstat 211
5.5.4 arp 213
5.5.5 iptrace e ipreport 213
5.5.6 tcpdump 214
5.5.7 no (Network Options) 214
5.5.8 Comandos stat 214
5.6 Resolución de problemas de NIS (Network Information Services) 215

5.6.1 Herramientas para la resolución de problemas de NIS 215
5.6.1.1 ping 215
5.6.1.2 rpcinfo 215
5.6.1.3 ypmatch 216
5.6.1.4 ypwhich 217
5.6.2 Ejemplos de resolución de problemas con NIS 218
5.6.2.1 yppush falla al crear mapas nuevos 218
5.6.2.2 Los broadcast de clientes no vinculan 218
5.6.2.3 El comando ypwhich es inconsistente 219
5.6.2.4 Mapas muy largos no son soportados 219
5.6.2.5 Routers, dispositivos de red, y vinculación NIS 219
5.6.2.6 Grupos incorrectos por cambios en un grupo nuevo 220
5.6.2.7 mkdbm dalla para entradas de mapas NIS muy grandes 220
5.7 Resolución de problemas de NFS (Network File Systems) 220

5.7.1 Pasos generales para solucionar un problema de NFS 220
5.7.2 Problemas de montaje en NFS 221
5.7.2.1 Montajes soft y montajes hard 222
5.7.3 Problemas de performance de NFS 223
5.7.3.1 Empeorando el rendimiento del cliente para redes o servidores lentos 226
5.7.4 Fallas de locking 227
5.7.4.1 Iniciando el rpc.lockd con depuración 227
5.7.5 Un cliente NFS se detiene durante el reinicio del sistema 228
5.8 Depuración de SLIP (Serial Line Internet Protocol) 228

5.9 Depuración de PPP (Point-to-Point Protocol) asincrónico 230

5.9.1 AIX como cliente PPP (llamadas salientes) 230
5.9.1.1 Chat scripts (scripts de conversación) 232
5.9.1.2 Problemas de autenticación 232
5.9.2 AIX como servidor PPP (llamadas entrantes) 233
6. Resolución de problemas de impresión 234
6.1 Pasos a seguir para resolver problemas comunes 235

6.1.1 Pasos a seguir en problemas de impresión local 235
6.1.2 Pasos a seguir en problemas de impresión remota 235
6.1.3 Revise lo obvio 236
6.1.4 Nada se imprime en impresoras locales 236
6.1.4.1 Mi trabajo se perdió, pero otros son impresos 236
6.1.4.2 Nada se imprime, pero las luces en la impresora parpadean o cambian 237
6.1.4.3 Nada llega a la impresora 238
6.1.4.4 ¿Hay espacio suficiente en el file system del spool? 241
6.1.4.5 Nada se imprime, pero se obtiene un mensaje de error 242
6.1.5 La salida es basura o está incompleta 242
6.1.5.1 ¿Los parámetros del puerto son correctos? 242
6.1.5.2 ¿Los tabuladores están configurados correctamente? 242
6.1.5.3 ¿Se imprime únicamente la primera línea o líneas escalonadas? 242
6.1.5.4 ¿La impresora funciona bien por un tiempo y luego mal? 243
6.1.5.5 ¿Hay problemas imprimiendo gráficos? 244
6.1.5.6 ¿El tipo de impresora es el correcto? 244
6.1.6 El espaciado es incorrecto 244
6.1.6.1 Espaciado doble 245
6.1.6.2 Sin margen izquierdo 245
6.1.7 La impresión con una fuente incorrecta 245
6.1.7.1 ¿El archivo es PostScript o PCL formateado? 245
6.1.7.2 ¿Cuál es la fuente por defecto de la impresora? 245
6.1.7.3 ¿Qué fuentes están instaladas en la impresora? 246
6.1.7.4 ¿El programa interfase o el backend de impresión fijan la fuente? 246
6.1.7.5 ¿Qué fija la variable LANG? 246
6.1.8 El trabajo de impresión pide un tamaño de papel equivocado 247
6.1.9 El trabajo de impresión por red falla 247
6.1.9.1 Los trabajos de impresión quedan encolados en la cola local 247
6.1.9.2 ¿Está configurado el tiempo de espera para la impresión remota
con System V? 249
6.1.9.3 Los trabajos de impresión quedan en la cola remota 249
6.1.9.4 Los trabajos de impresión desaparecen 249
6.2 Técnicas de resolución de problemas comunes 250

6.2.1 Utilizando lptest para generar archivos de impresión 250
6.2.2 Use enscript para generar PostScript 251
6.2.3 Use splp para ver los dispositivos especiales 251
6.2.4 Imprimiendo a un archivo 251
6.2.5 Imprimiendo directamente al archivo del dispositivo especial 251
6.2.6 Imprimiendo directamente en impresoras de red 252
6.2.6.1 Imprimiendo directamente en una impresora conectada a LPD 252
6.2.6.2 Imprimiendo directamente en una impresora conectada a HP JetDirect 252
6.2.6.3 Telnet a impresoras JetDirect 252
6.2.7 Utilizando iptrace para rastrear una impresión de red 253
6.2.8 Capturando archivos 253
6.2.8.1 Capturando el archivo antes de que pase por la cola 253
6.2.8.2 Capturando un archivo después de que pasó por la cola 254

6.2.8.3 Capturando un archivo tal como va por la red 254

6.2.8.4 Capturando un archivo en el sistema remoto 255
6.2.9 Capturar el flag 255
6.2.9.1 Flags de System V 255
6.2.9.2 Flags de PowerPC 255
6.2.10 Utilizando script para capturar las entradas del usuario 257
6.2.11 Utilizando fuser para encontrar procesos 257
6.2.12 Utilizando el comando echo en scripts shell 258
6.3 Resolución de problemas en el subsistema de impresión System V 258

6.3.1 Problemas de permisos en archivos 258
6.3.2 ¿El servicio de impresión está activo? 258
6.3.3 ¿La impresora tiene los atributos correctos? 258
6.3.3.1 Dispositivo de impresión 259
6.3.3.2 Atributos de la impresora definidos en System V 259
6.3.4 Logs y archivos de estado 259
6.3.4.1 Revise el correo 259
6.3.4.2 Revise los logs en /var/lp/logs 259
6.3.4.3 Verificando el archivo pstatus 260
6.3.5 ¿La variable LANG está configurada correctamente? 261
6.3.6 Trabajos remotos cancelados quedan encolados 261
6.3.7 Imprimiendo en un archivo 261
6.3.8 Limpiando y comenzando de nuevo 262
6.3.8.1 Reiniciar los números de trabajo del subsistema de impresión 262
6.3.8.2 Limpiando archivos de impresión viejos 262
6.3.8.3 Limpiando impresoras viejas 263
6.3.8.4 Elimine los archivos temporales 263
6.3.8.5 Elimine archivos de log viejos 263
6.3.9 Desactivando los banners 263
6.3.9.1 Configuración de los banners 263
6.3.9.2 Evitando los banners por línea de comando 264
6.3.9.3 Evitando los banners con el archivo interfase 264
6.3.10 Resolviendo problemas de scripts interfase en System V 264
6.3.11 Revise los tiempos de espera en el archivo Systems para las colas
remotas 266
6.3.12 ¿Está bien ingresado el nombre del servidor en el archivo
/etc/lp/Systems? 266
6.3.13 Ejemplos: solucionando problemas de impresión remota 266
6.3.13.1 Ejemplo: desaparecen trabajos de impresión de red salientes 266
6.3.13.2 Ejemplo: se pierde un trabajo de impresión remoto entrante 268
6.3.14 Resolviendo problemas de impresión de HP JetDirect 269
6.3.14.1 Permisos de archivo erróneos en el script interfase 269
6.3.14.2 Revise los archivos de log /tmp/hpnpf.* 270
6.3.14.3 Salida escalonada en impresoras PCL 270
6.4 Resolución de problemas en el subsistema de impresión PowerPC 270

6.4.1 Problemas de permisos en archivos 270
6.4.2 ¿El servicio de impresión está activo? 271
6.4.2.1 Iniciando los servicios de impresión 271
6.4.2.2 El qdaemon no permanece activo 271
6.4.3 ¿La impresora tiene los atributos correctos? 271
6.4.3.1 Impresora 272
6.4.3.2 Impresoras virtuales 272
6.4.4 Logs y archivos de estado 272
6.4.4.1 Mensajes de error por línea de comando 272
6.4.4.2 Mensajes por correo 273
6.4.4.3 Mensajes en la consola 273
6.4.4.4 Archivos de mensajes de error de las impresoras virtuales 273

6.4.4.5 Logs de impresiones remotas 273

6.4.4.6 Archivos de descripción del trabajo 274
6.4.4.7 Archivos de estado 275
6.4.5 Imprimiendo en un archivo con el subsistema PowerPC 275
6.4.6 Limpiando y comenzando de nuevo 276
6.4.6.1 Primero se debe encontrar la causa 276
6.4.6.2 Último recurso: limpiar el sistema de impresión 277
6.4.7 Revisando los flags para enq 277
6.4.8 Desactivando los banners 278
6.4.8.1 Configuración de los banners 278
6.4.8.2 Evitando los banners por línea de comando 278
6.4.8.3 Evitando los banners con la impresora virtual 279
6.5 Errores comunes y soluciones 279

6.5.1 Problemas agregando una segunda impresora local en el mismo
dispositivo 279
6.5.2 No se pueden cambiar los atributos porque el dispositivo está ocupado 280
6.5.3 Los trabajos remotos desaparecen después de activar la cola de
impresión 280
6.5.4 Bad mandatory environment variable 280
6.5.5 LOG: is read only 281
6.5.6 No hay suministro de papel luego de la página de encabezamiento 281
Lista de abreviaciones 283
Bibliografía 285

Parte 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
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 prerequisitos 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 prerequisitos, 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 prerequisitos 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.
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)
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 chances 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
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.

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


hdisk1 000bc6fdbff75ee2 testvg
hdisk2 000bc6fdbff92812 testvg
hdisk3 000bc6fdbff972f4 None
hdisk4 000bc6fd672864b9 None
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
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/syncd /u/db01
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.

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:
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
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,
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
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:
lvdb02 jfs 500 1000 2 open/stale /u/db02
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:
El sistema volvió nuevamente a la normalidad.

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

Esta era la asignación de volúmenes físicos antes de que el disco fuese removido:
# lspv
hdisk1 000bc6fdbff75ee2 volg01
hdisk2 000bc6fdbff92812 volg01
hdisk3 000bc6fdbff972f4 volg01
Los volúmenes lógicos en el grupo de volúmenes:

# lsvg -l volg01
volg01:
logvol01 jfs 1000 1000 2 open/syncd /userfs01
La distribución de volúmenes lógicos en los volúmenes físicos era la siguiente:
# lslv -l logvol01
logvol01:/userfs01
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
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 Version 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:
# 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.

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.
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
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
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 la performance 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
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:
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
16- Elimine el espacio de paginado temporal. Ingrese:
rmps paging00
17- Si el dispositivo de dump fue modificado en el paso 8, entonces reestablezca la anterior

configuración. Ingrese:
sysdumpdev -P -p /dev/hd6

Parte 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
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
Para especificar el dispositivo de dump secundario utilice el siguiente comando:
# sysdumpdev -P -s /dev/hd7
primary /dev/hd6
secondary /dev/hd7

3.1.3 Creando un dispositivo de dump
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
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

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 supervisó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

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 lo copia 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
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.

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
detallado del error se puede ver de la siguiente manera:
# errpt -a -j C60BB505
--------------------------------------------------------------------------
LABEL: CORE_DUMP
IDENTIFIER: C60BB505
Date/Time: Wed Jul 5 10:14:59
Sequence Number: 8
Machine Id: 000BC6DD4C00
Node Id: client1
Class: S
Type: PERM
Resource Name: SYSPROC
Description
SOFTWARE PROGRAM ABNORMALLY TERMINATED
Probable Causes
SOFTWARE PROGRAM
User Causes
USER GENERATED SIGNAL
Recommended Actions
CORRECT THEN RETRY
Failure Causes
SOFTWARE PROGRAM
Recommended Actions
RERUN THE APPLICATION PROGRAM
IF PROBLEM PERSISTS THEN DO THE FOLLOWING
CONTACT APPROPRIATE SERVICE REPRESENTATIVE
Detail Data
SIGNAL NUMBER
4
USER'S PROCESS ID:
15394
FILE SYSTEM SERIAL NUMBER
5
INODE NUMBER
2
PROGRAM NAME
netscape_aix4

ADDITIONAL INFORMATION
Unable to generate symptom string.
Too many stack elements.
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, corra el comando crash con los archivos del dump,
utilizando 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
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)"
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 un
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
• 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 tipee 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
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
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.
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.
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.
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:
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:
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
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 |....|

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

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

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

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

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


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
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
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
13 0x60015015 yes 0x0001 0x00000000 TEXT
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)

pcb:0x702fee44 proto:0x04f33f90 q0:0x00000000 q0len:0
timeo:0 error:0 oobmark:0 pgid:0 proc/fd: 23/4

fd 5: 702fe800: type:0x0001 (STREAM) opts:0x0006 (ACCEPTCONN|REUSEADDR)

pcb:0x702fea44 proto:0x04f33f90 q0:0x00000000 q0len:0

pcb:0x702fe644 proto:0x04f33f90 q0:0x00000000 q0len:0

pcb:0x702fe244 proto:0x04f33f90 q0:0x00000000 q0len:0
fd 8: 702d6c00: type:0x0001 (STREAM) opts:0x0006 (ACCEPTCONN|REUSEADDR)

pcb:0x702d6e44 proto:0x04f33f90 q0:0x00000000 q0len:0
fd 10: 7005d800: type:0x0002 (DGRAM) opts:0x0000 ()

state:0x0082 (ISCONNECTED|PRIV) linger:0x0000
pcb:0x7007e880 proto:0x000dfb30 q0:0x00000000 q0len:0
fd 11: 702c6000: type:0x0001 (STREAM) opts:0x0006 (ACCEPTCONN|REUSEADDR)

pcb:0x702c6244 proto:0x04f33f90 q0:0x00000000 q0len:0
fd 12: 70328c00: type:0x0001 (STREAM) opts:0x0006 (ACCEPTCONN|REUSEADDR)

pcb:0x70328e44 proto:0x04f33f90 q0:0x00000000 q0len:0
fd 13: 702d2e00: type:0x0002 (DGRAM) opts:0x0000 ()

pcb:0x700dc480 proto:0x000dfb30 q0:0x00000000 q0len:0
timeo:0 error:0 oobmark:0 pgid:0 proc/fd: 23/0 23/13
fd 14: 70328800: type:0x0001 (STREAM) opts:0x0006 (ACCEPTCONN|REUSEADDR)

pcb:0x70328a44 proto:0x04f33f90 q0:0x00000000 q0len:0

pcb:0x70328644 proto:0x04f33f90 q0:0x00000000 q0len:0
q:0x7000a000 qlen:1 qlimit:1000 head:0x00000000


pcb:0x70328244 proto:0x04f33f90 q0:0x00000000 q0len:0

fd 17: 702d2c00: type:0x0000 () opts:0x0000 ()

state:0x0000 () linger:0x0000
pcb:0x00000000 proto:0x00000000 q0:0x00000000 q0len:0
El ultimo descriptor de archivos (17) es ciertamente un poco extraño. Mientras todos los demás
parecen razonables, el 17 sufre una llamativa escasez de información y datos. Ahora debemos
observar con detenimiento el socket sospechoso con el subcomando socket:
> socket -b 702d2c00

702d2c00: type:0x0000 () opts:0x0000 ()
state:0x0000 () linger:0x0000
pcb:0x00000000 proto:0x00000000 q0:0x00000000 q0len:0
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
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
rcv: cc: 0 hiwat: 0 mbcnt: 0 mbmax: 0

lowat: 0 mb:0x00000000 events:0x 0
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.

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
abend code: 0
csa: 0x0
> status
0 811 8 60c 6 yes gil
1 254d 37 2246 34 yes squid
> cpu
> 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

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

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.

Parte 4
Performance tuning
4.1 Introducción al monitoreo y tuning de performance en AIX
La performance en un sistema computarizado está basada en las expectativas humanas y la

capacidad del sistema para cumplir con dichas expectativas. El objetivo en el tuning de
performance 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 tuning de la performance requiere un alto nivel de conoci-
mientos y experiencia, y no puede ser realizado únicamente analizando estadísticas, gráficos y
figuras. Las percepciones humanas sobre la performance no se deben dejar de lado si ayudan en
la obtención de resultados. En el tuning de performance entrarán en consideración tanto aspectos
de la determinación de problemas como asuntos puramente de performance. 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 tuning de performance puede ser iniciado por varias razones:
• Para lograr un optimización de la performance en un sistema instalado recientemente.
• Para resolver problemas de performance causados durante la fase de diseño (dimensio-

namiento).
• Para resolver problemas de performance que ocurran en la fase productiva.
El tuning de performance 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 un
tuning, o generarán un costo muy alto para poder realizarlo. El sistema no cumplirá con las
expectativas de performance 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 performance para las
cuales fue diseñado, pero las demandas y necesidades de la organización han superado la
capacidad básica del sistema, el tuning de performance es realizado 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 performance 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.

4.1.1 Performance de CPU
Esta sección es una revisión general sobre las operaciones del kernel y la CPU. Para realizar un
monitoreo y tuning satisfactorios, se debe entender la forma en que operan los procesos y los
threads en un entorno AIX.
Los sistemas que presentan problemas de performance, 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 la performance. 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

el concepto de modo usuario y modo kernel, cuando se interpreta la salida de comandos como
vmstat y sar.
4.1.1.4 Performance 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 la mejor performance.
• 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 la performance 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

perjudicar la performance 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
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 performance.
4.1.2 Performance 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 una mala performance 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.
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 de performance, 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
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 la performance 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)


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.

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

• Configuraciones del sistema operativo, por ejemplo striping o espejado
• Implementación de la performance 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 la performance 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 una performance pobre normalmente afecta
severamente la performance 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, la performance general de una aplicación es limitada 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 performante 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:
• Performance contra disponibilidad

Una decisión debe tomarse a tiempo sobre que es más importante; la performance 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 la performance 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 una
performance de I/O aceptable.
• Rendimiento requerido del subsistema de disco

Los requerimientos de performance 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.
• Costo
Aunque no esté relacionado con la performance, 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 performance cuesta más que uno de menor performance.
4.1.3.3 Consideraciones de performance 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 performance son expresados típicamente en rendimiento máximo o pico de rendimiento, lo que
no describe realmente la verdadera performance 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.
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
un track ubicado 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 los tracks 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 El tiempo de transferencia de datos es determinado por el tiempo

transferencia que tarda en moverse el bloque de datos requerido a través del

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 performance de disco, volúmenes lógicos, y file systems a veces llegan a la
conclusión de que a mayor cantidad de discos, mejor la performance 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 de la performance 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 la
performance 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, la performance 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 la performance
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
$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 performance. 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
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 Performance de red
El tuning 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 el tuning 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 performance,
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 performance. 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

Una performance 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. Una pobre performance entre dos sistemas
conectados a la red puede ser provocada 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
/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
ARM utilizando un MTU de 65527) es preferible utilizar ISNO para realizar el tuning 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 Tuning 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.


Dispositivo Velocidad MTU tcp tcp sb_max Rfc1323

Mbits sendspace recvspace
Ethernet 10 1500 16384 16384 32768 0
Ethernet 100 1500 16384 16384 32768 0
Ethernet 1000 1500 131072 65536 131072 0
Ethernet 1000 9000 131072 65536 262144 0
Ethernet 1000 9000 262144 131072 262144 1
ATM 155 1500 16384 16384 131072 0
ATM 155 9180 65536 65536 131072 1
ATM 155 65527 655360 655360 1310720 1
FDDI 100 4352 45056 45056 90012 0
SPSW - 65520 262144 262144 1310720 1
SPSW2 - 65520 262144 262144 1310720 1
HiPPI - 65536 655360 655360 1310720 1
HiPS - 65520 655360 655360 1310720 1
ESCON - 4096 40960 40960 81920 0
Token Ring 4 1492 16384 16384 32768 0
Token Ring 16 1492 16384 16384 32768 0
Token Ring 16 4096 40960 40960 81920 0
Token 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, la
performance 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 performance de CPU y memoria

En esta sección vamos a revisar varias herramientas que ayudan a determinar problemas de
performance 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.
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
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
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
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
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
----- ----------- ------------------------ ------------ -----------
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
----- ----------- ------------------------ ------------ -----------
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 dek 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
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.
- 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
----- ----------- ------------------------ ------------ -----------
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
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
----- ----------- ------------------------ ------------ -----------
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 la

performance 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á
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

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

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
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
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
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
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
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
• El uso de tprof para estudios generales de performance 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

======= === === ===== ====== ==== ====== =====
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
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
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 o tuning.
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 performance.
El comando svmon genera siete tipos de reporte:
• Global
• Usuario
• Proceso
• Segmento
• Segmento detallado
• Comando
• Clase Workload Manager
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

memory 131063 125037 6026 6811 15948
pg space 131072 305
work pers clnt

pin 6820 0 0
in use 21950 103087 0

memory 131063 125847 5216 6811 15949
pg space 131072 305
work pers clnt

pin 6820 0 0
in use 21954 103893 0

memory 131063 126769 4294 6811 15949
pg space 131072 305
work pers clnt

pin 6820 0 0
in use 21954 104815 0

memory 131063 127890 3173 6811 15949
pg space 131072 305
work pers clnt

pin 6820 0 0
in use 21954 105936 0

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:
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
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
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
...............................................................................
3816 1269 175 3535
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
...............................................................................
5024 53 0 3905
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
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.

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
7162 - pers /dev/lv00:17 26650 0 - - 0..100362
0 0 work kernel seg 3790 1265 175 3509 0..32767 :
65475..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
------------------------------------------------------------------------------
...
-------------------------------------------------------------------------------
3452 telnetd 6001 1266 175 4214 N N

0 0 work kernel seg 3790 1265 175 3509 0..32767 :
65475..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
-------------------------------------------------------------------------------
...
-------------------------------------------------------------------------------
6968 rtcmd 3794 1266 175 3513 N N
0 0 work kernel seg 3790 1265 175 3509 0..32767 :
65475..65535
6a0d 2 work process private 4 1 0 4 65314..65535
-------------------------------------------------------------------------------
516 wait 3792 1266 175 3511 N N
0 0 work kernel seg 3790 1265 175 3509 0..32767 :
65475..65535
8010 2 work process private 2 1 0 2 65339..65535
-------------------------------------------------------------------------------
0 3 1 0 3 N N
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
-------------------------------------------------------------------------------
10294 X 6579 1275 175 4642 N N
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
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
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 - -
...
0 0 work kernel seg 3792 1265 175 3511 0..32767 :
65475..65535
500a 2 work process private 122 1 0 122 0..122 :
65306..65535
b156 - pers /dev/hd4:4286 1 0 - - 0..0
d81b 1 pers code,/dev/hd2:10393 9 0 - - 0..8
-------------------------------------------------------------------------------
5682 sendmail: a 6081 1266 175 4136 N N
0 0 work kernel seg 3792 1265 175 3511 0..32767 :
65475..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
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
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
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
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
700e - work kernel pinned heap 1919 624 0 1920 0..65535
63488..65535
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-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
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).
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
...............................................................................
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
...............................................................................


36189 1 0 148
985e - pers /dev/lv00:17 35977 0 - - 0..40307
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
...............................................................................
2117 0 0 301
===============================================================================
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:
# svmon -C ftp -d
===============================================================================
Command ftp Inuse Pin Pgsp Virtual
46435 1266 175 3966
-------------------------------------------------------------------------------
2728 ftp 46435 1266 175 3966 N N
...............................................................................
3798 1265 175 3517
0 0 work kernel seg 3798 1265 175 3517 0..32767 :
65475..65535
...............................................................................
40520 1 0 148
985e - pers /dev/lv00:17 40308 0 - - 0..40307
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
...............................................................................
2117 0 0 301

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

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

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.
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 la performance
empeora en lugar de mejorar, será debido 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.
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
la performance:
# /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 performance de I/O de disco
• Análisis de performance del Logical Volume Manager (LVM), utilizando el comando lslv.
• Herramientas para el análisis de performance 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 performance 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
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

0.0 603.5 91.5 8.5 0.0 0.0

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

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.
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:
...
0.0 223.5 0.2 4.2 70.0 25.5

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 perfor-
mance 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
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 performance 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 de la performance 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.
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 a la performance de discos,
volúmenes lógicos y file systems es que a mayor cantidad de discos en el sistema, mejor es la
performance 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 performance del LVM utilizando el lslv
Hay varios factores que afectan la performance 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
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
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
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 performance, 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 la performance.
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.
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 la mejor performance 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 la
performance 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, la performance de la política intra-disco es la 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 la mejor performance.
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 la performance 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:
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
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 USED 101-109
USED USED USED USED USED USED USED USED USED USED 110-119
USED USED USED USED USED USED USED USED 210-217
USED USED USED USED USED USED FREE FREE FREE FREE 238-247
FREE FREE FREE FREE FREE FREE FREE FREE 318-325
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 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.
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 La mejor performance del LVM
Las siguientes recomendaciones generales pueden ser usadas para crear volúmenes lógicos con
alta demanda de performance. Si embargo, se debe tener en cuenta que cuando un volumen
lógico es configurado para una mejor performance, 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 performance 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 de la performance 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 de la performance.
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:
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-
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
reads: 2048 (0 errs)
FILE: /dev/null
opens: 1
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
reads: 6 (0 errs)
lseeks: 15
FILE: /usr/lib/nls/msg/en_US/dd.cat volume: /dev/hd2 (/usr) inode: 22970

opens: 2


reads: 2 (0 errs)
lseeks: 10
FILE: /usr/lib/nls/msg/en_US/cmdtrace.cat volume: /dev/hd2 (/usr) inode: 22947

opens: 1
reads: 2 (0 errs)
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
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:

...
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
...
Most Active Physical Volumes
------------------------------------------------------------------------
------------------------------------------------------------------------
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.
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

...
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.
4.3.4.3 Comportamiento típico del sistema AIX
Cuando se utiliza el comando filemon para el análisis de performance, 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 la
performance.
• 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 una performance crítica.
4.3.5 Performance de los file systems
Hay algunos factores que afectan la performance 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:

- 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 la performance del file system,

lo que influye a su vez en la performance 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.
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
Physical Addresses (mirror copy 2) Logical

Fragment
---------------------------------- ---------------
-
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
impacto negativo en la performance 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 performance 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 una buena performance en file systems y el LVM, y cuándo utilizar las herramientas
descriptas.
Organización de un volumen lógico para obtener la mejor performance:
• 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 la performance de aplicaciones de lectura intensiva, pero como las
escrituras necesitan ser realizadas varias veces, puede impactar en la performance 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
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 a la performance 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 a la performance 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 performance
Como en toda medición de performance 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 la performance 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.
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 la performance 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 performance de red

• Visión general de los problemas de performance de red
• Herramientas de monitoreo de red
• Herramientas de tuning de red
4.4.1 Visión general
Las herramientas de performance 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 de la performance 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:
- 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 Tuning 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:
# 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 Tuning de protocolos
El principal objetivo en el tuning de performance de red es balancear las demandas de los usuarios
dentro de los límites de los recursos para asegurar una performance de red aceptable.
Se puede hacer siguiendo estos pasos:
• Distinguir la carga de trabajo, la configuración y el ancho de banda.

• Medir la performance.
- Utilizar herramientas, identificar cuellos de botella.
- Herramientas útiles son: netstat, tcpdump, iptrace.
• Ajustar los parámetros de red.
- Realizar los ajustes.
- Herramientas de tuning ú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 la
performance 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.
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 la performance 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 de la performance de red
Esta sección describe las herramientas de monitoreo mas comúnmente utilizadas para aislar los
problemas de performance 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
----- ----------- ------------------------ ------------ -----------
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
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

^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
performance. Es útil para determinar la cantidad de tráfico en la red, y por lo tanto, para determinar
si los problemas de performance 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
# 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 type inuse calls failed memuse memmax mapb

mbuf 16 41218 0 4096 19712 0
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

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 la performance 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
El siguiente ejemplo muestra como la operación de red puede impactar en la performance 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]
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)
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 manejo de la performance 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
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 tuning, 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,
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 Tuning de la performance de NFS
En esta sección se ven temas relacionados con la performance de clientes y servidores NFS.
4.4.7.1 Performance del lado del servidor NFS
Cuando los problemas de performance 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 datagrams dropped due to no socket
0 socket buffer overflows

11983 delivered
11663 datagrams output
(En este sistema el tamaño del buffer era suficiente)
Normalmente, los paquetes NFS serán descartados en el buffer del socket únicamente cuando un
servidor tiene mucho tráfico NFS de escritura. El servidor NFS utiliza un socket UDP y un socket
TCP conectados al puerto NFS, y todos los datos entrantes son alojados en esos puertos.
El tamaño por defecto de ese buffer es 60000 bytes. Dividiendo ese número por el tamaño por
defecto de un paquete NFS Versión 3 (32765), se puede ver que con sólo 2 paquetes simultáneos
se sobrepasa el tamaño del buffer. Esto puede ser realizado por tan sólo un cliente NFS (con la
configuración por defecto). No es tan fácil como parece el hecho de sobrepasar el límite del buffer
durante la operación normal del sistema. Tan rápido como el primer paquete llega al socket, un
nfsd estará atento para tomar los datos.
Una de dos cosas debe ocurrir para que haya pérdida de paquetes. Debe haber un gran volumen
de datos o una gran explosión de tráfico para que los paquetes comiencen a ser rechazados. Si
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 performance 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 Performance del lado del cliente NFS
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, la performance 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 la performance.
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 performance 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:
# 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
4.5 Herramientas específicas para el manejo de performance
• 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
----- ----------- ------------------------ ------------ -----------
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
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
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
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 el tuning de la
performance: 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
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
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 de la performance 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
El tuning 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 un tuning de
performance 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.
• 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-
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
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 &

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


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.
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 - - -
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.
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 la performance 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 una lenta performance 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.
-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 de la
performance 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
o igual al minpgahead. El valor por defecto es 8. Incrementar este número
ayudará a mejorar la performance 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 una mejor performance debido a la menor dependencia del
daemon sync para forzar las escrituras a disco. Algunas aplicaciones
pueden empeorar su performance 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.
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 performance

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 performance de CPU
En esta sección, se muestra un problema de performance 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:

0.0 328.5 100.0 0.0 0.0 0.0


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

0.0 332.1 100.0 0.0 0.0 0.0

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

thomasc 15860 12948 93 10:30:49 pts/1 17:41 ./tcprg5
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

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


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
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 a la performance, 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 de performance 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 performance 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.
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

0.0 41.4 61.1 0.1 38.9 0.0

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

0.9 52.6 2.7 20.1 43.3 33.9

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

1.0 0.0 0.0 12.0 0.0 88.0

hdisk0 29.0 1616.0 101.0 0 1616
hdisk1 100.0 2164.0 108.0 1656 508
cd0 0.0 0.0 0.0 0 0

1.0 58.0 0.0 6.0 0.0 94.0

hdisk0 25.0 660.0 50.0 0 660
hdisk1 100.0 1108.0 111.0 672 436
cd0 0.0 0.0 0.0 0 0

2.0 58.0 0.0 6.0 0.0 94.0

hdisk0 18.0 208.0 21.0 4 204
hdisk1 100.0 1552.0 114.0 316 1236
cd0 0.0 0.0 0.0 0 0

2.0 94.0 0.0 12.0 0.0 88.0

hdisk0 18.0 232.0 28.0 0 232
hdisk1 98.0 808.0 111.0 312 496
cd0 0.0 0.0 0.0 0 0

1.0 47.0 0.0 6.0 0.0 94.0

hdisk0 12.0 80.0 20.0 4 76
hdisk1 100.0 804.0 105.0 188 616

cd0 0.0 0.0 0.0 0 0

2.0 94.0 0.0 9.0 0.0 91.0

hdisk0 17.0 216.0 21.0 0 216
hdisk1 100.0 916.0 103.0 328 588
cd0 0.0 0.0 0.0 0 0

2.0 48.0 0.0 13.0 0.0 87.0

hdisk0 18.0 184.0 19.0 0 184
hdisk1 99.0 1728.0 120.0 244 1484
cd0 0.0 0.0 0.0 0 0

1.0 1.0 0.0 20.8 0.0 79.2

hdisk0 8.9 67.3 13.9 4 64
hdisk1 100.0 3655.4 127.7 136 3556
cd0 0.0 0.0 0.0 0 0

11.0 11.0 0.0 6.0 0.0 94.0

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
----- ----------- ------------------------- ------------ -----------
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.
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 de la
performance. Para brindar una buena performance, 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.
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á la performance.
• 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 performance de I/O. Los reportes de los
comandos utilizados ayudarán a realizar un tuning 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
----- ----------- ------------------------- ------------ -----------
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
hasta un pico del 92 por ciento en la novena medición. El promedio de tiempo de I/O wait es del 72
%, lo que indica un cuello de botella en I/O.
La columna wa especifica el porcentaje de tiempo que la CPU estuvo idle esperando un I/O local a
disco. Generalmente, un valor wa superior al 25 por ciento indica que el subsistema de disco
puede no estar bien balanceado, o es el resultado de una actividad intensiva de disco. Se debe
revisar el valor b en la columna de thread del kernel. La columna b lista el promedio de thread del
kernel que fueron puestos en la cola de espera por segundo y debería ser cercana a 0. Estos
threads están esperando recursos o I/O. En este caso, el problema no se puede relacionar con la
memoria, ya que los parámetros de paginado están todos en cero y la lista de páginas de memoria
libres (fre) es aceptable.
Para obtener más información sobre dónde ocurre el cuello de botella, se debe ejecutar el
comando iostat. Este provee información sobre cómo el I/O de disco es distribuido entre los
volúmenes físicos.
4.6.3.2 Distribución de I/O
Este escenario devuelve las siguientes salidas de los comandos lsps y iostat:
# lsps -a
Page Space Physical Volume Volume Group Size %Used Active Auto Type
hd6 hdisk0 rootvg 256MB 13 yes yes lv
# iostat 120 5
...
47.8 1394.6 50.3 19.6 25.0 5.1

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

47.1 1046.3 45.0 40.0 4.0 11.0

hdisk0 98.5 186.1 56.4 9260 13008
hdisk1 0.6 23.8 18.5 96 332

hdisk2 0.3 0.6 0.1 4 32

39.8 1709.1 30.0 40.0 10.0 20.0

hdisk0 98.3 164.6 55.2 7144 12532
hdisk1 0.2 36.9 26.6 312 904
hdisk2 1.2 2.3 0.5 36 100

32.9 1467.4 30.6 37.4 22.0 10.0

hdisk0 99.8 183.9 22.6 1364 20576
hdisk1 0.6 35.6 16.8 672 464
hdisk2 0.5 1.2 0.3 24 48

33.6 875.5 18.4 41.1 10.5 30.0

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 la performance 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 95-95
USED USED USED USED USED USED USED FREE FREE FREE 96-105
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 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
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 de la performance
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 la performance del volumen lógico.
4.6.3.4 Monitoreando el escenario utilizando filemon
Teniendo en cuenta un sistema con los siguientes discos disponibles:

# lspv
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
------------------------------------------------------------------------
------------------------------------------------------------------------
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
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:
# 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:
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:
# lspv -l hdisk3
hdisk3:
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
TYPE: jfs WRITE VERIFY: off
LPs: 1 PPs: 1
MOUNT POINT: /db01 LABEL: /db01
# lslv lv02
LPs: 1 PPs: 1
# lslv lv03
LPs: 1 PPs: 1
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 la performance. De esta
manera, los diferentes file systems no incrementan la carga del hdisk1 para utilizar el jfs log.
4.6.4 Escenario de performance del paginado
En esta sección, se investigará la performance del paginado. Serán descriptos los síntomas de la
utilización excesiva de memoria y las posibles acciones correctivas.
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
----- ----------- ------------------------ ------------ -----------
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:
# vmstat 1 15
----- ----------- ------------------------ ------------ -----------
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
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
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

memory 131063 130942 121 6942 206567
pg space 131072 108647
work pers clnt

pin 6951 0 0
in use 105067 25875 0

memory 131063 130951 113 6942 208406
pg space 131072 110432
work pers clnt

pin 6955 0 0
in use 104809 26127 0

memory 131063 130942 121 6942 206567
pg space 131072 108647
work pers clnt

pin 6951 0 0
in use 105067 25875 0

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
-------------------------------------------------------------------------------
12478 memory 92498 1259 95911 189707 N N
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
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
-------------------------------------------------------------------------------
13796 dd 2829 1260 1100 4303 N N
0 0 work kernel seg 1522 1258 1076 3897 0..32767 :
65475..65535
dc53 - pers /dev/hd3:45 1011 0 - - 0..1010
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
-------------------------------------------------------------------------------
14856 dd 2826 1260 1100 4301 N N
0 0 work kernel seg 1522 1258 1076 3897 0..32767 :
65475..65535
dc53 - pers /dev/hd3:45 1011 0 - - 0..1010
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
949a 3 work shmat/mmap 1 1 0 1 0..0
-------------------------------------------------------------------------------
4994 ksh 1975 1259 1100 4400 N N
0 0 work kernel seg 1522 1258 1076 3897 0..32767 :
65475..65535
7b7c 2 work process private 98 1 0 96 0..115 :
65310..65535
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

-------------------------------------------------------------------------------
15434 ksh 1897 1259 1100 4328 N N
0 0 work kernel seg 1522 1258 1076 3897 0..32767 :
65475..65535
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 - -
-------------------------------------------------------------------------------
16728 -ksh 1897 1259 1103 4324 N N
0 0 work kernel seg 1522 1258 1076 3897 0..32767 :
65475..65535
ef7a 2 work process private 24 1 2 23 0..83 :
65310..65535
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
-------------------------------------------------------------------------------
15808 ksh 1896 1259 1166 4366 N N
0 0 work kernel seg 1522 1258 1076 3897 0..32767 :
65475..65535
cec9 2 work process private 25 1 54 62 0..91 :
65310..65535
2865 - pers /dev/hd2:32343 2 0 - - 0..1
e35c - pers /dev/hd1:19 1 0 - - 0..0
-------------------------------------------------------------------------------
2622 X 1888 1268 1889 5132 N N
0 0 work kernel seg 1522 1258 1076 3897 0..32767 :
65475..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
-------------------------------------------------------------------------------
11402 -ksh 1882 1259 1166 4364 N N
0 0 work kernel seg 1522 1258 1076 3897 0..32767 :
65475..65535
6b0d 2 work process private 18 1 52 59 0..83 :
65310..65535
2865 - pers /dev/hd2:32343 2 0 - - 0..1
3326 - pers /dev/hd4:605 0 0 - - 0..1
-------------------------------------------------------------------------------
5686 -ksh 1872 1259 1106 4304 N N
0 0 work kernel seg 1522 1258 1076 3897 0..32767 :
65475..65535
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
# lsps -a
# lsps -a
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 performance. 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.
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 performance, 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 de performance, 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.
Teniendo en cuenta todos los datos recopilados, las siguientes recomendaciones pueden
implementarse para aliviar la situación:
• 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á la performance.
• 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.

Parte 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
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
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.
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.
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
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
#
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
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.
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:
--------------------------------------
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.

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
?(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
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
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
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.
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
##################################################################
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.
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
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 la performance 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
performance. 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
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
^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.
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
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:
# 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
• 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
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 de
tuning 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
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
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.
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.
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
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, la performance 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.

• 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
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.
• 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 performance de NFS
Lo primero que se determina cuando hay problemas de performance 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.
• ¿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 necesario un tuning del sistema para proveer más
recursos para una performance NFS adecuada, el siguiente paso es poner en el lugar un entorno
controlado para evaluar qué efectos tienen las operaciones de tuning 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 la performance 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 el tuning
de performance 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, el tuning 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
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 performance 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
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
performance. 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-
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 una performance adecuada. 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, la
performance debe ser mejorada incrementado la cantidad de biods respecto la valor por
defecto.
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 de la performance.
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.
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 la mejor
performance.
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.
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
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
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"
• 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).
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:
• 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

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

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

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

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.
¿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
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
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
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-
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
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
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:
• 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,

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:

# 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
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?

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.

¿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

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

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
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.
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
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].
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.
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:
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á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
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)
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
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.
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”
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
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
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 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:

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

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

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=

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

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

Lista de abreviaciones
AC Alternating Current HP Hewlett-Packard
ACL Access Control List HPF High Performance FORTRAN
AIX Advanced Interactive eXecutive HTTP Hypertext Transfer Protocol
ANSI American National Standards I/O Input/Output
Institute IAR Instruction Address Register
APAR Authorized Program Analysis IBM International Business Machines
Report Corporation
ARP Address Resolution Protocol ICMP Internet Control Message Protocol
ASCI Accelerated Strategic Computing ID Identification
Initiative IDE Integrated Device Electronics
ASCII American National Standards Code IDS Intelligent Decision Server
for Information Interchange IGMP Internet Group Management
ATE Asynchronous Terminal Emulator Protocol
ATM Asynchronous Transfer Mode IP Internet Protocol
ATMLE ATM LAN Emulation IPL Initial Program Load
BFF Backup File Format JDF Job Description File
BI Business Intelligence JFS Journaled File System
BIND Berkeley Internet Name Daemon LAN Local Area Network
CAE Computer-Aided Engineering LECS LAN Emulation Configuration
CD Compact Disc Server
CDE Common Desktop Environment LED Light Emitting Diode
CD-ROM Compact Disc Read Only Memory LES LAN Emulation Server
CE Customer Engineer LP Logical Partition
CPI Characters Per Inch LPD Line Printer Daemon Protocol
CPU Central Processing Unit LPP Licensed Program Product
CSS Communication Subsystems LR Link Register
Support LUM Licence Use Management
CTS Clear To Send LV Logical Volume
DAR Data Address Register LVCB Logical Volume Control Block
DAR2 Secondary Data Address Register LVDD Logical Volume Device Driver
DBM Database Manager LVID Logical Volume Identifier
DE Dual-Ended LVM Logical Volume Manager
DFS Distributed File System MAC Medium Access Control
DHCP Dynamic Host Configuration MCA Micro Channel Architecture
Protocol MSS Maximum Segment Size
DMA Direct Memory Access MST Machine State Save Area
DNS Domain Name Server MTU Maximum Transfer Unit
DSI Data Storage Interrupt NFS Network File System
DSIRR Data Storage Interrupt Reason NIS Network Information Service
Register NUA Network User Address
DSISR Data Storage Interrupt Status ODM Object Data Manager
Register OEM Original Equipment Manufacturer
DTE Data Terminal Equipment OLTP Online Transaction Processing
DTR Data Terminal Ready PAP Password Authentication Protocol
EC Engineering Change PCI Peripheral Component Interface
ELAN Emulated LAN PCL Printer Control Language
ESCON Enterprise Systems Connection PDU Power Distribution Unit
(Architecture, IBM System/390) PID Program Identification
FDDI Fiber Distributed Data Interface PJL Printer Job Language
FTP File Transfer Protocol POSIX Portable Operating Interface for
HACMP High Availability Cluster Multi Computing Environments
Processing POST Power-On Self-Test
HiPPI High Performance Parallel POWER Performance Optimization with
Interface Enhanced RISC (Architecture)
HiPS High Performance Switch PP Physical Partition

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

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.

Resolución de Problemas y Soporte Avanzado en AIX v5

Cargado por

Copyright:

Formatos disponibles

Resolución de Problemas y Soporte Avanzado en AIX v5

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Resolución de Problemas y Soporte Avanzado en AIX v5

Cargado por

Copyright:

Formatos disponibles

Resolución de

Andrés Córdoba Rossi

1.1 Proceso de determinación de problemas 11

1.2 Evitar los problemas 14

2. LVM, file systems, y determinación de problemas de disco 16

2.1 Estructuras de datos en el LVM 16

2.2 Determinación de problemas del LVM 17

2.3. Reemplazo de discos 21

2.4 El JFS en AIX 26

2.5 Espacio de paginado 30

Andrés Córdoba Página 2 de 287

2.5.1 Recomendaciones para crear o extender espacios de paginado 31

3.1 Configuración de los dispositivos de dump 35

3.2 Revisando el estado del dump 39

3.3 Core dumps 42

3.4 Introducción al análisis del dump 44

3.5 Observación y análisis de algunos ejemplos 56

4.1 Introducción al monitoreo y tuning de performance en AIX 67

Andrés Córdoba Página 3 de 287

4.1.1.1 Procesos y threads 68

4.2 Herramientas de performance de CPU y memoria 84

Andrés Córdoba Página 4 de 287

4.3 Herramientas de performance de I/O de disco 119

4.4 Herramientas de performance de red 143

4.5 Herramientas específicas para el manejo de performance 160

Andrés Córdoba Página 5 de 287

4.5.1 El scheduler de AIX 160

4.6 Escenarios de performance 175

5. Resolución de problemas de red TCP/IP 194

5.1 Identificar un problema genérico de red 194

5.2 Pasos para aislar un problema de red TCP/IP 194

Andrés Córdoba Página 6 de 287

5.2.5 Ruteo estático o dinámico 196

5.3 Problemas de TCP/IP más comunes 205

5.4 Asuntos de configuración de TCP/IP 209

5.5 Comandos para identificar un problema de TCP/IP 210

5.6 Resolución de problemas de NIS (Network Information Services) 215

5.7 Resolución de problemas de NFS (Network File Systems) 220

5.8 Depuración de SLIP (Serial Line Internet Protocol) 228

Andrés Córdoba Página 7 de 287

5.9 Depuración de PPP (Point-to-Point Protocol) asincrónico 230

6. Resolución de problemas de impresión 234

6.1 Pasos a seguir para resolver problemas comunes 235

6.2 Técnicas de resolución de problemas comunes 250

Andrés Córdoba Página 8 de 287

6.2.8.3 Capturando un archivo tal como va por la red 254

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

6.4 Resolución de problemas en el subsistema de impresión PowerPC 270

Andrés Córdoba Página 9 de 287

6.4.4.5 Logs de impresiones remotas 273

6.5 Errores comunes y soluciones 279

Lista de abreviaciones 283

Andrés Córdoba Página 10 de 287

La intención de este curso es ayudar a los administradores de sistemas y personal de soporte a

1.1 Proceso de determinación de problemas

1.1.1 Definiendo el problema

El primer paso en la resolución de un problema es definir el problema. Es importante que la

Andrés Córdoba Página 11 de 287

1.1.2 Recolectando información del usuario

La mejor manera de entender el problema desde la perspectiva del usuario es realizándole