Curso VzAIX06

AIX PERFORMANCE
c e
a n
o r m e
r f n c
P e m a
I X f o r a
• A e r r m
c e P r f o
a n A I X P e m a
r m c e I X f o r
f o
r rm a n • A e r r
c e P r f o
f o a n A I X P e
e r r m c e I X o
P fo a
Ramón Barrios Lascar

n A r f
• e
2014

e r r m c e P
X P f o n I X
 Le dedico este libro y todo mi trabajo a
la mujer que ha soportado que pase
horas y horas frente a un “jugando” con
computadoras que parecen primitivas.
Tatiana

Marcas registradas
En este documento aparecen una cantidad de términos que son marcas registradas o marcas comerciales de IBM u
otras compañías.
IBM® es una marca registrada de International Business Machines Corporation.
Las siguientes sin marcas registradas de International Business Machines Corporation en los Estados Unidos de
América y otros países:
AIX® DB2® DB2 UDB®
POWER PowerPC® System Power
PowerVM® eServer pSeries
Intel® es una marca registrada de Intel Corporation en los Estados Unidos de América y otros países.
UNIX® es una marca registrada de The Open Group en los Estados Unidos de América y otros países.
Sun y Sun Solaris® son unas marca registrada por Sun Microsystems Corporation en los Estados Unidos de América y
otros países.
Linux® es una marca registrada de Linus Torvalds en los Estados Unidos de América y otros países.
Korn Shell es una marca registrada de AT&T en los Estados Unidos de América y otros países.
Edición de junio de 2014. © Ramón Barrios Lascar 2003, 2014. Todos los derechos reservados. Este documento no
puede ser reproducido sin el permiso y consentimiento expreso de Ramón Barrios Lascar.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 2

Contenidos
INTRODUCCIÓN ..................................................................................................................7
OBJETIVOS 7
AUDIENCIA 7
INTRODUCCIÓN AL MANEJO DEL DESEMPEÑO ...................................................................9
EL CONCEPTO GENERAL 9
METODOLOGÍA ..................................................................................................................11
CONCEPTOS DE DESEMPEÑO DE CPU: FUNCIONAMIENTO DEL DESPACHADOR DE MÁQUINAS
VIRTUALES DEL HYPERVISOR POWER................................................................................13
INTRODUCCIÓN Y JUSTIFICACIÓN 13
FUNCIONAMIENTO DEL DESPACHADOR DE MÁQUINAS VIRTUALES POWERVM 15
Arquitectura De Los Procesadores IBM Power 15
Configuración De Procesadores Virtuales En VMs De Procesador Compartido/Virtualizado 16
Configuración Del Valor De Ilimitado En VMs De Procesador Compartido/Virtualizado 17
CONCEPTOS DE DESEMPEÑO DE CPU: FUNCIONAMIENTO DEL DESPACHADOR DE TAREAS DE
AIX ...................................................................................................................................20
EL SCHEDULER O DESPACHADOR DE TAREAS DE AIX 20
MONITOREO DE DESEMPEÑO DE AIX: MONITOREO DEL CONSUMO DE CPU .......................25
SÍNTOMAS GENERALES DEL EXCESIVO USO DE CPU 25
MONITOREO DE DESEMPEÑO DE AIX: COMANDOS ............................................................27
COMANDO SAR -U 27
COMANDO LPARSTAT 31
COMANDO VMSTAT -W 35
COMANDO TPROF 37
Reporte De Tprof 38
COMANDO TOPAS 41
PARAMETRIZACIÓN DEL DESPACHADOR DE TAREAS DE AIX..............................................45
COMANDO CHDEV 45
COMANDO SCHEDO 47
CONCEPTOS DE DESEMPEÑO: FUNCIONAMIENTO DEL MANEJADOR DE MEMORIA VIRTUAL DE
AIX....................................................................................................................................51
EL VMM O MANEJADOR DE MEMORIA DE AIX 51
CONCEPTOS: MANEJADOR DE MEMORIA VIRTUAL 51
Asignación Postergada 51
CONCEPTOS: PÁGINAS Y PAGINACIÓN 52
Fallas De Página (page Faults) 52
Páginas Grandes De Memoria 53
Clasificación Según Tipos De Consumo 54
Paginación A Disco 55
Paginación A Disco: Archivos 56
CONCEPTOS DE MEMORIA: LÍMITES, PARÁMETROS Y VALORES 59
Minfree 59
Maxfree 59
Mempools 59
Maxperm 60
Minperm 60

AIX Performance ● Ramón Barrios Lascar ® Ínodo 3

 Maxclient 61
Npswarn 62
Npskill 62
Nokilluid 63
CONCEPTOS DE DESEMPEÑO: MONITOREO DE DESEMPEÑO DE MEMORIA .......................65
MONITOREO DE DESEMPEÑO DE MEMORIA RAM 65
MONITOREO DE DESEMPEÑO DE ESPACIOS DE PAGINACIÓN 67
Interpretación 67
MONITOREO DE DESEMPEÑO DE MEMORIA: COMANDOS..................................................69
COMANDO VMSTAT -W 69
COMANDO VMSTAT -S 75
COMANDO VMSTAT -V 79
COMANDO SVMON -G 83
COMANDO SVMON -P 87
COMANDO LSPS 91
COMANDO TOPAS 93
PARAMETRIZACIÓN DEL VMM DE AIX ...............................................................................95
COMANDO VMO 95
CONCEPTOS DE DESEMPEÑO DE I/O: FUNCIONAMIENTO DEL LVM ....................................99
EL LVM O LOGICAL VOLUME MANAGER DE AIX 99
CONCEPTOS DE ARQUITECTURA DE I/O DE BAJO NIVEL EN POWER 99
ALGUNOS PARÁMETROS IMPORTANTES DE I/O A BAJO NIVEL 101
Colas De Tareas En Disco 101
Colas De Tarea De Adaptadora 102
MONITOREO DEL DESEMPEÑO DEL LOGICAL VOLUME MANAGER: COMANDOS ................103
COMANDO IOSTAT -D 103
COMANDO IOSTAT -A 107
COMANDO SAR -D 109
COMANDO TOPAS 111
COMANDO LVMSTAT 115
COMANDO VMSTAT -V 119
COMANDO LVMO -A 121
COMANDO FCSTAT 123
PARAMETRIZACIÓN DEL LVM DE AIX................................................................................125
COMANDO CHDEV 125
COMANDO LVMO 127
COMANDO IOO 129
CONCEPTOS DE DESEMPEÑO DE AIX: MANEJADOR DE ARCHIVOS DE AIX ........................133
MANEJADOR UNIFICADO DE ARCHIVOS DE AIX 133
MONITOREO DE DESEMPEÑO DE AIX: MANEJADOR DE ARCHIVOS DE AIX........................135
MONITOREO DE DESEMPEÑO DEL MANEJADOR DE ARCHIVOS DE AIX: COMANDOS .........137
COMANDO VMSTAT -V 137
COMANDO SVMON 141
COMANDO FILEMON 143
COMANDO FILEPLACE 147

AIX Performance ● Ramón Barrios Lascar ® Ínodo 4

CONCEPTOS DE DESEMPEÑO DE COMUNICACIONES: REDES IP .......................................149
REDES IP INTEGRADAS 149
Velocidad De Transmisión Del Medio Físico 151
MTU: Unidad Máxima De Transmisión 151
MONITOREO DE DESEMPEÑO DE REDES: IP .....................................................................153
MONITOREO DE REDES IP: COMANDOS............................................................................155
COMANDO NETSTAT -I 155
COMANDO NETSTAT -I 157
COMANDO NETSTAT -A 159
COMANDO NETSTAT -M 163
COMANDO NETSTAT -D 167
COMANDO PING 169
Cómo Se Usa Ping Flood? 169
Cómo Se Usa TCPING? 170
Cómo Se Usa NetCat? 171
Cómo Se Usa Spray? 172
COMANDO HOST 175
PARAMETRIZACIÓN DEL SISTEMA DE REDES IP ...............................................................177
COMANDO NO 177
COMANDO IFCONFIG 187
COMANDOS NSLOOKUP Y DIG 189

AIX Performance ● Ramón Barrios Lascar ® Ínodo 5

AIX Performance ● Ramón Barrios Lascar ® Ínodo 6
Introducción
Objetivos
El presente curso pretende mostrar, explicar y poner en práctica una serie de conceptos,
herramientas, comandos y prácticas que permitan obtener, observar, analizar y ajustar
el desempeño de servidores IBM Power corriendo IBM AIX v6.1 y v7.1 y tal vez IBM
PowerVM VIOS también.
Al tomar este curso y aprender lo que aquí se pretende, el estudiante logra los
conocimientos necesarios para reportar y diagnosticar situaciones de desempeño de
servidores y tal vez tomar acciones correctivas.

Audiencia
Este libro y el curso relacionado está dirigidos a profesionales de sistemas con
experiencia con servidores IBM Power corriendo bajo AIX v6.1 y v7.1, que necesitan de
administrar servidores de manera que obtengan el máximo desempeño en sus tareas y
servicios sin poner en riesgo la estabilidad de los mismos.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 7

AIX Performance ● Ramón Barrios Lascar ® Ínodo 8
Introducción al Manejo del Desempeño
El concepto general

AIX Performance ● Ramón Barrios Lascar ® Ínodo 9

AIX Performance ● Ramón Barrios Lascar ® Ínodo 10
Metodología

CPU

Network Memory

Disk I/O

En general, existen diversas maneras de atacar las situaciones relacionadas con el

manejo del desempeño pero en general el primer punto de todos se resume a:
Establecer una línea base
Sin esa línea base no podremos saber realmente qué está bien y qué no.
El segundo punto a tener en cuenta se resume a:
Usar siempre la misma metodología y las mismas herramientas
Como todas las herramientas que se usan para hacer las mediciones y obtener las
estadísticas son comandos que corren en el mismo servidor, y usando los mismos
recursos (CPU, RAM, I/O) que los demás procesos del sistema, afectan de la misma
manera que otros procesos, por los que el simple hecho de mostrar unos indicadores
afectará los mismos —es algo prácticamente cuántico—, es decir, es imposible obtener
unas mediciones sin afectar —así sea muy poco— las mismas mediciones. Si usamos
siempre la misma metodología y las mismas herramientas, las mediciones serán
afectadas de la misma manera y en la misma proporción, por lo que al menos, podrán
ser comparables.
Nótese, que lo que buscamos en este documento, y en el curso relacionado es lograr
unos resultados comparables y no tanto unos resultados absolutos —es decir buscar
unos resultados mejores y no tanto unos resultados con un número exacto dado—.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 11

 En nuestro documento seguiremos el orden mostrado en la gráfica arriba:
1. Hablaremos de conceptos, haremos mediciones, posiblemente ajustaremos
parámetros que relacionados con el despacho, uso y consumo de CPU y turnos
de CPU.
2. Hablaremos de conceptos, haremos mediciones, posiblemente ajustaremos
parámetros que relacionados con la ocupación, uso y consumo de RAM y
memoria en general.
3. Hablaremos de conceptos, haremos mediciones, posiblemente ajustaremos
parámetros que relacionados con el acceso a disco, uso de entrada y salida a
disco a través de buses, controladoras y caminos, y de la actividad de entrada y
salida a disco en general. Esta sección la dividimos en dos partes:
3.1. Entrada y salida cruda —raw— a disco, de bajo nivel, centrándonos en
dispositivos disco, manejadores, controladoras, y LVM.
3.2. Entrada y salida a archivos lógicos. Sistemas de archivos, JFS, JFS2.
4. Hablaremos de conceptos, haremos mediciones, posiblemente ajustaremos
parámetros que relacionados con el acceso a redes, sockets, paquetes,
datagramas y protocolos.
5. Repetición: como es común que medir y ajustar uno de esos temas destape
otros cuellos de botella en las otras áreas, simplemente se repiten completos los
procesos. No los repetimos sólo en las áreas problemáticas, si no todo el
proceso para mantener la metodología, y para mantener las mediciones
comparables, como ya se ha mencionado.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 12

Conceptos de Desempeño de CPU: Funcionamiento del
Despachador de Máquinas Virtuales del Hypervisor Power
Introducción y Justificación
Debido a que, de unos años para acá, todas las máquinas System Power son vendidas
con al menos la licencia de virtualización IBM PowerVM —PowerVM Express las
pequeñas, Standard las grandes—, la mayoría de las máquinas de AIX ahora están
siendo virtualizadas. Esto implica que antes de hablar del uso de CPU dentro de AIX
deberemos hablar del uso compartido de CPU dentro de un servidor Power, pero por
fuera del ambiente AIX. De esto se trata este apartado.
Debido que es más flexible y manejable, las últimas recomendaciones apuntan a
expresar que casi siempre es mejor subdividir los servidores IBM System Power en
múltiples ambientes —lo que antes se llamaban LPARs y ahora VMs— donde cada una
usa los procesadores asignados de manera “procesadores virtualizados” —shared
processors—, aunque realmente no los vaya a compartir con otros ambientes —con
otras LPARs o VMs—. De qué se trata esto?
! Una VM que no se define con Shared Processors, esto es con Dedicated
Processors, no permite definirla con procesadores virtuales, así verá siempre
cinco Power cores como cinco, no se les podrán hacer simular otra cantidad, y
esto es muchas veces beneficioso desde el punto de vista del desempeño.
! Una VM que se define con Dedicated Processors no se puede configurar
ilimitada —uncapped—, y a veces, desde el punto de vista del desempeño es
muy deseable.
! Una VM que se define con Dedicated Processors con N cores, y una VM que se
define con Shared Processors con N.00 cores titulados, donde esta última
realmente no los comparte con nadie no se diferencian típicamente en más de
un 3% de capacidad de procesamiento real, y nunca en más de un 5% de esto.
! IBM publica unas tablas de referencia de desempeño, con indicadores
“estandarizados” rPerf. Las mediciones para reportar los rPerf, de unos años
para acá IBM las viene haciendo con máquinas divididas en diez VMs, es
decir que usa los servidores como aquí se viene mencionando.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 13

AIX Performance ● Ramón Barrios Lascar ® Ínodo 14
 Funcionamiento del Despachador de Máquinas Virtuales
PowerVM
Habiendo mencionado la justificación del porqué explicar extensamente conceptos
internos del despachador de máquinas virtuales IBM PowerVM, entramos en materia.

Arquitectura de los Procesadores IBM Power

Desde la generación IBM Power5, los procesadores IBM Power han soportado de manera
nativa la virtualización, esto es, simular varios procesadores independientes para
múltiples ambientes de sistema operativo sobre un núcleo de procesador. Para ello, IBM
implementó un esquema de para-virtualización, donde:
! Hay un hypervisor implementado parcialmente en hardware y parcialmente
en firmware. Este hypervisor siempre existe y siempre está activo, aunque se
puede obviar —y usar un servidor con una única instancia de sistema
operativo a la vez—. Este hypervisor implementa un reloj externo preciso con
el que se deben guiar los ambientes de AIX del sistema e implementa un
switchado de turnos de CPU a partir del mismo reloj. En los servidores de
arquitecturas IBM Power5, Power5+, Power6, Power6+ y Power7 el reloj tiene
una precisión de 10ms, y en los Power7+ y Power8 de 5ms.
! El hardware de los procesadores IBM Power incluyen un conjunto de diez
“archivos de registros de bus” (10 bus register files) completos por cada núcleo
(CPU core), y así, de manera nativa y sin traducción por
software manejan diez conjuntos completos de los
registros que AIX —y los otros sistemas operativos NOTA: Lo
s
virtuales procesadores
—
compatibles, Linux on Power e IBM i— necesitan para de despa es decir las línea
ch s
funcionar. Un sistema operativo en Power reporta el existen y o paralelo— sólo
son confi
número de LPAR y el número de archivo de registros de VMs defi gurables
nid en
procesad as como de
bus (bus register file) que necesita. En los servidores or compa
(shared p rti
rocessor) do
Power7+ y Power8 el hardware incluye 20 archivos de
registros de bus, es decir el doble que antes.
! El hypervisor implementa un esquema de turnos por
peso, donde hay 100 turnos de CPU en cada segundo en cada núcleo (100
turnos de 10ms por 1s). Estas características de hardware permiten asignar
CPU de manera porcentual a diferentes ambientes de sistema operativo en un
único núcleo de CPU. En los servidores Power7+ y Power8 hay 200 turnos de
CPU en cada segundo en cada core (200 turnos de 5ms por 1s).
! El hypervisor, debido a los recursos de hardware que
tiene cada núcleo de CPU, puede cambiar que un núcleo
rse que
ejecute las instrucciones de un AIX a instrucciones de D e b e r á recorda n
NOTA : e haga
ios que s
otro AIX en unos pocos microsegundos. los camb reconfiguración
usando la e VMs IBM
d on
! Los AIX no pueden usar los archivos de registros de bus dinámica se pierden si no s
que no se les han asignado de ninguna manera, y así, los Powe r V M erfil a l
s en un p
guardado misma
la
apagarse
AIX Performance ● Ramón Barrios Lascar ® Ínodo 15
 que no se usen —porque o no se están virtualizando los cores o hay menos
ambientes AIX que los que puede manejar la arquitectura— efectivamente
son desperdiciados y no llevarán a aumentar el desempeño de un ambiente
AIX individual.

Configuración de Procesadores Virtuales en VMs de Procesador

Compartido/Virtualizado
Cuando se configura una LPAR o VM para correr con procesadores compartidos/
virtualizados (shared processor), puede configurarse con una asignación decimal de
CPU, esto es, que el hypervisor le asigne una porción porcentual de uno o más núcleos
de procesador para que funcione normalmente (desired CPU entitlement), para que
pueda cambiarse manualmente hacia abajo o cargue si no hay cómo asignarle lo normal
(minimum CPU entitlement), y para que pueda cambiarse manualmente hacia arriba
(maximum CPU entitlement). Esta asignación decimal equivale a lo que el sentido
común nos dice (0.50 de CPU titulada equivale a la mitad de los 100 turnos típicamente
asignables en un núcleo de CPU IBM Power; 1.00 de CPU titulada
equivale a todos los 100 turnos; y 10.00 equivale a 10 veces todos los NOTA: La
c
ilimitada apacidad de crec
m er
100 turnos asignables de un núcleo de procesador Power, que como VM) sólo ente (uncapped
se puede
no es posible se pueden convertir en todos los 100 turnos asignables para VMs definir
d
virtualiza e procesador
de 10 núcleos de procesador Power). (sh
do/comp
arti
ared proc do
VM). essor
Siempre que se define una LPAR o VM con procesadores
compartidos/virtualizados (shared processor) la consola de
administración y el hypervisor obligan a definir a cuántas líneas de
procesamiento paralelas equivalen o simulan los turnos definidos (desired entitlement).
Esas líneas de procesamiento se convierten efectivamente en unidades paralelas de
despacho que IBM típicamente ha nombrado como “CPUs virtuales” (virtual processors).
Como los procesadores físicos sólo pueden manejar 100 turnos por segundo, asignar más
de 100 turnos obliga a definir simultáneamente más de 1 procesador virtual o línea de
despacho. Ahora, por como es la arquitectura de procesadores físicos, por cada 100
turnos se pueden definir hasta 10 líneas de despacho (virtual processors), es decir que
una VM puede tener 100 turnos, o lo que es equivalente, una asignación de 1.00 titulado,
y al mismo tiempo 4 líneas de despacho o lo que es lo mismo, 4 procesadores virtuales
(virtual processors).
Desde el punto de vista del desempeño, si se hace una X asignación de capacidad de
cómputo o CPU titulada (CPU entitlement), se pueden asignar mínimo X (si X es entero,
si no, min(floor(X))) y máximo 10×X (si X es entero, si no,
trunc(10×X)). Cuando los procesos que se ejecutan en el AIX cargado
e en
dentro de la VM —u otro sistema operativo compatible— son muy be teners e
NOTA: De hay software qu
intensos matemáticamente, y con una linealidad compleja, lo más cu e n ta q u e
según los
común es asignar el mínimo de procesadores virtuales posibles; se licencia res virtuales
o
pero cuando dentro del sistema operativo se ejecutan múltiples procesad no los físicos,
id o s y
defi n do se
cargas livianas paralelizables, es más común asignar más p e c ia lm ente cuan
e s as
procesadores virtuales que la asignación de CPU indicaría (de s ilimitad
usan VM Ms)
d V
(uncappe

AIX Performance ● Ramón Barrios Lascar ® Ínodo 16

 int(2×C) a int(5×C), donde C es la CPU titulada). Afortunadamente, si se define la LPAR
o VM con un mínimo de procesadores virtuales de algo así como la mitad de lo definido
como normal, y el máximo como el doble de lo definido como normal, se podría
aprovechar la capacidad de reconfiguración dinámica de AIX, Linux e IBM i para ajustar
este valor sobre la marcha y llegar a un valor adecuado de manera empírica.

Configuración del Valor de Ilimitado en VMs de Procesador Compartido/

Virtualizado
Cuando se configura una LPAR o VM con procesadores virtualizados (shared processor),
puede definirse simultáneamente que pueda crecer en caso de necesidad extrema, esto
es, que aunque se le hayan titulado una cantidad X de turnos de CPU, pueda consumir
temporal y puntualmente más que eso, hasta llegar a N×100 turnos, donde N es el número
de procesadores virtuales que tenga definidos en el momento de la extrema necesidad.
Esta posibilidad se llama de “máquina virtual ilimitada” (uncapped VM). Esos turnos de
procesador los recibirá de manera temporal si el hypervisor nota dos situaciones:
! Hay líneas de procesamiento (procesadores virtuales) asignados a la VM que
los puedan recibir. Así si se tiene definido 1 procesador virtual, lo máximo
que podría recibir es la diferencia entre los 100 turnos que tiene un núcleo de
procesador físico y lo que actualmente está usando la VM. Si tiene, por
ejemplo definidos 5 procesadores virtuales, pero 2.00 de asignación de
procesador —así que normalmente tiene titulados 200 turnos—, podría llegar
hasta 5×100, 500 turnos, en caso de que los hubiere, recibiendo como adicional
los 300 turnos que son la diferencia entre los 200 que tiene y los 500 que puede
llegar a manejar.
! Hay turnos de procesador físico disponibles, primero en los mismos núcleos
de procesador físico donde ya está funcionando, segundo en el pool de
procesamiento compartido donde inició, y por último en cualesquiera de
todos los otros pools de procesamiento compartido que existan definidos en
el servidor físico.
! Cuando hay múltiples VMs funcionando en el mismo servidor físico que sean
de procesadores virtualizados, que también estén creadas con la posibilidad
de crecer (ilimitadas o uncapped), entra en juego el valor de obligatoria
definición “peso de la VM” (VM weight). Este valor se usa para definir cómo se
reparten los turnos libres entre todas las VMs que estén “hambrientas de
CPU”. Si varias VMs tienen el mismo peso, los turnos libres de CPU adicional
se reparten en igualdad de condiciones entre todas —todas las
“desesperadas”—, y si una tiene el doble de peso que otra, la primera recibirá
el doble de turnos de CPU adicional que la segunda, y así.
Como se podrá imaginar el lector, favorecerá al desempeño del AIX y de los procesos
dentro de una VM que esta pueda crecer en asignación de CPU cuando se encuentre en
situaciones de máxima necesidad por máxima carga y consumo interno de CPU.
Ejemplo:

AIX Performance ● Ramón Barrios Lascar ® Ínodo 17

 Si una VM se define con 1.00 de procesador titulado y 10 procesadores virtuales —10
líneas de procesamiento paralelas— con esos 100 turnos (1.00 de procesador), si se
configura no ilimitada (no uncapped) o con peso 0, que es lo mismo, sin importar la
carga, consumirá 100 turnos en cada 1s de ejecución física del servidor. En cambio, si se
define con el mismo 1.00 de procesador titulado y los mismos 10 procesadores virtuales
—las mismas 10 líneas de procesamiento paralelas—, con esos 100 turnos de procesador
y configurada como ilimitada (uncapped), cuando tenga mediana carga usará 100 turnos
de procesamiento por segundo, pero con máxima carga tenderá a consumir hasta 10×100,
1000 turnos de procesamiento por segundo (es decir 10.00 de CPU), si los hay libres en
todo el servidor y si no hay otra VM uncapped que le compita.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 18

AIX Performance ● Ramón Barrios Lascar ® Ínodo 19
Conceptos de Desempeño de CPU: Funcionamiento del
Despachador de Tareas de AIX
El scheduler o Despachador de Tareas de AIX
Apenas AIX inicia, como muchos otros sistemas operativos arma unas colas de ejecución
de hilos de proceso. En el caso del despachador de AIX se manejan varias ideas:
! El despachador de tareas (scheduler) de AIX arma una cola dinámica de
ejecución por cada procesador lógico que vea.
! El despachador de tareas inserta nuevos procesos o hilos de ejecución según
una variable de ambiente (AIXTHREAD_SCOPE) que define si se insertan los
procesos completos con sus hilos de ejecución como un único objeto
despachable (AIXTHREAD_SCOPE=P) o cada hilo de ejecución es un único objeto
despachable (AIXTHREAD_SCOPE=S). El valor predeterminado para la variable
(como cuando no está definida) es P. Cuando un proceso tiene muchos hilos,
el despachador maneja cada 12 hilos de proceso como un único objeto
despachable (esto debido a que la variable AIXTHREAD_SLPRATIO=12 de manera
predeterminada)
! Todos los procesos e hilos tienen prioridad. La prioridad de un proceso se usa
como el valor predeterminado para todos sus hilos internos de ejecución. La
prioridad de un proceso o hilo resulta de la suma de la prioridad base más el
valor nice más una penalización de CPU. La prioridad base predeterminada
en AIX 5 y posterior es 40, el número nice predeterminado si el usuario del
proceso usa Korn Shell es 20 para los procesos interactivos y 24 para los que
se ejecutan en background, y la penalización la recalcula
dinámicamente el despachador como se mencionará a
úmero de
continuación. Las prioridades en AIX recientes son A : A u nque el n tero
N OT n en
la p r io ridad es u lo muestra
números enteros entre 0 y 255. 0 y 255,
AIX
entre y 127
o s i fu e se entre 0
! Las prioridades son dinámicas, a menos que un proceso com
tener la
use una de las funciones setpri(), setpriority(), para man idad histórica.
il
compatib
thread_setsched() o nice() para que el despachador le
asigne una prioridad fija. Estas funciones siempre
retornan exitoso, pero el despachador sólo asigna prioridades fijas a procesos
si la función la invoca un proceso de usuario root. Adicionalmente, con esas
funciones un proceso puede solicitar una prioridad con número menor, pero
el despachador, de igual manera, sólo asigna prioridades de menor número
que la corriente si la función la invoca un proceso de usuario root.
! Para el despachador, un proceso con menor número de prioridad menor es
más importante en el sistema, ya que el mismo comienza con la prioridad 0 al
buscar hilos de ejecución para activar/ejecutar. Cuando termina con los hilos
con prioridad N el despachador revisa los hilos de prioridad N+1, si los hay, y

AIX Performance ● Ramón Barrios Lascar ® Ínodo 20

 así. El despachador sólo revisa hilos que sean ejecutables, y no aquellos que
están dormidos, detenidos, en espera de I/O o en espera de RAM.
! El reloj de hardware del sistema hace “tick” cada 10ms, y de manera
predeterminada cada 1 tick el despachador de tareas del sistema detiene
todas las tareas que se manejen con la política predeterminada (que es
SCHED_OTHER) y revisa si las instrucciones que se ejecutaban eran de nivel
usuario/aplicación o de nivel sistema/kernel. Si eran de nivel usuario/
aplicación, el despachador asigna Penalización=Penalización+1 (recordando
que la prioridad final para términos de turnos de despacho es PrioridadBase
+NúmeroNice+Penalización), si las instrucciones que se estaban ejecutando al
finalizar el turno eran de sistema/kernel, la penalización no se afecta. Con
este esquema, las aplicaciones que consumen turnos de CPU y tienen
instrucciones típicas de código de aplicación tienden a aumentar en prioridad
final, ya que aumentan en el número Penalización. Si una aplicación invoca
una función incluida con el sistema base, de núcleo, o de librería base de
funciones (típicamente read(), write(), fread(), fwrite(), open(), fopen(),
bind(), select(), malloc(), xmalloc(), calloc(), free(), disclaim(), send(),
receive(), largesend()), y su turno termina, no es penalizado, por lo que
tienden a mantener su número de prioridad total. La penalización real, por
compatibilidad con scripts y utilitarios desarrollados para versiones
anteriores de AIX, no es mostrada en el rango de 0 a 255 —los valores reales—
si no que se muestra en la escala de 0 a 127, igual que antes.
! Cada cien (100) ticks, el despachador de tareas recalcula las penalizaciones,
que según la parametrización resulta en Penalización=Penalización/2, es
decir, una amnistía global de penalizaciones a los hilos con política de
despacho predeterminada.
Nota: La explicación de arriba está un poco simplificada. Las penalizaciones realmente
son Penalización=Penalización+2×sched_R/32, donde Penalización inicia en 0 con el
nacimiento de un hilo de ejecución, y sched_R es de manera predeterminada 16. Las
penalizaciones se “amnistían” una vez por segundo según
Penalización=Penalización×sched_D, y sched_D es 16. Los turnos son de timeslice ticks
(de 10ms cada tick), con timeslice igual a 1 de manera predeterminada.
! Con el esquema predeterminado, los hilos de ejecución que menos I/O
realizan aumentan de número de prioridad total (lo que les disminuye el
chance de ejecutar próximamente), logrando que otros hilos se ejecuten poco
después —y que tal vez sean penalizados, por lo que otros más tendrán el
chance—. Así que todos los procesos normales (con política de despacho
SCHED_OTHER) eventualmente se ejecutarán.

! Modificar el parámetro sched_R permite controlar qué tan competitivos son

los procesos consumidores de CPU con los consumidores de I/O. Modificar el
parámetro sched_D permite controlar qué tan competitivos son los procesos
en foreground con los de background.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 21

 ! Independientemente de que se estén tomando o reportando estadísticas de
desempeño, en AIX siempre se están tomando unos indicadores de uso y
consumo de turnos de CPU; así, cada vez que el despachador detiene los hilos
de ejecución para reasignar prioridades y turnos de ejecución analiza:
‣ Si un hilo de ejecución estaba corriendo instrucciones de código interno
—es decir no llamando o usando funciones de núcleo o de librerías
estándar, como read(), write(), open(), malloc() y las otras ya
mencionadas— y además no estaba en espera del hardware, el
despachador reporta consumo de tipo user, así que este indicador se
aumenta para el hilo. Nótese que no importa para aumentar esta
estadística si hilo es de un servicio del sistema (como cron o printq o
audit)

‣ Si un hilo de ejecución estaba corriendo instrucciones de código de núcleo

o de librerías estándar, pero las mismas no estaban en espera del
hardware, el despachador reporta consumo de tipo system, así que este
indicador —y no otro— se aumenta para el hilo. Nótese que no importa
para aumentar esta estadística si el hilo de ejecución es de un proceso de
usuario (como ksh, o vi, o smit o ping). Las demoras generadas por
acomodar páginas de RAM solicitadas por un proceso cuentan en los
indicadores system.
‣ Si un hilo de ejecución debía correr, pero estaba esperando una respuesta
demorada por el hardware, como los movimientos de las cabezas de disco
para encontrar un archivo y poder abrirlo, o los desplazamientos
normales en las operaciones de lectura, todos estos hacen que los
indicadores de tipo wait se aumenten. El origen del requerimiento que
termina en una demora o espera no es importante al contabilizarlo como
wait (así que paginar a disco unas páginas de memoria, para poder liberar
RAM para poder recibir unos paquetes de red, si generan demoras,
cuentan como wait).
‣ Si un hilo entrega su resto de turno, voluntaria o involuntariamente —
invoca sleep(), usleep(), select() y otras funciones que no procesan, si
no que esperan una señal o dato externo, se contabiliza como que no
estaba haciendo nada, y se aumenta el indicador idle. Cuando un proceso
entra en uno de estos casos, se remueve de las colas de ejecución
mientras no sea necesario. Eventualmente el sistema de manejo de
energía “dormirá” o desactivará los núcleos de CPU temporalmente
innecesarios. El despachador de AIX normalmente invoca un hcall —
hypervisor call— para “devolver” los turnos de CPU que no se necesitan
en la VM.
! Con estos casos, de cada hilo de ejecución se llevan tres indicadores (user,
system, wait), más los sobrantes (idle), y con estos el sistema puede hacer
múltiples reportes detallados, resumidos, consolidados, agrupados,
totalizados, promediados y más.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 22

 ! Adicionalmente, el despachador de hilos también lleva estadísticas por
núcleo y por cola: si se usan, cuántos hilos están en cola de ejecución y en
espera de cola de ejecución en cada momento.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 23

AIX Performance ● Ramón Barrios Lascar ® Ínodo 24
Monitoreo de Desempeño de AIX: Monitoreo del Consumo de
CPU
Monitorear el desempeño y consumo de CPU en AIX es fácil y es casi gratis, ya que los
indicadores los lleva AIX siempre, y por hilo de ejecución. Adicionalmente muchas de las
utilidades que reportan estadísticas de desempeño de otro tipo también incluyen o
pueden incluir las estadísticas de CPU. Como el sistema operativo lleva estos
indicadores de manera permanente, reportarlos prácticamente tiene una incidencia casi
nula en el consumo de más turnos de CPU —básicamente lo que se consuma en generar
los listados—.
Ahora, algunos utilitarios incluidos con el sistema operativo y/o las herramientas de
desarrollo permiten reportar el consumo por función (los llamados internos del código
de un proceso o hilo de ejecución), números que AIX no acumula de manera
predeterminada, por lo que este estilo de reporte (generable comúnmente con
herramientas que tienen la partícula o sílaba “prof” en el nombre) sí consume turnos de
ejecución en las CPU, por lo que sí afecta los indicadores y el desempeño mismo del
sistema. A menos que sea absolutamente necesario, deberán evitarse este tipo de
herramientas o de reportes.

Síntomas Generales del Excesivo Uso de CPU

Cuando se use cualquiera de las herramientas que pueden mostrar los indicadores
consolidados, lo más común es obtener una serie de estadísticas %user, %sys, %iowait y
%idle. Cuando se obtienen así, consolidados, para todo el sistema, o por CPU o núcleo,
hace años se tienen unas reglas generales (thumb rules se dice en inglés): Si %user +
%sys ≥ 80% la máquina está sufriendo por excesivo consumo de CPU.
Cuando se tienen números de este estilo por momentos, pues no habrá causa de
preocupación, pero sí si el sistema se mantiene en esos consumos por un período de
tiempo considerable, y deberá analizarse más a fondo para poder concluir y para poder
pensar en buscar soluciones —no siempre se trata de “asignar más CPU”—.
Mucho consumo de CPU, de manera simplificada se puede ver de tres maneras:
! Uno, o unos pocos, procesos o hilos en el sistema tienen un consumo
exagerado de turnos de CPU para lo que se espera o se planeó la máquina.
Cuando se da esta situación es fácil encontrar al o a los consumidores
máximos para poder seguir con los análisis y la búsqueda de soluciones.
! Muchos o muchísimos procesos o hilos en el sistema tienen, individualmente,
poco consumo de turnos de CPU, cada uno, pero combinados, como son
muchos, los núcleos de CPU están siendo insuficientes para toda la carga.
Cuando se da esta situación es mucho más difícil encontrar “culpables”. En
estos casos en general es recomendable o lograr más núcleos de CPU, sin
importar tanto su potencia, para tener más colas de ejecución en paralelo y
poder manejar así, mejor, las numerosas mini-cargas. Se recomienda en

AIX Performance ● Ramón Barrios Lascar ® Ínodo 25

 general, dividir o distribuir las cargas en más máquinas, o a lo largo de
períodos de tiempo —con programaciones o despachadores programados—.
! Una situación de hardware —como un fallo físico— puede generar excesivas
demoras: contención en buses externos a la máquina virtual, o fallas en el
sistema de caché o de memoria RAM.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 26

Monitoreo de Desempeño de AIX: Comandos
Comando sar -u
El comando más versátil, pero últimamente tal vez menos usado, que puede ser usado
para obtener estadísticas de CPU en AIX y en numerosos Unix es sar (oficialmente el
nombre es la sigla de system activity report). Este comando tiene numerosas opciones
que varían su uso y los reportes obtenidos. Cuando se usa la opción u reportará los
indicadores básicos de CPU. Como siempre, necesitará al menos un número que le
indique cada cuánto generar reportes —primer argumento, en segundos—, y
opcionalmente cuántos reportes generar —segundo argumento, en veces—. Si el
segundo argumento no se da, sar genera un reporte con una única muestra, y no
muestra la línea de promedio como en el ejemplo que sigue.
Ejemplo:
[0 root@AIX1:/] sar -u 5 5

AIX AIX1 1 6 0005FA92D900 06/07/14

System configuration: lcpu=4 ent=0.35 mode=Uncapped

[Link] %usr %sys %wio %idle physc %entc

[Link] 9 20 0 71 0.11 30.5
[Link] 10 24 0 66 0.12 35.1
[Link] 11 23 0 65 0.12 35.5
[Link] 6 14 0 80 0.07 21.2
[Link] 0 0 0 100 0.00 0.9

Average 7 16 0 76 0.09 24.7

Se observa:
! sar con la opción u necesita de al menos un argumento: el número de
segundos entre muestra y muestra (entre línea estadística reportada y la
siguiente, en nuestro ejemplo 5s). Si se da un segundo argumento se asumirá
como el número de estadísticas o muestras a reportar (en nuestro ejemplo 5
líneas, aparte de las comunes como título y el reporte promedio final).
! La primera línea informa el nombre del sistema operativo (como lo reporta
uname); el nombre de la máquina (como lo reporta hostname -s), AIX1 en
nuestro caso; la sub-versión y versión 1 6, es decir AIX 6.1; el serial único de
la VM (0005FA92D9 es el serial del servidor físico y 00 de la VM); y la fecha de
ejecución (junio/07/2014 en nuestro ejemplo).
! La segunda línea muestra un resumen de la configuración básica de la VM o
servidor. En nuestro ejemplo tiene 4 CPUs lógicas, 0.35 de CPU titulada (35
turnos de cada segundo); y se ejecutará en modo ilimitado (uncapped).
! Muestra una línea de título que resume la hora de ejecución ([Link]), y las
columnas que mostrará: %usr (turnos consumidos por todos los hilos

AIX Performance ● Ramón Barrios Lascar ® Ínodo 27

 ejecutándose en el servidor y clasificados como user); %sys (turnos
consumidos por todos los hilos ejecutándose en el servidor y clasificados
como system); %wio (turnos desperdiciados en el servidor y clasificados como
wait); %idle (turnos sobrantes en el sistema, si es que los hay); physc
(porciones de un núcleo completo físico consumidos por este ambiente AIX,
como fracción de 1); %entc (porción de la asignación a esta VM AIX consumida
en turnos usados). En la descripción del comando lparstat se describen
mejor estas columnas, revísela más adelante.
! Luego muestra n líneas de reporte, siendo n el segundo argumento dado (en
nuestro ejemplo 5 líneas). Cada línea espaciada de la siguiente por m
segundos, siendo m el primer argumento dado (en nuestro ejemplo, 5
segundos). Cada línea muestra la hora exacta de la estadística reportada.
! En nuestro ejemplo, se observa que puntualmente no hay problemas reales
de CPU —al ambiente le “sobran” muchos de los turnos de CPU que tiene
titulados, más de dos terceras partes de los mismos, ya que %idle se
mantiene en más de la mitad de todo—. Adicionalmente si sumamos %usr+
%sys, se mantiene por debajo de un 40%, y los problemas se comienzan a notar
en más del 80%.
! Luego de las líneas de reporte solicitadas, y algo separadas, muestra una
línea promedio (average), ya que se solicitó mostrar más de una línea de
reporte. Simplemente promedia las columnas de las líneas superiores.
Nota: Cuando la máquina donde se ejecuta sar -u tiene procesadores dedicados (o no es
una máquina virtual con procesadores compartidos/virtualizados o es un ambiente
donde se instaló AIX directamente en el servidor, o lo que se conoce como full system),
sar no incluye las columnas physc (physical cores) ni %entc (entitled CPU consumed).
Si se quiere tener más detalle del consumo de CPUs, en especial, por núcleo (per core) se
puede agregar P ALL —si se ejecuta en un AIX sin WPARs o en la WPAR global— o P RST
—si se ejecuta dentro de una WPAR—.
Ejemplo:
[0 root@AIX1:/] sar -uP ALL 5 5

AIX AIX1 1 6 0005FA92D900 06/07/14

System configuration: lcpu=4 ent=0.35 mode=Uncapped

[Link] cpu %usr %sys %wio %idle physc %entc

[Link] 0 14 63 0 23 0.00 0.9
1 0 18 0 82 0.00 0.1
2 0 32 0 68 0.00 0.0
3 0 32 0 68 0.00 0.0
U - - 0 99 0.35 99.0
- 0 1 0 99 0.00 1.0
[Link] 0 4 79 0 17 0.00 1.3
1 0 20 0 80 0.00 0.1
2 0 30 0 70 0.00 0.0

AIX Performance ● Ramón Barrios Lascar ® Ínodo 28

 3 0 29 0 71 0.00 0.0
U - - 0 99 0.35 98.6
- 0 1 0 99 0.00 1.4
[Link] 0 33 66 0 1 0.06 17.7
1 0 15 0 85 0.00 0.1
2 0 31 0 69 0.00 0.0
3 0 32 0 68 0.00 0.0
U - - 0 82 0.29 82.1
- 6 12 0 82 0.06 17.9
[Link] 0 33 66 0 1 0.12 33.0
1 0 11 0 89 0.00 0.1
2 0 34 0 66 0.00 0.0
3 0 29 0 71 0.00 0.0
U - - 0 67 0.23 66.8
- 11 22 0 67 0.12 33.2
[Link] 0 34 65 0 1 0.10 29.6
1 0 10 0 90 0.00 0.1
2 0 31 0 69 0.00 0.0
3 0 31 0 69 0.00 0.0
U - - 0 70 0.25 70.2
- 10 19 0 71 0.10 29.8

Average 0 33 66 0 2 0.06 16.5

1 0 14 0 86 0.00 0.1
2 0 32 0 68 0.00 0.0
3 0 31 0 69 0.00 0.0
U - - 0 83 0.29 83.3
- 5 11 0 84 0.06 16.7
Como se ve en el ejemplo, básicamente el reporte es igual a excepción de que cada línea
reportada se convierte en un párrafo:
! A diferencia de sar -u sin P, muestra una línea por cada CPU lógica
(recordando que la cantidad de CPU lógicas es m CPUs virtuales × n hilos por
CPU virtual según se configure SMT). Como esta máquina tiene cuatro CPUs
lógicas, como lo muestra la segunda línea del mismo sar, mostrará las líneas
por CPU: 0, 1, 2, 3, además de “no indentificada” (unidentified o U), y
“promedio” (la última línea de cada párrafo o -).

AIX Performance ● Ramón Barrios Lascar ® Ínodo 29

AIX Performance ● Ramón Barrios Lascar ® Ínodo 30
 Comando lparstat
El comando lparstat, como muchos otros comandos puede reportar el consumo de CPU,
en este caso del ambiente dentro de la LPAR o VM, pero eso es lo mismo que pueden
reportar todos los otros comandos mencionados en este documento. El comando reporta
las estadísticas básicas de CPU cuando no se dan opciones. Si no se dan números como
argumento mostrará los datos básicos de configuración de la LPAR o VM y una única
estadística de consumos de CPU. Si se da un primer argumento número reportará
infinitas estadísticas —hasta que se le detenga con la señal TERM o Ctrl-C— cada una
separada por n segundos, tomando el primer argumento como la espera entre dato y
dato. Si se dan dos argumentos números mostrará n estadísticas —usando como n al
segundo argumento—, cada una separada de las otras por m segundos —usando como m
al primer argumento—.
Ejemplo:
[0 root@AIX1:/] lparstat 10 10

System configuration: type=Shared mode=Uncapped smt=On lcpu=4 mem=2048MB psize=2

ent=0.35

%user %sys %wait %idle physc %entc lbusy app vcsw phint
----- ----- ------ ------ ----- ----- ------ --- ----- -----
18.4 19.8 0.0 61.8 0.14 38.7 3.4 1.83 234 4
18.6 18.1 0.0 63.3 0.13 37.2 3.0 1.84 232 4
1.4 2.3 0.0 96.3 0.01 4.1 0.4 1.98 197 0
%user %sys %wait %idle physc %entc lbusy app vcsw phint %nsp
----- ----- ------ ------ ----- ----- ------ --- ----- ----- -----
0.0 0.4 0.0 99.6 0.00 0.7 0.0 1.86 150 0 99
0.0 0.3 0.0 99.6 0.00 0.7 0.0 1.99 150 0 99
0.0 0.4 0.0 99.6 0.00 0.7 0.0 1.99 155 0 99
0.0 0.3 0.0 99.6 0.00 0.7 0.0 1.98 153 0 99
0.1 0.4 0.0 99.5 0.00 0.8 0.0 1.99 152 0 99
%user %sys %wait %idle physc %entc lbusy app vcsw phint
----- ----- ------ ------ ----- ----- ------ --- ----- -----
7.8 9.4 0.2 82.7 0.06 17.5 1.6 1.92 179 2
22.5 23.3 0.0 54.2 0.16 46.3 4.5 1.80 242 6
Se observa:
! A semejanza de sar, muestra una línea con la configuración básica del
servidor completo (cuando el AIX corre en full system) o de la LPAR o VM,
siendo un poco más detallado en los datos de configuración física de la VM o
LPAR: muestra type=Dedicated o type=Shared (según la VM tenga
procesadores dedicados/físicos o compartidos/virtualizados); mode=Capped o
mode=Uncapped (según la VM sea de consumo sólo de lo titulado o pueda
crecer más allá de lo titulado, si necesita); smt=Off o smt=On (según el AIX se
configure con SMT apagado o =1, o encendido con =2, en Power6, o =2, =4, en
Power7, o =2, =4, =8 en Power8); lcpu=X (según de el resultado de CPUs o
virtual CPUs asignadas × SMT); mem=YMB (obviamente RAM en megabytes);
psize=W (el número de núcleos de CPU en el pool de procesadores donde inició

AIX Performance ● Ramón Barrios Lascar ® Ínodo 31

 este AIX); ent=Z (CPU titulada o turnos de CPU por segundo asignados, como
fracción de 1). Nuestro ejemplo corre en un AIX dentro de una VM de
procesadores virtualizados/compartidos (shared), en modo ilimitado
(uncapped), con SMT encendido (on), con cuatro CPUs lógicas (lcpu=4), 2GB de
RAM (mem=2048MB), en un pool de 2 núcleos (psize=2) y con sólo un poco más
de un tercio de núcleo titulado (ent=0.35). En las máquinas donde se tiene
licencia de compresión de memoria AME (Active Memory Expansion), este
título incluye también tmem=QMB (donde Q es la cantidad real de MB de RAM
asignada a la VM, antes de la compresión).
! Luego un reporte con tantas líneas de datos como se solicitó (es decir el
segundo parámetro numérico).
! A continuación se describen las columnas (aunque algunas ya se han
mencionado en la descripción del comando sar):
‣ %user Porcentaje de turnos consumidos en instrucciones de nivel
aplicación —interpretados exacto como en sar -u—. Si la VM es
limitada (capped) o ilimitada (uncapped) sin haber crecido, el
porcentaje es la porción de los núcleos de CPU titulados; pero si
ha crecido, es la porción de los núcleos de CPU activados,
aunque son por encima de lo titulado.
‣ %sys Porcentaje de turnos consumidos en instrucciones de nivel
sistema (kernel o librerías de bajo nivel). Al igual que con %user,
si la VM es limitada (capped) o ilimitada (uncapped) sin haber
crecido, el porcentaje es la porción de los núcleos de CPU
titulados; pero si ha crecido, es la porción de los núcleos de CPU
activados, aunque son por encima de lo titulado.
‣ %idle Porcentaje de los turnos de CPU titulados que no se usaron
porque no había nada que ejecutar y donde al mismo tiempo no
se estaban presentando esperas de I/O de hardware. Se analiza
proporcionalmente de igual manera que %user y %sys.
‣ %wait Porcentaje de los turnos de CPU titulados que no se usaron
porque los hilos de ejecución estaban a la espera de los
resultados de una operación de I/O pendiente o en progreso. Al
igual que con %user y %sys, si la VM es limitada (capped) o
ilimitada (uncapped) sin haber crecido, el porcentaje es la
porción de los núcleos de CPU titulados; pero si ha crecido, es la
porción de los núcleos de CPU activados, aunque son por encima
de lo titulado.
‣ physc Porción de núcleos de CPU consumidos, como fracción de 1.
‣ %entc Porcentaje de los núcleos de CPU titulados. Cuando la LPAR o VM
es de tipo ilimitado (uncapped) puede sobrepasar
temporalmente el 100%.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 32

 ‣ lbusy Porcentaje de los procesadores lógicos (teniendo en cuenta el
SMT) que se consumió al ejecutar instrucciones (de tipo %usr y
%sys).

‣ app Cantidad decimal de núcleos de CPU aún disponibles en el pool

de procesadores compartidos donde se inició la VM actual.
‣ vcsw Cantidad de cambios de contexto que son realmente
intercambios de ejecución de diferentes LPARs o VMs.
‣ phint Cantidad de interrupciones fantasma recibidas (las
interrupciones fantasma apuntan a otra VM del mismo pool de
procesadores compartidos que la VM actual).
‣ %nsp Velocidad promedio de los procesadores virtuales actuales
comparadas con la velocidad nominal de los procesadores físicos
donde se ejecutan.
Se pueden concluir:
! Como siempre la regla burda, pero directa y usable: si %usr + %sys ≥ 80% la
máquina virtual puede considerarse con cuellos de botella por insuficiencia
de capacidad de CPUs.
! Si aparece a menudo la VM con %entc con más del 100%, la VM se puede
considerar que está necesitando —y por ello usa— más CPU titulada. Esto
solo se da cuando es ilimitada (uncapped) y tiene más CPUs virtuales que
CPU titulada. Debería analizarse el definir realmente la VM con más CPU
titulada, porque realmente la necesita y la puede usar.
! Si %nsp baja del 90% continuamente, o hay muchos procesadores virtuales
ejecutándose en el mismo pool de procesadores físicos que la VM actual, o la
VM actual tiene configurados muchos procesadores virtuales para la CPU
titulada que tiene definida.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 33

AIX Performance ● Ramón Barrios Lascar ® Ínodo 34
 Comando vmstat -w
El comando vmstat, incluido en muchas plataformas UNIX también permite revisar las
estadísticas de CPU, aunque realmente se diseñó para revisar las estadísticas del
sistema manejador de memoria virtual.
Ejemplo:
[0 root@AIX1:/] vmstat -w 30 10

System configuration: lcpu=4 mem=2048MB ent=0.35

kthr memory page faults cpu

------- --------------------- ------------------------------------ ------------------ -----------------------
r b avm fre re pi po fr sr cy in sy cs us sy id wa pc ec
0 0 216399 283838 0 0 0 0 0 0 10 119 83 0 1 99 0 0.00 1.3
0 0 216399 283838 0 0 0 0 0 0 5 61 73 0 1 99 0 0.00 1.0
2 0 216906 283331 0 0 0 0 0 0 78 60034 6695 36 46 18 0 0.30 86.7
0 0 216906 283331 0 0 0 0 0 0 8 86 79 0 1 99 0 0.00 0.9
1 0 216970 283267 0 0 0 0 0 0 2438 116919 17251 38 55 2 5 0.40 115.6
1 0 217037 283200 0 0 0 0 0 0 3577 171621 25562 38 55 2 5 0.59 169.2
1 0 217133 283104 0 0 0 0 0 0 3111 206064 35970 38 53 6 3 0.83 236.6
1 0 217133 283104 0 0 0 0 0 0 3536 169727 29902 37 54 4 5 0.59 169.3
1 0 217133 283104 0 0 0 0 0 0 3566 171176 26796 38 55 2 5 0.59 169.2
1 0 217133 283104 0 0 0 0 0 0 3546 170192 25401 38 55 2 5 0.59 167.9

Se puede observar:
! El comando vmstat también se puede ejecutar con uno o dos números como
parámetros. El primer número es —como lo es para los otros comandos— el
tiempo en segundos entre muestra y muestra estadística. El segundo número
es el número de muestras que se desee observar. En nuestro ejemplo el
vmstat mostrará 10 líneas de muestras estadísticas, cada una separada de la
anterior por 30 segundos. En la sintaxis de vmstat la opción w es para usar un
formato más ancho de línea, que permita ver estadísticas con indicadores
más grandes.
! El comando vmstat inicia con una corta línea que describe lo mínimo de
configuración del sistema o VM donde se está ejecutando. En nuestro ejemplo
dice “System configuration:” y luego: cantidad de procesadores lógicos
(lcpu=4); cantidad de memoria RAM reportada (mem=2048MB); cantidad de CPU
titulada (ent=0.35).
! Luego vmstat incluye las estadísticas. Las mismas, las agrupa (cuando no se
dan otras opciones aparte de la w), en cinco grupos: hilos de ejecución en
núcleo (kernel threads o kthr); memoria virtual (memory); actividad del
liberador de memoria y de movimientos de páginas de memoria (page);
cambios de contexto, llamados e interrupciones (faults); indicadores de uso
de CPU (cpu, que es lo que nos interesa en este capítulo).
! En el grupo del consumo de CPU volvemos a las mismas columnas
indicadoras:
‣ us Porcentaje de turnos consumidos en instrucciones de nivel
aplicación. Si la VM es limitada (capped) o ilimitada (uncapped)
sin haber crecido, el porcentaje es la porción de los núcleos de

AIX Performance ● Ramón Barrios Lascar ® Ínodo 35

 CPU titulados; pero si ha crecido, es la porción de los núcleos de
CPU activados, aunque son por encima de lo titulado.
‣ sy Porcentaje de turnos consumidos en instrucciones de nivel
sistema (kernel o librerías de bajo nivel). Al igual que con %user,
si la VM es limitada (capped) o ilimitada (uncapped) sin haber
crecido, el porcentaje es la porción de los núcleos de CPU
titulados; pero si ha crecido, es la porción de los núcleos de CPU
activados, aunque son por encima de lo titulado.
‣ id Porcentaje de los turnos de CPU titulados que no se usaron
porque no había nada que ejecutar y donde al mismo tiempo no
se estaban presentando esperas de I/O de hardware. Se analiza
proporcionalmente de igual manera que %user y %sys.
‣ wa Porcentaje de los turnos de CPU titulados que no se usaron
porque los hilos de ejecución estaban a la espera de los
resultados de una operación de I/O pendiente o en progreso. Al
igual que con %user y %sys, si la VM es limitada (capped) o
ilimitada (uncapped) sin haber crecido, el porcentaje es la
porción de los núcleos de CPU titulados; pero si ha crecido, es la
porción de los núcleos de CPU activados, aunque son por encima
de lo titulado.
‣ pc Porción de núcleos de CPU consumidos, como fracción de 1.
‣ %entc Porcentaje de los núcleos de CPU titulados. Cuando la LPAR o VM
es de tipo ilimitado (uncapped) puede sobrepasar
temporalmente el 100%.
Nota: Todas las columnas de vmstat (o vmstat -w) se interpretan exacto como en sar -u:
us es idéntica a %user de sar -u, sy es idéntica a %sys y así.

Como en los otros comandos la regla burda y directa, pero útil es considerar a las
máquinas limitadas por capacidad de CPU cuando us + sy ≥ 80%.
Adicional a esto, la columna r de la sección kthr es el número promedio de hilos de
ejecución de kernel en el despachador que están quedando encolados porque no hay
suficientes turnos de CPU para atenderlos. Notando que en las máquinas y AIX actuales,
la configuración predeterminada es que un hilo de ejecución de kernel puede atender
hasta 12 hilos de ejecución de aplicación, si este número aumenta, y se mantiene encima
de cinco (5), se puede considerar que la máquina tiene demasiados procesos paralelos
que atender o muy pocas colas de ejecución que los despache (donde una cola de
ejecución está asignada a un único procesador lógico), o las dos cosas a la vez.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 36

 Comando tprof
El comando tprof es un comando que inicialmente se diseñó para analizar procesos en
fase de desarrollo (es un perfilador de consumo de turnos de CPU —y otros— por
función e hilo de proceso). El mismo permite analizar de múltiples maneras pero aquí
sólo usaremos el modo más sencillo. Con éste podemos obtener un reporte de consumos
de CPU por proceso en todo el sistema, y con ello encontrar —en un período de tiempo
corto— de manera semi-interactiva los procesos más consumidores de CPU. El mismo, si
se sigue el uso aquí, deberá trabajarse donde el usuario actual tenga permisos de
escritura, ya que genera un archivo de texto con el reporte estadístico.
Ejemplo:
[127 root@AIX2:/tmp] tprof -x sleep 60
Tue Sep 11 [Link] 2012
System: AIX 6.1 Node: AIX2 Machine: 0005FA92D900
Starting Command sleep 60
stopping trace collection.
Generating [Link]

[0 root@AIX2:/tmp] cat [Link]

Configuration information
=========================
System: AIX 6.1 Node: AIX2 Machine: 0005FA92D900
Tprof command was:
tprof -x sleep 60
Trace command was:
/usr/bin/trace -ad -M -L 47392358 -T 500000 -j 00A,001,002,003,38F,
005,006,134,210,139,5A2,5A5,465,234,5D8, -o -
Total Samples = 5537
Traced Time = 60.01s (out of a total execution time of 60.01s)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Process Freq Total Kernel User Shared Other

======= ==== ===== ====== ==== ====== =====
wait 8 99.96 99.96 0.00 0.00 0.00
/usr/bin/sh 1 0.02 0.02 0.00 0.00 0.00
xmgc 1 0.02 0.02 0.00 0.00 0.00
======= ==== ===== ====== ==== ====== =====
Total 10 100.00 100.00 0.00 0.00 0.00

Process PID TID Total Kernel User Shared Other

======= === === ===== ====== ==== ====== =====
wait 131076 131077 24.11 24.11 0.00 0.00 0.00
wait 983070 1441837 10.84 10.84 0.00 0.00 0.00
wait 1048608 1572913 10.84 10.84 0.00 0.00 0.00
wait 917532 1376299 10.84 10.84 0.00 0.00 0.00
wait 1179684 1703989 10.84 10.84 0.00 0.00 0.00
wait 1114146 1638451 10.84 10.84 0.00 0.00 0.00
wait 1245222 1769527 10.84 10.84 0.00 0.00 0.00
wait 1310760 1835065 10.84 10.84 0.00 0.00 0.00
/usr/bin/sh 4849834 15794411 0.02 0.02 0.00 0.00 0.00
xmgc 851994 1310761 0.02 0.02 0.00 0.00 0.00
======= === === ===== ====== ==== ====== =====
Total 100.00 100.00 0.00 0.00 0.00

AIX Performance ● Ramón Barrios Lascar ® Ínodo 37

 Se puede observar:
! La sintaxis más básica es tprof -x comando, la que hace que tprof contabilice
los consumos en todo el sistema mientras el comando está en ejecución
(inicia la contabilidad cuando el comando arranca y termina la contabilidad y
genera el reporte cuando el comando finaliza).
! Con esta sintaxis, y con el tema de desempeño de CPU que nos atañe, es
típico usar, como en el ejemplo, el comando sleep, ya que el mismo
prácticamente no consume CPU —lo que no nos desvía los indicadores
estadísticos— y además, ejecuta por un tiempo determinado por el
parámetro.
! Cuando tprof ejecuta con -x, invoca al comando, inicia la cuenta y genera el
reporte. El reporte es un archivo de texto (en el directorio actual), con el
nombre del comando y la extensión .prof. El mismo, al terminar la ejecución se
revisa con cualquier herramienta de texto que lo permita.

Reporte de tprof
El reporte de tprof tiene tres partes:
! Datos del sistema y detalles de la ejecución de tprof
! Resumen de consumos de CPU por nombre de proceso (aunque no tengan
relación directa o en el tiempo o diferentes usuarios).
! Detalle de consumos de CPU por proceso.
Detalles del sistema: Muestra primero la información de la configuración
(adecuadamente titulada Configuration information). Incluye nombre del sistema
operativo (AIX), versión (6.1), nombre de la máquina (AIX2), serial de la VM
(0005FA92D900, recordando que los dos últimos números son el serial de la VM dentro del
servidor físico son los primeros diez hexadígitos); incluye el comando y la sintaxis
interna del trace que se usó para la captura. Muestra cuántos turnos de ejecución se
pudieron contabilizar y cuánto tiempo duró la muestra.
Resumen por nombre de proceso: Inicia con la línea “Process Freq Total...”. Muestra,
acumulando los turnos consumidos por procesos con igual nombre, de mayor a menor
los consumos en varias columnas, que se describen:
! Nombre (Process) nombre de los procesos que se vio en ejecución durante
el tiempo de la muestra. Pueden ser de diversos momentos y
diversos usuarios, mientras hayan estado en ejecución mientras
estuvo ejecutando el comando usado en la sintaxis.
! Cantidad (Freq) cuántas veces se vio un proceso con igual nombre durante
el muestreo. En el ejemplo el proceso wait aparece ocho (8) veces
en ejecución.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 38

 ! Total cuántos turnos de ejecución se consumieron, porcentualmente,
sumando todos los procesos de igual nombre a los que se refiere
esta línea.
! Kernel cuántos turnos de ejecución se consumieron, porcentualmente,
sumando todos los que el despachador de tareas clasificó como
de tipo system, sumando los de los procesos de igual nombre a
los que se refiere esta línea.
! User cuántos turnos de ejecución se consumieron, porcentualmente,
sumando todos los que el despachador de tareas clasificó como
de tipo user, sumando los de los procesos de igual nombre a los
que se refiere esta línea.
! Shared cuántos turnos de ejecución se consumieron, porcentualmente,
sumando todos los que el despachador de tareas clasificó como
de “intercambio de user a system y de system a user”, sumando los
de los procesos de igual nombre a los que se refiere esta línea.
! Other cuántos turnos de ejecución se consumieron, porcentualmente,
sumando todos los que el despachador de tareas no supo cómo
clasificar —si user, si system o si wait—, sumando los de los
procesos de igual nombre a los que se refiere esta línea.
Luego de las líneas donde se agrupan los procesos de igual manera, el reporte muestra la
línea Total, con los totales por columna, siendo las mismas columnas.
Detalle por Proceso Individual: Inicia con la línea “Process PID TID...”. Muestra los
turnos de CPU consumidos por proceso individual, de mayor consumidor a menor
consumidor, uno a uno, en básicamente las mismas columnas, que se describen:
! Nombre (Process) nombre del proceso cuyos consumos se describen en
cada línea.
! Proceso (PID) número identificador del proceso del cual se están
describiendo los consumos de CPU en la línea estadística.
! Hilo (TID) número identificador del hilo de ejecución inicial del
proceso del cual se están describiendo los consumos de CPU en
la línea.
! Total cuántos turnos de ejecución se consumieron, porcentualmente,
contando únicamente al proceso de la línea reportada.
! Kernel cuántos turnos de ejecución se consumieron, porcentualmente,
contando únicamente los del proceso que se describe y que el
despachador de tareas de AIX clasificó como system.
! User cuántos turnos de ejecución se consumieron, porcentualmente,
contando únicamente los del proceso que se describe y que el
despachador de tareas de AIX clasificó como user.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 39

 ! Shared cuántos turnos de ejecución se consumieron, porcentualmente,
contando los del proceso que se describe y que el despachador de
tareas clasificó como de “intercambio de user a system y de
system a user”.

! Other cuántos turnos de ejecución se consumieron, porcentualmente,

sumando todos los del proceso que se describe y que el
despachador de tareas no supo cómo clasificar —si user, si
system o si wait—.

Luego de las líneas donde se detallan los procesos de igual manera, el reporte muestra la
línea Total, con los totales por columna, siendo las mismas columnas.
Con un reporte como éste:
! Se puede encontrar si muchísimos procesos están en ejecución —o
intentando ejecutarse—, analizando la segunda sección, y encontrando si hay
muchos procesos donde la cantidad (Freq) es muy alta.
! Se puede encontrar si hay unos pocos procesos consumidores de muchos
turnos de CPU (revisando los primeros de la sección tercera) o si son
muchísimos (revisando las longitudes de las secciones segunda y tercera).

AIX Performance ● Ramón Barrios Lascar ® Ínodo 40

 Comando topas
El comando topas es un software “monitor” que permite hacer seguimiento a numerosas
estadísticas de desempeño de un AIX. Es ligeramente interactivo (habiendo diversas
teclas que se pueden presionar cuando está funcionando para entrar en detalles).
El modo más sencillo es ejecutando topas directamente:
[0 root@AIX1:/] topas
Topas Monitor for host: AIX1 EVENTS/QUEUES FILE/TTY
Sun Jun 22 [Link] 2014 Interval: 2 Cswitch 60 Readch 0
Syscall 50 Writech 261
CPU User% Kern% Wait% Idle% Physc Entc Reads 0 Rawin 0
ALL 0.1 0.5 0.0 99.4 0.00 0.9 Writes 1 Ttyout 261
Forks 0 Igets 0
Network KBPS I-Pack O-Pack KB-In KB-Out Execs 0 Namei 2
Total 0.0 0.0 0.0 0.0 0.0 Runqueue 0.0 Dirblk 0
Waitqueue 0.0
Disk Busy% KBPS TPS KB-Read KB-Writ MEMORY
Total 0.0 0.0 0.0 0.0 0.0 PAGING Real,MB 2048
Faults 2 % Comp 42
FileSystem KBPS TPS KB-Read KB-Writ Steals 0 % Noncomp 5
Total 0.0 0.0 0.0 0.0 PgspIn 0 % Client 5
PgspOut 0
Name PID CPU% PgSp Owner PageIn 0 PAGING SPACE
rmcd 4980888 0.0 211.0 root PageOut 0 Size,MB 1536
lrud 262152 0.0 0.5 root Sios 0 % Used 0
vmptacrt 327690 0.0 0.4 root % Free 100
psmd 393228 0.0 0.5 root NFS (calls/sec)
vmmd 458766 0.0 0.8 root SerV2 0 WPAR Activ
pvlist 524304 0.0 0.4 root CliV2 0 WPAR Total
memgrdd 589842 0.0 0.4 root SerV3 0 Press: "h"-help
ldmp_pro 655418 0.0 0.5 root CliV3 0 "q"-qui

Cuando se ejecuta así muestra la pantalla predeterminada, que se refresca cada 2

segundos. Nótese que se puede seleccionar otro intervalo usando la opción i número.
Aunque tiene numerosas secciones, nos interesan por lo pronto dos secciones que
detallan los consumos de CPU:
! La primera parte (superior izquierda) detalla el nombre del sistema (AIX1), la
fecha y la hora, y el intervalo de refresco, en este caso el predeterminado de
cada 2 segundos.
! La segunda parte (superior izquierda), titulada CPU, muestra los consumos,
de manera semejante que vmstat -w.
‣ User% Igual que en vmstat -w, porcentaje de turnos consumidos en
instrucciones de nivel aplicación. Si la VM es limitada (capped) o
ilimitada (uncapped) sin haber crecido, el porcentaje es la
porción de los núcleos de CPU titulados; pero si ha crecido, es la
porción de los núcleos de CPU activados, aunque son por encima
de lo titulado.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 41

 ‣ Kern% También, al igual que en vmstat -w, porcentaje de turnos
consumidos en instrucciones de nivel sistema (kernel o librerías
de bajo nivel). Al igual que con User%, si la VM es limitada
(capped) o ilimitada (uncapped) sin haber crecido, el porcentaje
es la porción de los núcleos de CPU titulados; pero si ha crecido,
es la porción de los núcleos de CPU activados, aunque son por
encima de lo titulado.
‣ Wait% Igual que antes, porcentaje de los turnos de CPU titulados que no
se usaron porque los hilos de ejecución estaban a la espera de
los resultados de una operación de I/O pendiente o en progreso.
Al igual que con User% y Kernel%, si la VM es limitada (capped) o
ilimitada (uncapped) sin haber crecido, el porcentaje es la
porción de los núcleos de CPU titulados; pero si ha crecido, es la
porción de los núcleos de CPU activados, aunque son por encima
de lo titulado.
‣ Idle% También igual, porcentaje de los turnos de CPU titulados que no
se usaron porque no había nada que ejecutar y donde al mismo
tiempo no se estaban presentando esperas de I/O de hardware.
Se analiza proporcionalmente de igual manera que User% y
Kernel%.

‣ Physc Porción de núcleos de CPU consumidos, como fracción de 1.

‣ Entc Porcentaje de los núcleos de CPU titulados. Cuando la LPAR o VM
es de tipo ilimitado (uncapped) puede sobrepasar
temporalmente el 100%.
! La sexta parte (inferior izquierda), iniciada con “nombre” (Name), describe los
procesos encontrados como más consumidores, de mayor a menor:
‣ Name Nombre de un proceso muy consumidor de turnos de CPU o de
espacio de paginación.
‣ PID Número identificador del proceso que se encontró como muy
consumidor de turnos de CPU o espacio de paginación.
‣ CPU% Porcentaje de turnos de CPU que se encontró que últimamente
está consumiendo el proceso.
‣ PgSp Espacio que consume en espacio de paginación el proceso.
Reporta en páginas (de 4KB).
‣ Owner Usuario dueño de cada proceso muy consumidor.
Note que si presiona p mientras está topas en ejecución, dejará de mostrar esta última
sección inferior izquierda.
Por otro lado, se puede invocar una pantalla más detallada de CPU si se presiona P
mientras está topas en ejecución, o se invoca con la opción P:

AIX Performance ● Ramón Barrios Lascar ® Ínodo 42

 [0 root@AIX1:/] topas -P
Topas Monitor for host: AIX1 Interval: 2 Sun Jun 22 [Link] 2014

DATA TEXT PAGE PGFAULTS

USER PID PPID PRI NI RES RES SPACE TIME CPU% I/O OTH COMMAND
root 4456652 3997910 81 20 698 149 698 0:01 6.8 0 0 sshd
root 4980888 3145980 60 20 54017 269 54017 0:02 0.0 0 0 rmcd
root 327690 0 40 41 112 0 112 0:00 0.0 0 0 vmptacrt
root 393228 0 16 41 128 0 128 0:00 0.0 0 0 psmd
root 458766 0 16 41 208 0 208 0:00 0.0 0 0 vmmd
root 524304 0 16 41 112 0 112 0:00 0.0 0 0 pvlist
root 589842 0 16 41 112 0 112 0:00 0.0 0 0 memgrdd
root 655418 1 60 20 128 0 128 0:00 0.0 0 0 ldmp_pro
root 720918 0 40 41 112 0 112 0:00 0.0 0 0 devstatd
root 786456 0 59 41 160 0 160 0:00 0.0 0 0 pilegc
root 851994 0 60 41 112 0 112 0:00 0.0 0 0 xmgc
root 1114146 0 36 41 112 0 112 0:00 0.0 0 2 netm
root 1179684 0 37 41 240 0 240 0:00 0.0 0 0 gil
root 1245222 0 16 41 128 0 128 0:00 0.0 0 0 wlmsched
root 1310760 0 16 41 112 0 112 0:00 0.0 0 0 armtrace
root 1507498 1 60 20 147 2 147 0:00 0.0 0 0 syncd
root 1573024 1 60 20 99 11 99 0:00 0.0 0 0 shlap64
root 1704140 1 60 20 250 30 250 0:00 0.0 0 0 errdemon
root 1769566 0 60 20 112 0 112 0:00 0.0 0 0 memp_rbd

Al igual que antes, esta pantalla de reporte se auto refresca cada 2 segundos. Muestra:
! Una línea de título con el nombre del sistema (AIX1), el intervalo de refresco
(2 segundos), y la fecha y hora de la toma de estadísticas.
! Muestra luego una sección grande y detallada con el listado de procesos más
consumidores de CPU. Inicia con un par de líneas con los títulos de las
columnas a mostrar.
‣ La columna PID muestra el identificador del proceso que se encontró
dentro de los más consumidores de CPU.
‣ La columna CPU% muestra el porcentaje de consumos de CPU del proceso
sumando User% y Kernel% del proceso.
‣ La columna COMMAND muestra el nombre del proceso.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 43

AIX Performance ● Ramón Barrios Lascar ® Ínodo 44
Parametrización del Despachador de Tareas de AIX
Comando chdev
El primer comando que se puede usar para parametrizar el despachador de tareas de
AIX es chdev. Este se usa para modificar muchísimos atributos de muchísimos
dispositivos en el sistema. En este caso nos interesa el atributo maxuproc del núcleo del
sistema, mismo que permite poner un límite absoluto de cuántos procesos simultáneos
puede tener un usuario en ejecución en un momento dado. El mismo afecta mucho el
desempeño, ya que:
! Si un usuario llega al límite de procesos dado por maxuproc no podrá ejecutar
más procesos si no cuando termine(n) uno(s) de los que tiene en ejecución —y
no podrá generar más carga en el sistema—.
! Si el límite es muy alto, es más probable que un único usuario genere tanta
carga como para afectar muy negativamente al sistema.
Ejemplo #1a:
[0 root@AIX1:/] lsattr -EHl sys0 -a maxuproc
attribute value description user_settable

maxuproc 128 Maximum number of PROCESSES allowed per user True

[0 root@AIX1:/] lsattr -RHl sys0 -a maxuproc
40...131072 (+1)
[0 root@AIX1:/] lsattr -DHl sys0 -a maxuproc
attribute deflt description user_settable

maxuproc 128 Maximum number of PROCESSES allowed per user True

Se observa que en este AIX el valor actual —con la opción E— (128 procesos simultáneos
por usuario) es el predeterminado 128 —con la opción D—. Se observa también que el
rango va de 40 a 131072, siendo cualquier entero (va de 1 en 1).
Ejemplo #1b:
[0 root@AIX1:/] chdev -l sys0 -a maxuproc=512
sys0 changed
Muestra en el ejemplo #1b cómo se cambia el atributo, ahora, deberá tenerse en cuenta
que:
! Cuando se aumenta maxuproc el cambio lo toma inmediatamente.
! Cuando se disminuye maxuproc el cambio lo toma en el próximo inicio,
aunque no reporte este caso.
Nota #1: iniciar un proceso toma en el mejor de los casos 50 ms, esta situación se da
cuando el proceso sale de un ejecutable que ha sido ejecutado recientemente.
Nota #2: En AIX reciente se puede limitar la cantidad de procesos simultáneos por
usuario individual también —maxuproc es un límite global por usuario para todos los
usuarios—, usando los atributos de usuario nproc y nproc_hard.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 45

AIX Performance ● Ramón Barrios Lascar ® Ínodo 46
 Comando schedo
El comando schedo (scheduler options) es un comando administrativo poderoso. El
mismo necesita permisos de root y permite listar, revisar y cambiar los parámetros que
afectan directamente al despachador de tareas de AIX.
Ejemplo #1:
[0 root@AIX1:/] schedo -a
... # salida suprimida ...
sched_D = 16
sched_R = 16
tb_balance_S0 = 2
tb_balance_S1 = 2
tb_threshold = 100
timeslice = 1
... # salida suprimida ...

El mismo, cuando se usa con la opción a lista todos los atributos no restringidos con sus
valores actuales.
Ejemplo #2:
[1 root@AIX1:/] schedo -L
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
affinity_lim 7 7 7 0 100 dispatches D
--------------------------------------------------------------------------------
big_tick_size 1 1 1 1 100 10 ms D
--------------------------------------------------------------------------------
ded_cpu_donate_thresh 80 80 80 0 100 % busy D
--------------------------------------------------------------------------------
fixed_pri_global 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
force_grq 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
maxspin 16K 16K 16K 1 4G-1 spins D
--------------------------------------------------------------------------------
pacefork 10 10 10 10 2G-1 clock ticks D
--------------------------------------------------------------------------------
proc_disk_stats 1 1 1 0 1 boolean D
--------------------------------------------------------------------------------
sched_D 16 16 16 0 32 D
--------------------------------------------------------------------------------
sched_R 16 16 16 0 32 D
--------------------------------------------------------------------------------
tb_balance_S0 2 2 2 0 2 ticks D
--------------------------------------------------------------------------------
tb_balance_S1 2 2 2 0 2 ticks D
--------------------------------------------------------------------------------
tb_threshold 100 100 100 10 1000 ticks D
--------------------------------------------------------------------------------
timeslice 1 1 1 0 2G-1 clock ticks D
--------------------------------------------------------------------------------
vpm_fold_policy 1 1 1 0 15 D
--------------------------------------------------------------------------------
vpm_throughput_core_threshold

AIX Performance ● Ramón Barrios Lascar ® Ínodo 47

 1 1 1 0 512 cores D
--------------------------------------------------------------------------------
vpm_throughput_mode 0 0 0 0 4 level D
--------------------------------------------------------------------------------
vpm_xvcpus 0 0 0 -1 512 processors D
--------------------------------------------------------------------------------

n/a means parameter not supported by the current platform or kernel

Parameter types:
S = Static: cannot be changed
D = Dynamic: can be freely changed
B = Bosboot: can only be changed using bosboot and reboot
R = Reboot: can only be changed during reboot
C = Connect: changes are only effective for future socket connections
M = Mount: changes are only effective for future mountings
I = Incremental: can only be incremented
d = deprecated: deprecated and cannot be changed

Value conventions:
K = Kilo: 2^10 G = Giga: 2^30 P = Peta: 2^50
M = Mega: 2^20 T = Tera: 2^40 E = Exa: 2^60

Cuando se usa con la conveniente opción L lista todos los parámetros no restringidos
con, mostrando diversas columnas:
! Name Nombre del parámetro del despachador.
! CUR Valor actual del parámetro
! DEF Valor predeterminado del mismo
! BOOT Valor que tomará al próximo inicio del sistema
! MIN Valor mínimo aceptable para el parámetro
! MAX Valor máximo aceptable para el parámetro
! UNIT Descripción de la unidad de medida del parámetro
! TYPE Como lo describe abajo, si el parámetro es estático/no cambiable
(S), si es dinámico/cambiable en línea (D), si sólo lo toma al
recrear la copia del núcleo en el volumen de carga del sistema
operativo hd5 (B), si necesita un reinicio (R), si lo toma en la
próxima conexión de un usuario (C), si lo toma en el próximo
montaje de un sistema de archivos (M), si sólo lo toma si el
parámetro se aumenta (I), si está despreciado y no debe
cambiarse (d).
Para cambiar cualquier parámetro se usa schedo -o parámetro=valor, que tomará si el
parámetro es dinámico (D). Ahora, los cambios hechos así se pierden al reiniciar el
sistema, a menos que se “vuelvan” permanentes con schedo -p -o parámetro=valor.
Ejemplo #2a:
[0 root@AIX1:/] schedo -o sched_R
sched_R = 16

AIX Performance ● Ramón Barrios Lascar ® Ínodo 48

 [0 root@AIX1:/] schedo -o sched_R=20
Setting sched_R to 20
[0 root@AIX1:/] schedo -L sched_R
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
sched_R 20 16 16 0 32 D
--------------------------------------------------------------------------------
[0 root@AIX1:/] schedo -po sched_R=20
Setting sched_R to 20 in nextboot file
Setting sched_R to 20
[0 root@AIX1:/] schedo -L sched_R
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
sched_R 20 16 20 0 32 D
--------------------------------------------------------------------------------

En este ejemplo revisamos el parámetro sched_R, lo cambiamos dinámicamente —

cambio que recibe porque el parámetro es de tipo D— y como no deseamos que se pierda
el cambio lo dejamos permanente con sched -p -o sched_R=20.
Si se revisa el archivo /etc/tunables/nextboot se encontraría el efecto:
Ejemplo #2b:
[0 root@AIX1:/] cat /etc/tunables/nextboot | tail -n3

schedo:
sched_R = "20"

AIX Performance ● Ramón Barrios Lascar ® Ínodo 49

AIX Performance ● Ramón Barrios Lascar ® Ínodo 50
Conceptos de Desempeño: Funcionamiento del Manejador de
Memoria Virtual de AIX
El VMM o Manejador de Memoria de AIX
Aunque el manejador de memoria —oficialmente manejador de memoria virtual— de
AIX se derivó originalmente del de Unix System V, con el tiempo ha evolucionado a algo
muy diferente que amerita de una explicación detallada —misma que no se podrá hacer
en este documento con la profundidad que de verdad amerita—. A pesar de eso, se
tratará aquí de dar una explicación suficientemente detallada para poder comprender y
parametrizar su funcionamiento para el ajuste del desempeño en la mayoría de los
casos.

Conceptos: Manejador de Memoria Virtual

Según el funcionamiento del hardware de acceso y manejo de memoria RAM en los
servidores Power, apenas el núcleo del sistema operativo carga, una de sus rutinas
internas se encarga de distribuir porciones de RAM para su uso posterior. Esta rutina se
denomina Manejador de Memoria Virtual (Virtual Memory Manager, VMM). Esta rutina
se encarga de asignar porciones de memoria a los diferentes procesos, hilos y tareas que
lo solicitan. Debido a la no muy positiva aceptación del “nuevo” funcionamiento de la
asignación de memoria en AIX v5.3, en AIX v6.1 se volvió a un funcionamiento muy
parecido al que se tenía antes —AIX v7.1 mantiene básicamente el mismo esquema—. En
AIX v6.1 el concepto central en la asignación de memoria es el de aceptar cualquier
requerimiento o solicitud de memoria —mientras no se salga de los límites definidos
para el usuario propietario del proceso o hilo que hace el requerimiento ni de los límites
definidos para la WPAR donde está el mismo proceso o hilo—, y de respaldar cualquier
requerimiento con el mínimo bloque de RAM posible para el mismo, postergando la
asignación real de memoria “para después”. Así, si un hilo solicita —a través de llamados
como malloc() o xmalloc()— memoria, si solicitara 1KB, AIX “asignaría” 4KB, que es lo
mínimo que pueden administrar tanto los chips manejadores de memoria en Power
como el VMM, temporalmente “desperdiciando” los otros 3KB —que se usarían en una
posible solicitud posterior del mismo hilo—; y si solicitara 1MB, AIX también asignaría
4KB, postergando la entrega de los otros 1020KB (1MB = 1024KB), donde esperaría la primera
referencia real —uso— para asignar, normalmente otros 4KB.

Asignación Postergada
Como se ha mencionado ligeramente AIX, de manera predeterminada usa dos ideas en la
asignación de memoria:
! La memoria siempre la asigna por “bloques” de tamaño fijo, que para el caso
de la memoria se llaman “memory pages” o simplemente páginas. En AIX el
tamaño predeterminado y no configurable es 4KB por página.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 51

 ! La memoria AIX siempre la asigna de a una (1) página por llamado,
independientemente del tamaño real de la solicitud. Si le piden 200B, AIX
asigna 4KB, si le piden 2KB AIX asigna 4KB, si le piden 2MB AIX asigna 4KB, y si le
piden 2GB, también asigna 4KB.
Siendo como se menciona, el VMM de AIX administra una tabla indexada con las
asignaciones de páginas (de 4KB) por hilo de ejecución. Y, siendo tan grande este índice
—habiendo 1048576 páginas de 4KB en 4GB de RAM— en la mayoría de las máquinas,
administra simultáneamente un índice al índice. El índice al índice —siendo el grande lo
que se denomina TLB y el pequeño el índice del TLB— AIX lo marca para estar siempre
residente en RAM, al igual que las rutinas del mismo VMM. En esta tabla de
asignaciones, simultáneamente AIX administra una columna de “asignaciones
pendientes” o “deudas”, que el VMM sabe que debe cumplir con celeridad y sin excusas,
ya que oficialmente en lenguaje C —el lenguaje en que se desarrollaron el núcleo y el
VMM de AIX— y en la mayoría de los lenguajes de programación, si un llamado de
memoria no se pudo cumplir debió haber fallado —en C sería devolver un nulo—, y si no
falló se tiene permiso para usar la memoria que se asignó o se obtuvo a través del
llamado. El VMM va llevando registro de todos estos “pendientes”, cosa que se puede
consultar en muchos comandos estadísticos como el “tamaño virtual” de un proceso,
hilo, bloque de memoria y así. En nuestro ejemplo, si un programa solicita 1024KB (1MB),
recibe 4KB reales más 1020KB virtuales, que sólo existen temporalmente como una
anotación en las tablas del VMM.
El sistema manejador de memoria de AIX es progresivo: cuando un programa o proceso
ejecuta, va leyendo las instrucciones de disco —del archivo ejecutable— de a 4KB en 4KB,
y las va copiando a regiones idénticas en RAM, iguales, de 4KB. Cuando va asignando
dinámicamente memoria lo va haciendo de 4KB en 4KB. Y cuando va liberando —o
buscando qué liberar— lo va haciendo de 4KB en 4KB, también.

Conceptos: páginas y paginación

Como se mencionó, AIX trabaja toda la RAM como una gran cuadrícula, donde va
tomando porciones de 4KB y las va asignando para el uso de los hilos que los van
requiriendo.

Fallas de Página (page faults)

Cuando un proceso usa o menciona la dirección 4096 —siendo la primera dirección de la
primera página la número 0 y la última de la misma página la 4095—, la primera página
que se solicitó y el VMM respondió con un bloque que supuestamente la incluía —la
segunda página, sólo la primera realmente estaba incluida— el chip manejador de
memoria dispara una señal —en hardware, que se captura en software— llamada “falla
de página” (page fault). Con esta señal:
! AIX lleva una estadística, por hilo/proceso, por CPU lógica, global, por
período de tiempo.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 52

 ! Se detiene el proceso por “falta de memoria”. Esta pausa es temporal,
mientras se resuelve una nueva asignación real de RAM. Esta pausa también
entra a unas estadísticas.
! Se dispara automáticamente el VMM, el cual asigna una (y solo una) página
de memoria para resolver la situación con un único acceso —a la dirección
4096 del bloque—.

Páginas Grandes de Memoria

Una manera como el VMM de AIX intenta optimizar el esquema arriba descrito, sin
aumentar excesivamente el consumo —como sería el entregar inmediatamente toda la
RAM asignada— es el de manejar páginas —y así las asignaciones— mucho más
grandes. Esto es posible según el hardware con el que se cuente, ya que sólo los chips
manejadores de memoria de los servidores más recientes pueden direccionar bloques
con otros tamaños.
! Los servidores de últimas generaciones permiten manejar páginas medianas
de 64KB, y en este caso, si el VMM de AIX nota que el hardware lo permite,
promueve 16 páginas contiguas, todas asignadas a un mismo hilo para que se
comporten como una única página de 64KB. Cuando es necesario, hay vuelve a
fraccionar las páginas de 64KB en páginas de 4KB automáticamente y sin
consecuencia. Este comportamiento se puede observar únicamente en los
indicadores estadísticos, que separan los números de 4KB de los consumos y
usos de 64KB. Este esquema permite reducir el número de apuntadores
manejados en los índices TLB en una considerable cantidad.
! Los servidores (y AIX) de últimas generaciones permiten configurar regiones
de memoria que se manejen como páginas grandes de 16MB cada una, páginas
enormes de 16GB cada una o páginas gigantes de 1TB cada una. Estas deben
configurarse previamente en AIX (y las de 16GB y 1TB primero como
propiedades de la LPAR/VM donde el AIX corre). Y son sólo asignables a hilos
de procesos debidamente configurados corriendo con usuarios privilegiados
que hagan los llamados adecuados de manejo de memoria de 64 bits.
Cuando se configuran bloques grandes, enormes o gigantes:
! Se puede afectar muy negativamente el desempeño de todo el AIX, ya que los
bloques de memoria de estos tamaños son “saltados” por el VMM cuando hay
que liberar, reorganizar, y que copiar a disco. Así, a AIX le quedará menos
para el uso de todos los procesos comunes y de todas las tareas
administrativas —como el manejo de los dispositivos, los archivos y las
comunicaciones de red—.
! Se puede afectar muy positivamente unos procesos, ya que AIX y el proceso,
para llegar a una posición de RAM tiene que hacer muy pocos cálculos y muy
pocos saltos (para manejar 4GB de RAM en bloques de 16MB se necesitan sólo
256 entradas en la TLB, y no más de un millón si fuesen de 4KB las páginas).
Este tipo de configuraciones se realizan cuando se quiere beneficiar

AIX Performance ● Ramón Barrios Lascar ® Ínodo 53

 totalmente el desempeño de unos pocos procesos que se han validado son
compatibles y pueden hacer el tipo de requerimientos que se necesitan para
acceder a RAM en bloques grandes.
Nota #1: Cuando no se hacen todas las configuraciones necesarias para los accesos
especiales de memoria, el VMM simplemente cumple los requerimientos con bloques de
memoria de 4KB. Así, si un servidor se configura de 32GB, y de esos, 16GB en bloques de
memoria grande (sin importar si son de 16MB o de 16GB), y un proceso solicita 16GB de
RAM, se le entregará un apuntador a 4KB si no se dan las condiciones, pero un
apuntador a 16GB si sí se dan las condiciones. Es decir, o se usa efectivamente lo que se
configuró —y el desempeño mejorará— o no se usará nada de lo que se configuró —y
todo lo que no se configuró, con lo que el desempeño empeorará—.
Nota #2: La memoria en bloques grandes nunca es apoyada por disco para completar los
requerimientos. Es decir, AIX no “pagina” los bloques de memoria grande.

Clasificación Según Tipos de Consumo

Cada vez que un proceso solicita memoria a través de un llamado estándar —un
malloc(), calloc() o xmalloc()— AIX “marca” en el índice TLB que el bloque asignado
fue para propósito general, esto es le pone una marca W (working o computational se
reporta en diferentes utilitarios estadísticos). Esta marca de clasificación le indica al
VMM que AIX no tiene certeza de los contenidos, y por ello debe tener una protección
especial. En cambio, cuando AIX mismo consume RAM porque está procesando
paquetes de red, o requerimientos RPC (o NFS que se basa en requerimientos RPC), el
VMM sabe de dónde vienen o para dónde van los contenidos, así que no tiene que hacer
protecciones especiales de los contenidos, más bien asegurar el envió o entrega a su
destinatario —y con ello las regiones de memoria se podrían considerar liberados de su
uso y se pueden reusar sin guardar los contenidos—. Mientras se procesa un archivo (a
través de un archivo usando una variable apuntador de tipo FILE* o equivalente), el
VMM sabe que lo que se maneja a través de los accesos es un archivo, y cuál es el
archivo, por lo que se refleje en la memoria o se obtiene del archivo o se verá reflejado en
el archivo. Cualquiera de estos usos hará que los segmentos de memoria relacionados
(aquí “segmento” equivale a un conjunto de páginas de memoria una detrás de otra con
contenidos de archivos con fragmentos del mismo, uno detrás de otro), se marquen
como relacionados o apoyados en el archivo, y la protección que tienen es el de
soportarse en el archivo y AIX protege para que el archivo no se pueda borrar. En
general, conforme AIX va leyendo un archivo, va copiando bloques suficientes para
completar 4KB y los contenidos los copia a una página igual, de 4KB; esto en términos
genéricos de teoría de sistemas operativos quiere decir que todos los archivos en AIX
son “memory mapped files”, donde cada archivo que se lea es copiado, al menos
parcialmente a espacio igual de memoria RAM, sin solicitud directa del hilo o proceso
que lo lee. Cuando el archivo se cierra —porque ya no se está leyendo o escribiendo—
AIX no lo “limpia” de la memoria, lo mantiene, al menos parcialmente, bajo la premisa de
que es muy probable de que se vuelva a usar muy pronto, y ya lo tendrá, en la memoria.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 54

 Nota #3: Cuando se abre un archivo y se incluye la bandera u opción de apertura
O_DIRECT, o se abre de un sistema de archivos que fue montado con las opciones DIO —
direct I/O— y/o CIO —concurrent direct I/O— el VMM no copia lo que va leyendo o
escribiendo a bloques de memoria.
Nota #2: Cuando se borra un archivo de un sistema de archivos, si el VMM tiene
porciones del archivos copiados a memoria, marcará inmediatamente las porciones
como memoria libre, hasta un cierto límite, según el parámetro del núcleo pd_npages.
Según esto AIX va clasificando:
! Las páginas de memoria que se van asignando directamente a los hilos de
ejecución como resultado de llamados de requerimiento de memoria se
marcan —se marcan sus índices— como de tipo W o working memory.
! Las páginas de memoria que se van usando cuando se va leyendo o
escribiendo un archivo que está contenido en un sistema de archivos de tipo
“Sistema de Archivos de AIX con Registro” —formato JFS— se marcan como
de tipo P (persistent o permanent memory).
! Las páginas de memoria que se van usando cuando se va leyendo o
escribiendo en un archivo que está contenido en un sistema de archivos
JFS2, NFS, CDRFS, UDF (AIX Enhanced Journal File System) se marcan como
de tipo C (client memory). Todos los formatos de archivo instalable en AIX
usan la memoria diferente —GPFS usa un gran bloque de memoria W y otros
varios más pequeños W e indirectamente C—, así que deberá revisarse la
documentación para saber identificar.

Paginación a Disco
Como la mayoría de los sistemas operativos —en especial los sistemas operativos que
cumplen Posix y no son de tiempo real—, AIX se apoya en espacio de disco para cumplir
con requerimientos de RAM superiores a la físicamente disponible. Dependiendo de la
política de manejo de paginación que tenga el hilo (que es la política de paginación del
proceso donde está el hilo, y si no la hay, sería la política de paginación del sistema), se
pueden dar cuatro casos:
! Original El esquema original de manejo de espacio de paginación (hasta
AIX v4.3.2) hacía que el VMM capturara espacio de temporal de paginación en
disco cuando cada página de memoria RAM asignada directamente (con
malloc(), calloc(), xmalloc() y equivalentes) era usada. Cuando el proceso
que contiene al hilo de ejecución finalice, o cuando el mismo use disclaim()
el VMM recuperará el espacio temporal de paginación usado. Este es el
esquema de manejo predeterminado hasta AIX v4.3.2.
! PSALLOC=late Este esquema de manejo de espacio de paginación hace
que el VMM capture espacio de paginación sólo cuando está liberando
páginas en RAM de tipo W —no cuando se asignan inicialmente—. Cuando el
proceso que contiene al hilo de ejecución finalice, o cuando el mismo use

AIX Performance ● Ramón Barrios Lascar ® Ínodo 55

 disclaim() el VMM recuperará el espacio temporal de paginación usado. Este
es el esquema de manejo predeterminado de las versiones anteriores a AIX
v5.3.
! PSALLOC=early Este esquema de manejo de espacio de paginación hace
que el VMM capture espacio de paginación igual a las páginas de RAM
asignadas a un hilo o proceso tan pronto como se asignen, si se considera que
son de tipo W (como cuando son el resultado de un requerimiento directo
malloc(), calloc(), xmalloc()). Cuando el proceso que contiene al hilo de
ejecución finalice, o cuando el mismo use disclaim() el VMM recuperará el
espacio temporal de paginación usado. Este es el esquema de manejo
predeterminado de AIX v5.3.
! defps=1 Este esquema de manejo de espacio de paginación hace que el
VMM capture espacio temporal de paginación cuando está liberando páginas
en RAM de tipo W —no cuando se asignan inicialmente—. Cuando el proceso
dueño de las páginas en RAM usa disclaim(), las páginas copiadas a disco
son “marcadas para liberar” pero no liberadas. Cuando se detecte que en los
espacios de paginación sólo quedan menos o igual cantidad que el parámetro
npsscrubmin el VMM liberará tantas páginas temporales en disco como sean
necesarias para llegar al parámetro npsscrubmax. La detección de espacio para
liberar en paginación de disco sólo se activa si los parámetros scrub o
scrubclean son iguales a uno (1). Independiente de scrub y scrubclean, el
VMM libera las páginas en espacio temporal de disco de los procesos recién
terminados.
Conforme se va necesitando AIX va llenando las páginas de RAM y siempre va
clasificando según su uso, como se mencionó (en páginas W, páginas P y páginas C). Con
esto, poco a poco, toda la RAM del sistema se va consumiendo, siendo el funcionamiento
normal y sin presiones de AIX. Conforme se esté llenando casi toda la RAM del sistema,
el VMM considera un primer parámetro importantísimo en el manejo de la memoria:
minfree.

Paginación a Disco: Archivos

Un concepto que puede confundir al administrador novato de AIX es el de las
estadísticas de paginación:
! Todas las lecturas de páginas en espacio de paginación mas todas las lecturas
de archivos con búfer (las normales sin O_DIRECT) se contabilizan en el
indicador pageins o lo que es lo mismo, pi (dependiendo del comando y la
sintaxis para verla).
! Todas las escrituras de páginas a espacio de paginación mas todas las
escrituras de archivos con búfer (las normales sin O_DIRECT) se contabilizan
en el indicador pageouts o lo que es igual, po (dependiendo del comando y la
sintaxis para verla).

AIX Performance ● Ramón Barrios Lascar ® Ínodo 56

 ! Todas las lecturas de páginas en espacio de paginación son contabilizadas
simultáneamente en el indicador page space pageins (aunque se suman al
también a pageins).
! Todas las escrituras de páginas a espacio de paginación son contabilizadas al
mismo tiempo en el indicador page space pageouts (aunque se sumen al
indicador pageouts).
Para obtener los indicadores de páginas leídas de archivos deberá restarse entonces
page space pageins de pageins y para obtener los indicadores de páginas escritas a
archivos deberá restarse page space pageouts de pageouts.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 57

AIX Performance ● Ramón Barrios Lascar ® Ínodo 58
 Conceptos de Memoria: Límites, Parámetros y Valores
El VMM de AIX considera numerosas variables que definen cómo se consume la RAM,
en qué, cómo se libera, cómo se copia, cómo se mueve y cómo se protegen las diferentes
páginas de RAM. Se listan algunos —los más importantes— a continuación.

Minfree
El parámetro minfree del núcleo del sistema operativo (visible entre otros con vmo -o
minfree) le indica al VMM qué es aceptable tener como libre sin uso absoluto en cada
uno de los pools de memoria (mempools, subdivisiones de memoria “manejada” cada una
por procesador lógico). Cuando se llega a este número o menos, se dispara la rutina
“robador de páginas” (page stealer) del núcleo del sistema para tratar de conseguir
páginas de memoria RAM libre antes de que lleguen a cero. Como el parámetro ahora es
por mempool, luego de unos días de funcionamiento normal en un servidor parametrizado
predeterminado —o adecuadamente— la cantidad libre absoluta del servidor estará
alrededor de mempools×minfree, en unidades de páginas de 4KB.

Maxfree
Cuando se dispara el “liberador de páginas” (page stealer) del VMM, el mismo escaneará
un primer pool de memoria (mempool) para “candidatizar” páginas que sean posibles de
liberar en un próximo paso. Cuando termine de analizar el pool de memoria, el liberador
de páginas marcará como libres todas las páginas que encuentre sin usar recientemente
hasta llegar al parámetro maxfree. Ahora, el simple hecho de que un proceso haga
mención o uso —oficialmente “referencie”— una dirección de memoria hace que el chip
manejador de memoria de los Power marcará la página de RAM donde está contenida
como “usada” y así el page stealer no la podrá marcar como libre cuando la vea. Al igual
que el parámetro minfree, se puede revisar con vmo -o maxfree, considerando que el
valor está en páginas de 4KB.

Mempools
Inicialmente, en AIX se consideraba toda la RAM como una gran bolsa, pero conforme
las cantidades típicas de RAM que los Power y AIX manejan actualmente, en las
versiones recientes, cuando el núcleo del sistema operativo inicia, el VMM subdivide la
RAM en mempools, cada uno manejado —cuando hay varios— por un diferente
procesador lógico. Cuando mempools es diferente de uno (1), tanto maxfree como minfree
—y la estadística free— son por mempool. Cuando se active el “liberador de
páginas” (page stealer) el mismo intentará liberar primero de un mempool, la siguiente
vez de otro mempool, la siguiente de otro más, y así, cuando libere —poco a poco— del
último de los mempools, volverá a intentarlo con el primer mempool, y así, siendo
menores que toda la RAM, escaneará una porción de la memoria —y no toda— cada vez.
De igual manera que los otros parámetros mencionados, este se revisa con vmo -o
mempools.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 59

 Maxperm
Cuando AIX tiene menos páginas de RAM libres que minfree —por mempool— se dispara
el “liberador de páginas” (page stealer). El mismo considera varios casos para
determinar qué libera —como ya se vio, liberando por mempool a la vez—:
! Revisa cuánta de la memoria se está consumiendo en páginas marcadas como
P (que son copias de los archivos relativamente hace poco usados que están
contenidos en sistemas de archivos JFS).
! Si la cantidad de RAM usada en páginas P es superior a maxperm y el
parámetro strict_maxperm es uno (1), analizará y liberará inmediatamente
tantas páginas como se necesiten para que máximo se estén consumiendo
maxperm.

! Si la cantidad de RAM usada en páginas P es superior a maxperm pero

strict_maxperm no es uno (1) sino cero (0), liberará tantas de tipo P como se
necesite para llegar a maxfree.
! De manera predeterminada strict_maxperm es cero (0), pero como ya no se
usa mucho JFS, ahora es menos común que este parámetro afecte.
! Si la cantidad de RAM usada hace que haya menos libres que minfree, pero
las marcadas como P son menores que maxperm, entonces el “liberador de
páginas” (page stealer) intentará liberar por igual cantidad páginas marcadas
P, marcadas W y marcadas C.

Como las páginas de RAM marcadas como de tipo P son copias directas de fragmentos de
archivos en sistemas de archivos JFS, cuando se liberan el page stealer considera:
! Si las páginas P marcadas para liberar también están marcadas como
“modificadas”, el VMM las envía al sistema de archivos que contiene al
archivo y éste las graba en disco —en sistema de archivos y nunca en
paginación—. Al ser recibidas por el sistema de archivos y las de RAM son
marcadas “libres” y son candidatas de reuso/sobreescritura.
! Si las páginas P marcadas para liberar no están marcadas como
“modificadas”, es decir son iguales las de RAM a las de disco, el VMM
simplemente las marca “libres” y las reusará —para cualquier fin, P, W, C—, sin
más consideración.
Igual que los otros parámetros recién mencionados, este se revisa con vmo -o maxperm o
con el relacionado vmo -o maxperm%.

Minperm
Cuando AIX tiene menos páginas de RAM libres que minfree —por mempool— se dispara
el “liberador de páginas” (page stealer). El mismo también considera varios casos para
determinar qué libera —como ya se vio, liberando por mempool a la vez—:

AIX Performance ● Ramón Barrios Lascar ® Ínodo 60

 ! Revisa cuánta de la memoria se está consumiendo en páginas marcadas como
P (que son copias de los archivos relativamente hace poco usados que están
contenidos en sistemas de archivos JFS).
! Si la cantidad de RAM usada en páginas P es inferior a maxperm el “liberador
de páginas” (page stealer) sólo considerará para liberar páginas que no estén
marcadas como de tipo P, si no las de tipo W o C (working o client pages)
únicamente. Como las marcadas de tipo P son copias de archivos en sistemas
de archivos JFS, la idea es que haya un mínimo de caché de archivos JFS.
! Como el sistema de archivos JFS ha entrado en desuso, es común que las
páginas marcadas P en un AIX sean cero (0) y este parámetro no afectará
realmente.
Igual que los otros parámetros recién mencionados, este se revisa con vmo -o minperm o
con el relacionado vmo -o minperm%.

Maxclient
Como ya se ha mencionado, cuando AIX tiene menos páginas de RAM libres que minfree
—por mempool— se dispara el “liberador de páginas” (page stealer). El mismo considera
varios casos para determinar qué libera —como ya se vio, liberando por mempool a la vez
—:
! Revisa cuánta de la memoria se está consumiendo en páginas marcadas como
C (que son o celdas de memoria usadas para I/O de red, o son copias de
archivos contenidos en sistemas de archivos CDRFS, UDF y especialmente,
JFS2).
! Si la proporción de RAM usada en páginas C es superior a maxclient% y el
parámetro strict_maxclient es uno (1), analizará y liberará inmediatamente
tantas páginas como se necesiten para que máximo se esté consumiendo
como maxclient%.
! Si la proporción de RAM usada en páginas C es superior a maxclient% pero
strict_maxclient no es uno (1) sino cero (0), liberará tantas de tipo C como se
necesite para llegar a maxfree.
! De manera predeterminada strict_maxperm es uno (1). Por lo que casi siempre
el sistema intenta que la RAM máximo contenga maxclient% en porciones
copiadas de archivos.
! Si la cantidad de RAM usada hace que haya menos libres que minfree, pero
las marcadas como C son menores que minclient%, entonces el “liberador de
páginas” (page stealer) intentará liberar por igual cantidad páginas marcadas
P, marcadas W y marcadas C.

Como las páginas de RAM marcadas como de tipo C en su mayoría son copias directas de
fragmentos de archivos en sistemas de archivos JFS2, cuando se liberan el page stealer
considera:

AIX Performance ● Ramón Barrios Lascar ® Ínodo 61

 ! Si las páginas C contienen celdas de memoria de transmisión de paquetes de
red, el VMM se las salta y no intenta liberarlas —cuando la capa de
comunicaciones las entregue al destinatario local o las envíe a la red las
marcará como “libres”—.
! Si las páginas C marcadas para liberar también están marcadas como
“modificadas”, el VMM las envía al sistema de archivos que contiene al
archivo y éste las graba en disco —en sistema de archivos y nunca en
paginación—. Al ser recibidas por el sistema de archivos y las de RAM son
marcadas “libres” y son candidatas de reuso/sobreescritura. Este caso es el
mismo sean archivos JFS2 o sean archivos NFS.
! Si las páginas C marcadas para liberar no están marcadas como
“modificadas”, es decir son iguales las de RAM a las de disco, el VMM
simplemente las marca “libres” y las reusará —para cualquier fin, P, W, C—, sin
más consideración.
Igual que los otros parámetros recién mencionados, este se revisa con vmo -o maxclient
o con el relacionado vmo -o maxclient%.

Npswarn
Cuando la cantidad de páginas libres (o no reservadas) en la suma de los espacios de
paginación activos en el sistema son muy pocas, el VMM de AIX se fija en el parámetro
npswarn del núcleo. Apenas hay menos (o lo mismo) páginas libres en los espacios
comparadas con npswarn el VMM (específicamente el proceso init) iniciará el envío de la
señal SIGDANGER (es decir kill -33) a los procesos más nuevos que no sean de los
usuarios excluidos del esquema. Aunque la señal es fuerte, no es absoluta, de manera
que un proceso puede capturar la señal y reaccionar adecuadamente —liberando
memoria con disclaim(), cerrando archivos, terminando de manera ordenadamente y
así— y puede también ignorarla. De manera predeterminada ningún usuario es excluido
y el parámetro npswarn es igual a 4×npskill, parámetro que se describe a continuación.
Igual que todos los parámetros de esta sección, se puede revisar con vmo -o npswarn.

Npskill
Cuando la cantidad de páginas libres (o no reservadas) en la suma de los espacios de
paginación activos en el sistema son demasiadas pocas, el VMM de AIX observa al
parámetro npskill del núcleo. Si son tan pocas que quedan npskill páginas libres o
menos —en espacio de paginación temporal de disco— iniciará el envío de la señal
SIGKILL (es decir kill -9) a los procesos más nuevos que no sean de los usuarios
excluidos del esquema y que no hayan iniciado con pre-captura de espacio de
paginación (así, los iniciados con PSALLOC=early están “protegidos”). De manera
predeterminada npskill tiene el valor de la fórmula:
npskill = MAX( 64, SUM(páginas en espacios de paginación)/128 )

AIX Performance ● Ramón Barrios Lascar ® Ínodo 62

 Así, si se tienen dos espacios de paginación de 1GB cada uno, es decir de 1024MB o 262144
cada uno, se tendría:
npskill = MAX( 64, SUM(262144,262144)/128 ) = MAX( 64,4096) = 4096
y con ello
npswarn = 4 × 4096 = 16384
Igual que todos los parámetros mencionados en esta sección, se puede revisar con el
comando vmo -o npskill.

Nokilluid
Cuando el VMM de AIX nota que hay que detener procesos porque la cantidad de
páginas libres (o no reservadas) en la suma de espacios de paginación temporal en disco
de sistema es críticamente libre, iniciará el envío de señales (SIGDANGER o SIGKILL, según
la situación) para hacerlos terminar. El proceso init se saltará y no les enviará señales a
los procesos de los usuarios cuyo usuario dueño tengan UID menor que el parámetro de
núcleo nokilluid. De manera predeterminada nokilluid es igual a cero (0) con lo que ni
los procesos de root (cuyo UID == 0) son protegidos de las señales de terminación en
caso de escasez crítica de espacio de paginación.
Como siempre en esta sección, revise el parámetro con vmo -o nokilluid.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 63

AIX Performance ● Ramón Barrios Lascar ® Ínodo 64
Conceptos de Desempeño: Monitoreo de Desempeño de
Memoria
Monitoreo de Desempeño de Memoria RAM
Básicamente existen dos tipos de herramientas para monitorear el uso y consumo de
memoria RAM y la manera como éste afecta el desempeño de todo un AIX: (a) usando
herramientas genéricas que hay en todo Unix y (b) usando herramientas específicas de
AIX. Aunque ambas son válidas hay que anotar:
! Las herramientas genéricas o estándar son básicas pero muy livianas, casi no
consumen y cargan las CPU y consumen relativamente muy poca RAM.
! Las herramientas genéricas no tienen en cuenta el reuso que hace el VMM en
AIX, ni conceptos específicos como AME o AMS.
! Las herramientas específicas de AIX son más detalladas, pero cargan más en
consumo de CPU y de RAM.
! Las herramientas específicas de AIX son las únicas que reportan funciones
especiales de AIX como AMS y AME (IBM PowerVM Active Memory Sharing y
Active Memory Expansion).
En todos lo casos es vital tener en cuenta:
! AIX tiende a usar toda la RAM instalada en la máquina. Cuando el conjunto
de hilos y procesos solicitan memoria, se les entrega progresivamente página
a página (marcándola como de tipo W), y el resto lo usa para mantener
búferes de red y copias —a modo de caché— de todos los archivos que se van
usando. A final de cuentas, se mantiene alrededor de un 99 % de uso
permanente de toda la RAM.
! En AIX no se afecta casi el desempeño por el porcentaje de RAM que se esté
usando, se afecta por el porcentaje de RAM que se esté escaneando —para
liberar— y se esté moviendo hacia disco y desde disco —paginando—.
! AIX reusa los segmentos de RAM de tipo P y de tipo C. Así, si diferentes hilos o
procesos referencian al mismo archivo —incluso los archivos ejecutables y
los archivos que son bibliotecas de funciones, es decir códigos binarios— AIX
dará acceso a los diferentes procesos para trabajar simultáneamente las
mismas páginas en RAM.
! El concepto de named y unnamed shared memory segments en AIX cumple
POSIX, como en los demás UNIX. Si un proceso ocupa 450MB en RAM,
incluyendo 400MB de un segmento de memoria compartida, y otro proceso
ocupa 500MB de RAM, pero está accediendo al mismo segmento de memoria
compartida, lo más seguro es que no sumen 950MB de RAM si no 550MB (es
decir (450MB-400MB) + (500MB-400MB) + (400MB)).
Así, que:

AIX Performance ● Ramón Barrios Lascar ® Ínodo 65

 ! Cien (100) procesos ksh, cada uno de 4MB no suman 400MB. Una parte de cada
proceso es una copia en RAM de los fragmentos del archivo ejecutable y otras
partes son copias de los archivos bibliotecas de funciones. Algunos procesos
tienen grandes segmentos de RAM W y otros más pocos.
! Si un hilo de un proceso lee un archivo el mismo se copia a RAM, cuando un
segundo hilo de ejecución —aunque sea de otro proceso— lo lee, realmente le
dan un apuntador a la misma copia en RAM del archivo.
Nota #1: Es muy común que las herramientas genéricas sumen todos los segmentos de
memoria a los que tiene acceso un proceso en ejecución, sin diferenciar si es compartido
con muchos otros procesos.
Nota #2: Dependiendo de la herramienta, si un proceso abre y lee un archivo de 10GB, los
10GB que ocupa en páginas marcadas de tipo P o C puede ser sumado al consumo del
proceso. Algunas herramientas sí diferencian entre el consumo directo del proceso (lo de
uso interno del proceso) y lo que indirectamente usa entre búferes de red y búferes de
operaciones I/O a archivos en disco.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 66

 Monitoreo de Desempeño de Espacios de Paginación
Siendo AIX un sistema operativo donde las direcciones de memoria siempre son
virtuales, el contar siempre con algo de espacio de paginación temporal en disco es un
requerimiento. Ahora, existen muchas preconcepciones alrededor del uso del mismo:
! Tener un x porcentaje de espacio de paginación no debe ser motivo de gran
preocupación en AIX de versiones recientes (AIX v6.1 o v7.1), mucho menos en
versiones anteriores. A semejanza de los indicadores de memoria RAM, tener
una cantidad de datos almacenados “temporalmente” en espacio de
paginación no genera problemas de desempeño mientras estos se encuentren
relativamente estáticos.
! Tener cualquier cantidad de actividad de I/O sobre los espacios de paginación
debe ser una situación a monitorear muy seguido y con gran detalle. Esta es
una de las actividades “internas” de AIX que más pueden afectar
negativamente el desempeño de un sistema como un todo.
Nota #1: Es muy común seguir los requerimientos de un tercero proveedor de un
software a instalar sobre AIX y configurar entre el doble y el triple del tamaño de la RAM
en espacios de paginación. Debería revisarse si esos números son válidos en máquinas
con AIX reciente (AIX v6.1 y/o v7.1) y en especial si son válidos para los tamaños de las
máquinas actuales —es más probable necesitar 12GB de espacio de paginación en una
máquina de 4GB de RAM que 120GB de espacio de paginación en una máquina de 40GB de
RAM—.

Interpretación
Supongamos la situación donde un servidor tiene 64GB de RAM (esto es, más de 16
millones de páginas de memoria), y se le han configurado dos espacios, que suman
128GB. Si este servidor lleva activo, digamos, seis meses, y las estadísticas indican que
tiene usados el 40 % del espacio —51.2GB— esto no tiene porqué ser motivo de
preocupación mientras no tenga gran actividad en el momento que se revise. En 51.2GB
hay algo más de 13M de páginas, pero en seis meses hay más de 15M de segundos
(6 × 30 × 24 × 60 × 60). Es decir, que al bajo ritmo de una página por segundo (4KB/s) se
llegaría a 51.2GB en 77, casi 78 días, y la máquina llevaría tres meses y doce días estable
después de eso, y, además, 4KB es una carga insignificante para un servidor con las CPUs,
controladoras y discos actuales.
Por otro lado, si un servidor, tenga x cantidad de RAM y z cantidad de espacio de
paginación, está moviendo al ritmo de 1000 páginas por segundo, eso equivale a una
transferencia de 4MB/s, que pueden cargar mucho a un disco, por lo que el mismo frenará
otras actividades y les dará poco chance de avanzar.
Nota #2: AIX —hasta versión 7.1— sólo soporta espacios de paginación de memoria
virtual individuales de hasta 64GB. Por eso en el ejemplo se menciona “dos espacios” y
no “un espacio”.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 67

 Nota #3: Los comandos básicos de uso de espacio de paginación reportan “cantidad
usada” y no “actividad actual”.
Nota #4: En AIX v5.3 se usaba mucho el esquema “early paging space allocation”, por
eso en esa versión se puede notar un “consumo” mucho más alto que en la actualidad,
donde lo común es “deferred paging space allocation”.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 68

Monitoreo de Desempeño de Memoria: Comandos
Comando vmstat -w
El comando más básico para el monitoreo del uso de la memoria y cómo se relaciona con
el desempeño es vmstat, cuando se usa sin opciones o se usa con la opción w —la opción
w simplemente le da más espacios a las columnas, conveniente en los servidores
actuales donde la RAM se mide en decenas de GB—.
Ejemplo:
root@srvprbd1 />vmstat -w 10 20

System configuration: lcpu=4 mem=7776MB ent=0.35

kthr memory page faults cpu

------- --------------------- ------------------------------------ ------------------ -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
1 1 3012481 7378 0 35 0 135 974 0 315 47892 721 33 5 57 5
1 1 3014605 2742 0 38 0 196 1668 0 368 148622 1326 50 13 32 4
2 1 3023601 961 0 22 173 654 4627 0 440 38995 899 36 4 49 11
1 2 3025115 1496 0 33 274 806 2554 0 670 42996 1197 33 5 38 24
1 1 3022920 7023 0 10 68 319 820 0 187 34057 426 28 4 64 4
1 1 3018888 9733 0 16 0 0 0 0 204 35047 499 23 3 71 3
1 1 3016503 8726 0 37 0 0 0 0 229 201345 544 24 13 57 5
1 1 3004673 12176 0 82 0 0 0 0 328 29563 764 25 5 61 9
1 2 2983184 14276 0 164 0 32 132 0 423 33838 937 30 4 49 17
1 1 2985420 8264 0 46 0 279 1755 0 373 33051 827 25 4 60 12
2 1 2984925 8462 0 15 0 371 8653 0 444 48577 1009 36 5 49 10
2 1 2975222 10536 0 50 0 123 1246 0 301 31902 676 42 3 48 7
1 1 2969190 14559 0 14 0 51 539 0 271 89681 628 27 7 62 3
2 1 2974387 6872 0 20 0 39 462 0 196 157692 568 26 10 61 3
2 1 2976483 4181 0 30 0 386 11616 0 338 45090 804 31 4 59 6
1 1 2968386 5510 0 45 0 388 3769 0 397 33619 867 26 4 56 14
2 1 2960689 9992 0 38 0 45 82 0 192 40195 481 20 3 72 5
2 1 2958180 10904 0 12 0 180 352 0 193 140462 1205 50 13 35 2
2 1 2961931 7080 0 3 0 65 93 0 150 34088 383 31 3 64 2
2 1 2958146 7805 0 39 0 142 4155 0 359 211693 819 35 14 44 7

El ejemplo muestra un uso básico de vmstat (que como se mencionó con la opción w
reporta usando columnas más anchas, para mantener todo alineado).
Entre otra información, vmstat sin opciones, o sólo con la opción w:
! El comando vmstat se puede ejecutar con uno o dos números como
parámetros. El primer número es —como lo es para los otros comandos— el
tiempo en segundos entre muestra y muestra estadística. El segundo número
es el número de muestras que se desee observar. En nuestro ejemplo el
vmstat mostrará 20 líneas de muestras estadísticas, cada una separada de la
anterior por 10 segundos.
! El comando vmstat inicia con una corta línea que describe lo mínimo de
configuración del sistema o VM donde se está ejecutando. En nuestro ejemplo
dice “System configuration:” y luego: cantidad de procesadores lógicos

AIX Performance ● Ramón Barrios Lascar ® Ínodo 69

 (lcpu=4); cantidad de memoria RAM reportada (mem=7776MB); cantidad de CPU
titulada (ent=0.35).
! Luego vmstat incluye las estadísticas. Las mismas, las agrupa (cuando no se
dan otras opciones aparte de la w), en cinco grupos: hilos de ejecución en
núcleo (kernel threads o kthr); memoria virtual (memory); actividad del
liberador de memoria y de movimientos de páginas de memoria (page);
cambios de contexto, llamados e interrupciones (faults); indicadores de uso
de CPU. En este apartado hablaremos de lo que no mencionamos en el
apartado de vmstat en el capítulo anterior (que hablaba de desempeño de
CPU).
! El grupo “memoria” (memory) incluye dos columnas:
‣ avm (active virtual memory) es la “memoria de trabajo” (en inglés
working set), es decir la cantidad de memoria activamente usada
y necesitada, entre lo que se usa de RAM y lo que se usa en
espacios de paginación. La unidad es “páginas de 4KB”. El ideal es
que el working set sea menor que la RAM —obviamente
comparadas en la misma unidad—, pero no es problemático que
sea algo así como un 110 % del tamaño de la memoria —es decir,
un 10 % superior—.
‣ fre (free pages) es la cantidad de memoria RAM —en páginas de 4KB
— que tiene el sistema. Luego de varios días, en una máquina
predeterminada o debidamente configurada, se estabiliza
alrededor del resultado de multiplicar minfree×mempools. No
indica nada excepto cuando es un número demasiado grande,
donde indica parametrización incorrecta —no tiene sentido más
allá de un 2% de la RAM—.
! El grupo “hilos de núcleo” (kthr o kernel threads) incluye también dos
columnas:
‣ r (ready to run) Es el número de hilos de ejecución de kernel (que
como se mencionó antes, manejan, cada uno, de manera
predeterminada, doce hilos de aplicación) que están o en
ejecución o en las colas de ejecución de cada procesador lógico.
Es un indicador de carga de CPU.
‣ b (blocked on wait queue) Es el número de hilos de ejecución de
kernel —es decir 12× de aplicación— promedio, por cola —y hay
una cola por procesador lógico, habiendo 4 procesadores lógicos
en el AIX del ejemplo— que están esperando por respuestas de
los sistemas de archivos, de los espacios de paginación o porque
el sistema operativo está trabajando a un ritmo reducido por el
esquema de control de carga. Es un indicador de carga de
memoria.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 70

 Como se podrá imaginar por la descripción, no es bueno que el número b
comience a crecer en una máquina, ya que son los procesos que “no ejecutan
porque están esperando o I/O o memoria”, y gran parte del I/O se puede evitar
cuando el sistema cuenta con adecuadas cantidades de memoria. El que el
número se mantenga por encima de cinco (5) es ya un indicador serio o de
necesidades grandes de memoria adicional o de un inadecuado sistema de I/O a
discos.
! El grupo “páginas” (page) es en este apartado el más interesante: muestra las
estadísticas de las actividades del VMM. Incluye:
‣ cy (clock cycles) El número de “vueltas” por segundo, durante el
período (es decir, que como en nuestro ejemplo el parámetro de
vmstat es 10, es promedio en los 10s) en que tuvo que escanear
un memory pool el page stealer, para identificar qué páginas son
susceptibles de ser “liberadas”. Como la “primera vuelta” no se
cuenta, porque se usa para “candidatizar” páginas a “liberar” es
común que el indicador sea cero (0), y de hecho, cualquier
número diferente de cero (0) es indicador malo de escasez seria
de memoria.
‣ sr (scanned pages) El número de páginas promedio por segundo
durante el período que fueron examinadas por el algoritmo de
búsqueda del “liberador de páginas” (page stealer). Como esta
búsqueda consume tiempo de procesador, considerar miles de
páginas por segundo es un indicador de insuficiencia de
memoria.
‣ fr (freed pages) El número de páginas promedio por segundo
durante el período que fueron marcadas como “libre” (free) por el
algoritmo del page stealer. Algunas de las páginas que se marcan
libres implican I/O a disco, por ello no siempre son indicador
directo de algo —puede ser que se esté perdiendo caché de
lectura de archivos pero también puede ser que se estén por fin
enviando paquetes de red que estaban parcialmente retenidos—.
Ahora, si se tiene que este número es mucho menor que el sr,
entonces es un indicador de la intensidad con el que el sistema
intenta liberar memoria aunque no lo logre —con lo que es muy
probable que el indicador sy del grupo cpu aumente al tiempo—.
‣ po (page outs) El número de páginas que salieron —realmente
“fueron copiadas”— de memoria e implicaron escritura en disco.
Este número, al igual que los otros es “páginas por segundo
promedio durante el período”. En este indicador no se
diferencian las páginas de archivos normales que van a disco
por I/O explícita archivos (resultado de fwrite() y similares) de
las páginas que se graban temporalmente en espacios de
paginación porque hay que proteger los contenidos ya que están

AIX Performance ● Ramón Barrios Lascar ® Ínodo 71

 marcadas como tipo W. Ahora, cuando un sistema está corto de
memoria, graba en disco más a menudo y más cosas que
innecesariamente le toca, porque no tiene como mantener en
RAM.
‣ pi (page ins) El número de páginas que “subieron” —realmente
“fueron copiadas”— de disco a memoria. Como todas las
columnas del grupo page, el número es “páginas por segundo
promedio durante el período”. Igual que po, este indicador no
diferencia las páginas de archivos normales que se reciben de
disco por I/O explícita de archivos (resultado de fread() y
similares) de las páginas cuyos contenidos se necesitaron pero
como estaban en espacios de paginación debieron ser leídas a
RAM nuevamente —es decir páginas marcadas W que no hace
mucho debieron desocuparse de la memoria—. Ahora, cuando un
sistema está corto de memoria poco a poco termina aumentando
este número, ya que saca cosas de la memoria que vuelve a
necesitar pronto, lo que implica leer de disco, y esto aumenta el
indicador pi.
En el ejemplo se pueden notar:
! La máquina se beneficiaría de mucha más RAM. AIX está trabajando con
7776MB, que son un poco menos de 2 millones de páginas de 4KB, pero el
conjunto de datos que trabaja necesitan de alrededor de 3 millones de
páginas ya que la columna avm reporta permanentemente alrededor de eso —
a veces ligeramente por arriba, a veces ligeramente por debajo—.
! La columna kthr.b reporta que efectivamente se están manteniendo en
espera al menos a un hilo de núcleo, promedio, en cada muestreo. Así que o el
sistema de I/O es muy lento, o hay una actividad que lo está cargando.
! La columna [Link] muestra que para trabajar cómodo, este AIX debería
tener unos 12GB de RAM, y no un poco menos de 8GB, como está. [Link]
siempre es de alrededor de 3M de páginas, que por 4KB son 12GB.
! Al sistema operativo no le cambiaron los parámetros minfree y maxfree. Eso
no es malo directamente. Por esta razón, mantiene libres siempre entre
0.025 % y 0.100 % de la memoria RAM.

! El sistema operativo por momentos “desespera” mucho por la insuficiencia de

la memoria, lo que sube mucho el indicador [Link] —que llega a ser varios
miles y hasta más de diez mil—, y al mismo tiempo, frena a todo el sistema
operativo, ya que concuerda con las subidas del indicador [Link] y también, a
veces de kthr.b. Este AIX está buscando muy activamente qué liberar de la
memoria para poder cumplir con los requerimientos de 3M de páginas cuando
sólo hay físicamente menos de 2M de páginas de RAM.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 72

 ! El sistema operativo no logra liberar mucho de lo que considera, por lo que
mucha de la actividad del page stealer se pierde. Es un síntoma serio el que
no logra liberar más de 1/6 de lo que considera el page stealer. En nuestro
ejemplo muchas veces sólo libera 1/10 de lo que considera (es decir que
[Link] > 6×[Link])

! Otro síntoma serio es el hecho de que [Link] sea activo mientras que
[Link] se mantenga en cero. Esto se da por dos casos: se están leyendo
archivos que básicamente se procesan en RAM —y cuyos resultados no se
necesitan en disco, como archivos de configuración, o cuando el ambiente es
un servidor de páginas web, servidor DNS o servidor DHCP—; o cuando el
servidor intenta llenar el caché lectura de archivos en RAM pero la necesidad
extrema de memoria lo obliga constantemente a desocuparlo. Debería
analizarse la función que cumple el servidor del ejemplo para poder
diferenciar y decidir.
! Cuando el ambiente está limitado por el sistema de I/O, sea porque este no
tiene la arquitectura adecuada para la carga del servidor o sea porque la
carga que se le impone es excesiva —debe leer archivos y los tiene que volver
a leer pronto, porque lo que leyó sale pronto de RAM; o peor, tiene que estar
escribiendo y leyendo continuamente en espacios de paginación— se elevará
el indicador [Link]. Si este se mantiene por encima de 10 % o 15 % se hará
regular el desempeño del servidor; y si se mantiene por encima del 20 %, lo
más probable es que los administradores, los operadores, y hasta los usuarios
remotos del servidor se quejen del desempeño, porque será muy regular
yendo a malo.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 73

AIX Performance ● Ramón Barrios Lascar ® Ínodo 74
 Comando vmstat -s
El comando vmstat con la opción s muestra una única estadística puntual —no muestras
repetidas— pero muy detallada de la actividad del VMM —y del page stealer— sin
incluir estadísticas de otros subsistemas —no de hardware o de CPU—, y en especial,
incluye los indicadores de movimiento de espacios de paginación por separado del total,
a diferencia de vmstat -w.
Como el comando no es repetitivo, deberá entonces usarse al menos dos veces seguidas,
con el espacio de tiempo intermedio que se considere necesario, durante el cual haya
una actividad o proceso que se quiera detallar. Nótese que el comando vmstat -s no
tiene cómo reportar únicamente la actividad del VMM relacionada con un proceso
específico.
Ejemplo:
[0 root@AIX1:/] vmstat -s >> /tmp/vmstat-s_20140618a.txt
... # otras actividades
... # tiempo después
[0 root@AIX1:/] vmstat -s >> /tmp/vmstat-s_20140618b.txt
[0 root@AIX1:/] cat /tmp/vmstat-s_20140618a.txt
725660 total address trans. faults
33344 page ins
4590 page outs
0 paging space page ins
0 paging space page outs
0 total reclaims
627092 zero filled pages faults
2576 executable filled pages faults
0 pages examined by clock
0 revolutions of the clock hand
0 pages freed by the clock
103083 backtracks
0 free frame waits
0 extend XPT waits
9115 pending I/O waits
37934 start I/Os
16849 iodones
166347 cpu context switches
12200 device interrupts
50010 software interrupts
153092 decrementer interrupts
138 mpc-sent interrupts
138 mpc-receive interrupts
808 phantom interrupts
0 traps
2762297 syscalls
[0 root@AIX1:/] cat /tmp/vmstat-s_20140618b.txt
734742 total address trans. faults
40501 page ins
30691 page outs
0 paging space page ins
0 paging space page outs
0 total reclaims
630373 zero filled pages faults
2611 executable filled pages faults

AIX Performance ● Ramón Barrios Lascar ® Ínodo 75

 0 pages examined by clock
0 revolutions of the clock hand
0 pages freed by the clock
103171 backtracks
0 free frame waits
0 extend XPT waits
9195 pending I/O waits
71192 start I/Os
18598 iodones
673810 cpu context switches
25855 device interrupts
65202 software interrupts
216179 decrementer interrupts
186 mpc-sent interrupts
186 mpc-receive interrupts
1418 phantom interrupts
0 traps
5547789 syscalls
Se observa:
! vmstat -s genera un reporte de 26 estadísticas puntuales. Los indicadores
que muestra siempre son contadores absolutos desde el inicio del sistema.
! Entre otras estadísticas menos interesantes muestra:
! page ins totales, en número de operaciones. Esto incluye lecturas de archivos
comunes y lecturas de espacios de paginación.
! page outs totales, en número de operaciones. Esto incluye escrituras
comunes a archivos y escrituras en espacios de paginación.
! paging space page ins, en número de operaciones. Como lo indica es sólo la
porción relacionada con las lecturas de espacios de paginación.
! paging space page outs, en número de operaciones. Como lo indica es sólo la
porción relacionada con las escrituras en espacios de paginación.
! zero filled pages faults, en número de operaciones. Esto básicamente es la
cantidad de veces que, entre todos los procesos, se ha tenido que cumplir con
calloc() página de 4KB por página de 4KB.

! executable filled pages faults, en número de operaciones. Esto es

básicamente la cantidad de veces, entre toda la actividad, que se ha tenido
que leer fragmentos de archivos ejecutables y bibliotecas de funciones para
poder ejecutar las instrucciones binarias allí contenidas.
! pages examined by clock, en número de operaciones. Esto básicamente es el
indicador absoluto de la columna [Link] de vmstat básico sin la opción s.
! revolutions of the clock hand, en número de operaciones. Esto
básicamente es el indicador absoluto de la columna [Link] de vmstat básico
sin la opción s.
! pages freed by the clock, en número de operaciones. Esto básicamente es el
indicador absoluto de la columna [Link] de vmstat básico sin la opción s.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 76

 ! pending I/O waits, en número de operaciones. Esto básicamente es el
indicador absoluto de la columna kthr.b de vmstat básico sin la opción s.
! start I/Os, en número de operaciones. Esto es cuántas veces se ha iniciado
operaciones dirigidas por las funciones read(), fread(), write() y fwrite().
! iodones, en número de operaciones. Esto es cuántas veces se ha iniciado
operaciones dirigidas por las funciones read(), fread(), write() y fwrite().
Como son contadores absolutos, lo común es usar un script para calcular diferencias en
un período.
Ejemplo:
[0 root@AIX1:/] egrep ‘page (ins|outs)’ /tmp/vmstat-s_20140618?.txt
33344 page ins
4590 page outs
0 paging space page ins
0 paging space page outs
40501 page ins
30691 page outs
0 paging space page ins
0 paging space page outs
[0 root@AIX1:/] echo "page ins difference=" $((40501-33344))
page ins difference= 7157
[0 root@AIX1:/] echo "page outs difference=" $((30691-4590))
page outs difference= 26101
Donde:
! Como no hubo movimiento de lectura de espacio de paginación no se usaron
para cálculos. Las lecturas de archivos son
(page ins) - (paging space page ins)
! Como no hubo movimiento de escritura en espacio de paginación no se
usaron para cálculos. Las escrituras de archivos son
(page outs) - (paging space page outs)
Script:
El siguiente script, vmstatit es práctico, realmente usable si se van a repetir las
operaciones:
#!/usr/bin/ksh
# vmstatit

export PRGNAME=$(basename "$0" .sh)

if [ $(uname) != "AIX" ] ; then
printf "$PRGNAME only runs on AIX\n" >&2
exit 1
else
TEMPFILE="/tmp/${PRGNAME}_${$}.tmp"
NUMRFILE="/tmp/${PRGNAME}_${$}.nr"
RESUFILE="/tmp/${PRGNAME}_${$}.txt"
> "$TEMPFILE"
> "$RESUFILE"
vmstat -s >> "$TEMPFILE"
echo "COMMAND: $@ ----------------------------------------------------"| tee -a "$RESUFILE"

AIX Performance ● Ramón Barrios Lascar ® Ínodo 77

 echo "OUTPUT: ----------" | tee -a "$RESUFILE"
time "$@"
echo "OUTPUT: ----------" | tee -a "$RESUFILE"
vmstat -s >> "$TEMPFILE"
grep "^[ 0-9]*page ins" "$TEMPFILE" > "$NUMRFILE"
REALPAGEINS=$(awk '{t=t-$1} END {print -1*t}' "$NUMRFILE")
printf "Ordinary Input:\n" | tee -a "$RESUFILE"
cat "$NUMRFILE" | tee -a "$RESUFILE"
printf " % 8d real pageins\n" ${REALPAGEINS} | tee -a "$RESUFILE"
grep "^[ 0-9]* page outs" "$TEMPFILE" > "$NUMRFILE"
REALPAGEOUTS=$(awk '{t=t-$1} END {print -1*t}' "$NUMRFILE")
printf "Ordinary Output:\n" | tee -a "$RESUFILE"
cat "$NUMRFILE" | tee -a "$RESUFILE"
printf " % 8d real pageouts\n" ${REALPAGEOUTS} | tee -a "$RESUFILE"
grep "pagi.*outs" "$TEMPFILE" > "$NUMRFILE"
REALPSOUTS=$(awk '{t=t-$1} END {print -1*t}' "$NUMRFILE")
printf "True Paging Output:\n" | tee -a "$RESUFILE"
cat "$NUMRFILE" | tee -a "$RESUFILE"
printf " % 8d real paging space page outs\n" ${REALPSOUTS}| tee -a "$RESUFILE"
grep "pagi.*ins" "$TEMPFILE" > "$NUMRFILE"
REALPSINS=$(awk '{t=t-$1} END {print -1*t}' "$NUMRFILE")
printf "True Paging Input:\n" | tee -a "$RESUFILE"
cat "$NUMRFILE" | tee -a "$RESUFILE"
printf " % 8d real paging space page ins\n" ${REALPSINS} | tee -a "$RESUFILE"
printf -- "$PRGNAME results in \"$RESUFILE\"\n" >&2
rm -f "$TEMPFILE" "$NUMRFILE" 2>/dev/null
fi

Se ejecuta vmstatit comando argumentos

Ejemplo:
[0 root@AIX1:/] vmstatit dd if=/unix of=/dev/null bs=512
COMMAND: dd if=/unix of=/dev/null bs=512
----------------------------------------------------
OUTPUT: ----------
56939+1 records in.
56939+1 records out.

real 0m0.48s
user 0m0.09s
sys 0m0.35s
OUTPUT: ----------
Ordinary Input:
40836 page ins
40836 page ins
81672 real pageins
Ordinary Output:
31027 page outs
31027 page outs
62054 real pageouts
True Paging Output:
0 paging space page outs
0 paging space page outs
0 real paging space page outs
True Paging Input:
0 paging space page ins
0 paging space page ins
0 real paging space page ins
vmstatit results in "/tmp/vmstatit_6029450.txt"

AIX Performance ● Ramón Barrios Lascar ® Ínodo 78

 Comando vmstat -v
A semejanza del comportamiento de vmstat cuando se usa la opción s, vmstat con la
opción v muestra unas estadísticas puntuales de uso y consumo desde el inicio del
sistema, es decir no es repetitivo. Esta se concentra en los números de ocupación
absoluta y en los valores de los parámetros de memoria, lo que permite revisar cómo se
usa la memoria con respecto a lo configurado.
Ejemplo:
[0 root@AIX1:/] vmstat -v
524288 memory pages
496568 lruable pages
278199 free pages
1 memory pools
172061 pinned pages
80.0 maxpin percentage
3.0 minperm percentage
90.0 maxperm percentage
5.2 numperm percentage
25948 file pages
0.0 compressed percentage
0 compressed pages
5.2 numclient percentage
90.0 maxclient percentage
25948 client pages
0 remote pageouts scheduled
0 pending disk I/Os blocked with no pbuf
0 paging space I/Os blocked with no psbuf
2228 filesystem I/Os blocked with no fsbuf
0 client filesystem I/Os blocked with no fsbuf
0 external pager filesystem I/Os blocked with no fsbuf
42.0 percentage of memory used for computational pages
Se observa:
! Muestra un reporte con 22 indicadores —entre parámetros y estadísticas—
puntuales. Donde:
‣ memory pages es el tamaño de la memoria, como siempre en
páginas de RAM de 4KB.
‣ lruable pages cuánto de la memoria se puede considerar como
reemplazable, movible o manejable. Es la memoria
RAM menos lo pinned, menos los índices y menos
la memoria de uso propio del VMM.
‣ free pages el nombre lo dice, cuántas páginas se consideran
libres.
‣ pinned pages cuánto de la memoria está marcado como “fija”,
“no paginable”, “no manejable”.
‣ file pages cuánto de la memoria está marcada como de tipo
P.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 79

 ‣ client pages cuánto de la memoria está marcada como de tipo
C.

‣ compressed pages cuánto de la memoria está marcada como

comprimida.
‣ percentage ... computational pages cuánto de la memoria, en
porcentaje, está marcada como de tipo W.
‣ memory pools en cuantos mempools está subdividida toda la RAM.
‣ maxperm percentaje cuánto es el parámetro maxperm como porciento de
la RAM total.
‣ minperm percentaje cuánto es el parámetro minperm como porciento de
la RAM total.
‣ maxclient percentaje cuánto es el parámetro maxclient como porciento
de la RAM total.
‣ maxpin percentaje cuánto es el parámetro maxpin como porciento de
la RAM total.
‣ numperm percentaje cuánto de la memoria actualmente usada está
marcada como de tipo P, como porcentaje de la
RAM total.
‣ numclient percentaje cuánto de la memoria actualmente usada está
marcada como de tipo C, como porcentaje de la
RAM total.
‣ compressed percentaje cuánto de la memoria actualmente usada está
marcada como comprimida (cuando se usa AME),
como porcentaje de la RAM total.
‣ remote pageouts ... cuántas operaciones de escritura se han
programado hacia sistemas de archivos “no de
kernel y no externos”, esto es “remotos”. Esto
incluye a NFS y casi todos los sistemas de archivos
instalables. JFS se considera de kernel, JFS2 se
considera externo.
‣ pending disk I/O blocked ... pbuf cuántas operaciones de I/O se han
frenado por insuficientes pbufs. Se usan para
lecturas y escrituras a nivel de LVM.
‣ pending page space ... blocked ... cuántas operaciones de I/O a
espacios de paginación (paging space page outs)
se han frenado por insuficientes psbufs. Se usan
para lecturas y escrituras a nivel de espacio de
paginación.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 80

 ‣ file system ... blocked ... fsbuf cuántas operaciones de I/O a
sistemas de archivos se han frenado por
insuficientes fsbufs. Se usan para todo tipo de
sistemas de archivos, a nivel de vfs.
‣ client file ... blocked ... fsbuf cuántas operaciones de I/O a
sistemas de archivos “cliente” se han frenado por
insuficientes fsbufs. Se usan para los sistemas de
archivos instalables como NFS y GPFS, entre
otros.
‣ external file ... blocked ... fsbuf cuántas operaciones de I/O a
sistemas de archivos “externos” se han frenado
por insuficientes fsbufs. Se usan para los sistemas
de archivos JFS2 básicamente.
Lo más común es usar este comando para ver si se deben ajustar minperm,
maxperm, maxclient, maxpin, que son básicamente parámetros del núcleo
para ajustar el funcionamiento del VMM. También se usa para ajustar los
parámetros que pueden limitar al sistema de I/O: parámetros de NFS, de
controladoras, de discos, de manejadores de disco, y/o de manejadores de
multicamino. Nos dice si se necesitarán ajustar ciertos parámetros del
LVM, de JFS, JFS2.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 81

AIX Performance ● Ramón Barrios Lascar ® Ínodo 82
 Comando svmon -G
El comando svmon es una utilidad para reportar el uso y consumo de la memoria en un
sistema, siendo muy poderoso y detallado al ser una herramienta específica de AIX.
Desafortunadamente su uso, dependiendo de las opciones escogidas, puede ser pesado
en consumo de CPU. A pesar de ello, es la herramienta más indicada para lograr reportes
y detallados del consumo de memoria. Siendo específica de AIX, reconoce las
funcionalidades nativas del VMM como memoria compartida, memoria comprimida, y
memoria virtual, como las maneja AIX.
Cuando se usa la opción G, se indica “reporte los números globales y no detallados”, es
decir para todo AIX y no para unos procesos, unos tipos o unos consumos. Se pueden
usar algunos de los switches de la opción O.
Ejemplo #1:
/ # svmon -G
--------------------------------------------------------------------------------------
size inuse free pin virtual available mmode
memory 134217728 92489646 41728081 13526630 92426732 41717596 Ded
pg space 237502464 175636

work pers clnt other

pin 9594470 0 2621 3932160
in use 92426732 0 62915
Se puede observar:
! Muestra un reporte de dos párrafos. Los primeros indicadores son generales,
y los del segundo párrafo son el detalle descompuesto de algunos del primer
párrafo. Sin más opciones los indicadores todos están en páginas de 4KB.
! La primera línea es un separador, la segunda detalla los títulos de los campos
mostrados en el reporte.
! La tercera línea detalla los indicadores de RAM:
‣ size el tamaño de la memoria RAM, en páginas como el resto del
reporte.
‣ inuse cuánta de la memoria RAM está ocupada, en uso.
‣ free cuánta de la memoria está libre, o marcada para reuso.
‣ pin cuánta de la memoria usada está marcada como “no paginable”,
“no movible”, “no administrable”.
‣ virtual cuántas páginas han sido solicitadas por los procesos, dando
respuesta válida a llamados de solicitud de memoria —como
malloc(), xmalloc() y semejantes— que no se han cumplido con
memoria física aún.
‣ mmode si el ambiente AIX —la LPAR o VM— está corriendo sólo con
memoria dedicada (Ded) o parcialmente con compartida (Sha,

AIX Performance ● Ramón Barrios Lascar ® Ínodo 83

 disponible en servidores con licencia PowerVM Enterprise y
AMS habilitado).
! La cuarta línea detalla los indicadores del total de espacios de paginación:
‣ size el tamaño de la suma de todos los espacios de paginación
activos, como todo el reporte, en páginas de 4KB.
‣ inuse cuánto de la suma de los espacios de paginación está marcado
como usado, o al menos, reservado.
! La sexta línea muestra los títulos del detalle del segundo párrafo
! La séptima línea detalla los consumos marcados como pinned (tercera línea,
cuarta columna de indicadores, 13526630):
‣ work cuánto de la memoria usada pinned está marcada como de tipo W
(computational o working).
‣ pers cuánto de la memoria usada pinned está marcada como de tipo P
(persistent o persistent, caché JFS).
‣ clnt cuánto de la memoria usada pinned está marcada como de tipo C
(client, caché JFS2, NFS, y búferes de I/O de red).
! La octava línea detalla los consumos (tercera línea, columna segunda de
indicadores, 92489646):
‣ work cuánto de la memoria usada está marcada como de tipo W
(computational o working).
‣ pers cuánto de la memoria usada está marcada como de tipo P
(persistent o persistent, caché JFS).
‣ clnt cuánto de la memoria usada está marcada como de tipo C (client,
caché JFS2, NFS, y búferes de I/O de red).
Nota #1: En situaciones ideales memory inuse (92489646) debería ser exactamente
igual a inuse work + inuse pers + inuse clnt + inuse other, pero como svmon
no detiene al VMM para mientras hace el reporte, los consumos y por tanto los
indicadores siguen cambiando mientras svmon genera los números. Pasa
exactamente lo mismo, donde memory pin (13526630) debería ser exactamente
igual a pin work + pin pers + pin clnt + pin other.
Ejemplo #2:
/ # svmon -G -O unit=GB
Unit: GB
--------------------------------------------------------------------------------------
size inuse free pin virtual available mmode
memory 512.00 352.82 159.18 51.6 352.58 159.14 Ded
pg space 906.00 0.67

work pers clnt other

pin 36.6 0 0.01 15.0

AIX Performance ● Ramón Barrios Lascar ® Ínodo 84

 in use 352.58 0 0.24

El comando permite seleccionar las unidades para el reporte, usando la opción O del
comando svmon con los parámetros unit=auto, unit=page (predeterminado), unit=KB,
unit=MB, unit=GB o unit=TB. El ejemplo #2 es el mismo ambiente —y con la misma
explicación— que el del ejemplo #1.
Ejemplo #3:
[0 root@AIX1:/] svmon -GO unit=auto
Unit: auto
--------------------------------------------------------------------------------------
size inuse free pin virtual available mmode
memory 2.00G 963.93M 1.06G 672.06M 845.49M 1.09G Ded
pg space 512.00M 6.00M

work pers clnt other

pin 591.86M 0K 3.54M 76.7M
in use 845.49M 0K 118.45M
Cuando se usa unit=auto, para cada indicador el comando selecciona la unidad más
adecuada para representarlo (donde cada número sea en la unidad más grande que no
muestre menor que 1).

AIX Performance ● Ramón Barrios Lascar ® Ínodo 85

AIX Performance ● Ramón Barrios Lascar ® Ínodo 86
 Comando svmon -P
El segundo uso más común de svmon (de los múltiples reportes que tiene) es el de listar
los consumos de memoria por proceso, de mayor a menor consumidor en el sistema.
Esto se logra con la opción P y sin argumento numérico.
Ejemplo #1:
[0 root@AIX1:/] svmon -P

-------------------------------------------------------------------------------
Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 16MB
4391048 rmcd 70206 65346 0 69925 N Y N

PageSize Inuse Pin Pgsp Virtual

s 4 KB 54366 54178 0 54085
m 64 KB 990 698 0 990

Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual

8682ed 2 work process private sm 51221 51204 0 51221
10002 0 work kernel segment m 552 506 0 552
9000 d work shared library text m 438 192 0 438
8702ce f work shared library data sm 2099 2099 0 2099
8c0298 3 work working storage sm 729 729 0 729
8d831b 1 clnt code,/dev/hd2:17590 s 269 139 - -
810482 - work s 36 7 0 36
848309 - clnt /dev/hd2:26655 s 8 0 - -
8f005e - clnt /dev/hd2:25583 s 2 0 - -
808481 - clnt /dev/hd9var:450 s 1 0 - -
8b8477 - clnt /dev/hd9var:449 s 1 0 - -
8282e5 5 work working storage sm 0 0 0 0
880270 4 work working storage sm 0 0 0 0
8f835f - clnt /dev/hd9var:338 s 0 0 - -
8e825d 6 mmap maps 3 source(s) sm 0 0 - -
898253 - clnt /dev/hd9var:417 s 0 0 - -

-------------------------------------------------------------------------------
Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 16MB
4260004 clcomd 16691 11179 0 16323 N Y N

PageSize Inuse Pin Pgsp Virtual

s 4 KB 851 11 0 483
m 64 KB 990 698 0 990

Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual

10002 0 work kernel segment m 552 506 0 552
9000 d work shared library text m 438 192 0 438
820244 2 work process private sm 354 4 0 354
890372 - clnt /dev/hd9var:528 s 226 0 - -
8982b3 1 clnt code,/dev/hd2:110996 s 137 0 - -
890312 f work shared library data sm 94 0 0 94
888471 - work s 35 7 0 35
8382e7 - clnt /dev/hd9var:475 s 5 0 - -
... # salida recortada del comando...
Siendo un reporte extensísimo, se recortó la salida. Muestra:

AIX Performance ● Ramón Barrios Lascar ® Ínodo 87

 ! Una “página” de información por cada proceso encontrado en ejecución
durante la invocación de svmon. La información de un proceso se separa del
siguiente por una línea punteada (--------).
! Los procesos los lista de mayor consumidor de memoria a menor consumidor.
! De cada proceso muestra:
‣ Pid Como en todo AIX, el número único temporal identificador del
proceso.
‣ Command El nombre del comando con el que inició el proceso.
‣ Inuse El total de memoria RAM que estaba usando el proceso cuando lo
revisó svmon. Las unidades son las especificadas con la opción O
unit=XX, o páginas de 4KB si no se especifica.

‣ Pin Del total de la memoria usada, cuántas páginas están marcadas

pinned (no movible, no paginable, no manejable). Están incluidas
dentro de inuse.
‣ Pgsp Cuánta de la memoria solicitada por el proceso ha sido copiada a
espacios de paginación.
‣ Virtual Cuánta de la memoria solicitada por el proceso no ha sido
materializada, ni otorgada como RAM ni entregada de espacio de
paginación.
‣ 64-bit Si el proceso usa puras instrucciones de 64 bits (Y) o no (N).
‣ Mthrd Si el proceso es multihilo (Y) o no (N)
‣ 16MB Si el proceso ha solicitado memoria RAM en páginas grandes —
de 16MB cada una— (Y) o no (N)
! En un segundo párrafo, del mismo proceso muestra el consumo según los
diferentes tipos de páginas —según el tamaño—. Dependiendo de la
arquitectura de procesador, y de la configuración de la VM/LPAR mostrará
diferentes tamaños. Muestra primero las descripción de las columnas.
! s Descripción de los consumos en páginas predeterminadas o pequeñas,
de 4KB (s):
‣ PageSize Descripción del tamaño
‣ Inuse Cuántas en uso en RAM, de tamaño pequeño
‣ Pin Cuántas de las usadas están marcadas como pinned (no
movibles, no paginables, no administrables)
‣ Pgsp Cuántas solicitadas están copiadas a algún espacio de
paginación
‣ Virtual Cuántas de las solicitadas no han sido nunca
materializadas, ni en RAM ni en espacio de paginación.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 88

 ! m Describe los consumos en páginas medianas (de 64KB cada una). Repite
las mismas columnas, si la arquitectura soporta este tamaño de página.
! L Describe los consumos en páginas grandes (de 16MB cada una). Repite las
mismas columnas, si la arquitectura soporta y tiene configurado este tamaño
de página.
! S Describe los consumos en páginas supremas (de 16GB cada una). Repite
las mismas columnas, si la arquitectura soporta y tiene configurado este
tamaño de página.
Notése cómo en el primer proceso del ejemplo (rmcd, 4391048), las páginas en uso de la
primera línea (inuse, 70206) son iguales a la sumatoria de inuse en el reporte por tamaño
de página (70206 × 4KB = 54366 × 4KB + 990 × 64KB).
! En un tercer párrafo describe los consumos de memoria por segmento, una
línea por segmento, incluyendo las columnas:
‣ Vsid Identificador virtual único del segmento. Es un número de
seis hexadígitos.
‣ Esid Identificador del segmento dentro del proceso. Es un
entero corto representado como hexadígitos.
‣ Type Uso como lo reconoce el VMM. Como siempre, work (W),
client (C), permanent (P).
‣ Description Uso, más descriptivo. Se pueden reconocer fácilmente
“espacio de trabajo” (working storage), que son espacios
de RAM resultados de malloc(), calloc() y xmalloc();
“segmento de núcleo” (kernel segment), que es una imagen
de las funciones del núcleo exportadas para que el
proceso pueda invocarlas; “código de biblioteca
compartida” (shared library text), donde comúnmente el
segmento d es libc.a; y especialmente el segmento 1,
“código” (code), que es el código ejecutable del proceso
invocado, en el primer ejecutable del ejemplo /dev/
hd2:17590 y en el segundo ejecutable del ejemplo /dev/
hd2:110996.

‣ PSize Tamaño de página, donde s son de 4KB, m son de 64KB, l

son de 16MB, S son de 16GB.
‣ Inuse Como ya se deberá imaginar, cuántas páginas de este
segmento están en RAM
‣ Pin Cuántas de las inuse están marcadas como “no movibles”,
“no paginables” y “no manejables”.
‣ Pgsp Cuántas páginas del segmento están en espacios de
paginación.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 89

 ‣ Virtual Cuántas páginas del segmento han sido solicitadas pero
no han sido materializadas aún ni en RAM ni en espacios
de paginación.
Ejemplo #1b:
[0 root@AIX1:/] lsvg -l $(lsvg -o) | grep hd2
hd2 jfs2 65 65 1 open/syncd /usr
[0 root@AIX1:/] find /usr -xdev -inum 17590
/usr/sbin/rsct/bin/rmcd
[0 root@AIX1:/] find /usr -xdev -inum 110996
/usr/es/sbin/cluster/clcomd

Se observa cómo se convierte hd2 en el sistema de archivos equivalente —aunque siendo

uno de los sistemas de archivos estándar, no debería ser necesario—.
Luego dos casos de cómo encontrar el nombre del archivo dado el ínodo dentro de un
sistema de archivos montado, y cómo los nombres de los archivos concuerdan con los
nombres de los procesos en la segunda línea de información de cada proceso mostrada
por svmon -P.
El primer proceso del ejemplo #1 muestra que tiene abiertos seis archivos más, dos en
hd2 (/usr) y cuatro en hd9var (/var). Encontrémoslos:

Ejemplo #1c:
[0 root@AIX1:/] find /usr -xdev \( -inum 26655 -o -inum 25583 \)
/usr/lib/nls/msg/en_US/ct_rmc.cat
/usr/lib/nls/msg/en_US/[Link]
[0 root@AIX1:/] find /var -xdev \( -inum 338 -o -inum 417 -o -inum 449 -o -inum 450 \)
/var/ct/100307673/lck/mc/rmcd
/var/ct/100307673/log/mc/default
/var/ct/100307673/registry/local_tree/IBM,IBM_LPCommands,ClassACLs
/var/ct/100307673/registry/local_tree/IBM,IBM_LPCommands,ResourceACLs

Se observan que al parecer son unos catálogos de mensajes en inglés (en_US) en /usr, y
unos archivos de datos en /var.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 90

 Comando lsps
El comando lsps es muy básico, sólo lista los espacios de paginación.
Ejemplo #1:
[0 root@AIX1:/] lsps -a
Page Space Physical Volume Volume Group Size %Used Active Auto Type Chksum
swapnfs0 --- --- 1024MB 1 yes yes nfs 8
hd6 hdisk0 rootvg 512MB 2 yes yes lv 0
[0 root@AIX1:/] lsps -s
Total Paging Space Percent Used
1536MB 1%
Nótese que:
! La opción a lista uno por uno los espacios de paginación, uno por uno,
incluyendo el tamaño de cada uno y el espacio usado más el espacio
reservado.
! La opción s lista el total del espacio de paginación —resumido— pero el
porcentaje usado que muestra es sólo el usado pero no el reservado —lo que
implica que los dos datos pueden diferir—.
El comando, con la opción a muestra:
! Una línea con los títulos de las columnas:
‣ Page Space Nombre del espacio de paginación. Puede ser un nombre
de columna o puede ser un nombre de un archivo —
comúnmente cuando es un espacio compartido accedido
por NFS—.
‣ Physical Volume Cuando el espacio de paginación es un volumen
lógico —lo más común—, muestra el nombre del volumen
físico (disco) que lo contiente. Cuando es un acceso NFS
muestra nulo (---).
‣ Volume Group Cuando el espacio de paginación es un volumen, muestra
el nombre del grupo de volúmenes que contiene al disco
que contiene al espacio de paginación. Cuando es un
acceso NFS muestra nulo (---).
‣ Size Muestra el tamaño del espacio de paginación en MB.
‣ %Used Muestra la cantidad del espacio usado o reservado en
cada uno.
‣ Active Muestra yes si en el momento de la ejecución del
comando estaba “prendido” o activado.
‣ Auto Muestra yes si está registrado para ser activado en cada
inicio del sistema.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 91

 ‣ Type Muestra el tipo, lv si es un volumen lógico, nfs si es un
archivo remoto que se accede por este protocolo.
‣ Cksum Muestra los bits del tipo de sumatoria de validación que
se está usando para cada espacio de paginación, o 0 si no
se está usando validación.
Nótese que más o menos se puede obtener la información también a través del comando
swap:

[0 root@AIX1:/] swap -l
device maj,min total free
/dev/swapnfs0 36, 0 1024MB 1023MB
/dev/hd6 10, 2 512MB 506MB
[0 root@AIX1:/] swap -s
allocated = 393216 blocks used = 1533 blocks free = 391683 blocks
En este caso nos muestra los nombres completos de cada dispositivo de paginación
(necesario para activarlos y desactivarlos dinámicamente) y cuánto está libre —no
cuánto está siendo usado—.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 92

 Comando topas
El comando ya mencionado topas tiene también una pantalla dedicada a estadísticas de
memoria, a la misma se llega usando la tecla M o invocando topas -M:
[0 root@AIX1:/] topas -M
Topas Monitor for host: AIX1 Interval: 2 Sun Jun 22 [Link] 2014
================================================================================
REF1 SRAD TOTALMEM INUSE FREE FILECACHE HOMETHRDS CPUS
--------------------------------------------------------------------------------
0 0 1939.7 865.3 1074.4 102.8 - 0-3
================================================================================
CPU SRAD TOTALDISP LOCALDISP% NEARDISP% FARDISP%
------------------------------------------------------------
1 0 199 100.0 0.0 0.0
0 0 130 100.0 0.0 0.0
2 0 0 0.0 0.0 0.0
3 0 0 0.0 0.0 0.0

Cuando se invoca así —se llama reporte de topología—, muestra una pantalla con dos
secciones, la primera mostrando detalles del consumo de memoria en megabytes.
Muestra:
! Una línea de título con el nombre del sistema (AIX1), el intervalo de refresco
(2 segundos), y la fecha y hora de la toma de estadísticas.
! Muestra luego una sección con la topología y los consumos de memoria, por
mempool:

‣ REF1 Número de referencia, mempool, o conjunto de recursos

que se acceden como conjunto porque físicamente —a
nivel hardware— están cerca uno del otro.
‣ SRAD Identificador de captura de recurso (scheduler resource
domain ID).
‣ TOTALMEM Cuánta memoria RAM tiene asignado en el momento este
SRAD, en MB.
‣ INUSE Cuánta memoria se considera “en uso”, incluyendo la que
contiene copias de archivos en RAM —en este reporte,
incluyendo a FILECACHE—. También en MB.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 93

 ‣ FREE Cuánta memoria se considera “libre”, es decir no se ha
almacenado nada en esas páginas de RAM o está marcada
para reuso inmediato. En MB.
‣ FILECACHE Cuánta memoria “en uso” incluye páginas de archivos
copiadas a RAM (es decir P, permanent, o C, client).
‣ HOMETHRDS Número de hilos de ejecución en este SRAD.
‣ CPUS Lista de CPUs lógicas en este SRAD. Como este es un
servidor pequeño, todos las CPUs lógicas están en el
mismo SRAD. Es el resultado de vCPUs × SMT.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 94

Parametrización del VMM de AIX
Comando vmo
El comando vmo (virtual memory manager options) es un comando administrativo
poderoso. El mismo necesita permisos de root y permite listar, revisar y cambiar los
parámetros que afectan directamente al manejador de memoria (virtual memory
manager, VMM) de AIX.
Ejemplo #1:
[0 root@AIX1:/] vmo -a
... # salida suprimida ...
minfree = 960
minperm = 14897
minperm% = 3
nokilluid = 0
npskill = 3072
npswarn = 12288
... # salida suprimida ...
El mismo, cuando se usa con la opción a lista todos los atributos no restringidos con sus
valores actuales.
Ejemplo #2:
[0 root@AIX1:/] vmo -L
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
ame_cpus_per_pool n/a 8 8 1 1K processors B
--------------------------------------------------------------------------------
ame_maxfree_mem n/a 24M 24M 320K 2G bytes D
ame_minfree_mem
--------------------------------------------------------------------------------
ame_min_ucpool_size n/a 0 0 5 95 % memory D
--------------------------------------------------------------------------------
ame_minfree_mem n/a 8M 8M 64K 2047M bytes D
ame_maxfree_mem
--------------------------------------------------------------------------------
ams_loan_policy n/a 1 1 0 2 numeric D
--------------------------------------------------------------------------------
enhanced_affinity_affin_time
1 1 1 0 100 numeric D
--------------------------------------------------------------------------------
enhanced_affinity_vmpool_limit
10 10 10 -1 100 numeric D
--------------------------------------------------------------------------------
esid_allocator 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
force_relalias_lite 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
kernel_heap_psize 64K 0 0 0 16M bytes B
--------------------------------------------------------------------------------
lgpg_regions 0 0 0 0 8E-1 D
lgpg_size

AIX Performance ● Ramón Barrios Lascar ® Ínodo 95

 --------------------------------------------------------------------------------
lgpg_size 0 0 0 0 16M bytes D
lgpg_regions
--------------------------------------------------------------------------------
low_ps_handling 1 1 1 1 2 D
--------------------------------------------------------------------------------
maxfree 1088 1088 1088 16 419430 4KB pages D
minfree
memory_frames
--------------------------------------------------------------------------------
maxperm 446911 446911 S
--------------------------------------------------------------------------------
maxpin 423359 423359 S
--------------------------------------------------------------------------------
maxpin% 80 80 80 1 100 % memory D
pinnable_frames
memory_frames
--------------------------------------------------------------------------------
memory_frames 512K 512K 4KB pages S
--------------------------------------------------------------------------------
memplace_data 2 2 2 0 2 D
--------------------------------------------------------------------------------
memplace_mapped_file 2 2 2 0 2 D
--------------------------------------------------------------------------------
memplace_shm_anonymous 2 2 2 0 2 D
--------------------------------------------------------------------------------
memplace_shm_named 2 2 2 0 2 D
--------------------------------------------------------------------------------
memplace_stack 2 2 2 0 2 D
--------------------------------------------------------------------------------
memplace_text 2 2 2 0 2 D
--------------------------------------------------------------------------------
memplace_unmapped_file 2 2 2 0 2 D
--------------------------------------------------------------------------------
minfree 960 960 960 8 419430 4KB pages D
maxfree
memory_frames
--------------------------------------------------------------------------------
minperm 14897 14897 S
--------------------------------------------------------------------------------
minperm% 3 3 3 1 100 % memory D
--------------------------------------------------------------------------------
nokilluid 0 0 0 0 4G-1 uid D
--------------------------------------------------------------------------------
npskill 3K 3K 3K 1 384K-1 4KB pages D
--------------------------------------------------------------------------------
npswarn 12K 12K 12K 1 384K-1 4KB pages D
--------------------------------------------------------------------------------
num_locks_per_semid 1 1 1 1 64 numeric B
--------------------------------------------------------------------------------
numpsblks 384K 384K 4KB blocks S
--------------------------------------------------------------------------------
pinnable_frames 349710 349710 4KB pages S
--------------------------------------------------------------------------------
relalias_percentage 0 0 0 0 32K-1 D
--------------------------------------------------------------------------------
scrub 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
v_pinshm 0 0 0 0 1 boolean D

AIX Performance ● Ramón Barrios Lascar ® Ínodo 96

 --------------------------------------------------------------------------------
vmm_default_pspa 0 0 0 -1 100 numeric D
--------------------------------------------------------------------------------
vmm_klock_mode 0 -1 -1 -1 3 numeric B
--------------------------------------------------------------------------------
wlm_memlimit_nonpg 1 1 1 0 1 boolean D
--------------------------------------------------------------------------------

n/a means parameter not supported by the current platform or kernel

Parameter types:
S = Static: cannot be changed
D = Dynamic: can be freely changed
B = Bosboot: can only be changed using bosboot and reboot
R = Reboot: can only be changed during reboot
C = Connect: changes are only effective for future socket connections
M = Mount: changes are only effective for future mountings
I = Incremental: can only be incremented
d = deprecated: deprecated and cannot be changed

Value conventions:
K = Kilo: 2^10 G = Giga: 2^30 P = Peta: 2^50
M = Mega: 2^20 T = Tera: 2^40 E = Exa: 2^60

Cuando se usa con la conveniente opción L lista todos los parámetros no restringidos
con, mostrando diversas columnas:
! Name Nombre del parámetro del despachador.
! CUR Valor actual del parámetro
! DEF Valor predeterminado del mismo
! BOOT Valor que tomará al próximo inicio del sistema
! MIN Valor mínimo aceptable para el parámetro
! MAX Valor máximo aceptable para el parámetro
! UNIT Descripción de la unidad de medida del parámetro
! TYPE Como lo describe abajo, si el parámetro es estático/no cambiable
(S), si es dinámico/cambiable en línea (D), si sólo lo toma al
recrear la copia del núcleo en el volumen de carga del sistema
operativo hd5 (B), si necesita un reinicio (R), si lo toma en la
próxima conexión de un usuario (C), si lo toma en el próximo
montaje de un sistema de archivos (M), si sólo lo toma si el
parámetro se aumenta (I), si está despreciado y no debe
cambiarse (d).
! DEPENDENCES Lista otros atributos que afecten el rango real del valor del
parámetro (tal vez deba ser mayor o deba ser menor que los
parámetros listados como dependencias).

AIX Performance ● Ramón Barrios Lascar ® Ínodo 97

 Para cambiar cualquier parámetro se usa schedo -o parámetro=valor, que tomará si el
parámetro es dinámico (D). Ahora, los cambios hechos así, con o se pierden al reiniciar el
sistema, a menos que se “vuelvan” permanentes con schedo -p -o parámetro=valor.
Si el parámetro es de reinicio (R) deberá cambiarse no con schedo -p si no con schedo -r
-o parámetro=valor, y si es de nuevo núcleo (B), deberá cambiarse con schedo -r -o
parámetro=valor, seguido de bosboot -a, y sólo lo tomará el sistema luego de un reinicio.

Ejemplo #1:
[0 root@AIX1:/] vmo -o minperm -o minperm%
minperm = 14897
minperm% = 3
[0 root@AIX1:/] vmo -L minperm
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
minperm 14897 14897 S
--------------------------------------------------------------------------------
[0 root@AIX1:/] vmo -L minperm%
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
minperm% 3 3 3 1 100 % memory D
--------------------------------------------------------------------------------
Se listan primero los valores actuales, y muestra minperm como estático pero minperm%
como dinámico —sabemos que realmente minperm no es estático, pero en este caso,
cuando se necesite se puede cambiar minperm% pero no minperm—.
Ejemplo #2:
[0 root@AIX1:/] vmo -r -o minperm%=10
Setting minperm% to 10 in nextboot file
Warning: changes will take effect only at next reboot
[1 root@AIX1:/] vmo -L minperm%
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
minperm% 3 3 10 1 100 % memory D
--------------------------------------------------------------------------------
Se observa en el ejemplo, que aunque un parámetro sea dinámico, se puede dejar
registrado para que asuma el cambio en el próximo reinicio, con vmo -r -o
parámetro=valor. Nótese cómo al listar el valor actual sigue siendo 3, igual al
predeterminado, pero el del próximo boot ha sido cambiado a 10.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 98

Conceptos de Desempeño de I/O: Funcionamiento del LVM
El LVM o Logical Volume Manager de AIX
Igual que muchos otros componentes de AIX, el sistema de I/O está armado por
subsistemas organizados en capas. En el caso de I/O es bastante complejo, ya que
muchos, prácticamente todo software avanzado que se usa en AIX usa dos tipos de
operaciones de I/O: operaciones de I/O de volumen o de dispositivo y operaciones de
AIX de archivos comunes —y eso, aparte de las operaciones de I/O de red—. En todo
sistema operativo Unix o derivado, estas dos operaciones son operaciones de “archivo
lógico”, pero siendo que el manejador de volúmenes de AIX es muy avanzado y tiene sus
propias estadísticas y parámetros, los separé en dos, esta que concierne al manejador de
volúmenes y lo que son discos, LUNs, controladoras, paths y drivers; y la otra, que atañe
a una sección aparte, que afecta a los sistemas de archivos y los archivos tradicionales.
En el caso del LVM, lo que más nos puede afectar el desempeño es la arquitectura del
servidor, siendo que una arquitectura diseñada para el fin por el cual el servidor se
adquirió o configuró permite no tener que parametrizar nada, y en cambio, una
arquitectura que para nada se ajuste a la función principal del servidor hará que ningún
parámetro que usemos nos arregle los problemas de I/O que el mismo sufra.
De qué se trata esto? Si el servidor tiene como función principal el manejo de bases de
datos transaccionales, de seguro lo que más nos afectará es la posibilidad de usar
múltiples controladoras de disco, con múltiples caminos a los discos, y con múltiples
discos, separados estos por función, y simultáneamente la posibilidad de acceder a un
buen sistema de caché de I/O, sea local —in server— o remoto —in storage—, y los
parámetros que se usen en el software manejador de bases de datos, para que use todo
efectivamente, y muy poco de lo que se haga como administrador de AIX hará gran
cambio. Por otro lado, si es un servidor de archivos, lo más probable es que necesitemos
un sistema que lea archivos muy rápido pero secuencialmente, y que los envíe a sus
clientes de red, y no nos afectará tanto si son múltiples controladoras y si son múltiples
discos físicos.

Conceptos de Arquitectura de I/O de Bajo Nivel en Power

Los servidores Power tienen un concepto central en su arquitectura física: todos los
dispositivos necesitan de acceso DMA. Cuando se energiza un servidor Power, el mismo
hace un inventario —realmente el FSP lo hace— de todas las tarjetas adaptadoras,
incluyendo las adaptadoras integradas en el mismo. En este inventario se incluyen
rangos, cantidades de memoria que cada chip necesita, y la cantidad de canales directos
(DMA es Direct Memory Access) que también, cada uno necesita. Teniendo esto, el
hypervisor separa zonas de memoria RAM, que va asignando a buses y puertos PCI y
que serán la manera de dar acceso al software hasta los dispositivos de hardware.
Cuando una LPAR o VM con AIX da inicio, parte de la RAM que se le asigne se usará para
direccionar los bloques de memoria que representan o son la puerta de entrada al

AIX Performance ● Ramón Barrios Lascar ® Ínodo 99

 hardware —y si no hay para esto la LPAR o VM no inicia—. Teniendo esto, cuando ya se
cargue el núcleo (kernel) de AIX, se cargarán los manejadores (drivers) de las diferentes
controladoras, y donde cada uno armará unas colas de elementos, donde también, cada
elemento se usa para mandar o recibir mensajes al dispositivo de hardware en cuestión.
Simultáneamente, AIX en un momento muy temprano carga los manejadores (drivers)
de los discos duros —diferentes para discos físicos de diferentes modelos, para
volúmenes o LUN, para discos virtuales/virtualizados, y diferentes según los
manejadores multicaminos que se tengan instalados. Estos manejadores también
solicitan memoria RAM, y cuando cargan, arman unas colas de elementos, elementos
que también se usarán para mandar o recibir mensajes a los diferentes discos con los
que se cuenten.
Cuánta RAM se tenga para armar estas colas de elementos, cuántos de estos elementos
se parametricen en cada nivel, y en los casos donde aplica, cuánto mida cada elemento
nos permitirá afectar directamente las operaciones de I/O desde y hacia el hardware de
almacenamiento. Aunque la arquitectura como se diseñó el servidor es lo que más a
menudo define el desempeño logrado, se pueden obtener estadísticas que nos indicarían
si ajustar ciertos parámetros es necesario o conveniente.
En AIX existen parámetros de cola en cada controladora (como los dispositivos fcsX),
muchas veces en objetos de software que manejan los protocolos (como los dispositivos
fscsiX), en objetos de software que manejan los manejadores multicamino (multipath
drivers), en los discos (dispositivos hdiskX), en los grupos de volúmenes, y todos son
susceptibles de ser ajustados, en especial cuando alguna estadística los muestra
insuficientes.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 100

 Algunos Parámetros Importantes de I/O a Bajo Nivel
Es posible revisar algunos parámetros que afectan las operaciones de I/O a bajo nivel.
Los mencionaremos a continuación:

Colas de Tareas en Disco

Todos los discos en Power se consideran que tienen unas colas de tareas que permiten
enviarle múltiples tareas, que el disco desarrollará de la mejor manera —no
necesariamente en el mismo orden en que se envían— y que de las que posteriormente
enviará los resultados. Cuando un disco no es bien reconocido —aparece como de tipo
Other SCSI Disk, u Other FC Disk o parecido— AIX considerará lo más sano y la cola se
trabajará como “de tamaño 1”. En cambio si el disco es reconocido por algún manejador
(driver), el disco aparecerá con una cola de trabajo de tamaño superior, pero con un
valor conservador para no saturar los sistemas de hardware. Como no todos los discos
se reconocen de igual manera, deberá buscar un atributo con el nombre queue_depth o
q_depth o semejante. Como todo atributo de dispositivo se lista el rango que se puede
trabajar con lsattr -Rl NombreDisco -a queue_depth (o q_depth, según el disco), y puede
ver el valor actual con lsattr -El.
Ejemplo:
root@pmundial:/> iostat 20 20

System configuration: lcpu=4 drives=7 paths=8 vdisks=0

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

0.0 2.9 15.8 5.6 36.7 41.8

Disks: % tm_act Kbps tps Kb_read Kb_wrtn

hdisk0 1.3 15.6 2.6 0 314
hdisk3 0.1 2.4 0.5 0 48
hdisk1 0.0 0.0 0.0 0 0
hdisk2 1.2 15.6 2.6 0 314
hdisk6 0.2 3.2 0.7 0 64
hdisk4 99.2 4546.2 799.6 79634 11620
cd0 0.0 0.0 0.0 0 0
...
root@pmundial:/>lsattr -El hdisk4
PCM PCM/friend/fcpother Path Control Module False
algorithm fail_over Algorithm True
clr_q no Device CLEARS its Queue on error True
dist_err_pcnt 0 Distributed Error Percentage True
dist_tw_width 50 Distributed Error Sample Time True
hcheck_cmd inquiry Health Check Command True
hcheck_interval 60 Health Check Interval True
hcheck_mode nonactive Health Check Mode True
location Location Label True
lun_id 0x0 Logical Unit Number ID False
max_transfer 0x40000 Maximum TRANSFER Size True
node_name 0x50060160b9a02e48 FC Node Name False
pvid 00053502724f04d30000000000000000 Physical volume identifier False
q_err yes Use QERR bit True
q_type simple Queuing TYPE True

AIX Performance ● Ramón Barrios Lascar ® Ínodo 101

 queue_depth 1 Queue DEPTH True
reassign_to 120 REASSIGN time out value True
reserve_policy single_path Reserve Policy True
rw_timeout 30 READ/WRITE time out value True
scsi_id 0x10800 SCSI ID False
start_timeout 60 START unit time out value True
ww_name 0x5006016039a02e48 FC World Wide Name False

Se nota cómo por alguna razón, aunque el disco hdisk4 trabaja muchísimo tiempo, el
desempeño podría ser mejor. Se revisan los atributos y se encuentra que como la cola de
trabajo es de tamaño 1, AIX le envía una tarea y hasta que no la complete no le envía
otra. Como el atributo tiene la columna “Settable” en True, es susceptible de ser
cambiado —la mayoría de los dispositivos no aplican el cambio mientras están en uso—.

Colas de Tarea de Adaptadora

Al igual que los discos, las adaptadoras y controladoras también tienen un parámetro
que define cuánta de la RAM asignada al bus PCI se usará para colas de tarea. Este
parámetro siempre existe y siempre se llama num_cmd_elems ya que AIX no puede usar
una adaptadora o controladora con el manejador (driver) adecuado, es decir con un
módulo específico y no genérico. Este parámetro debe ser tal que:
! Alcance para manejar todos los discos que de la controladora dependan (así
que debe ser mayor o igual que las sumas de las colas de los discos que
maneja).
! Esté dentro del rango que maneja el driver.
! No sature ni las fibras ni los sistemas de almacenamiento con los que “habla”.
Nota: En particular, las controladoras virtuales SCSI (vscsiX) no tienen este parámetro
manejable y se considera que siempre lo tienen igual a 512.
Como todo dispositivo, se revisan con lsattr.
Ejemplo:
# lsattr -El fcs0
bus_intr_lvl 8355 Bus interrupt level False
bus_io_addr 0xffc00 Bus I/O address False
bus_mem_addr 0xf8040000 Bus memory address False
init_link al INIT Link flags True
intr_priority 3 Interrupt priority True
lg_term_dma 0x1000000 Long term DMA True
max_xfer_size 0x100000 Maximum Transfer Size True
num_cmd_elems 200 Maximum number of COMMANDS to queue to the adapter True
pref_alpa 0x1 Preferred AL_PA True
sw_fc_class 2 FC Class for Fabric True

Si el driver lo permite, se podría subir el valor de num_cmd_elems mientras que se calcule

para no saturar el sistema de almacenamiento que se accede a través de esta
controladora.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 102

Monitoreo del Desempeño del Logical Volume Manager:
Comandos
Comando iostat -d
El comando iostat con la opción -d es quizás el más directamente usado para obtener
unas estadísticas que nos muestren si el sistema de discos tiene desbalance. Como la
opción d es predeterminada, mostrará la información de la misma a menos que se use la
opción t o las opciones a o A.
Ejemplo:
root@pmundial:/> iostat -d 20 30

System configuration: lcpu=4 drives=7 paths=8 vdisks=0

Disks: % tm_act Kbps tps Kb_read Kb_wrtn

hdisk0 1.3 15.6 2.6 0 314
hdisk3 0.1 2.4 0.5 0 48
hdisk1 0.0 0.0 0.0 0 0
hdisk2 1.2 15.6 2.6 0 314
hdisk6 0.2 3.2 0.7 0 64
hdisk4 99.2 4546.2 799.6 79634 11620
cd0 0.0 0.0 0.0 0 0

Disks: % tm_act Kbps tps Kb_read Kb_wrtn

hdisk0 0.1 7.0 0.3 0 140
hdisk3 0.0 0.0 0.0 0 0
hdisk1 0.0 0.0 0.0 0 0
hdisk2 0.1 7.0 0.3 0 140
hdisk6 0.0 0.0 0.0 0 0
hdisk4 99.5 3588.1 691.9 68860 2902
cd0 0.0 0.0 0.0 0 0

Disks: % tm_act Kbps tps Kb_read Kb_wrtn

hdisk0 0.6 16.3 1.1 0 326
hdisk3 0.0 0.0 0.0 0 0
hdisk1 0.0 0.0 0.0 0 0
hdisk2 0.5 16.3 1.1 0 326
hdisk6 0.0 0.0 0.0 0 0
hdisk4 99.3 4447.5 710.4 88136 1014
cd0 0.0 0.0 0.0 0 0
...
Se puede observar:
Se pueden dar como parámetros unos nombres de dispositivos discos luego de la opción
d (en el ejemplo no se usó esta posibilidad), y se pueden dar los parámetros tiempo y
repeticiones (en el ejemplo el 20 es el parámetro tiempo y el 30 las repeticiones). Si se
dan, el comando iostat mostrará un conjunto de estadísticas tomadas cada tanto tiempo
segundos, y hasta repeticiones estadísticas).
El comando iostat -d muestra:

AIX Performance ● Ramón Barrios Lascar ® Ínodo 103

 Primero una línea con un resumen de la configuración del sistema:
System configuration: lcpu=4 drives=7 paths=8 vdisks=0
Donde:
! lcpu muestra cuántos procesadores lógicos (hijos de ejecución
posibles) representa la máquina (en nuestro caso puede ser una
CPU virtual multiplicada por SMT 4 o pueden ser dos CPUs
virtuales × SMT 2, o pueden ser cuatro CPUs virtuales con SMT
apagado).
! drives muestra cuántos discos reconoce la máquina, en nuestro ejemplo
serían seis discos duros más una unidad de DVD.
! paths muestra cuántos caminos a disco se reconocen
! vdisks muestra cuántos de los discos se reconocen como discos
virtuales.
Luego muestra una línea con títulos:
Disks: % tm_act Kbps tps Kb_read Kb_wrtn
Nos detalla qué va a mostrar:
! Disks: esta columna nos muestra los nombres de los dispositivos disco
y dispositivos CD o DVD.
! % tm_act: esta columna nos muestra cuánto tiempo de cada estadística
(que en nuestro ejemplo fue de 20 segundos) estuvo en actividad
cada uno de los dispositivos. Si unos de nuestros dispositivos
muestran que tienen mucha más actividad —porcentual— que
otros discos puede indicar un desbalance que vale la pena
investigar.
! Kbps: esta columna nos muestra cuántos KB/s promedio, durante los
segundos de cada estadística trabajó (leyó y escribió) cada
dispositivo. Vale la pena compararlo con el tiempo de actividad,
ya que si un dispositivo trabaja mucho más tiempo para igual o
menos KB/s nos puede indicar que hay desorden en las
operaciones de I/O que impulsan a mayores tiempos de atención.
! tps: esta columna nos muestra cuántas transacciones (operaciones
open(), read() y write(), o equivalentes) promedio por segundo
realizó cada dispositivo durante el tiempo de las estadísticas.
Aquí lo más importante es observar desbalances, ya que
concentrar muchas de estas operaciones sobre unos pocos
dispositivos mientras otros no trabajan puede generar cuellos de
botella, y con ello, demoras en la prestación del servicio.
! Kb_read: esta columna nos muestra el total de KB leídos de cada
dispositivo durante el tiempo de la estadística.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 104

 ! KB_wrnt: esta columna nos muestra el total de KB escritos de cada
dispositivo durante el tiempo de la estadística.
Luego el comando nos muestra las líneas con los datos estadísticos de cada dispositivo.
Note cómo en nuestro ejemplo, prácticamente toda y la única actividad son las
operaciones de I/O sobre el dispositivo disco hdisk4, y cómo éste trabaja casi el 100% del
tiempo mientras los otros discos trabajan prácticamente 0%. Este es el tipo de
desbalance que nos ayuda el comando iostat -d a identificar.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 105

AIX Performance ● Ramón Barrios Lascar ® Ínodo 106
 Comando iostat -a
El comando iostat tiene diferentes reportes y diferentes estadísticas. Cuando se usa la
opción a se está seleccionando el reporte que incluye las adaptadoras (controladoras) y
los caminos (paths).
Ejemplo:
root@p520vm1:/# iostat -a

Adapter: Kbps tps Kb_read Kb_wrtn

scsi0 0.0 0.0 0 0

Paths/Disk: % tm_act Kbps tps Kb_read Kb_wrtn

hdisk1_Path0 37.0 89.0 0.0 0 0
hdisk0_Path0 67.0 47.0 0.0 0 0
hdisk4_Path0 0.0 0.0 0.0 0 0
hdisk3_Path0 0.0 0.0 0.0 0 0

Adapter: Kbps tps Kb_read Kb_wrtn

ide0 0.0 0.0 0 0

Paths/Disk: % tm_act Kbps tps Kb_read Kb_wrtn

cd0 0.0 0.0 0.0 0 0
En este caso no hay cuellos de botella, pero nos es útil para explicar los diferentes
campos de información estadística.
Muestra:
La primera sección nos muestra las controladoras y/o adaptadoras, de a una por sección:
! La primera línea nos muestra los nombres de las columnas a reportar. La
primera columna “Adaptadora” (Adapter) nos mostrará los
nombres de las diferentes adaptadoras/controladoras a reportar.
! Kbps muestra el promedio por segundo de KB operados (leídos más
escritos) durante el tiempo de la muestra, consolidado por cada
controladora.
! tps muestra el promedio por segundo de operaciones (open(), read(),
write() y equivalentes) durante el tiempo de la muestra,
consolidado por cada controladora.
! Kb_read muestra el total de KB leídos de todos los discos manejados por
esta controladora durante el tiempo de la muestra
! Kb_wrtn muestra el total de KB escritos en todos los discos manejados por
esta controladora durante el tiempo de la muestra
La segunda sección nos muestra los dispositivos disco manejados por la controladora
justo reportada, con una línea por disco y camino usado. La primera línea muestra los
títulos de las columnas a reportar:

AIX Performance ● Ramón Barrios Lascar ® Ínodo 107

 ! Paths/Disk Muestra el nombre de cada dispositivo disco combinado con un
camino así: NombreDisco_NombreCamino.
! % tm_act al igual que otras estadísticas, muestra cuánto porciento del
tiempo de la muestra estuvo trabajando el dispositivo disco, pero
especificando el camino por donde se hicieron las operaciones.
Nos sirve para encontrar desbalances.
! Kbps muestra cuántos KB promedio por segundo se trabajaron
(lecturas más escrituras) en este dispositivo disco, pero siendo
específico por el camino que la operación se hizo.
! tps muestra el promedio por segundo de operaciones (open(), read(),
write() y equivalentes) durante el tiempo de la muestra,
individualizando por disco y el camino que se usó para ello.
! Kb_read muestra el total de KB leídos de este disco siendo específico por
el camino por el que la operación se envió.
! Kb_wrtn muestra el total de KB escritos en este disco, siendo específico
por el camino por donde se enviaron los datos a escribir.
El comando luego repite el esquema de reporte para los otros discos y caminos y más
adelante las otras controladoras y los discos que las otras controladoras manejan.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 108

 Comando sar -d
El comando sar (system activity report) es bastante flexible y útil. En particular, con la
opción d permite obtener un reporte estadístico parecido al de iostat -d, pero con la
diferencia de que se pueden obtener columnas con los detalles de cargas de trabajo (con
las cantidades de elementos enviados y procesados por cada operación de I/O sobre
cada dispositivo disco).
Ejemplo:
root@p520vm01:# sar -d 1 2
AIX p520vm01 1 7 00F604884C00 08/11/12

System configuration: lcpu=4 drives=1 ent=0.25 mode=Uncapped

[Link] device %busy avque r+w/s Kbs/s avwait avserv

[Link] hdisk0 1 0.0 6 24 0.0 1.9
[Link] hdisk0 0 0.0 3 15 0.0 2.3
Average hdisk0 0 0.0 4 19 0.0 2.1
Se puede observar:
! Muestra una línea descriptiva del servidor donde se ejecuta:
AIX p520vm01 1 7 00F604884C00 08/11/13

Esta línea nos aclara que se ejecutó sar de AIX (existe para las otras plataformas Unix y
Linux con básicamente los mismos usos y sintaxis). Luego nos da, en orden: el nombre
del servidor —p520vm01—, la versión menor y mayor de AIX, 1 7 que combinado sería
AIX v7.1, el serial único de la VM, 00F604884C00 —parcialmente tomado del serial del
servidor físico—, y la fecha, en formato MM/DD/YY.
! Muestra luego un encabezado de la configuración de la VM donde se ejecuta:
System configuration: lcpu=4 drives=1 ent=0.25 mode=Uncapped

Esta línea nos cuenta básicamente lo mismo que el comando iostat -d:
! lcpu muestra cuántos procesadores lógicos (hijos de ejecución
posibles) representa la máquina (en nuestro caso puede ser una
CPU virtual multiplicada por SMT 4 o pueden ser dos CPUs
virtuales × SMT 2, o pueden ser cuatro CPUs virtuales con SMT
apagado).
! drives muestra cuántos discos reconoce la máquina, en nuestro ejemplo
sería un único disco duro.
! ent muestra cuánto CPU tiene titulado la VM o LPAR (0.25 de
procesador son 25 turnos de cada 100 turnos por segundo de un
core Power6 o Power7).
! mode muestra si la VM o LPAR es capped o uncapped, esto último en
nuestro ejemplo.
Luego muestra una línea de títulos que aclara las siguientes líneas de estadísticas:

AIX Performance ● Ramón Barrios Lascar ® Ínodo 109

 ! HH:MM:SS muestra la hora exacta, con segundos del momento de
presentación de los datos estadísticos
! device muestra el nombre del dispositivo disco del que se reportan los
datos
! % busy igual que otros comandos como iostat, cuánto porciento del
tiempo de la toma de estadísticas estuvo haciendo operaciones
de I/O cada dispositivo reportado. Como el tiempo de separación
de las muestras en nuestro ejemplo fue de 1 segundo, el
porcentaje es de ése segundo.
! avque muestra cuántas operaciones en promedio estuvieron en cola,
detenidas, debido a la ocupación de cada disco. Como cada disco
tiene colas internas adicionales de servicio, idealmente esta cola
debería mantenerse en cero (0) siempre.
! r+w/s muestra cuántos bloques de disco (de 512B cada uno) fueron
enviados o recibidos, promedio por segundo, durante cada
muestra estadística. La idea es que si este servidor realiza
muchas operaciones reales debido a su función, si hay mucha
RAM pueden retenerse, si no, deberán realizarse físicamente
sobre los discos, pero estos tienen un límite real de lo que
pueden manejar.
! avwait muestra cuánto tiempo —en milisegundos– tienen que esperar
las tareas de I/O antes de ser operadas realmente por cada disco.
Se relaciona directamente con avque, ya que si la cola es corta no
deberían haber muchas demoras en las operaciones antes de
entrar —y viceversa—.
! avserv muestra cuánto tiempo —en milisegundos también— tienden a
demorarse, en promedio las actividades de I/O dentro de cada
dispositivo disco. Este tiempo se puede aumentar si hay muchas
operaciones simultáneas por dispositivo disco y si las
operaciones individuales son grandes. Si estos elementos se
crecen piense en aumentar la profundidad de cola del disco
(queue_depth) de ser posible.
Este comando es especialmente útil, ya que muchas compañías adquieren servidores,
sistemas de almacenamiento y discos con la premisa de lograr tiempos de servicio del
orden de 5ms máximo —típicamente—, y así es que los diseñadores de arquitecturas y
áreas comerciales “venden” las soluciones como las más convenientes.
En conclusión: lo más probable es que los usuarios del sistema esperen tiempos
promedios donde avwait+avserv ≤ 5.0ms.
Al finalizar el reporte, el comando sar -d muestra una línea promedio (Average) con los
datos promediados de todas las líneas presentadas.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 110

 Comando topas
El comando topas es tal vez el preferido de los usuarios nuevos de AIX. Permite
observar numerosísimas estadísticas, muchas de ellas simultáneamente —entre estas
algunas estadísticas de la actividad de los discos—.
Ejemplo #1:
# topas

Topas Monitor for host: AIX2 EVENTS/QUEUES FILE/TTY

Sat May 31 [Link] 2014 Interval: 2 Cswitch 110 Readch 7
Syscall 104 Writech 384
CPU User% Kern% Wait% Idle% Physc Entc Reads 1 Rawin 0
ALL 0.3 0.8 0.0 98.9 0.01 1.5 Writes 4 Ttyout 305
Forks 0 Igets 0
Network KBPS I-Pack O-Pack KB-In KB-Out Execs 0 Namei 2
Total 0.7 6.5 5.5 0.4 0.3 Runqueue 3.5 Dirblk 0
Waitqueue 0.0
Disk Busy% KBPS TPS KB-Read KB-Writ MEMORY
Total 0.0 4.0 1.0 4.0 0.0 PAGING Real,MB 3072
Faults 4 % Comp 50
FileSystem KBPS TPS KB-Read KB-Writ Steals 0 % Noncomp 8
Total 0.0 0.0 0.0 0.0 PgspIn 0 % Client 8
PgspOut 0
Name PID CPU% PgSp Owner PageIn 1 PAGING SPACE
java 8519696 0.0 52.2 root PageOut 0 Size,MB 512
java 5767410 0.0 75.1 root Sios 1 % Used 2
java 8257550 0.0 41.0 pconsole % Free 98
cimserve 4653210 0.0 30.2 root NFS (calls/sec)
rmcd 5701828 0.0 211.5 root SerV2 0 WPAR Activ
pvlist 524304 0.0 0.4 root CliV2 0 WPAR Total
memgrdd 589842 0.0 0.4 root SerV3 0 Press: "h"-help
shlap64 655470 0.0 0.4 root CliV3 0 "q"-qui

De manera predeterminada topas muestra tres secciones

! Superior izquierda con los datos del servidor, fecha y hora, y tiempo entre
muestra y muestra —que de manera predeterminada son dos segundos—,
con los porcentajes de consumo de CPUs globales —dos líneas iniciadas en
CPU—, con los datos de consumo global de red —dos líneas iniciadas en
Network—, con los datos de ocupación en actividades de disco —dos líneas
iniciadas en Disk— y con los datos de ocupación en actividades de sistemas
de archivos, que en parte también son disco —dos líneas iniciadas en
FileSystem—.

! Inferior izquierda con los detalles de los procesos del sistema más
consumidores de CPU, listados de manera descendente.
! Superior derecha con los detalles de actividades generales, Eventos/Colas
(Events/Queues), Paginación (Paging), NFS, Archivo/Terminal (File/TTY),
Memoria (Memory), Espacio de Paginación (Paging Space), Actividad de
WPAR (WPAR Activ).

AIX Performance ● Ramón Barrios Lascar ® Ínodo 111

 En esta pantalla general del comando topas, lo que más nos puede interesar —desde el
punto de vista del desempeño y estadísticas de disco— es obviamente la sección
titulada “Disco” (Disk), que nos muestra el porcentaje promedio de utilización “Ocupado
%” (Busy%), que si es muy alto nos indicaría que necesitamos abrir más detalle (con el
mismo comando topas o con otro específico como el ya observado sar -d).
Aunque es un comando muy sencillo, este uso precluye las comparaciones directas a
través del tiempo, por lo que si se quieren seguir tendencias, no es la herramienta más
recomendada si se usa así.
Nota: en las versiones recientes de AIX —donde nmon se incluye preinstalado con el
sistema operativo—, topas y nmon son el mismo ejecutable, y la invocación implica qué
pantallas o datos se muestran.
Ahora, topas tiene numerosos switches de opción, para seleccionar el detalle de alguna
estadística. En particular topas -D muestra detalles de la actividad de los discos
únicamente:
Ejemplo #2:
# topas -D

Topas Monitor for host: AIX2 Interval: 2 Sat May 31 [Link] 2014
===============================================================================
Disk Busy% KBPS TPS KB-R ART MRT KB-W AWT MWT AQW AQD
hdisk3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
hdisk4 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
hdisk1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
hdisk2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
cd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
hdisk5 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
hdisk0 0.0 0.0 0.0 0.0 0.0 0.4 0.0 0.0 0.0 0.0 0.0

Cuando se usa así muestra:

! La primera línea —Iniciando en Topas Monitor...— muestra los detalles del
nombre del servidor, tiempo entre muestra y muestra, y fecha y horas de la
toma de estadística.
Luego muestra los nombres de las columnas que va a reportar:
! Disk muestra como es natural, el nombre de cada dispositivo disco a
reportar.
! Busy% muestra el porcentaje del tiempo entre muestra y muestra —que
de manera predeterminada son 2 segundos, como lo indica en la
primera línea—.
! KBPS muestra el promedio de KB operados (tanto leídos como escritos)
en los dos segundos —típicos— de la estadística. Con este
número podemos comparar los diferentes discos del sistema —
en nuestro ejemplo sólo hay uno— y ver si toda o la mayoría de la
carga la reciben unos pocos dispositivos, lo que indicaría si vale
la pena una reorganización entre diferentes discos—.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 112

 ! TPS muestra el promedio de transacciones realizadas (open(), read(),
write() y equivalentes) en cada uno de los dispositivos entre
muestra y muestra. Con estos números también podemos
analizar si hay desbalance de carga entre dispositivo y
dispositivo.
! KB-R muestra el total de KB leídos de cada dispositivo entre muestra y
muestra. Un número bajo en esta estadística comparado con un
número alto en las esperas podría indicar que o los datos están
muy espaciados y desordenados en los discos —desde el punto
de vista de AIX, lo que se llama fragmentación de archivos y/o de
volúmenes—, los datos están muy espaciados y desordenados en
el sistema de almacenamiento —cuando lo hay—, o el caché —
RAM— de lectura del sistema de almacenamiento no está siendo
efectivo.
! ART muestra el promedio de tiempo, en milisegundos, que están
tomando las operaciones de lectura. Este es uno de los números
que nos es útil comparar con KB-R. Hay que recordar que la
mayoría de los clientes espera que este número se mantenga por
debajo de 5ms.
! MRT muestra el tiempo máximo, en milisegundos, que tomaron las
lecturas durante el periódo —2s— de la muestra, en cada
dispositivo. No es anormal que unas de las operaciones tomen
muchísimo más de lo esperado.
! KB-W muestra el total de KB escritos de cada dispositivo entre muestra
y muestra. Un número bajo en esta estadística comparado con
un número alto en las espera podría indicar que o los datos están
muy espaciados y desordenados en los discos —desde el punto
de vista de AIX, lo que se llama fragmentación de archivos y/o
volúmenes—, los datos están muy espaciados y desordenados en
el sistema de almacenamiento, el caché —RAM— de escritura del
sistema de almacenamiento no está siendo efectivo —o no se
está usando— o, cuando se usan discos que realmente son
volúmenes elásticos —thin provisioned—, el sistema de
almacenamiento se está tomando demasiado en aprovisionar
nuevo espacio real físico.
! AWT muestra el promedio de tiempo, en milisegundos, que están
tomando las operaciones de escritura. Este es uno de los
números que nos es útil comparar con KB-W. Hay que recordar
que la mayoría de los clientes espera que este número se
mantenga por debajo de 5ms. Es común que este número sea
superior al ART, pero también es común que en la mayoría de los
ambientes haya cinco o seis veces más operaciones de lectura

AIX Performance ● Ramón Barrios Lascar ® Ínodo 113

 que de escritura —por lo que este número nos influye un poco
menos las estadísticas totales—.
! MRT muestra el tiempo máximo, en milisegundos, que tomaron las
escrituras durante el período —2s— de la muestra, en cada
dispositivo. No es anormal que unas de las operaciones tomen
muchísimo más de lo esperado.
! AQW muestra el promedio de espera, en milisegundos, en la cola de
cada dispositivo disco. Cuando este número supera el cero (0) ya
es de preocuparse, ya que cada dispositivo tiene una cola
interna, y esta se puede interpretar como una “cola overflow”.
! AQD muestra el número promedio de elementos en la cola de cada
dispositivo disco. Si se presenta que este número supera el cero
(0) debería investigarse —con otra herramienta— si los
elementos en cola de los discos son suficientes para la carga que
se está dando.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 114

 Comando lvmstat
El comando lvmstat no es muy conocido. Este comando lvmstat permite analizar la
actividad de los volúmenes lógicos de un grupo de volúmenes y la actividad de las
particiones que componen un volumen lógico. El comando no es muy complejo, pero sí
muy útil. Ahora, de manera predeterminada AIX no tiene activos los contadores que
necesita lvmstat para reportar, por lo que su uso nos puede presentar un mensaje de
error:
# lvmstat -v rootvg
0516-1309 lvmstat: Statistics collection is not enabled for this logical device.
Use -e option to enable.
Ejemplo #1:
root@pmundial:/>lsvg
rootvg
datosvg
PRODvg
root@pmundial:/>lvmstat -e -v PRODvg
root@pmundial:/>sleep $((20 * 20)) ; lvmstat -v PRODvgv

Logical Volume iocnt Kb_read Kb_wrtn Kbps

DEV_PROD_DAT2 125699 744150 5580 0.39
DEV_PROD_DAT1 104542 399302 1136 0.21
DEV_PROD_DAT 54980 609378 8414 0.32
DEV_TEMPDB3 32597 906 64512 0.03
DEV_PROD_DAT3 24102 166760 1204 0.09
DEV_PROD_DAT8 21433 91772 3020 0.05
DEV_PROD_DAT5 19450 11166 37072 0.02
DEV_PROD_DAT11 16904 166098 2488 0.09
DEV_PROD_DAT4 12885 141540 342 0.07
DEV_PROD_DAT7 12422 138304 1326 0.07
DEV_TEMPDB 11871 838 23086 0.01
DEV_PROD_DAT14 6100 28392 1770 0.02
DEV_PROD_DAT10 4732 24856 1534 0.01
DEV_PROD_DAT9 2681 24134 534 0.01
DEV_TEMPDB4 2657 322 8730 0.00
DEV_PROD_DAT13 1610 15914 186 0.01
DEV_PROD_DAT12 847 9630 394 0.01
DEV_TEMPDB1 810 16 1968 0.00
DEV_TEMPDB2 740 100 1912 0.00
DEV_PROD_DAT15 510 1600 540 0.00
DEV_PROD_DAT6 363 3008 0 0.00
DEV_PROD_DAT16 0 0 0 0.00
DEV_PROD_LOG1 0 0 0 0.00
DEV_PROD_LOG 0 0 0 0.00
root@pmundial:/>lvmstat -d -v PRODvg
El ejemplo nos muestra el uso típico.
! Obtenemos los nombres de los grupos de volúmenes en el sistema, como es
natural, con lsvg. Por comandos anteriores sabemos que nos interesa la
información de PRODvg.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 115

 ! Para obtener las estadísticas del grupo de volúmenes de PRODvg primero
debemos activar la recolección de estadísticas del mismo, para ello se usa
lvmstat -e -v NombreVG, donde: la opción e indica “activar” (enable), la
opción v indica “grupo de volúmenes” (volume group), y hay que dar el
nombre de un grupo de volúmenes, en nuestro ejemplo PRODvg.
! Para ver las estadísticas de un grupo de volúmenes se usa lvmstat -v
NombreVG, pero como en nuestro caso acabamos de activar la recolección de
los indicadores, le damos un tiempo al sistema (de ahí el comando sleep).
Muestra:
! Una primera línea con la descripción de las columnas estadísticas que
reportará.
! Logical Volume muestra el nombre de cada volumen contenido dentro del
grupo de volúmenes seleccionado/reportado, notando que
lvmstat siempre muestra de mayor a menor (más activo a menos
activo)
! iocnt muestra la cantidad de operaciones de I/O realizadas sobre el
volumen (open(), read(), write() o equivalentes).
! Kb_read muestra cuántos KB se han trabajado en sólo lecturas durante el
tiempo de la muestra —es decir desde el momento del lvmstat -
e -v hasta el momento del lvmstat -v—.

! Kb_wrnt muestra cuántos KB se han trabajado en sólo lecturas durante el

tiempo de la muestra —es decir desde el momento del lvmstat -
e -v hasta el momento del lvmstat -v—.

! Kbps muestra cuántos KB promedio por segundo se han trabajado

durante el tiempo de la muestra —es decir desde el momento del
lvmstat -e -v hasta el momento del lvmstat -v—. No es normal
que un dispositivo permanezca con números de trabajo muy
reducido, en especial teniendo en cuenta las tasas de
transferencia de los sistemas de almacenamiento actual.
Al final del análisis desactivamos la toma de indicadores den el grupo de volúmenes
seleccionado, en especial ya que el servidor del ejemplo tiene unos problemas serios de
desempeño, y cualquier tarea adicional podría afectarle negativamente. Desactivar la
toma de datos en un grupo de volúmenes se realiza con lvmstat -d -v NombreVG, donde d
indica “desactivar” (disable) y v “grupo de volúmenes” (volume group).
En un comando como ése podemos ver si los volúmenes más activos son los mejores
ubicados (mejores controladoras, mejores caminos, mejores discos, mejores posiciones
en los discos), y si de verdad los que se creen son los volúmenes más activos realmente
lo son.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 116

 El comando puede mostrarnos aún más detalles, en especial si se tienen máquinas con
volúmenes con mucha actividad, que de pronto nos interesa tener —bien— distribuidos
en múltiples dispositivos disco. Un nuevo ejemplo nos mostrará.
Ejemplo #2:
root@pmundial:/>lvmstat -v PRODvg
0516-1309 lvmstat: Statistics collection is not enabled for this logical device.
Use -e option to enable.
root@pmundial:/>lvmstat -ev PRODvg ; sleep $((20 * 20)) ; lvmstat -v PRODvg

Logical Volume iocnt Kb_read Kb_wrtn Kbps

DEV_TEMPDB2 84904 1506 169688 0.09
DEV_PROD_DAT2 74056 343254 5552 0.18
DEV_PROD_DAT 50864 476240 13260 0.25
DEV_PROD_DAT1 48661 352020 1128 0.18
DEV_TEMPDB3 34693 472 69376 0.04
DEV_TEMPDB4 27384 566 55448 0.03
DEV_PROD_DAT7 24390 280078 4486 0.15
DEV_PROD_DAT5 22983 22604 42626 0.03
DEV_PROD_DAT3 22689 189246 1308 0.10
DEV_PROD_DAT4 15345 169430 3006 0.09
DEV_PROD_DAT11 11620 71832 2228 0.04
DEV_PROD_DAT8 9678 58572 1900 0.03
DEV_PROD_DAT14 5221 25724 5200 0.02
DEV_PROD_DAT10 4521 33780 686 0.02
DEV_TEMPDB1 3115 52 7998 0.00
DEV_PROD_DAT9 3053 29564 482 0.02
DEV_PROD_DAT15 1531 3278 442 0.00
DEV_PROD_DAT13 1068 11276 170 0.01
DEV_TEMPDB 781 204 1554 0.00
DEV_PROD_DAT12 664 8610 208 0.00
DEV_PROD_DAT6 534 4700 50 0.00
DEV_PROD_DAT16 0 0 0 0.00
DEV_PROD_LOG1 0 0 0 0.00
DEV_PROD_LOG 0 0 0 0.00
root@pmundial:/>lvmstat -l DEV_TEMPDB2

Log_part mirror# iocnt Kb_read Kb_wrtn Kbps

7 1 49120 360 99448 0.05
6 1 45621 344 90898 0.05
1 1 10870 226 21514 0.01
4 1 1741 562 2920 0.00
2 1 649 106 1640 0.00
3 1 517 2 1032 0.00
15 1 71 12 298 0.00
19 1 43 8 148 0.00
12 1 22 12 32 0.00
18 1 22 10 34 0.00
14 1 15 6 24 0.00
11 1 11 0 22 0.00
5 1 8 4 12 0.00
10 1 7 8 6 0.00
8 1 4 4 4 0.00
9 1 2 0 4 0.00
17 1 1 0 2 0.00
13 1 0 0 0 0.00
16 1 0 0 0 0.00

AIX Performance ● Ramón Barrios Lascar ® Ínodo 117

 20 1 0 0 0 0.00
root@pmundial:/>lvmstat -d -v PRODvg
En el nuevo ejemplo vemos cómo se pueden tener las particiones más activas de
cualquier volumen lógico contenido dentro de un grupo de volúmenes que tenga la
recolección de indicadores estadísticos activados. Esto nos puede servir cuando se
tienen —como es común— volúmenes que no se pueden dividir lógicamente —es decir,
que tienen que ser volúmenes únicos según las necesidades de aplicación—, pero que sí
se pueden dividir físicamente —ubicando mitad y mitad de un volumen lógico en dos
discos físicos, por ejemplo, o haciendo striping—.
En el segundo ejemplo de lvmstat vemos cómo usar el comando lvmstat -l NombreLV
nos detalla porción por porción (por particiones lógicas) cuáles son las áreas más
“calientes” del volumen lógico especificado.
Muestra:
! Log_part muestra el número (de 1 al número de particiones que componen
el volumen) de la partición más activa a la menor.
! mirror# muestra el número de la copia de la partición lógica —la original
es la #1, la primera copia cuando se tiene mirror es #2, y la
segunda copia, cuando se tiene doble mirror es #3—.
! iocnt muestra la cantidad de operaciones de I/O realizadas sobre la
partición lógica del volumen (open(), read(), write() o
equivalentes).
! Kb_read muestra cuántos KB se han trabajado en sólo lecturas durante el
tiempo de la muestra —es decir desde el momento del lvmstat -
e -v hasta el momento del lvmstat -l—.

! Kb_wrnt muestra cuántos KB se han trabajado en sólo lecturas durante el

tiempo de la muestra —es decir desde el momento del lvmstat -
e -v hasta el momento del lvmstat -l—.

! Kbps muestra cuántos KB promedio por segundo se han trabajado

durante el tiempo de la muestra —es decir desde el momento del
lvmstat -e -v hasta el momento del lvmstat -l—. No es normal
que un dispositivo permanezca con números de trabajo muy
reducido, en especial teniendo en cuenta las tasas de
transferencia de los sistemas de almacenamiento actual.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 118

 Comando vmstat -v
El comando vmstat tiene múltiples usos y sintaxis, en particular vmstat -v nos permite
obtener estadísticas que muestren insuficiencia en varias colas y búferes de la capa de I/
O de bajo nivel.
Ejemplo:
root@pmundial:/>vmstat -v
6291456 memory pages
6084656 lruable pages
705556 free pages
4 memory pools
1503109 pinned pages
80.0 maxpin percentage
3.0 minperm percentage
90.0 maxperm percentage
27.7 numperm percentage
1689829 file pages
0.0 compressed percentage
0 compressed pages
27.7 numclient percentage
90.0 maxclient percentage
1689829 client pages
0 remote pageouts scheduled
347103 pending disk I/Os blocked with no pbuf
20634977 paging space I/Os blocked with no psbuf
2228 filesystem I/Os blocked with no fsbuf
0 client filesystem I/Os blocked with no fsbuf
144278 external pager filesystem I/Os blocked with no fsbuf
61.9 percentage of memory used for computational pages

Aunque el comando muestra numerosas estadísticas, sólo la parte resaltada nos

interesa por ahora.
Cuando la capa del volumen lógico que maneja los volúmenes físicos necesita hacer
operaciones de I/O, usa unos elementos de cola del grupo de volúmenes que lo contiene
—cola cuyo tamaño observamos con lvmo -a | grep pbuf—. Si no puede obtener un
elemento de cola de trabajo, porque todos se están usando por la alta carga y/o las
demoras en cada operación, el manejador de memoria virtual (VMM) aumenta el
indicador resaltado “I/O a disco pendiente bloqueada porque no hay pbufs” (pending
disk I/Os blocked with no pbuf). Este es un indicador directo de que deberán
aumentarse, cambio que se realiza también con lvmo.
Nótese que cuántos pbufs usa un grupo de volúmenes está parametrizado en el grupo de
volúmenes, pero no en las estructuras de disco del mismo si no en la ODM del servidor,
por lo que llevar un grupo de volúmenes a otro servidor o exportarlo e importarlo pierde
esta parametrización.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 119

AIX Performance ● Ramón Barrios Lascar ® Ínodo 120
 Comando lvmo -a
El comando lvmo permite revisar y parametrizar ciertos números de búferes que maneja
AIX para los discos que están en grupos de volúmenes.
Ejemplo:
0 root@Sanson:/> lvmo -a
vgname = rootvg
pv_pbuf_count = 512
total_vg_pbufs = 512
max_vg_pbufs = 16384
pervg_blocked_io_count = 0
pv_min_pbuf = 512
max_vg_pbuf_count = 0
global_blocked_io_count = 0
Aunque muestra varios valores y parámetros, en esta sección nos interesa comentar un
par:
! pervg_blocked_io_count muestra cuántos elementos de cola de I/O a algún
disco o volumen físico de algún grupo de volúmenes no se pudo obtener. No
se pueden obtener cuando hay alta actividad de disco en ése grupo de
volúmenes y el número de elementos no fue suficiente.
! global_blocked_io_count muestra cuántos elementos de cola de I/O a
cualquier disco contenido en grupo de volúmenes no se pudo obtener. No se
pueden obtener cuando hay alta actividad de disco y el número global de
pbufs no es suficiente.
Ambos parámetros se analizan cuando vmstat -v reporta “I/O a disco pendiente
bloqueada porque no hay pbufs” (pending disk I/Os blocked with no pbuf).

AIX Performance ● Ramón Barrios Lascar ® Ínodo 121

AIX Performance ● Ramón Barrios Lascar ® Ínodo 122
 Comando fcstat
El comando fcstat permite ver numerosísimas estadísticas de una adaptadora fibre
channel, y del objeto de protocolo FCP que tiene encima (de una fcsX y el objeto fscsiX
que va encima). Aunque explicar todas las estadísticas que puede mostrar sería
demasiado extenso para este documento podemos ver algunas cosas.
Ejemplo:
gmons01@REC_BD:/> lsdev -l fcs*
fcs2 Available 06-08 FC Adapter
fcs3 Available 06-09 FC Adapter
Con esto sólo obtenemos la lista de las adaptadoras de SAN FCP del servidor.
Revisamos a continuación algunos valores:
gmons01@REC_BD:/> fcstat fcs2 | egrep 'Port Type|Port Speed'
Port Speed (supported): 8 GBIT
Port Speed (running): 8 GBIT
Port Type: Fabric

Con este comando observamos la velocidad que soporta el puerto fcs2 de las HBAs. Se
nota que soporta hasta 8Gb/s (supported: 8 GBIT) y está trabajando a ése ideal
(running: 8 GBIT). Obviamente trabajar a menos del ideal va en detrimento del
desempeño. También con el comando obtenemos si la adaptadora se conecta por una
fibra a un switch (Fabric) o no.
Ejemplo:
El comando permite saber el uso adecuado de las colas de tareas:
# fcstat fcs0 | grep '^ No '
...

No DMA Resource Count: 4490 ← aumentar max_xfer_size

No Adapter Elements Count: 105688

No Command Resource Count: 133 ← aumentar num_cmd_elems

...
Se puede observar cómo el comando nos muestra los contadores de cuando las colas o
los bloques de transmisión no están siendo suficientes. Siendo estos dos atributos del
dispositivo —en el ejemplo de fcs0, se revisarían con lsattr -El fcs0—

AIX Performance ● Ramón Barrios Lascar ® Ínodo 123

AIX Performance ● Ramón Barrios Lascar ® Ínodo 124
Parametrización del LVM de AIX
Comando chdev
Como ya se ha mencionado, el comando chdev permite modificar muchísimos atributos
de muchísimos dispositivos en AIX. En este caso mencionaremos algunos de los
atributos que nos interesa modificar para afectar el desempeño del I/O a través del LVM
de AIX. Estos parámetros se pueden encontrar en los dispositivos disco (hdiskX),
dispositivos controladora (scsiX, vscsiX, fcsX) y en los dispositivos de protocolo FCP
(fscsiX).
Como se observó en el último ejemplo, cuando se usa el comando fcstat es posible que
se nos reporte “No Command Resource Count”. Para tratar de evitar estos mensajes de
error, que se reportan al quedarse sin espacio en la cola de elementos de una
controladora HBA FC/FCP, se usará chdev.
Ejemplo #1a:
# lsdev -l fcs*
fcs0 Available 00-00 8Gb PCI Express Dual Port FC Adapter (df1000f114108a03)
fcs1 Available 00-01 8Gb PCI Express Dual Port FC Adapter (df1000f114108a03)
fcs2 Available 01-00 8Gb PCI Express Dual Port FC Adapter (df1000f114108a03)
fcs3 Available 01-01 8Gb PCI Express Dual Port FC Adapter (df1000f114108a03)
fcs4 Available 02-00 8Gb PCI Express Dual Port FC Adapter (df1000f114108a03)
fcs5 Available 02-01 8Gb PCI Express Dual Port FC Adapter (df1000f114108a03)
fcs6 Available 03-00 8Gb PCI Express Dual Port FC Adapter (df1000f114108a03)
fcs7 Available 03-01 8Gb PCI Express Dual Port FC Adapter (df1000f114108a03)
# for DEV in $(lsdev -l 'fcs*' -F name) ; do
> printf "$DEV:\n" >&2
> lsattr -El $DEV -a max_xfer_size -a num_cmd_elems
> printf "\n" >&2
> done
fcs0:
max_xfer_size 0x100000 Maximum Transfer Size True
num_cmd_elems 500 Maximum number of COMMANDS to queue to the adapter True

fcs1:
max_xfer_size 0x100000 Maximum Transfer Size True
num_cmd_elems 500 Maximum number of COMMANDS to queue to the adapter True

fcs2:
max_xfer_size 0x100000 Maximum Transfer Size True
num_cmd_elems 500 Maximum number of COMMANDS to queue to the adapter True

fcs3:
max_xfer_size 0x100000 Maximum Transfer Size True
num_cmd_elems 500 Maximum number of COMMANDS to queue to the adapter True

fcs4:
max_xfer_size 0x100000 Maximum Transfer Size True
num_cmd_elems 500 Maximum number of COMMANDS to queue to the adapter True

fcs5:
max_xfer_size 0x100000 Maximum Transfer Size True

AIX Performance ● Ramón Barrios Lascar ® Ínodo 125

 num_cmd_elems 500 Maximum number of COMMANDS to queue to the adapter True

fcs6:
max_xfer_size 0x100000 Maximum Transfer Size True
num_cmd_elems 500 Maximum number of COMMANDS to queue to the adapter True

fcs7:
max_xfer_size 0x100000 Maximum Transfer Size True
num_cmd_elems 500 Maximum number of COMMANDS to queue to the adapter True
Se observa una manera de revisar qué tarjetas adaptadoras FC hay, y cuáles son sus
atributos —que de pronto interesa cambiar si el comando fcstat fcX está reportando
“No DMA Resource Count” y “No Command Resource Count”—.
Se procede a cambiarlos “en masa”:
Ejemplo #1b:
# for DEV in $(lsdev -l fcs* -F name) ; do
> chdev -l $DEV -a num_cmd_elems=1024 -a max_xfer_size=0x200000 -P
> done
fcs0 changed
fcs1 changed
fcs2 changed
fcs3 changed
fcs4 changed
fcs5 changed
fcs6 changed
fcs7 changed

En el caso del ejemplo se ejecutó chdev -P para que el cambio lo asuma en el próximo
reinicio del sistema. Como en muchos servidores los discos son volúmenes de SAN, y
están activos, las adaptadoras HBA también, lo que impedirá los cambios en línea —
reportarán “en uso” —busy— y no aceptarán el nuevo parámetro en caliente.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 126

 Comando lvmo
El comando administrativo lvmo (logical volume manager options) permite revisar, unas
estadísticas puntuales, listar y cambiar unos parámetros de búferes de I/O que usa el
manejador de volúmenes lógicos de AIX (LVM) para hacer I/O a volúmenes (LV) en
grupos de volúmenes (VG).
Ejemplo #1a:
root@CPP000SYB068# lvmo -a
vgname = rootvg
pv_pbuf_count = 512
total_vg_pbufs = 512
max_vg_pbufs = 16384
pervg_blocked_io_count = 1822
pv_min_pbuf = 512
max_vg_pbuf_count = 0
global_blocked_io_count = 1834
Se observa el uso (listar los parámetros y las estadísticas con la opción a). Se observa
que se han dado situaciones con insuficiencia de estructuras de control, entonces vale la
pena ajustar algunas.
Ejemplo #1b:
root@CPP000SYB068# lvmo -v rootvg -o pv_pbuf_count=2048
root@CPP000SYB068# lvmo -a
vgname = rootvg
pv_pbuf_count = 2048
total_vg_pbufs = 2048
max_vg_pbufs = 16384
pervg_blocked_io_count = 1822
pv_min_pbuf = 512
max_vg_pbuf_count = 0
global_blocked_io_count = 1834
Se trata de seguir monitoreando las estadísticas del grupo de volúmenes para así saber
si el cambio estabilizó los indicadores de error —y así sabemos que no se siguieron
presentando las insuficiencias—.
Nota: El parámetro se almacena en la ODM, específicamente en los atributos del grupo
de volúmenes dentro de la tabla CuAt, mismos que se borran cuando se exporta el grupo
de volúmenes y se vuelve a importar —o se importa en un servidor diferente—.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 127

AIX Performance ● Ramón Barrios Lascar ® Ínodo 128
 Comando ioo
El comando ioo (input/ouput system options) es un comando administrativo poderoso.
El mismo necesita permisos de root y permite listar, revisar y cambiar los parámetros
que afectan directamente los parámetros del manejador de memoria virtual que están
relacionados con los búferes de I/O a y desde disco.
Ejemplo #1:
[0 root@AIX1:/] ioo -a
... # salida suprimida ...
lvm_bufcnt = 9
maxpgahead = 8
maxrandwrt = 0
numclust = 1
numfsbufs = 196
pd_npages = 65536
... # salida suprimida ...
El mismo, cuando se usa con la opción a lista todos los atributos no restringidos con sus
valores actuales.
Ejemplo #2:
[0 root@AIX1:/] ioo -L
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
aio_active 0 0 boolean S
--------------------------------------------------------------------------------
aio_maxreqs 64K 64K 64K 4K 1M numeric D
--------------------------------------------------------------------------------
aio_maxservers 30 30 30 1 20000 numeric D
aio_minservers
--------------------------------------------------------------------------------
aio_minservers 3 3 3 0 20000 numeric D
aio_maxservers
--------------------------------------------------------------------------------
aio_server_inactivity 300 300 300 1 86400 seconds D
--------------------------------------------------------------------------------
j2_atimeUpdateSymlink 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
j2_dynamicBufferPreallocation
16 16 16 0 256 16K slabs D
--------------------------------------------------------------------------------
j2_inodeCacheSize 400 400 400 1 1000 D
--------------------------------------------------------------------------------
j2_maxPageReadAhead 128 128 128 0 64K 4KB pages D
--------------------------------------------------------------------------------
j2_maxRandomWrite 0 0 0 0 64K 4KB pages D
--------------------------------------------------------------------------------
j2_metadataCacheSize 400 400 400 1 1000 D
--------------------------------------------------------------------------------
j2_minPageReadAhead 2 2 2 0 64K 4KB pages D
--------------------------------------------------------------------------------
j2_nPagesPerWriteBehindCluster
32 32 32 0 64K D

AIX Performance ● Ramón Barrios Lascar ® Ínodo 129

 --------------------------------------------------------------------------------
j2_nRandomCluster 0 0 0 0 64K 16KB clusters D
--------------------------------------------------------------------------------
j2_recoveryMode 1 1 1 0 1 boolean D
--------------------------------------------------------------------------------
j2_syncPageCount 0 0 0 0 64K 4KB pages D
--------------------------------------------------------------------------------
j2_syncPageLimit 16 16 16 1 64K iterations D
--------------------------------------------------------------------------------
lvm_bufcnt 9 9 9 1 64 128KB/buffer D
--------------------------------------------------------------------------------
maxpgahead 8 8 8 0 4K 4KB pages D
--------------------------------------------------------------------------------
maxrandwrt 0 0 0 0 2G-1 4KB pages D
--------------------------------------------------------------------------------
numclust 1 1 1 0 2G-1 16KB/cluster D
--------------------------------------------------------------------------------
numfsbufs 196 196 196 1 2G-1 M
--------------------------------------------------------------------------------
pd_npages 64K 64K 64K 1 512K 4KB pages D
--------------------------------------------------------------------------------
posix_aio_active 0 0 boolean S
--------------------------------------------------------------------------------
posix_aio_maxreqs 64K 64K 64K 4K 1M numeric D
--------------------------------------------------------------------------------
posix_aio_maxservers 30 30 30 1 20000 numeric D
aio_minservers
--------------------------------------------------------------------------------
posix_aio_minservers 3 3 3 0 20000 numeric D
aio_maxservers
--------------------------------------------------------------------------------
posix_aio_server_inactivity
300 300 300 1 86400 seconds D
--------------------------------------------------------------------------------

n/a means parameter not supported by the current platform or kernel

Parameter types:
S = Static: cannot be changed
D = Dynamic: can be freely changed
B = Bosboot: can only be changed using bosboot and reboot
R = Reboot: can only be changed during reboot
C = Connect: changes are only effective for future socket connections
M = Mount: changes are only effective for future mountings
I = Incremental: can only be incremented
d = deprecated: deprecated and cannot be changed

Value conventions:
K = Kilo: 2^10 G = Giga: 2^30 P = Peta: 2^50
M = Mega: 2^20 T = Tera: 2^40 E = Exa: 2^60

Cuando se usa con la conveniente opción L lista todos los parámetros no restringidos
con, mostrando diversas columnas:
! Name Nombre del parámetro del despachador.
! CUR Valor actual del parámetro

AIX Performance ● Ramón Barrios Lascar ® Ínodo 130

 ! DEF Valor predeterminado del mismo
! BOOT Valor que tomará al próximo inicio del sistema
! MIN Valor mínimo aceptable para el parámetro
! MAX Valor máximo aceptable para el parámetro
! UNIT Descripción de la unidad de medida del parámetro
! TYPE Como lo describe abajo, si el parámetro es estático/no cambiable
(S), si es dinámico/cambiable en línea (D), si sólo lo toma al
recrear la copia del núcleo en el volumen de carga del sistema
operativo hd5 (B), si necesita un reinicio (R), si lo toma en la
próxima conexión de un usuario (C), si lo toma en el próximo
montaje de un sistema de archivos (M), si sólo lo toma si el
parámetro se aumenta (I), si está despreciado y no debe
cambiarse (d).
! DEPENDENCES Lista otros atributos que afecten el rango real del valor del
parámetro (tal vez deba ser mayor o deba ser menor que los
parámetros listados como dependencias).
Para cambiar cualquier parámetro se usa ioo -o parámetro=valor, que tomará si el
parámetro es dinámico (D). Ahora, los cambios hechos así se pierden al reiniciar el
sistema, a menos que se “vuelvan” permanentes con schedo -p -o parámetro=valor.
Ejemplo #2a:
[0 root@AIX1:/] ioo -o lvm_bufcnt
lvm_bufcnt = 9
[0 root@AIX1:/] ioo -o lvm_bufcnt=33
Setting lvm_bufcnt to 33
[0 root@AIX1:/] ioo -L lvm_bufcnt
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
lvm_bufcnt 33 9 9 1 64 128KB/buffer D
--------------------------------------------------------------------------------
[0 root@AIX1:/] ioo -po lvm_bufcnt=33
Setting lvm_bufcnt to 33 in nextboot file
Setting lvm_bufcnt to 33
[0 root@AIX1:/] schedo -L sched_R
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
lvm_bufcnt 33 9 33 1 64 128KB/buffer D
--------------------------------------------------------------------------------
En este ejemplo revisamos el parámetro lvm_bufcnt, lo cambiamos dinámicamente —
cambio que recibe porque el parámetro es de tipo D— y como no deseamos que se pierda
el cambio lo dejamos permanente con ioo -p -o lvm_bufcnt=33.
Si se revisa el archivo /etc/tunables/nextboot se encontraría el efecto:

AIX Performance ● Ramón Barrios Lascar ® Ínodo 131

 Ejemplo #2b:
[0 root@AIX1:/] tail -n3 /etc/tunables/nextboot

ioo:
lvm_bufcnt = "33”

AIX Performance ● Ramón Barrios Lascar ® Ínodo 132

Conceptos de Desempeño de AIX: Manejador de Archivos de
AIX
Manejador Unificado de Archivos de AIX
El manejador de archivos de AIX trata de ser lo más unificado posible aunque no lo es,
pero tiene dos conceptos muy clave en su funcionamiento:
! Todo archivo referenciado —mirado, leído, escrito— tiene una estructura de
control, que comúnmente copia toda la información del ínodo en un caché fijo
en RAM —pinned—, de manera que esta información sea de fácil y rápido
acceso.
! Todo archivo usado —leído o escrito— donde no se prohiba es copiado poco a
poco a RAM, de manera que los siguientes usos sean fáciles y de rápido
acceso.
Cuando se hace referencia a un archivo, el mismo hay que buscarlo por nombre a través
de los diferentes directorios en los diferentes sistemas de archivos montados. Cuando se
le encuentra, la información de cómo usarlo, en especial los contenidos del ínodo por
donde se encontró —y algo más— son copiados a un caché central en RAM fija. Esta
información será usada indirectamente por cada aplicación, proceso e hilo que intente
trabajar el archivo —indirectamente a menos que se use la función stat()—. Para evitar
corrupciones, normalmente una aplicación —también indirectamente— obtiene un
“spin lock” sobre la estructura referenciadora del ínodo en RAM y luego sí accede a los
bloques de memoria que contienen copias de los contenidos del archivo. En la mayoría
de los casos, este “spin lock” es inevitable pero es de acceso muy rápido, a menos que
muchísimos hilos intenten usar los mismos archivos —cosa que solo se presenta en
servicios multitarea muy específicos como servidores web y servidores de bases de
datos—. Es posible “relajar” el uso de los “spin locks” cuando se trabajan archivos JFS2 a
través de parámetros globales de JFS2 o del montaje de sistemas de archivos
individuales en modo CIO.
Por otro lado, cuando se usa un archivo, a menos que la aplicación lo haga usando
open() o fopen() con la bandera O_DIRECT, el mismo se va copiando a RAM poco a poco,
inicialmente de a páginas —como siempre de 4KB— y poco a poco de a múltiples páginas,
hasta un límite configurable. De esta manera todos los archivos comunes que se usen en
AIX son copiados a RAM —es decir que en AIX todos los usos normales de archivos son
“memory mapped”—, y ocupan mucho espacio en esta. AIX va copiando los archivos a
RAM que marca según sea el origen —tipo de sistema de archivos que los contiene—: los
archivos en JFS se copian a RAM que se marca PERManent o PERSistent —es lo mismo—,
los archivos en JFS2 se copian a RAM que se marca CLNT (cliente) —aunque JFS2 se
considera un external pager y no un client pager—, y los archivos en NFS se copian
también a RAM que se marca CLNT. Lo más importante aquí es que AIX no desocupa esa
RAM inmediatamente deje de usarse el archivo, con la premisa de que si se usó
recientemente es muy probable que se vuelva a usar nuevamente. Cuando AIX necesite

AIX Performance ● Ramón Barrios Lascar ® Ínodo 133

 la RAM para otros usos, como la va asignando en bloques de 4KB es posible que vaya
“robando” bloques de RAM que contienen copias de archivos que han sido usados, pero
va robando también de a 4KB en 4KB —y con ello un archivo recientemente usado de
100MB es posible que tenga todo menos unas cuantas porciones de 4KB en RAM, o que
sólo queden del mismo unas cuantas porciones de 4KB en la misma—.
Para obtener el mejor desempeño en las operaciones de I/O de archivos entonces lo
preferible es tener muchísima RAM en el servidor, así cuando se use un archivo se copia
a RAM y hay menos probabilidades de que no esté en un subsecuente uso,
independientemente de si el último uso fue reciente o lejano. Ahora, varios factores nos
afectarán aquí:
! AIX tiene unos parámetros que definen cómo son las operaciones a bajo nivel,
por debajo de los archivos, mismos que se mencionaron en temas pasados.
! AIX tiene unos parámetros que definen cuánta porción de la RAM mínimo y
máximo se pueden usar para copiar archivos JFS y cuánta para archivos JFS2
y NFS.
! AIX tiene parámetros que definen cómo detectar lecturas secuenciales,
independientes para JFS y JFS2, pero con las mismas ideas. También tiene
parámetros de cómo proseguir cuando el núcleo ya detectó que unos archivos
se usan de manera secuencial.
! AIX tiene parámetros que definen si y cómo se guardan los cambios en los
archivos que se están escribiendo de manera secuencial, independientes para
JFS y JFS2, pero con las mismas ideas.
! AIX tiene parámetros que definen si y cómo se guardan los cambios en los
archivos que no se usen de manera secuencial —lo que en inglés se dice
random writes—.
Hay que recordar que lo que se escriba en un archivo NFS se enviaría por red y los
parámetros de I/O a archivos del servidor son los que afectarían en ese caso; en cambio,
si lo que se escribe es un archivo JFS y/o JFS, nos afectarán además de los parámetros
que veremos en este capítulo, los parámetros de otros temas, en particular los de I/O a
bajo nivel —parámetros de discos, colas y adaptadoras—.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 134

Monitoreo de Desempeño de AIX: Manejador de Archivos de
AIX
Cuando se hace monitoreo del desempeño y las estadísticas de I/O a archivos debemos
tener en cuenta que los comandos son archivos, y que los comandos necesitan RAM para
capturar información y para hacer los reportes, tal vez los comandos generen archivos
reportes, por lo que todo lo que hagamos afectará en algo los resultados.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 135

AIX Performance ● Ramón Barrios Lascar ® Ínodo 136
Monitoreo de Desempeño del Manejador de Archivos de AIX:
Comandos
Comando vmstat -v
Aunque el comando vmstat ya lo hemos mencionado, seguirá usándose con otra sintaxis,
vmstat -v, para obtener estadísticas del trabajo y la eficiencia del caché de archivos (los
primeros ejemplos, para ubicarnos en un contexto, no son vmstat -v).
Ejemplo:
# vmstat -w 5 3

System configuration: lcpu=20 mem=524288MB

kthr memory page faults cpu

------- --------------------- ------------------------------------ ------------------ -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
1 0 48218922 85936234 0 0 0 0 0 0 5 799 361 1 4 95 0
1 0 49290138 84865017 0 0 0 0 0 0 28 5475 483 1 4 95 0
1 0 50352432 83802722 0 0 0 0 0 0 29 5801 478 1 4 95 0

En este caso, se trata de un servidor que no tiene problemas de I/O, en parte por lo
grande del espacio de memoria que tiene para trabajar. Se encuentra, por ejemplo, que la
columna wa (o %iowait en otros comandos estadísticos) se mantiene muy bajo.
Ejemplo:
root@pmundial:/>vmstat -w 20 20

System configuration: lcpu=4 mem=7936MB

kthr memory page faults cpu

------- --------------------- ------------------------------------ ------------------ -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
2 0 1931903 56332 0 0 0 0 0 0 1227 7146 4612 28 8 25 39
1 0 1933022 55130 0 0 0 0 0 0 1103 7401 4288 25 8 27 40
1 0 1932644 55444 0 0 0 0 0 0 1140 5768 3771 52 6 10 31
1 0 1932644 55371 0 0 0 0 0 0 1395 7854 5031 30 9 20 40
2 0 1932643 55328 0 0 0 0 0 0 1281 7148 4650 28 8 24 41
1 0 1932643 55297 0 0 0 0 0 0 1188 6858 4737 22 8 32 39
1 0 1932643 55246 0 0 0 0 0 0 1162 6940 4570 23 8 29 40
1 0 1932643 55189 0 0 0 0 0 0 1022 6533 4005 19 8 34 40
2 0 1932641 55137 0 0 0 0 0 0 1009 6203 3978 22 7 30 40
1 0 1932643 55112 0 0 0 0 0 0 1255 8063 5257 22 9 31 38
1 0 1932654 55053 0 0 0 0 0 0 1488 10513 6509 18 12 32 38
1 0 1932654 54994 0 0 0 0 0 0 2166 15562 9487 16 18 30 35
1 0 1932653 54942 0 0 0 0 0 0 2026 12831 8353 24 15 27 35
1 0 1932651 54891 0 0 0 0 0 0 2359 14677 9519 24 17 26 34
1 0 1932653 54838 0 0 0 0 0 0 2613 15446 10281 23 19 25 33
1 0 1932656 54784 0 0 0 0 0 0 3139 17941 11017 41 20 12 28
2 0 1932651 54733 0 0 0 0 0 0 2345 11438 7529 66 12 4 18
1 0 1932650 54677 0 0 0 0 0 0 1796 9655 6536 41 11 16 33
1 0 1932648 54623 0 0 0 0 0 0 1644 9935 6316 22 12 30 37
2 0 1932646 54602 0 0 0 0 0 0 1392 8076 5347 20 9 32 39

AIX Performance ● Ramón Barrios Lascar ® Ínodo 137

 Este otro servidor tiene serios problemas de desempeño que se pueden notar, aunque
también se nota que no está paginando, así que otros parámetros pueden ser los que
estén afectando.
Para investigar más en servidores como éste —donde no parece haber escasez de RAM—
también se puede usar otra sintaxis de vmstat.
Ejemplo:
sybase@sise15prod:tempdb/> vmstat -v
28573696 memory pages
27720800 lruable pages
24136529 free pages
4 memory pools
1368417 pinned pages
80.0 maxpin percentage
4.0 minperm percentage
94.0 maxperm percentage
9.6 numperm percentage
2671149 file pages
0.0 compressed percentage
0 compressed pages
9.6 numclient percentage
90.0 maxclient percentage
2671149 client pages
0 remote pageouts scheduled
0 pending disk I/Os blocked with no pbuf
0 paging space I/Os blocked with no psbuf
2228 filesystem I/Os blocked with no fsbuf
0 client filesystem I/Os blocked with no fsbuf
0 external pager filesystem I/Os blocked with no fsbuf
6.2 percentage of memory used for computational pages
Con esta sintaxis nos interesan las líneas que dicen “blocked”:
! Las líneas “pending disk I/Os blocked...” nos indican que los parámetros de
pbufs que usan los grupos de volúmenes son insuficientes —aquí no—.
! Las líneas “paging space I/Os blocked...” nos indican que la cantidad de
espacios de paginación es muy pequeña —o se pagina mucho—, en este
ejemplo eso no se da.
! Las líneas “filesystem I/Os blocked...” nos indican que los parámetros de
fsbufs usados para operaciones de I/O sobre archivos JFS son insuficientes.
Aquí nos están afectando.
! Las líneas “cliente filesystem I/Os blocked...” nos indican que los
parámetros de fsbufs usados para operaciones de I/O sobre archivos NFS son
insuficientes —aquí no se da—.
! Las líneas “external pager filesystem I/Os blocked...” nos indican que los
parámetros de fsbufs usados para operaciones de I/O sobre archivos JFS2
son insuficientes —aquí no se da—.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 138

 Cuando los pbufstructs que se usan para todos los volúmenes físicos están siendo
insuficientes, deberá revisarse la conveniencia de ajustar el parámetro pv_min_pbuf (con
el comando lvmo).
Cuando los psbufstructs que se usan para todos los espacios de paginación están siendo
suficientes, deberá revisarse la conveniencia de tener más espacios de paginación
individuales, independientemente del tamaño y espacio actual —o buscar la manera de
que el servidor pagine menos—.
Cuando los fsbufstructs que se usan para JFS están siendo insuficientes, deberá
revisarse la conveniencia de ajustar el parámetro numfsbufs en el núcleo (con el
comando ioo).
Cuando los fsbufstructs que se usan para JFS2 están siendo insuficientes, deberá
revisarse la conveniencia de ajustar el parámetro j2_nBufferPerPagerDevice en el núcleo
(con el comando ioo)

AIX Performance ● Ramón Barrios Lascar ® Ínodo 139

AIX Performance ● Ramón Barrios Lascar ® Ínodo 140
 Comando svmon
El comando svmon se usa para obtener todo tipo de estadísticas en el uso de la RAM. En
este caso nos interesa conocer los valores del uso de la RAM que funciona como caché de
archivos: la que se usa de tipo PERM o PERS y la que se usa de tipo CLNT.
Ejemplo:
# svmon -G -O unit=GB
Unit: GB
--------------------------------------------------------------------------------------
size inuse free pin virtual available mmode
memory 512.00 352.82 159.18 51.6 352.58 159.14 Ded
pg space 906.00 0.67

work pers clnt other

pin 36.6 0 0.01 15.0
in use 352.58 0 0.24

Lo de arriba nos muestra la salida del comando svmon -G, que resume el uso global. Con
la sintaxis del ejemplo, se le solicitó que no muestre los indicadores en unidades de
páginas de 4KB como es predeterminado si no en GB, siendo un servidor grande.
Resaltamos:
! El servidor se configuró con 512GB de RAM, como muestra la intersección de
la línea memory con la columna size.
! El servidor no tiene RAM marcada como pers, lo que indica que no tiene
sistemas de archivos JFS.
! El servidor sólo usa 0.24GB para archivos JFS2, que clasifica como memoria
clnt, es decir que prácticamente no usa caché.

Este es un ejemplo de un servidor de aplicaciones (por ejemplo WAS o JBoss, etc) o de

bases de datos transaccionales en raw devices (por ejemplo DB2 UDB, Oracle, Sybase
DS). Este servidor no está completamente configurado o en completo funcionamiento,
ya que tiene casi 160GB de RAM sin usar —completamente desperdiciada—.
Ejemplo:
root@s28intdb01(/)#svmon -G -O unit=MB
Unit: MB
--------------------------------------------------------------------------------------
size inuse free pin virtual available mmode
memory 98304.00 97309.12 994.88 10467.52 64609.89 26229.07 Ded
pg space 16384.00 229.55

work pers clnt other

pin 7458.57 0 147.02 2861.94
in use 64609.89 0 32699.23
Este es un servidor un poco “mas normal”, como se pueden observar los indicadores:
! Tiene 98304MB de RAM totales (96GB exactos)

AIX Performance ● Ramón Barrios Lascar ® Ínodo 141

 ! Tiene 994.88MB de RAM real libre (0.97GB libres), menos del 1%.
! Tiene el equivalente a casi 32GB (32699.23MB) de RAM dedicada a caché de
archivos JFS2 y NFS, 1/3 de la RAM de la máquina.
! Tiene el equivalente a casi 63GB (64609.89MB) de RAM dedicada a uso normal
de procesos.
Esta es una máquina con funcionamiento y parametrización adecuada cuando se trata
de un servidor de aplicaciones (por ejemplo WAS, JBoss, etc) o un servidor de bases de
datos transaccionales (DB2 UDB, Oracle, etc).

AIX Performance ● Ramón Barrios Lascar ® Ínodo 142

 Comando filemon
El comando filemon aunque el nombre no lo indique, permite obtener estadísticas de la
actividad de volúmenes físicos, volúmenes lógicos, espacios de paginación y archivos.
En este apartado nos interesa ver la actividad de archivos (archivos lógicos en la
documentación de este comando).
Ejemplo:
p520vm01[/] > filemon -o [Link] -O all

Run trcstop command to signal end of trace.

Fri Aug 12 [Link] 2011
System: AIX 7.1 Node: p520vm01 Machine: 00F604884C00
p520vm01[/] > trcstop

p520vm01[/] > cat [Link]

Fri Aug 12 [Link] 2011
System: AIX 7.1 Node: p520vm01 Machine: 00F604884C00
Cpu utilization: 72.8%
Cpu allocation: 100.0%

21947755 events were lost. Reported data may have inconsistencies or errors.

Most Active Files

------------------------------------------------------------------------
#MBs #opns #rds #wrs file volume:inode
------------------------------------------------------------------------
0.4 1 101 0 unix /dev/hd2:82241
0.0 9 10 0 vfs /dev/hd4:9641
0.0 4 6 1 [Link]
0.0 3 6 2 [Link] /dev/hd2:111192
0.0 1 2 0 [Link] /dev/hd2:110757
0.0 45 1 0 null
0.0 1 1 0 [Link] /dev/hd2:110827
0.0 9 2 0 SWservAt /dev/hd4:9156
0.0 1 0 3 [Link]
0.0 9 2 0 [Link] /dev/hd4:9157

Most Active Segments

------------------------------------------------------------------------
#MBs #rpgs #wpgs segid segtype volume:inode
------------------------------------------------------------------------
0.1 2 13 8359ba client

Most Active Logical Volumes

------------------------------------------------------------------------
util #rblk #wblk KB/s volume description
------------------------------------------------------------------------
0.04 0 32 0.3 /dev/hd9var /var
0.00 0 48 0.5 /dev/hd8 jfs2log
0.00 0 8 0.1 /dev/hd4 /

Most Active Physical Volumes

------------------------------------------------------------------------
util #rblk #wblk KB/s volume description
------------------------------------------------------------------------

AIX Performance ● Ramón Barrios Lascar ® Ínodo 143

 0.00 0 72 0.7 /dev/hdisk0 N/A

Most Active Files Process-Wise

------------------------------------------------------------------------
#MBs #opns #rds #wrs file PID(Process:TID)
------------------------------------------------------------------------
0.0 3 6 0 [Link] 7667828(ksh:9437345)
0.0 1 2 0 [Link] 7667828(ksh:9437345)
0.0 1 0 3 [Link] 7667828(ksh:9437345)
0.0 1 0 1 [Link] 7733344(ksh:7405633)
0.4 1 101 0 unix 7667830(ksh:9437347)
0.0 1 2 0 [Link] 7667830(ksh:9437347)
0.0 1 2 0 [Link] 7667830(ksh:9437347)
0.0 9 2 0 SWservAt 7667830(ksh:9437347)
0.0 9 2 0 [Link] 7667830(ksh:9437347)
0.0 1 0 0 systrctl 7667830(ksh:9437347)
0.0 44 0 44 null 4325546(slp_srvreg:8585241)
0.0 1 2 2 [Link] 7667826(ksh:23527615)
0.0 1 1 0 [Link] 7667826(ksh:23527615)
0.0 1 1 0 null 7667826(ksh:23527615)
0.0 1 0 0 test 7667826(ksh:23527615)
0.0 8 8 0 vfs 3473482(topasrec:13566119)
0.0 1 0 0 [Link] 3473482(topasrec:13566119)
0.0 1 0 0 CuAt 3473482(topasrec:13566119)
0.0 1 2 0 vfs 2097252(syncd:2490503)
0.0 1 0 0 installable 4260046(java:15073489)

Most Active Files Thread-Wise

------------------------------------------------------------------------
#MBs #opns #rds #wrs file TID(Process:PID)
------------------------------------------------------------------------
0.0 3 6 0 [Link] 9437345(ksh:7667828)
0.0 1 2 0 [Link] 9437345(ksh:7667828)
0.0 1 0 3 [Link] 9437345(ksh:7667828)
0.0 1 0 1 [Link] 7405633(ksh:7733344)
0.4 1 101 0 unix 9437347(ksh:7667830)
0.0 1 2 0 [Link] 9437347(ksh:7667830)
0.0 1 2 0 [Link] 9437347(ksh:7667830)
0.0 9 2 0 SWservAt 9437347(ksh:7667830)
0.0 9 2 0 [Link] 9437347(ksh:7667830)
0.0 1 0 0 systrctl 9437347(ksh:7667830)
0.0 44 0 44 null 8585241(slp_srvreg:4325546)
0.0 1 2 2 [Link] 23527615(ksh:7667826)
0.0 1 1 0 [Link] 23527615(ksh:7667826)
0.0 1 1 0 null 23527615(ksh:7667826)
0.0 1 0 0 test 23527615(ksh:7667826)
0.0 8 8 0 vfs 13566119(topasrec:3473482)
0.0 1 0 0 [Link] 13566119(topasrec:3473482)
0.0 1 0 0 CuAt 13566119(topasrec:3473482)
0.0 1 2 0 vfs 2490503(syncd:2097252)
0.0 1 0 0 installable 15073489(java:4260046)
[Link]: END
Se observa acerca del comando:
! Al mismo debería dársele el nombre de un archivo de reporte con la opción o
nombreReporte. Este se revisa luego con cat o con un editor de texto.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 144

 ! Al comando se le puede dar la opción O (letra O mayúscula) con una regla de lo
que debe monitorear y reportar, si no se da asume -O pv,lv,vm:
‣ O pv monitorea los volúmenes físicos. Se puede usar O pv=5, por
ejemplo, para que sólo reporte los cinco volúmenes físicos más
activos
‣ O lv monitorea los volúmenes lógicos. Se puede usar también O lv=N,
para que reporte los N más activos.
‣ O vm monitorea el uso de los segmentos de memoria virtual. También
se puede usar O vm=N.
‣ O lf monitorea el uso de los archivos comunes. También se puede
usar O lf=N para que reporte los N archivos más activos.
• Se pueden combinar las opciones, separándolas con comas (,): O
pv=3,lv=3,lf monitoreará y reportará los tres discos más activos, los tres
volúmenes lógicos más activos y todos los archivos comunes más activos,
reportando todo de mayor a menor actividad.
• El comando usa un búfer de memoria, y generalmente necesita uno muy
grande —sólo esto puede afectarnos muchísimo los indicadores—. Se
especifica con la opción T númeroBytes. Típicamente es útil un búfer de
1000000 (casi 1MB) o más.

En el ejemplo:
! Nos reporta que el archivo unix, contenido en /dev/hd2 (es decir, /usr), con el
ínodo 82241 es el más activo en MB, con la exhorbitante cantidad de 0.4MB de
actividad (☺︎). Este archivo se abrió una vez —según #opns—, pero se leyó 101
veces —columna #rds—. No tuvo ni una sola escritura —#wrs igual a 0—.
! Nos reporta también que el archivo null, y no reporta donde está contenido.
Normalmente es el dispositivo /dev/null. Este archivo se abrió 45 veces —
según #opns—, se intentó leer una vez —columna #rds— y no se intentó
escribir. Nótese que como es /dev/null, si se intenta leer, el mismo cerrará y
no devuelve nada, y si se intenta escribir, el sistema simplemente descarta lo
que se envíe y no escribe.
! El sistema reporta otros archivos con “alta” actividad también, en orden
descendente.
! Se reportan luego los segmentos de memoria más activos. En el reporte se
muestra que el segmento 8359ba es el más activo, y está marcado de tipo
cliente, lo que concuerda con el uso del caché de archivos JFS2.
! Se reportan a continuación los volúmenes lógicos más activos, de mayor a
menor, indicando que /dev/hd9var, es decir /var, fue el más activo. Incluye las
columnas “tiempo porcentaje de uso”, como fracción de 1.00, parecido a
%tm_act en otras herramientas (util); bloques leídos (#rblk); bloques escritos

AIX Performance ● Ramón Barrios Lascar ® Ínodo 145

 (#wblk); KB por segundo promedio trabajados (KB/s); nombre del volumen
(volume); nombre del sistema de archivos u otra descripción (description).
! Muestra luego los discos más activos, de mayor a menor. En nuestro ejemplo
cuenta que hdisk0 fue el más activo —y el único–. Incluye las columnas
“tiempo porcentaje de uso”, como fracción de 1.00, parecido a %tm_act en
otras herramientas (util); bloques leídos (#rblk); bloques escritos
(#wblk); KB por segundo promedio trabajados (KB/s); nombre del disco
(volume); detalles del disco (description).
! Más adelante muestra los archivos más usados, clasificados por
proceso —sección Most Active Files Process-Wise– y los archivos más
usados, clasificados por hilo de ejecución o thread –sección Most Active
Files Thread-Wise–
! En esas dos últimas secciones reporta de manera semejante:
‣ Cantidad trabajada (#MBs); cantidad de aperturas con open() o fopen()
(#opns); número de operaciones de lectura (#rds); número de
operaciones de escritura (#wrs); nombre del archivo (file); número
de proceso, nombre de proceso, hilo del proceso (PID(Process:TID)).
! Nótese que la cantidad de RAM que puede llegar a necesitar esta
herramienta es muy grande, y la que se asigne por línea de comandos —
opción -T número— se maneja de manera pinned mientras la misma está
en ejecución.
En este comando le interesa al administrador:
! Conocer realmente cuáles son los archivos con más actividad en el
sistema
! Conocer la ubicación lógica de los archivos con más actividad en el
sistema
! Si los archivos que se están usando caben en los límites de caché
impuestos en el sistema
! Conocer si los archivos que más se usen están físicamente bien
ubicados y organizados en el sistema de archivos que los contienen —y
si esos sistemas de archivos también están bien organizados y
ubicados físicamente—.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 146

 Comando Fileplace
El comando fileplace es ráramente usado en un sistema típico AIX, pero tiene sus usos.
Esta herramienta se usa para reportar la ubicación de un archivo en el sistema de
archivos que lo contiene —soporta sólo sistemas de archivos JFS y JFS2 locales—. La
idea es, para los archivos que más se trabajen en un sistema, saber si están almacenados
en una sola secuencia —o en pocas— y si esas secuencias están en orden —o lo más en
orden posible—.
Ejemplo:
# fileplace -pv big1
File: big1 Size: 3554273 bytes Vol: /dev/hd10
Blk Size: 4096 Frag Size: 4096 Nfrags: 868 Compress: no
Inode: 19 Mode: -rwxr-xr-x Owner: hoetzel Group: system
Physical Addresses (mirror copy 1)
----------------------------------
0001584-0001591 hdisk0 8 frags 32768 Bytes, 0.9% 0001040-0001047
0001624-0001671 hdisk0 48 frags 196608 Bytes, 5.5% 0001080-0001127
0001728-0002539 hdisk0 812 frags 3325952 Bytes, 93.5% 0001184-0001995
868 frags over space of 956 frags: space efficiency = 90.8%
3 fragments out of 868 possible: sequentiality = 99.8%
En el ejemplo, se muestra un uso típico:
! La opción p se usa para que muestre el archivo dado —big1— con respecto al
o los discos que lo contienen, así las direcciones son físicas —Physical
Addresses—. Se puede usar la opción l para que muestre el archivo según el
direccionamiento dentro del volumen lógico (sistema de archivos) que lo
contiene.
! La opción v se usa para que muestre los cálculos de eficiencia (space
efficiency) y secuencialidad (sequentiality).

! Se puede incluir la opción i para fileplace también muestre los bloques de

indirección del archivo. Normalmente un archivo que está en pocas
secuencias no tiene uso de bloques de indirección.
En este comando se busca conocer cómo se almacenan los archivos más usados. Se
busca tener archivos que:
! Tengan la menor cantidad de segmentos —oficialmente de extents—. Nuestro
archivo de ejemplo tiene sólo tres extents, por lo que está muy bien ubicado.
! Tengan los segmentos en orden. Nuestro archivo de ejemplo tiene el segundo
segmento en direcciones superiores o posteriores al primero, y el tercer
segmento después del segundo (obviamente del primero también), por lo que
está bien organizado.
! El comando nos muestra que nuestro archivo podría estar en sólo una
secuencia, pero tiene tres, podría ser peor, como tiene 868 fragmentos
(páginas de 4KB en disco), podría tener 868 secuencias. Está muy bien, en solo
tres, que equivalen a una secuencialidad del 99.8%.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 147

 ! El comando nos muestra que nuestro archivo, como tiene 868 fragmentos,
podrían estar todos en secuencia, pero tiene unos 8 fragmentos, un salto de
33 fragmentos, otros 48 fragmentos, un salto de 57 y luego los 812 fragmentos
finales. Tiene una eficiencia en espacio del 90.8%.
AIX soporta defragmentado de los sistemas de archivos, JFS se puede defragmentar
desmontado y JFS2 se puede defragmentar en línea. Pero la herramienta sólo
defragmenta sistemas de archivos completos, y lo que busca es que haya regiones
completas grandes de espacio libre, y no que los archivos estén perfectamente
secuenciados y con eficiencia en espacio perfecta.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 148

Conceptos de Desempeño de Comunicaciones: Redes IP
Redes IP Integradas
Cuando se habla de redes IP en AIX se habla de las comunicaciones integradas con el
núcleo, es decir, de las pilas simultáneas IP (IPv4 e IPv6) que no solo son preinstaladas,
si no que usan hilos de ejecución y páginas de memoria que se consideran como parte
del núcleo del sistema operativo —kernel—. Si queremos obtener el mejor desempeño
en las comunicaciones IP —concentrándonos en este documento en IPv4— tenemos que
manejar dos factores:
! El desempeño general del servidor como un todo, en especial el buen
desempeño de la ejecución de las tareas en la CPU, y el buen desempeño de
los accesos a memoria RAM.
! El flujo directo y sin contratiempos de la información a través de las capas
por las que sube —o baja— la información que se recibe de la red —o se envía
a la red—.
Cuando se habla de redes TCP/IP es muy común mencionar el modelo OSI, que es muy
buena referencia, pero siendo que TCP/IP se desarrolló primero que tal modelo, se
parece pero no cumple exactamente con las capas, funciones y límites del mismo.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 149

 De manera que se pueda visualizar cómo fluye la información de red por los diferentes
niveles se muestra
un diagrama de las
mismas: búfer de envío búfer de recepción
En este diagrama nivel de usuario
nivel de usuario
(user space)
cabe resaltar que (user space) nivel de sistema
nivel de sistema (system space)
cada capa se copia
(system space)
copia

búfer de envío de búfer de recepción

programa como si socket de socket
se comunicara streams datagramas datagramas streams

únicamente con la
capa equivalente cumplimiento
UDP TCP UDP
de MTU en TCP
en el otro extremo
de la
comunicación, así
la capa TCP de cumplimiento
de MTU colade
cola deentrada
entradaIPIP
quien envía se
programa como si
sólo se comunicara
con la capa TCP de forzado de
demultiplexor
MTU en ARP
quien recibe,
aunque en realidad
físicamente se
comunica con la colaTX
cola TXde
de colaRX
cola RXde
de
transmisión recepción
capa transmisión recepción
inmediatamente mbufs mbufs

inferior o DMA DMA

inmediatamente
MTU MTU
superior en la
misma máquina.
Para el caso del
desempeño de AIX, Envío físico recepción física

hay parámetros de Máquina que envía Máquina que recibe

colas y búferes en
los distintos niveles que se grafican.
Prácticamente todas las aplicaciones se comunican usando los protocolos de transporte
TCP o UDP. Cualquiera de estas dos capas funcionan de manera equivalente: reciben la
información de las aplicaciones y la dividen en paquetes de dicho protocolo
(datagramas). Los paquetes son diferentes, en especial los encabezados de los paquetes
son diferentes, y se puede generalizar que UDP es más rápido, pero TCP es más
confiable.
En este capítulo se mencionarán muchas opciones en los diferentes niveles, que
permitirán “optimizar” el funcionamiento de la capa en el servidor, pero los mismos no
se pueden cambiar “alegremente”, ya que pueden —y de hecho lo hacen— el
funcionamiento del servidor en redes en las que interactúan con otros equipos de

AIX Performance ● Ramón Barrios Lascar ® Ínodo 150

 comunicaciones —switches, enrutadores, cortafuegos— y con otros equipos de cómputo
—máquinas clientes y otros servidores—. Lo más probable es que el o los responsables
de los equipos AIX no sean quienes configuran esos otros equipos de red o de cómputo.
Nota: los componentes más importantes de todo el capítulo son las adaptadoras de red.
Son sus adaptadoras de red tarjetas ethernet de 1Gb/s? son tarjetas de 10Gb/s?

Velocidad de Transmisión del Medio Físico

Quizás el principal factor que determina las posibilidades de velocidad y desempeño son
los tipos de interfaces —según la velocidad— que se pueden tener en ethernet. Las redes
ethernet modernas pueden trabajar en velocidades 100Mb/s y 1000Mb/s cuando se
trata del estándar UTP con conectores RJ-45 (conectores realmente llamados 8P8C), esto
es los estándares 100Base-TX y 1000Base-T (históricamente se trabajaba a 10Mb/s
también, estándar 10Base-T, y aún más históricos a 1Mb/s y 5Mb/s sobre otros tipos de
cableado, estándares 10Base2 y 10Base5). Las redes más modernas pueden trabajar a
10Gb/s sobre UTP con conectores RJ-45 según el estándar 10GBase-T, y con diferentes
adaptadoras, conectores y cableados, 1Gb/s sobre fibra 1000Base-SX, 10Gb/s sobre fibra
10GBase-SR, 10GBase-LR, 10GBase-ER, y 10, 20 y 40Gb/s sobre fibra según los
estándares 40GBase-T.
Disponer de interfaces para conectarse a redes de estándares más modernos y más
rápidos obviamente facilita alcanzar mayores velocidades de comunicación sin tener
que manipular mucho los parámetros que aquí se revisaran y monitorearán.

MTU: Unidad Máxima de Transmisión

La unidad máxima de transmisión en ethernet es un parámetro que define cuánto es lo
máximo real que “le cabe” a una trama de red “en el cable”. Debido a cómo se inventó y
evolucionó ethernet, el estándar que más se usa es el “estándar de facto de ethernet”
que no tiene un campo en el cual insertar o registrar la longitud de la trama, por esa
razón, quien recibe una no tiene cómo saber cuánto mide la misma, por lo que siempre
asumirá que mide su MTU y no “la MTU del otro”, ni tampoco que “máximo mide lo de la
MTU, pero de pronto menos”. En AIX se pueden configurar dos tipos de funcionamiento
por adaptador, esos funcionamientos se seleccionan usando sólo uno de los objetos
interfaces que “existen sobre” cada una de las adaptadoras ethernet.
Si una adaptadora ethernet se quiere trabajar con el estándar de facto del mercado se
deberá configurar la interfaz enX correspondiente (es decir en2 para la adaptadora ent2),
y con esto se obviará el campo tamaño de cada trama, y todas se generarán con el
tamaño MTU sin importar la carga a enviar.
Si una adaptadora ethernet se quiere trabajar con el estándar oficial ethernet IEEE 802.3
se deberá configurar la interfaz etX correspondiente (es decir et2 para la adaptadora
ent2), y con esto se incluirá el campo tamaño de cada trama, y se generará con el tamaño
justo, notándose que en la posición del tamaño de las tramas etX va el campo VLANID de
las tramas enX y por tanto no son ni intercambiables ni compatibles. Cada puerto de
adaptadora AIX sólo puede trabajar de una sola manera (o enX o etX pero no las dos).

AIX Performance ● Ramón Barrios Lascar ® Ínodo 151

 Windows hasta hace muy poco sólo podía trabajar las tramas al estilo enX y por ello el
otro tipo de transmisión ethernet en AIX no se usa.
Una manera de optimizar las transmisiones en ciertos tipos de protocolos —en especial
los de transmisión o acceso remoto a archivos— es ampliando la carga que puede llevar
una trama ethernet. Como los encabezados de las tramas no son obviables, y ráramente
llevan información descartable, la manera de lograr esto es ampliando la trama
completa. Si en ethernet se usan tramas más grandes de 1500B, se dice que se usan
“tramas jumbo” (jumbo frames), que son las de cualquier número superior, pero que
típicamente son de 4500B, 8000B o 9000B por trama, siendo lo más común este último
número, 9000B.
Ahora, mirando lo que se explicó con las redes que siguen el estándar del mercado, será
necesario que estén de acuerdo las máquinas que envían y que reciben, por lo que
ambas deberán trabajar exactamente el mismo valor; y típicamente también el switch —
si es inteligente o administrable— al mismísimo valor. Cuando la máquina que recibe
está en una subred IP diferente, se asume que es una red ethernet diferente y ahí no es
necesario que tengan el mismo valor, pero deberá haber un equipo enrutador intermedio
que en cada subred cumpla con los requerimientos de tramas y demás.
Nota: otras redes IEEE 802 tienen diferentes encabezados y diferentes tamaños, sin
inconvenientes porque las comunicaciones entre un equipo ethernet y uno de otro tipo
deben hacerse a través de un enrutador que tenga los dos tipos de interfaces. Como dato
aparte las redes TokenRing manejan un MTU predeterminado de 17914 —a partir de
velocidades de 100Mb/s— y las FDDI MTU de 4352.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 152

Monitoreo de Desempeño de Redes: IP
Existen tal vez dos cosas que se pueden monitorear para conocer el buen o mal
desempeño en redes IP:
! Buen funcionamiento y eficiencia a la hora de transmitir —y aquí afectan
muchísimo las posibilidades de quien recibe en el otro extremo de la interfaz:
el switch y la máquina contraparte—
! Buen funcionamiento y eficiencia a la hora de recibir —y aquí afectan
muchísimo que haya disponibilidad de RAM para almacenar lo que llega y
que haya CPU para procesar eso que físicamente se recibió—.
Ahora, como las diferentes capas del modelo de redes IP —sobre ethernet, como es más
común— tienen cada una encabezados que procesar y agregar —o procesar y remover
cuando se recibe—, el sólo hecho de monitorear, siendo la ejecución de más comandos
afectará el desempeño, aunque hay herramientas integradas muy livianas y
herramientas integradas que perturban mucho más.
Antes de enfocarnos a monitorear y optimizar los componentes de red primero hay que
preocuparse por monitorear el uso de CPU —y optimizarlo si es el caso— y monitorear el
uso de RAM —y también optimizarlo si es el caso—. Optimizar la red es más complejo,
más esotérico, y más variable, y los requisitos son esos dos mencionados. Ajústelos
primero.
Como siempre, antes de poder analizar números estadísticos cuando se reportan
problemas de desempeño, o cuando se quiere optimizar el desempeño, tenga una línea
base comparativa, es decir tenga un juego de estadísticas iniciales de red.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 153

AIX Performance ● Ramón Barrios Lascar ® Ínodo 154
Monitoreo de Redes IP: Comandos
Comando netstat -i
Tal vez el comando más a la mano cuando se quieren obtener estadísticas básicas es
netstat. Este comando tiene muchos modos de ejecución según los switches que se
usen, pero en general no es tan “de estadísticas de desempeño” como lo son iostat o
vmstat. Cuando se usa con la opción i —interfaces—, muestra información muy básica.

Ejemplo:
root@banasyb068:/> netstat -in
Name Mtu Network Address ZoneID Ipkts Ierrs Opkts Oerrs Coll
en5 1500 link#2 0.14.5e.74.6e.5f - 1576179 0 483963 3 0
en5 1500 172.19 [Link] - 1576179 0 483963 3 0
en6 1500 link#3 0.14.5e.75.d4.38 - 4063806832 0 2768209186 3 0
en6 1500 2.2.2 [Link] - 4063806832 0 2768209186 3 0
en6 1500 [Link] [Link] - 4063806832 0 2768209186 3 0
en7 1500 link#4 0.14.5e.75.d7.d - 25864372 0 2615008215 3 0
en7 1500 3.3.3 [Link] - 25864372 0 2615008215 3 0
en7 1500 [Link] [Link] - 25864372 0 2615008215 3 0
en1* 1500 link#5 0.14.5e.75.d4.39 - 0 0 0 0 0
et1* 1492 link#6 0.14.5e.75.d4.39 - 0 0 0 0 0
et5* 1492 link#7 0.14.5e.74.6e.5f - 0 0 0 0 0
et6* 1492 link#8 0.14.5e.75.d4.38 - 0 0 0 0 0
et7* 1492 link#9 0.14.5e.75.d7.d - 0 0 0 0 0
lo0 16896 link#1 - 87975390 0 87979029 0 0
lo0 16896 127 [Link] - 87975390 0 87979029 0 0
lo0 16896 ::1 0 87975390 0 87979029 0 0

La sintaxis básica de netstat incluye una opción que es bastante seguro incluir siempre,
n, que hace que netstat no intente resolver los nombres de máquina (hostnames) ni de
servicios, lo que hará un poquito más complicada de interpretar la salida, pero evitará
tráfico adicional y en general funcionarán los reportes mucho más rápido.
Cuando se usa netstat -i:
! Se muestra un reporte puntual —no repetitivo— con los datos acumulados
desde el último momento en que se hayan borrado los indicadores (que como
nunca se hace es desde el último inicio de AIX).
! La primera línea describe las columnas: nombre de cada interfaz (Name),
misma que se mostrará múltiples veces —una por el enlace físico y una por
cada dirección IP que tenga—; tamaño de trama (MTU), enlace o subred a la
que se conecta (Network), dirección física —en la línea del enlace— o dirección
IP —en las otras líneas de la interfaz—(Address); número automático de zona
IPv6 (ZoneID); total de tramas entrantes (Ipkts); total de tramas entrantes con
errores (Ierrs); total de tramas salientes (Opkts); total de tramas con errores
de salida (Oerrs); colisiones (Colls).
! Las siguientes líneas muestran la información de las interfaces, al menos dos
veces cada interfaz activa y configurada: la primera línea de cada interfaz –de

AIX Performance ● Ramón Barrios Lascar ® Ínodo 155

 enlace— muestra datos del puerto “físico” de cada una, siendo en las
interfaces ethernet los datos mínimos del dispositivo entX que se
corresponde con el enX (o etX en los muy raros casos donde se usa). De interés
aquí básicamente es que se muestra la dirección física (la MAC Address) en
formato [Link], donde si un número es 0x lo muestra sólo como x
y no los dos hexadígitos.
! La segunda y demás líneas de cada interfaz muestran la subred a la que se
conecta cada una (no siempre exacta dependiendo de los bits de la máscara
de red) y la dirección IP de la interfaz. Si la interfaz tiene varias direcciones IP
—IP Alias— se mostrarán líneas independientes.
! En este comando AIX no separa las tramas que entran a una interfaz con
múltiples direcciones IP por dirección destino, así que todas las líneas de una
interfaz, con diferentes direcciones muestran los mismos indicadores.
En este comando básicamente podemos revisar:
! Cuántos paquetes han entrado a cada interfaz (ipkts) y cuántos han entrado
con problemas (ierrs). Nótese que si hay muchos paquetes con problemas
(más del 3% de los ipkts son ierrs) se pueden deducir que hay problemas
recibiendo, más a menudo en la máquina que se está revisando.
! Cuántos paquetes han salido por cada interfaz (opkts) y cuántos han tenido
problema al salir (oerrs). Nótese que si hay muchos paquetes con problemas
(más del 3% de los opkts son oerrs) se pueden deducir que hay problemas
enviando, y más a menudo eso es fuera de la máquina que se está revisando.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 156

 Comando netstat -I
Si lo que se necesita es monitorear continuamente —o al menos hacer seguimiento
repetitivo— de una interfaz en particular se puede usar la opción I de netstat. Es
básicamente lo mismo que netstat -i pero especificando sólo una interfaz y pudiendo
ser repetitivo
Ejemplo:
# netstat -I en0 5
input (en0) output input (Total) output
packets errs packets errs colls packets errs packets errs colls
8305067 0 7784711 0 0 20731867 0 20211853 0 0
3 0 1 0 0 7 0 5 0 0
24 0 127 0 0 28 0 131 0 0
CTRL C
Se tiene:
! netstat -I necesita que se de el nombre de una interfaz a reportar

! recibe dos números el primero el tiempo entre muestra y muestra, y el

segundo las veces a reportar. Si no se da el segundo correrá indefinido hasta
que se de cancelar (Ctrl-C).
! Se interpreta así:
‣ Las columnas primera a quinta hacen referencia sólo a la interfaz
seleccionada, en nuestro ejemplo en0, las sexta a décima a todo el AIX
(suma de todas las interfaces).
‣ La primera línea muestra los contadores desde la última vez que se
borraron o desde el inicio de AIX —si nunca se han borrado—.
‣ Las siguientes líneas muestran los contadores en el período (5 segundos
en nuestro ejemplo).
! Se analiza como se mencionó antes: si hay muchos errores entrando lo más
lógico es pensar que hay que ajustar el servidor actual, si hay muchos errores
saliendo habrá que ajustar la red externa —o bajarle el ritmo al servidor
actual—.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 157

AIX Performance ● Ramón Barrios Lascar ® Ínodo 158
 Comando netstat -a
Otro uso del comando netstat es el usarlo para obtener los sockets activos en el sistema,
para ello se usa la opción a (actividad). Como en AIX existen dos tipos de sockets los INET
(o INET6) que son los que se conocen tradicionalmente en otras plataformas y los UNIX
que son locales y sirven para comunicación entre procesos, especialmente en los
equipos UNIX o que cumplen con POSIX, deberá filtrarse siempre si lo que queremos
revisar es la red.
Ejemplo:
root@pmundial:/>netstat-anf inet | egrep (^Proto|LISTEN)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp 0 0 *.21 *.* LISTEN
tcp4 0 0 *.22 *.* LISTEN
tcp4 0 0 *.111 *.* LISTEN
tcp4 0 0 *.657 *.* LISTEN
tcp4 0 0 *.1334 *.* LISTEN
tcp 0 0 *.2049 *.* LISTEN
tcp 0 0 *.6389 *.* LISTEN
tcp4 0 0 *.6389 *.* LISTEN
tcp 0 0 *.7937 *.* LISTEN
tcp 0 0 *.7938 *.* LISTEN
tcp 0 0 *.7953 *.* LISTEN
tcp 0 0 *.8189 *.* LISTEN
tcp 0 0 *.8609 *.* LISTEN
tcp 0 0 *.8894 *.* LISTEN
tcp 0 0 *.9001 *.* LISTEN
tcp 0 0 *.9087 *.* LISTEN
tcp4 0 0 *.9090 *.* LISTEN
tcp 0 0 *.9218 *.* LISTEN
tcp 0 0 *.9662 *.* LISTEN
tcp4 0 0 [Link].32000 *.* LISTEN
tcp4 0 0 *.62759 *.* LISTEN
tcp4 0 0 *.18822 *.* LISTEN
tcp4 0 0 *.18823 *.* LISTEN
tcp4 0 0 [Link].6000 *.* LISTEN
tcp4 0 0 [Link].6001 *.* LISTEN
En el ejemplo se observan varias cosas de la sintaxis:
! Se usa la opción a para reportar los sockets activos —y no numerosas otras
estádísticas que netstat puede mostrar—.
! Para evitar que netstat tenga que hacer resolución de los nombres de
máquinas (hostnames) y de servicios (services) se usa la opción n. Con esto el
reporte es un poquito menos fácil de comprender pero aparecerá mucho más
rápido —y no generará tráfico adicional de red—.
! La opción f permite seleccionar la familia de sockets a reportar. Los de red
son de tipo inet (es decir “de internet”). Con esto se reportan los sockets IP y
encima de IP.
! En el ejemplo usamos grep LISTEN para filtrar del reporte los que dicen
“LISTEN”, que son los de tipo IPv4 TCP o IPv6 TCP que fueron “abiertos” en

AIX Performance ● Ramón Barrios Lascar ® Ínodo 159

 esta máquina con la función bind() o equivalente. Es decir esto lista los
puertos TCP “abiertos” únicamente. No filtra y muestra los “cerrados”, o los
que están en una conexión, o cerrándose o que funcionan sin conexión (como
los UDP).
! Las columnas son:
‣ Protocolo de transporte (Proto) si aparece tcp4 significa sólo TCP
sobre IPv4, si aparece tcp significa TCP sobre IPv4 o IPv6
indistintamente, si aparece udp4 significa UDP sobre IPv4 y si
aparece udp significa UDP sobre IPv4 o IPv6 indistintamente.
‣ Cola de salida (Send-Q), muestra cuántos de los paquetes que
están en cola de salida. Si hay muchos continuamente (más
de un dígito) indicará problemas de transmisión lo que hace
que se acumulen en el servidor y no “salgan”. Deberá
analizarse la infraestructura de comunicaciones o la máquina
contraparte en las comunicaciones. Los sockets en LISTEN
siempre muestran un 0.
‣ Cola de entrada (Recv-Q), muestra cuántos de los paquetes que
están en cola de recepción. Si hay muchos continuamente
(más de un dígito) indicará problemas de recepción –pero sí
fueron recibidos—, lo que comúnmente indica insuficiencia
de CPU en la máquina para procesarlos y pasarlos al proceso
del servicio correspondiente o “dueño” del socket de red.
‣ Dirección local (Local Address), muestra la dirección local donde
está abierto el socket, incluyendo el puerto local, como un
“quinto octeto”. Así, si se abre un socket en el puerto TCPv4
6000 en la interfaz que tiene la dirección [Link] mostrará
[Link].6000. Si se abre “para todas las interfaces”
aparecerá *.númeroPuerto.
‣ Dirección remota (Foreign Address), muestra la dirección remota o
de la contraparte, incluyendo el puerto remoto, como un
“quinto octeto”. Así que una conexión al puerto SSH estándar
del servidor [Link] mostrará [Link].22. Los
sockets en espera o LISTEN siempre muestran *.*
‣ Estado (Status), muestra si el socket está en escucha
(LISTEN), cerrado (CLOSED), abriendo (SYN_SENT), cerrando
(RST_SENT), y la más común, funcionando o establecida
(ESTABLISHED).
Si se quieren ver las actividades de las colas —válido sólo para sockets activos/
conectados— se usaría como en el ejemplo.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 160

 Ejemplo:
p520vm01[/tmp] netstat -af inet | egrep ‘(^Active|^Proto|telnet.*ESTABLISHED)’
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 1028 [Link] [Link].1254 ESTABLISHED
Se puede observar:
! Un truco válido con egrep para que el comando muestre las líneas de título y
encabezado de columnas
! Solamente las líneas con una conexión telnet establecida (ESTABLISHED,
activa).
! Que la conexión entre este servidor (p520vm01) y un cliente de nombre
[Link] va del puerto de cliente 1254 al puerto telnet (TCP/23) del
servidor.
! Que hay 1028 paquetes en cola de salida del servidor. Esta conexión parece
que ese está congestionando al salir del servidor hacia el cliente.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 161

AIX Performance ● Ramón Barrios Lascar ® Ínodo 162
 Comando netstat -m
Siguiendo con los usos de netstat, se menciona ahora la opción m. netstat -m muestra
estadísticas de uso de memoria, detallados por uso y tamaño.
Nótese que en AIX, los paquetes de red se procesan tratando de balancearlos por cada
CPU lógica (es decir los virtuales multiplicados por el valor SMT actual), y que cada CPU
lógica maneja un bloque de memoria (pinned por cierto) para hacer procesamiento de
red, y cada CPU lógica sólo puede procesar red usando la memoria que directamente
maneja —así que no usa la memoria de otra CPU lógica—. El comando netstat -m separa
las estadísticas por cada CPU lógica.
Ejemplo:
p520vm1[/tmp] > netstat -m
Kernel malloc statistics:

******* CPU 0 *******

By size inuse calls failed delayed free hiwat freed
64 566 2015884 0 7 266 5240 0
128 5890 1830085 0 175 158 2620 0
256 5781 651987 0 295 2875 5240 500
512 8000 181192188 0 972 56 6550 0
1024 3165 1889042 0 792 35 2620 0
2048 1071 3387085 0 520 23 3930 0
4096 2056 2775 0 83 5 1310 0
8192 6 260 0 3 163 327 0
16384 256 413 0 62 0 163 0
32768 55 274 0 23 4 81 0
65536 117 175 0 76 0 81 0
131072 4 5 0 0 102 204 0

******* CPU 1 *******

By size inuse calls failed delayed free hiwat freed
64 46 226765 0 0 146 5240 0
128 58 152657 0 2 134 2620 0
256 51 70035 0 2 301 5240 0
512 78 46458768 0 4 66 6550 0
1024 62 171426 0 12 30 2620 0
2048 23 3669503 0 5 25 3930 0
4096 1 891 0 4 9 1310 0
8192 1 567 0 3 306 327 0
16384 0 12 0 5 2 163 0
32768 2 17 0 3 7 81 0
65536 0 11 0 6 0 81 0
131072 0 1 0 0 20 40 0

******* CPU 2 *******

By size inuse calls failed delayed free hiwat freed
64 21 1295 0 1 43 5240 0
128 9 781 0 0 23 2620 0
256 9 1226 0 0 39 5240 0
512 81 36991563 0 10 55 6550 0
1024 27 1241 0 15 33 2620 0
2048 5 3286 0 0 23 3930 0
4096 0 52 0 1 5 1310 0

AIX Performance ● Ramón Barrios Lascar ® Ínodo 163

 8192 0 1 0 1 0 327 0
32768 0 1 0 1 1 81 0
131072 0 0 0 0 16 32 0

******* CPU 3 *******

By size inuse calls failed delayed free hiwat freed
64 42 1224 0 2 86 5240 0
128 15 1195 0 13 401 2620 0
256 12 2607 0 82 1316 5240 0
512 83 36405229 0 222 1733 6550 0
1024 32 1220 0 14 32 2620 0
2048 23 4549 0 260 507 3930 0
4096 1 42 0 3 3 1310 0
8192 0 58 0 7 21 327 0
16384 0 128 0 19 121 163 0
32768 2 29 0 7 22 81 0
65536 0 47 0 24 47 81 0
131072 0 0 0 0 102 204 0
Se puede observar:
! Cuando se procesan paquetes de red los procesa uno de cada core lógico
activo en el AIX. Éste lleva sus propios contadores, que netstat -m muestra,
armando secciones tituladas CPU x, donde x es el número del procesador
lógico.
! Cada CPU lógica usa la memoria en “celdas” llamadas mbuf, tomando de la
RAM de la máquina, según lo que tenga que enviar o recibir, pero siempre en
tamaños potencia de 2. Según lo vaya usando, va actualizando los contadores
por tamaño. Esta RAM se toma de la real libre de la máquina, y se marca
pinned mientras se está usando —así el VMM asigna la memoria a la red, el
subsistema IP la divide en la celda con el tamaño que necesita, la marca
pinned, la usa, la desmarca pinned y la marca libre—.
! Se muestran en la tabla de estadísticas, una sección por cada CPU lógica, con
las mismas líneas y columnas. La columna de títulos de columna, que incluye:
‣ By size que describe el tamaño de la celda o mbuf que se ha usado para
una trama. Siendo tamaños potencia de 2 entre 64 (2^6) y 131072
(2^17).
‣ in use que reporta lo que se está usando en cada tamaño de celda
actualmente, en la CPU lógica que se esté reportando.
‣ calls que reporta el total de veces que se ha usado, en cada tamaño de
celda, en la CPU lógica que se está reportando, desde la última
vez que se borraron las estadísticas o desde el inicio de AIX.
‣ failed que reporta el total de veces que no se pudo conseguir memoria
para crear una celda del tamaño necesario y que se está
reportando, en cada CPU, y desde la última vez que se borraron
las estadísticas o se inició AIX. Se cuentan como fallidos los
llamados de memoria para crear mbufs cuando el socket ha sido

AIX Performance ● Ramón Barrios Lascar ® Ínodo 164

 creado con la bandera de opción M_NOWAIT y no hubo memoria
inmediatamente para esa creación.
‣ delayed que reporta el total de veces que no se pudo inicialmente
conseguir memoria para crear una celda del tamaño necesario y
que se está reportando. Se cuenta cuando el proceso que recibe
abre el socket con la bandera de opción M_WAIT (así que prefiere
esperar a que el llamado para recibir datos falle por falta de
memoria). Igual cuenta desde la última vez que se borraron las
estadísticas o se inició AIX.
‣ free que reporta cuántas celdas se han recién capturado —y se
pueden usar— del tamaño que se está reportando y en la CPU
que se está reportando, desde la última vez que se borraron las
estadísticas o se inició AIX.
‣ hiwat reporta el tamaño máximo de cola de las celdas libres —
determinado automáticamente por AIX— y que si se sobrepasa
deberán devolverse a AIX como liberadas.
‣ freed reporta cuántas, de cada tamaño de celda se han liberado —
porque había más que hiwat— y se retornaron a AIX para su uso
posterior en otras cosas.
En este comando se obtiene información para saber si los límites superiores de la
memoria posible de usar en red (que se marcará CLIENT) son suficientes o insuficientes.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 165

AIX Performance ● Ramón Barrios Lascar ® Ínodo 166
 Comando netstat -D
El comando netstat también puede mostrar las estadísticas diferenciadas por capas.
Para ello se usa la sintaxis netstat -D como se verá a continuación.
Ejemplo:
p520vm1[/tmp] > netstat -D
Source Ipkts Opkts Idrops Odrops
-------------------------------------------------------------------------------
ent_dev1 71306227 337207 0 0
ent_dev0 203313084 82292 0 0
---------------------------------------------------------------
Devices Total 274619311 419499 0 0
-------------------------------------------------------------------------------
ent_dd1 71306227 337207 0 0
ent_dd0 203313084 82292 0 0
---------------------------------------------------------------
Drivers Total 274619311 419499 0 0
-------------------------------------------------------------------------------
ent_dmx1 70327758 N/A 978469 N/A
ent_dmx0 202846759 N/A 466325 N/A
---------------------------------------------------------------
Demuxer Total 273174517 N/A 1444794 N/A
-------------------------------------------------------------------------------
IP 204276236 1063977 899839 828213
IPv6 70588 70588 0 6208
TCP 714368 785630 72 0
UDP 202697468 319900 202172157 0
---------------------------------------------------------------
Protocols Total 407688072 2169507 203072068 828213
-------------------------------------------------------------------------------
en_if1 70327759 337207 0 0
en_if0 202846780 82315 0 0
lo_if0 780891 780890 12 0
---------------------------------------------------------------
Net IF Total 273955430 1200412 12 0
-------------------------------------------------------------------------------
NFS/RPC Client 24 N/A 0 N/A
NFS/RPC Server 0 N/A 0 N/A
NFS Client 279 N/A 0 N/A
NFS Server 0 N/A 0 N/A
---------------------------------------------------------------
NFS/RPC Total N/A 303 0 0
-------------------------------------------------------------------------------
(Note: N/A -> Not Applicable)

Este uso del comando netstat muestra:

! Secciones por diferentes capas: capa de hardware (desde Source hasta
Devices), capa de manejador (hasta Drivers), capa demultiplexor —procesa
los protocolos— (hasta Demuxer), capa de transporte (hasta Protocols), capa
de interfaces (hasta Net IF), y capa NFS y RPC (hasta NFS/RPC). En cada una
muestra una linea por cada elemento, y una línea con totales por cada capa.
! Muestra en cada elemento y cada capa, las siguientes columnas:

AIX Performance ● Ramón Barrios Lascar ® Ínodo 167

 ‣ Nombre (Source) muestra el elemento o capa en cuestión.
‣ Paquetes entrantes (Ipkts) muestra el total de paquetes entrantes
desde que se borraron las estadísticas o se inició AIX.
‣ Paquetes salientes (Opkts) muestra el total de paquetes salientes
desde que se borraron las estadísticas o se inició AIX.
‣ Paquetes descartados entrantes (Idrops) muestra el total de
paquetes entrantes que tocó descartar desde que se borraron
las estadísticas o se inició AIX.
‣ Paquetes descartados salientes (Odrops) muestra el total de
paquetes salientes que tocó descartar desde que se borraron
las estadísticas o se inició AIX.
Como se ha venido mencionando, tener un gran número (del 3% o más) de
paquetes descartados obligará a analizar en cuál de las capas o elemento hay el
problema y revisar si se ajustan los parámetros de cola. Este comando es mucho
más útil que los anteriores vistos, ya que nos permite saber si lo que se deberá
ajustar son los elementos de cola de transmisión en una tarjeta de red o si es el
espacio en la cola de salida a nivel de transporte TCP, por ejemplo.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 168

 Comando ping
El comando ping básicamente se usa para diagnosticar si una máquina es alcanzable a
través de IP. Debido a que es posible y muy fácil configurar dispositivos intermedios
para filtar el protocolo ICMP que usa ping, es probable que aunque ping no de los
resultados esperados, aunque sí haya conectividad. Si el comando ping básico funciona,
el uso aquí mencionado sí funcionará.
Para medir la carga que resiste la pila de comunicaciones IP de una máquina al enviar, y
una destino al recibir —implicando a todos los componentes intermedios— se puede
usar ping flood, es decir ping con la opción f.
Nótese que ping con la opción f necesita de permisos de usuario root.
Ejemplo:
[0 root@AIX1:/] time ping -f -c 100000 -s 1450 aix2
PING [Link]: ([Link]): 1450 data bytes
.
--- [Link] ping statistics ---
100000 packets transmitted, 100000 packets received, 0% packet loss
round-trip min/avg/max = 0/0/4 ms

real 0m11.14s
user 0m0.55s
sys 0m4.74s

Nota 1: Como siempre, si no se da la opción c del comando ping (cuántos paquetes a

enviar), el comando seguirá indefinidamente hasta que se corte con la combinación de
teclas CANCELAR (Cntrl-C).
Este uso aquí mencionado de ping es válido para generar estrés en las comunicaciones y
poder evaluar desempeño.

Cómo se usa Ping Flood?

Cómo se usa:
! Se llevan a cero los contadores de netstat con netstat -Zc; netstat -Zi ;
netstat -Zm; netstat -Zs -p ip; netstat -Zs -p icmp. Estos comandos
borran los contadores generales, de interfaz, de captura de memoria, del
protocolo IP y del protocolo ICMP.
! Se ejecuta un ping -c 10000 -f ServidorDestino. Esto envía a la máxima
rata/velocidad al ServidorDestino un chorro de 10000 paquetes. Deberían
aparecer unos pocos puntos en la pantalla —no caminando o corriendo como
secuencia—.
! Se revisan las estadísticas con netstat -i y/o netstat -D. Tal vez valga la
pena revisarlos con netstat -p icmp y/o netstat -p ip.
! Ajuste de ser necesario.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 169

 Nota 2: Existen algunas herramientas semejantes para hacer el equivalente de ping pero
no usando ICMP si no TCP o UDP. Debido a que no vienen preinstaladas con AIX deberán
instalarse por separado. Una herramienta de código abierto recomendada es tcping —
con una sintaxis semejante pero no igual a ping—. Otra herramienta útil para hacer
conexiones genéricas TCP es NetCat (el comando se llama nc), la que permite en una
máquina dejar en escucha (función bind()) en un puerto al comando, y desde otra
máquina hacer conexión a ése puerto. Se puede usar para hacer transmisiones grandes y
con ello generar carga y tomar mediciones estadísticas.
Nota 3: Una herramienta que sí viene incluida con AIX —y con otros tipos de UNIX— es
spray. La misma se trata de un cliente —el mencionado comando spray— que se
“conecta” por RPC —remote procedure call— a un servidor sprayd (comúnmente sprayd)
y puede enviarle tantos requerimientos “RPC eco” como sean necesarios —al máximo
que resista la infraestructura o con unos tiempos especificados—. AIX incluye ambos, el
cliente spray y el servicio [Link], pero este último debe ser habilitado porque no lo
está de manera predeterminada. Los requerimientos RPC que spray hace los hace sobre
UDP —para mantener un ritmo máximo— por lo que este otro transporte se puede
probar y diagnosticar basados en el uso de la herramienta.

Cómo se usa TCPING?

Ejemplo:
! Se llevan a cero los contadores de netstat con netstat -Zc; netstat -Zi ;
netstat -Zm; netstat -Zs -p ip; netstat -Zs -p tcp. Estos comandos
borran los contadores generales, de interfaz, de captura de memoria, del
protocolo IP y del protocolo TCP.
! Se ejecuta un tcping básico para probar conectividad:
[0 e@Gunther ~] tcping -p80 -c10 -h192.168.1.1
PING [Link]:80
connected to [Link]:80, seq=0 time=3.12 ms
connected to [Link]:80, seq=1 time=7.87 ms
connected to [Link]:80, seq=2 time=5.15 ms
connected to [Link]:80, seq=3 time=35.42 ms
connected to [Link]:80, seq=4 time=3.64 ms
connected to [Link]:80, seq=5 time=3.73 ms
connected to [Link]:80, seq=6 time=2.61 ms
connected to [Link]:80, seq=7 time=245.37 ms
connected to [Link]:80, seq=8 time=2.73 ms
connected to [Link]:80, seq=9 time=2.81 ms
--- [Link]:80 ping statistics ---
10 connects, 10 ok, 0.00% failed
round-trip min/avg/max = 2.6/31.2/245.4 ms
! Si no hay problemas se ejecuta un tcping flood para generar estrés y poder
tomar estadísticas:
[0 e@Gunther ~] tcping -f -p80 -c10000 -h192.168.1.1
PING [Link]:80
connected to [Link]:80, seq=0 time=2.05 ms

AIX Performance ● Ramón Barrios Lascar ® Ínodo 170

 connected to [Link]:80, seq=1 time=2.80 ms
connected to [Link]:80, seq=2 time=4.20 ms
connected to [Link]:80, seq=3 time=3.96 ms
connected to [Link]:80, seq=4 time=2.26 ms
connected to [Link]:80, seq=5 time=4.91 ms
connected to [Link]:80, seq=6 time=1.71 ms
connected to [Link]:80, seq=7 time=2.20 ms
connected to [Link]:80, seq=8 time=4.17 ms
connected to [Link]:80, seq=9 time=3.75 ms
connected to [Link]:80, seq=10 time=2.67 ms
...
connected to [Link]:80, seq=9991 time=2.16 ms
connected to [Link]:80, seq=9992 time=37.21 ms
connected to [Link]:80, seq=9993 time=11.38 ms
connected to [Link]:80, seq=9994 time=7.68 ms
connected to [Link]:80, seq=9995 time=12.17 ms
connected to [Link]:80, seq=9996 time=12.70 ms
connected to [Link]:80, seq=9997 time=13.03 ms
connected to [Link]:80, seq=9998 time=18.44 ms
connected to [Link]:80, seq=9999 time=12.80 ms
--- [Link]:80 ping statistics ---
10000 connects, 10000 ok, 0.00% failed
round-trip min/avg/max = 1.4/7.0/1058.5 ms

! Se revisan las estadísticas con netstat -i y/o netstat -D. Tal vez valga la
pena revisarlos con netstat -p tcp y/o netstat -p ip.
! Ajuste de ser necesario.

Cómo se usa NetCat?

Ejemplo:
! Se llevan a cero los contadores de netstat con netstat -Zc; netstat -Zi ;
netstat -Zm; netstat -Zs -p ip; netstat -Zs -p tcp. Estos comandos
borran los contadores generales, de interfaz, de captura de memoria, del
protocolo IP y del protocolo TCP.
! Se ejecuta un netcat básico con para probar conectividad.
‣ En el “servidor” se usa netcat con un puerto seleccionado y libre:
[0 root@Server ~] nc -l 1975

‣ En el “cliente” se usa netcat apuntando al servidor y puertos

seleccionados en la máquina “servidor”
[0 e@Gunther ~] echo Prueba de Conectividad | nc [Link] 1975

‣ Si se revisa la máquina “servidor” original deberá aparecer el mensaje

enviado.
[0 root@Server ~] nc -vl 1975
Prueba de Conectividad

! Se ejecuta la prueba de estrés. Para ello se vuelve a ejecutar netcat en el

“servidor”:
[0 root@Server ~] nc -l 1975 > /dev/null

AIX Performance ● Ramón Barrios Lascar ® Ínodo 171

 ! Desde el cliente se envía un archivo grande al servidor y puerto seleccionado,
de ser posible midiendo los tiempos:
[0 e@Gunther ~] dd if=/dev/zero bs=512 count=2048 | time nc [Link] 1975
2048+0 records in
2048+0 records out
1048576 bytes transferred in 0.009671 secs (108425080 bytes/sec)
0.01 real 0.00 user 0.00 sys
! Se revisan las estadísticas con netstat -i y/o netstat -D. Tal vez valga la
pena revisarlos con netstat -p tcp y/o netstat -p ip.
! Ajuste de ser necesario.

Cómo se usa spray?

Ejemplo:
! Se llevan a cero los contadores de netstat con netstat -Zc; netstat -Zi ;
netstat -Zm; netstat -Zs -p ip; netstat -Zs -p udp. Estos comandos
borran los contadores generales, de interfaz, de captura de memoria, del
protocolo IP y del protocolo UDP.
! Se habilita el servicio sprayd en otra máquina:
[0 root@AIX2:/] lssrc -ls inetd | egrep '^Subsystem|inetd|spray'
Subsystem Group PID Status
inetd tcpip 3735676 active
[0 root@AIX2:/] cp /etc/[Link] /etc/[Link]
[0 root@AIX2:/] sed 's/.\(sprayd.*\)/\1/g' /etc/[Link] > /etc/
[Link]
[0 root@AIX2:/] lssrc -ls inetd | egrep 'Subsystem|inetd|sprayd'
Subsystem Group PID Status
inetd tcpip 3735676 active
sprayd /usr/lib/netsvc/spray/[Link] sprayd 100012 1 active

! Se ejecuta la prueba de estrés:

[0 root@AIX1:/] time spray aix2
sending 1162 packets of length 86 to
aix2 ...

290 packets (24.957%) dropped by aix2

93834 packets/second, 8069729 bytes/second

real 0m0.13s
user 0m0.00s
sys 0m0.01s
En nuestro ejemplo deberían ajustarse algunos parámetros, ya que hubo demasiadas
pérdidas (casi el 25% de lo enviado) en la prueba de estrés.
! Debido a que no se necesita permanentemente, se deshabilita nuevamente el
servicio en la otra máquina:
[0 root@AIX2:/] cp /etc/[Link] /etc/[Link]
[0 root@AIX2:/] refresh -s inetd
0513-095 The request for subsystem refresh was completed successfully.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 172

 [0 root@AIX2:/] lssrc -ls inetd | egrep 'Subsystem|inetd|sprayd'
Subsystem Group PID Status
inetd tcpip 3735676 active

AIX Performance ● Ramón Barrios Lascar ® Ínodo 173

AIX Performance ● Ramón Barrios Lascar ® Ínodo 174
 Comando host
El comando host es una herramienta incluida con el sistema operativo que se usa
básicamente para hacer diagnósticos de resolución de nombres de máquina
(hostnames), pero debido a que algunas situaciones de conectividad que pueden
parecer de desempeño de redes realmente pueden ser de desempeño de las librerías de
cliente de resolución de nombres, pues se incluye aquí.
Ejemplo:
[0 root@AIX2:/] time host aix3
[Link] is [Link], Aliases: AIX3

real 0m0.20s
user 0m0.00s
sys 0m0.00s
[0 root@AIX2:/] echo 'hosts = local,bind4' >> /etc/[Link]
[0 root@AIX2:/] time host aix3
[Link] is [Link], Aliases: AIX3

real 0m0.00s
user 0m0.00s
sys 0m0.00s
[0 root@AIX2:/] time host [Link]
[Link] is [Link], Aliases: [Link]

real 0m0.20s
user 0m0.00s
sys 0m0.01s
[0 root@AIX2:/] grep -i gentoo /etc/hosts
[1 root@AIX2:/]

Como se puede observar, si se especifica en el archivo de configuración de resolución /

etc/[Link], que los nombres de máquinas (línea hosts =) el orden adecuado es
primero el archivo local /etc/hosts (dando la palabra clave local) antes que la
resolución por DNS sobre IPv4 (dando la palabra bind4) se puede acelerar el tiempo de
resolución si el nombre a buscar está en dicha tabla local, y no se afecta la búsqueda de
nombres de máquinas cuando no lo están.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 175

AIX Performance ● Ramón Barrios Lascar ® Ínodo 176
Parametrización del Sistema de Redes IP
Comando no
El comando no (network options) es un comando administrativo poderoso. El mismo
necesita permisos de root y permite listar, revisar y cambiar los parámetros que afectan
directamente al sistema de comunicaciones —más generalmente, IP—.
Ejemplo #1:
[0 root@AIX1:/] no -a
arpqsize = 1024
... # salida suprimida ...
ipqmaxlen = 512
... # salida suprimida ...
sb_max = 1048576
... # salida suprimida ...
tcp_recvspace = 16384
tcp_sendspace = 16384
... # salida suprimida ...
udp_recvspace = 42080
udp_sendspace = 9216
... # salida suprimida ...
[0 root@AIX1:/] no -Fo use_isno
use_isno = 1

El mismo, cuando se usa con la opción a lista todos los atributos no restringidos con sus
valores actuales. La opción F se usa para listar y manipular parámetros restringidos. En
el caso del ejemplo sólo estamos listando un parámetro restringido, no cambiándolo.
Ejemplo #2:
[2 root@AIX1:/] no -L
General Network Parameters
--------------------------------------------------------------------------------
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
bsd_loglevel 3 3 3 0 7 numeric D
--------------------------------------------------------------------------------
fasttimo 200 200 200 50 200 millisecond D
--------------------------------------------------------------------------------
init_high_wat 0 0 0 0 10 %_of_thewall D
--------------------------------------------------------------------------------
nbc_limit 256K 256K 256K 0 8E-1 kbyte D
thewall
--------------------------------------------------------------------------------
nbc_max_cache 128K 128K 128K 1 256M byte D
nbc_min_cache
nbc_limit
--------------------------------------------------------------------------------
nbc_min_cache 1 1 1 1 128K byte D
nbc_max_cache
--------------------------------------------------------------------------------
nbc_ofile_hashsz 12841 12841 12841 1 999999 segment D
--------------------------------------------------------------------------------

AIX Performance ● Ramón Barrios Lascar ® Ínodo 177

 nbc_pseg 0 0 0 0 2G-1 segment D
--------------------------------------------------------------------------------
nbc_pseg_limit 512K 512K 512K 0 1M kbyte D
--------------------------------------------------------------------------------
ndd_event_name {all} {all} {all} 0 128 string D
--------------------------------------------------------------------------------
ndd_event_tracing 0 0 0 0 64K-1 numeric D
--------------------------------------------------------------------------------
net_buf_size {all} {all} {all} 0 128 string D
--------------------------------------------------------------------------------
net_buf_type {all} {all} {all} 0 128 string D
--------------------------------------------------------------------------------
net_malloc_frag_mask {0} {0} {0} 0 128 string D
--------------------------------------------------------------------------------
netm_page_promote 1 1 1 0 1 numeric D
--------------------------------------------------------------------------------
sb_max 1M 1M 1M 4K 8E-1 byte D
--------------------------------------------------------------------------------
send_file_duration 300 300 300 0 4G-1 second D
--------------------------------------------------------------------------------
sockthresh 85 85 85 0 100 %_of_thewall D
--------------------------------------------------------------------------------
sodebug 0 0 0 0 1 boolean C
--------------------------------------------------------------------------------
sodebug_env 0 0 0 0 1 boolean C
--------------------------------------------------------------------------------
somaxconn 1K 1K 1K 0 32K-1 numeric C
--------------------------------------------------------------------------------
tcp_inpcb_hashtab_siz 24499 24499 24499 1 999999 numeric R
--------------------------------------------------------------------------------
tcptr_enable 0 0 0 0 1 boolean C
--------------------------------------------------------------------------------
thewall 1M 1M 1M 0 64M kbyte S
--------------------------------------------------------------------------------
udp_inpcb_hashtab_siz 24499 24499 24499 1 83000 numeric R
--------------------------------------------------------------------------------
use_sndbufpool 1 1 1 0 1 boolean R
--------------------------------------------------------------------------------

TCP Network Tunable Parameters

--------------------------------------------------------------------------------
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
clean_partial_conns 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
delayack 0 0 0 0 3 boolean D
--------------------------------------------------------------------------------
delayackports {} {} {} 0 10 ports_list D
--------------------------------------------------------------------------------
hstcp 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
limited_ss 0 0 0 0 100 numeric D
--------------------------------------------------------------------------------
rfc1323 0 0 0 0 1 boolean C
--------------------------------------------------------------------------------
rfc2414 1 1 1 0 1 boolean C
--------------------------------------------------------------------------------
rto_high 64 64 64 2 8E-1 roundtriptime R

AIX Performance ● Ramón Barrios Lascar ® Ínodo 178

 rto_low
--------------------------------------------------------------------------------
rto_length 13 13 13 1 64 roundtriptime R
--------------------------------------------------------------------------------
rto_limit 7 7 7 1 64 roundtriptime R
rto_high
rto_low
--------------------------------------------------------------------------------
rto_low 1 1 1 1 63 roundtriptime R
rto_high
--------------------------------------------------------------------------------
sack 0 0 0 0 1 boolean C
--------------------------------------------------------------------------------
tcp_bad_port_limit 0 0 0 0 8E-1 numeric D
--------------------------------------------------------------------------------
tcp_cwnd_modified 0 0 0 0 1 boolean C
--------------------------------------------------------------------------------
tcp_ecn 0 0 0 0 1 boolean C
--------------------------------------------------------------------------------
tcp_ephemeral_high 64K-1 64K-1 64K-1 32K+1 64K-1 numeric D
tcp_ephemeral_low
--------------------------------------------------------------------------------
tcp_ephemeral_low 32K 32K 32K 1K 65534 numeric D
tcp_ephemeral_high
--------------------------------------------------------------------------------
tcp_fastlo 0 0 0 0 1 boolean C
--------------------------------------------------------------------------------
tcp_fastlo_crosswpar 0 0 0 0 1 boolean C
--------------------------------------------------------------------------------
tcp_finwait2 1200 1200 1200 0 32K-1 halfsecond D
--------------------------------------------------------------------------------
tcp_icmpsecure 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
tcp_init_window 0 0 0 0 32K-1 byte C
--------------------------------------------------------------------------------
tcp_keepcnt 8 8 8 0 32K-1 numeric D
--------------------------------------------------------------------------------
tcp_keepidle 14400 14400 14400 1 32K-1 halfsecond C
--------------------------------------------------------------------------------
tcp_keepinit 150 150 150 1 32K-1 halfsecond D
--------------------------------------------------------------------------------
tcp_keepintvl 150 150 150 1 32K-1 halfsecond C
--------------------------------------------------------------------------------
tcp_limited_transmit 1 1 1 0 1 boolean D
--------------------------------------------------------------------------------
tcp_low_rto 0 0 0 0 3000 numeric D
timer_wheel_tick
--------------------------------------------------------------------------------
tcp_maxburst 0 0 0 0 32K-1 numeric D
--------------------------------------------------------------------------------
tcp_mssdflt 1460 1460 1460 1 64K-1 byte C
--------------------------------------------------------------------------------
tcp_nagle_limit 64K-1 64K-1 64K-1 0 64K-1 byte D
--------------------------------------------------------------------------------
tcp_nagleoverride 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
tcp_ndebug 100 100 100 0 32K-1 numeric D
--------------------------------------------------------------------------------
tcp_newreno 1 1 1 0 1 boolean D

AIX Performance ● Ramón Barrios Lascar ® Ínodo 179

 --------------------------------------------------------------------------------
tcp_nodelayack 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
tcp_recvspace 16K 16K 16K 4K 8E-1 byte C
sb_max
--------------------------------------------------------------------------------
tcp_sendspace 16K 16K 16K 4K 8E-1 byte C
sb_max
--------------------------------------------------------------------------------
tcp_tcpsecure 0 0 0 0 7 numeric D
--------------------------------------------------------------------------------
tcp_timewait 1 1 1 1 5 15_second D
--------------------------------------------------------------------------------
tcp_ttl 60 60 60 1 255 0.6_second C
--------------------------------------------------------------------------------
tcprexmtthresh 3 3 3 1 32K-1 numeric D
--------------------------------------------------------------------------------
timer_wheel_tick 0 0 0 0 100 numeric R
--------------------------------------------------------------------------------

UDP Network Tunable Parameters

--------------------------------------------------------------------------------
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
udp_bad_port_limit 0 0 0 0 8E-1 numeric D
--------------------------------------------------------------------------------
udp_ephemeral_high 64K-1 64K-1 64K-1 32K+1 64K-1 numeric D
udp_ephemeral_low
--------------------------------------------------------------------------------
udp_ephemeral_low 32K 32K 32K 1K 65534 numeric D
udp_ephemeral_high
--------------------------------------------------------------------------------
udp_recvspace 42080 42080 42080 4K 8E-1 byte C
sb_max
--------------------------------------------------------------------------------
udp_sendspace 9K 9K 9K 4K 8E-1 byte C
sb_max
--------------------------------------------------------------------------------
udp_ttl 30 30 30 1 255 second C
--------------------------------------------------------------------------------
udpcksum 1 1 1 0 1 boolean D
--------------------------------------------------------------------------------

IP Network Tunable Parameters

--------------------------------------------------------------------------------
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
directed_broadcast 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
ie5_old_multicast_mapping 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
ip6_defttl 64 64 64 1 255 numeric D
--------------------------------------------------------------------------------
ip6_prune 1 1 1 1 8E-1 second D
--------------------------------------------------------------------------------
ip6forwarding 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------

AIX Performance ● Ramón Barrios Lascar ® Ínodo 180

 ip6srcrouteforward 1 1 1 0 1 boolean D
--------------------------------------------------------------------------------
ip_ifdelete_notify 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
ip_nfrag 200 200 200 1 32K-1 byte D
--------------------------------------------------------------------------------
ipforwarding 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
ipfragttl 2 2 2 1 255 halfsecond D
--------------------------------------------------------------------------------
ipignoreredirects 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
ipqmaxlen 512 100 512 100 2G-1 numeric R
--------------------------------------------------------------------------------
ipsendredirects 1 1 1 0 1 boolean D
--------------------------------------------------------------------------------
ipsrcrouteforward 1 1 1 0 1 boolean D
--------------------------------------------------------------------------------
ipsrcrouterecv 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
ipsrcroutesend 1 1 1 0 1 boolean D
--------------------------------------------------------------------------------
lo_perf 1 1 1 0 1 boolean R
--------------------------------------------------------------------------------
maxnip6q 20 20 20 1 32K-1 numeric D
--------------------------------------------------------------------------------
multi_homed 1 1 1 0 3 boolean D
--------------------------------------------------------------------------------
ndogthreads 0 0 0 0 1K numeric D
--------------------------------------------------------------------------------
nonlocsrcroute 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
subnetsarelocal 1 1 1 0 1 boolean D
--------------------------------------------------------------------------------
tn_filter 1 1 1 0 1 boolean D
--------------------------------------------------------------------------------

ARP/NDP Network Tunable Parameters

--------------------------------------------------------------------------------
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
arpqsize 1K 1K 1K 1 32K-1 numeric D
tcp_pmtu_discover
udp_pmtu_discover
--------------------------------------------------------------------------------
arpt_killc 20 20 20 0 255 minute D
--------------------------------------------------------------------------------
arptab_bsiz 7 7 7 1 32K-1 bucket_size R
--------------------------------------------------------------------------------
arptab_nb 149 149 149 1 32K-1 buckets R
--------------------------------------------------------------------------------
dgd_packets_lost 3 3 3 1 32K-1 numeric D
--------------------------------------------------------------------------------
dgd_ping_time 5 5 5 1 8E-1 second D
--------------------------------------------------------------------------------
dgd_retry_time 5 5 5 1 32K-1 numeric D
--------------------------------------------------------------------------------
ndp_mmaxtries 3 3 3 0 8E-1 numeric D

AIX Performance ● Ramón Barrios Lascar ® Ínodo 181

 --------------------------------------------------------------------------------
ndp_umaxtries 3 3 3 0 8E-1 numeric D
--------------------------------------------------------------------------------
ndpqsize 50 50 50 1 32K-1 numeric D
--------------------------------------------------------------------------------
ndpt_down 3 3 3 1 8E-1 halfsecond D
--------------------------------------------------------------------------------
ndpt_keep 120 120 120 1 8E-1 halfsecond D
--------------------------------------------------------------------------------
ndpt_probe 5 5 5 1 4G-1 halfsecond D
--------------------------------------------------------------------------------
ndpt_reachable 30 30 30 1 4G-1 halfsecond D
--------------------------------------------------------------------------------
ndpt_retrans 1 1 1 1 4G-1 halfsecond D
--------------------------------------------------------------------------------
passive_dgd 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
rfc1122addrchk 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------

Stream Header Tunable Parameters

--------------------------------------------------------------------------------
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
lowthresh 90 90 90 0 100 %_of_thewall D
--------------------------------------------------------------------------------
medthresh 95 95 95 0 100 %_of_thewall D
--------------------------------------------------------------------------------
nstrpush 8 8 8 8 32K-1 numeric S
--------------------------------------------------------------------------------
psebufcalls 20 20 20 20 8E-1 numeric I
--------------------------------------------------------------------------------
psecache 1 1 1 0 1 boolean D
--------------------------------------------------------------------------------
psetimers 20 20 20 20 8E-1 numeric I
--------------------------------------------------------------------------------
strctlsz 1K 1K 1K 0 32K-1 byte D
--------------------------------------------------------------------------------
strmsgsz 0 0 0 0 32K-1 byte D
--------------------------------------------------------------------------------
strthresh 85 85 85 0 100 %_of_thewall D
--------------------------------------------------------------------------------
strturncnt 15 15 15 1 8E-1 numeric D
--------------------------------------------------------------------------------

Other Network Tunable Parameters

--------------------------------------------------------------------------------
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
bcastping 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
dgd_flush_cached_route 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
icmp6_errmsg_rate 10 10 10 1 255 msg/second D
--------------------------------------------------------------------------------
icmpaddressmask 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------

AIX Performance ● Ramón Barrios Lascar ® Ínodo 182

 ifsize 256 256 256 8 1K numeric R
--------------------------------------------------------------------------------
igmpv2_deliver 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
llsleep_timeout 3 3 3 1 2G-1 second D
--------------------------------------------------------------------------------
main_if6 0 0 0 0 32K-1 numeric D
--------------------------------------------------------------------------------
main_site6 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
maxttl 255 255 255 1 255 second D
--------------------------------------------------------------------------------
mpr_policy 1 1 1 1 6 numeric D
--------------------------------------------------------------------------------
pmtu_default_age 10 10 10 0 32K-1 minute D
--------------------------------------------------------------------------------
pmtu_expire 10 10 10 0 32K-1 minute D
--------------------------------------------------------------------------------
pmtu_rediscover_interval 30 30 30 0 32K-1 minute D
--------------------------------------------------------------------------------
route_expire 1 1 1 0 1 boolean D
--------------------------------------------------------------------------------
routerevalidate 0 0 0 0 1 boolean D
--------------------------------------------------------------------------------
rtentry_lock_complex 0 0 0 0 1 boolean R
--------------------------------------------------------------------------------
site6_index 0 0 0 0 32K-1 numeric D
--------------------------------------------------------------------------------
tcp_pmtu_discover 1 1 1 0 1 boolean D
--------------------------------------------------------------------------------
udp_pmtu_discover 1 1 1 0 1 boolean D
--------------------------------------------------------------------------------

n/a means parameter not supported by the current platform or kernel

Parameter types:
S = Static: cannot be changed
D = Dynamic: can be freely changed
B = Bosboot: can only be changed using bosboot and reboot
R = Reboot: can only be changed during reboot
C = Connect: changes are only effective for future socket connections
M = Mount: changes are only effective for future mountings
I = Incremental: can only be incremented

Value conventions:
K = Kilo: 2^10 G = Giga: 2^30 P = Peta: 2^50
M = Mega: 2^20 T = Tera: 2^40 E = Exa: 2^60

Cuando se usa con la conveniente opción L lista todos los parámetros no restringidos
con, mostrando diversas columnas:
! Name Nombre del parámetro del despachador.
! CUR Valor actual del parámetro
! DEF Valor predeterminado del mismo

AIX Performance ● Ramón Barrios Lascar ® Ínodo 183

 ! BOOT Valor que tomará al próximo inicio del sistema
! MIN Valor mínimo aceptable para el parámetro
! MAX Valor máximo aceptable para el parámetro
! UNIT Descripción de la unidad de medida del parámetro
! TYPE Como lo describe abajo, si el parámetro es estático/no cambiable
(S), si es dinámico/cambiable en línea (D), si sólo lo toma al
recrear la copia del núcleo en el volumen de carga del sistema
operativo hd5 (B), si necesita un reinicio (R), si lo toma en la
próxima conexión de un usuario (C), si lo toma en el próximo
montaje de un sistema de archivos (M), si sólo lo toma si el
parámetro se aumenta (I), si está despreciado y no debe
cambiarse (d).
Para cambiar cualquier parámetro se usa no -o parámetro=valor, que tomará si el
parámetro es dinámico (D). Ahora, los cambios hechos así se pierden al reiniciar el
sistema, a menos que se “vuelvan” permanentes con no -p -o parámetro=valor.
Ejemplo #3a:
[0 root@AIX1:/] no -o udp_recvspace -o udp_sendspace
udp_recvspace = 42080
udp_sendspace = 9216
[0 root@AIX1:/] no -o udp_recvspace=$((640*1024)) -o udp_sendspace=$((64*1024))
Setting udp_recvspace to 655360
Setting udp_sendspace to 65536
Change to tunable udp_recvspace,udp_sendspace, will only be effective for future
connections
[0 root@AIX1:/] no -o udp_recvspace -o udp_sendspace
udp_recvspace = 655360
udp_sendspace = 65536
[0 root@AIX1:/] no -L udp_recvspace -L udp_sendspace
--------------------------------------------------------------------------------
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
udp_recvspace 640K 42080 42080 4K 8E-1 byte C
sb_max
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
udp_sendspace 64K 9K 9K 4K 8E-1 byte C
sb_max
--------------------------------------------------------------------------------

En este ejemplo revisamos los parámetros udp_sendspace y udp_recvspace, los

cambiamos dinámicamente —cambios que recibe porque los parámetros son de tipo C
—. Estos parámetros aplicarán para las próximas “conexiones”. Siendo de tipo C, el
cambio queda registrado en el núcleo, y cuando se den nuevos tráficos —UDP casi nunca

AIX Performance ● Ramón Barrios Lascar ® Ínodo 184

 maneja conexiones porque no son obligatorias— se aplicará el nuevo valor. Nótese que
udp_sendspace es el tamaño en bytes del búfer de salida de cada nuevo chorro de bytes —
socket— que se envíe por UDP, y udp_recvspace es el tamaño del búfer de recepción de
los sockets que se abran para recibir por UDP (con listen() o bind()). Estos nuevos
parámetros son recomendados para servidores con software como Oracle RAC
Interconnect, BIND named name server, ISC DHCPsd dhcp/bootp server e ISC xNTPd
server. También son recomendados para servidores y clientes NFSv3 que manejen
puntos de montaje por UDP. En especial, estos números deben ajustarse cuando hay
números significativos en la capa UDP de la sección Demuxer del comando netstat -D —
ajustar udp_sendspace cuando se aumenta Odrops, y ajustar udp_recvspace cuando se
aumenta Idrops, ambos de ése comando y renglón—.
Ejemplo #3b:
[0 root@AIX1:/] no -o ipqmaxlen
ipqmaxlen = 512
[0 root@AIX1:/] no -p -o ipqmaxlen=1024
no: 1485-115 Tunable ipqmaxlen is of type R and cannot be changed without -r
[1 root@AIX1:/] no -r -o ipqmaxlen=1024
Setting ipqmaxlen to 1024 in nextboot file
Warning: changes will take effect only at next reboot
[0 root@AIX1:/] no -L ipqmaxlen
--------------------------------------------------------------------------------
NAME CUR DEF BOOT MIN MAX UNIT TYPE
DEPENDENCIES
--------------------------------------------------------------------------------
ipqmaxlen 512 100 1K 100 2G-1 numeric R
--------------------------------------------------------------------------------
En este caso se manipula el parámetro ipqmaxlen. Como se pudo observar en la tabla
completa anterior, es un parámetro de tipo R (sólo lo toma al reinicio). Se intenta
cambiar dinámicamente (con no -o), se intenta cambiar ahora y permanentemente (no -
p -o) pero el mismo reporta que sólo es cambiable con no -r -o. Se revisa al final los
valores para el parámetro. Este parámetro ipqmaxlen es necesario de manipular cuando
lo solicitan algunos procesos de instalación y configuración de software intenso en
comunicaciones: GPFS, HACMP/PowerHA, Oracle Server y Oracle RAC, entre otros. En
especial, debe aumentarse cuando las estadísticas Idrops u Odrops de la capa IP, en la
sección Demuxer del comando netstat -D está reportando números significativos.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 185

AIX Performance ● Ramón Barrios Lascar ® Ínodo 186
 Comando ifconfig
El comando ifconfig permite ajustar parámetros de protocolo y parámetros de interfaz,
en especial las direcciones de cada interfaz. Un uso particular se da cuando se habla de
los búferes de entrada y de salida a nivel de la capa TCP. Como en las versiones recientes
de AIX el parámetro use_isno del núcleo —visible con no -Fo use_isno— está
normalmente en 1, ajustar los valores de núcleo globales tcp_sendspace y tcp_recvspace
—igualmente visibles y ajustables con no -o— no aplica para nada, es necesario ajustar
con ifconfig por interfaz.
Ejemplo #1a:
[0 root@AIX1:/] ifconfig en0
en0: flags=1e080863,c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,
64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN>
inet [Link] netmask 0xffffff00 broadcast [Link]
tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0
[0 root@AIX1:/] ifconfig en0 tcp_sendspace $((256*1024)) tcp_recvspace $((128*1024))
[0 root@AIX1:/] ifconfig en0
en0: flags=1e080863,c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,
64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN>
inet [Link] netmask 0xffffff00 broadcast [Link]
tcp_sendspace 262144 tcp_recvspace 131072 rfc1323 0
Se observa cómo revisar los valores de una interfaz y cómo cambiarlos. Ahora, nótese
que ifconfig sólo hace cambios temporales, y que en caso de reinicio, remoción y
redetección de la interfaz, o en caso de ejecución de ifconfig enX detach, se perderán
los cambios. Para ajustarlos permanentemente se usa chdev.
Ejemplo #1b:
[0 root@AIX1:/] ifconfig en0
en0: flags=1e080863,c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,
64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN>
inet [Link] netmask 0xffffff00 broadcast [Link]
tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0
[0 root@AIX1:/] ifconfig en0 rfc1323 1 tcp_sendspace $((256*1024)) tcp_recvspace $
((256*1024)) tcp_nodelay 1
[0 root@AIX1:/] ifconfig en0
en0: flags=1e080863,c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,
64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN>
inet [Link] netmask 0xffffff00 broadcast [Link]
tcp_sendspace 262144 tcp_recvspace 262144 tcp_nodelay 1 rfc1323 1
[0 root@AIX1:/] lsattr -El en0 -a rfc1323 -a tcp_sendspace -a tcp_recvspace -a
tcp_nodelay
rfc1323 0 Enable/Disable TCP RFC 1323 Window Scaling True
tcp_sendspace 131072 Set Socket Buffer Space for Sending True
tcp_recvspace 65536 Set Socket Buffer Space for Receiving True
tcp_nodelay Enable/Disable TCP_NODELAY Option True
[0 root@AIX1:/] chdev -l en0 -a rfc1323=1 -a tcp_sendspace=262144 -a
tcp_recvspace=262144 -a tcp_nodelay=1 -P
en0 changed
[0 root@AIX1:/] lsattr -El en0 -a rfc1323 -a tcp_sendspace -a tcp_recvspace -a
tcp_nodelay
rfc1323 1 Enable/Disable TCP RFC 1323 Window Scaling True

AIX Performance ● Ramón Barrios Lascar ® Ínodo 187

 tcp_sendspace 262144 Set Socket Buffer Space for Sending True
tcp_recvspace 262144 Set Socket Buffer Space for Receiving True
tcp_nodelay 1 Enable/Disable TCP_NODELAY Option True

El comando chdev, como siempre, si se usa con la opción P aplica el cambio con la
próxima activación del dispositivo —que muy a menudo es el próximo inicio del sistema
—. Si se usa sin la P, aplicaría el cambio ahora y en la próxima activación.
Estos nuevos parámetros son recomendados para servidores con software como Apache
y otros servidores http —WebSphere Application Server—; como servidores intensos en
TCP como Oracle Server, DB2 UDB Server; servidores de archivos como FTPd y Samba.
También son recomendados para servidores y clientes NFSv3 y NFSv4 que manejen
puntos de montaje por TCP. En especial, estos números deben ajustarse cuando hay
números significativos en la capa TCP de la sección Demuxer del comando netstat -D —
ajustar tcp_sendspace cuando se aumenta Odrops, y ajustar tcp_recvspace cuando se
aumenta Idrops, ambos de ése comando y renglón—.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 188

 Comandos nslookup y dig
Parte de la velocidad aparente que perciben los procesos y los usuarios al realizar
conexiones nuevas depende del tiempo que necesita un servidor para preparar y alistar
una sesión de conexión nueva. En el caso de AIX, algunos servicios, dependiendo de su
configuración deben registrar en algún archivo o tabla dichas sesiones, y algunos
servicios, en especial los interactivos prefieren registrar los nombres de las máquinas
clientes de donde vienen las conexiones, esto implica hacer una consulta de resolución
inversa de nombres, donde el servidor, si es un cliente DNS, le hace una consulta de tipo
PTR a su(s) servidor(es) de nombre usando una dirección IP y esperando un nombre de
host como respuesta. Dependiendo del servicio, esta consulta DNS puede ser recursiva,
lo que le llevará al servidor un tiempo de navegar por diferentes DNS hasta encontrar la
respuesta o encontrar una respuesta negativa definitiva. Cuando se dan estas
situaciones, un cliente puede notar que cuando hace una conexión nueva a un servidor
AIX la conexión se da prontamente, pero la sesión —solicitud de usuario y contraseña—
no inicia si no un tiempo después —pueden llegar a ser entre 30s y 45s—, pero luego de
abierta la sesión ya no se notan más demoras en el procesamiento, y que si se abre una
nueva sesión mientras la primera está activa, la segunda sesión es creada muy
rápidamente.
Ejemplo #1a:
[/root] # time ssh -i $HOME/.ssh/id_dsa root@[Link] hostname
[Link]

real0m21.729s
user0m0.030s
sys0m0.000s
[/root] # time ssh -i $HOME/.ssh/id_dsa root@[Link] hostname
[Link]

real0m0.546s
user0m0.040s
sys0m0.000s
Como se puede observar, la primera conexión desde un cliente desconocido hasta un
cierto AIX1 toma 21.729s, mientras la segunda conexión toma solamente 0.546s. Si se
consultan más datos podremos investigar qué podrá ser.
Ejemplo #1b:
[0 root@AIX1:/] who
root pts/0 Jun 23 08:58 ([Link])
root pts/1 Jun 23 08:55 ([Link])
[1 root@AIX1:/] host [Link]
[Link] is [Link]
[0 root@AIX1:/] host [Link]
[Link] is [Link]
[0 root@AIX1:/] host [Link]
host: 0827-803 Cannot find address [Link].

AIX Performance ● Ramón Barrios Lascar ® Ínodo 189

 Se observa cómo el comando who —con el que se lista información de las sesiones
interactivas activas— muestra una sesión registrada con nombre de máquina y una
registrada sólo con la dirección IP. Se valida más información y encontramos que
mientras la sesión registrada con nombre se dio porque se pudo resolver de IP a nombre
—y de nombre a IP—, la que no está registrada con nombre, y que tiene demoras de
creación de sesión no se puede resolver de IP a nombre.
Ejemplo #2a:
[0 root@AIX1:/] time nslookup [Link]
Server: [Link]
Address: [Link]#53

Non-authoritative answer:
[Link] canonical name = [Link].
[Link] canonical name =
[Link].
[Link] canonical name =
[Link].
Name: [Link]
Address: [Link]

real 0m0.23s
user 0m0.01s
sys 0m0.01s
[0 root@AIX1:/] time nslookup [Link]
Server: [Link]
Address: [Link]#53

Non-authoritative answer:
[Link] canonical name = [Link].
[Link] canonical name =
[Link].
[Link] canonical name =
[Link].
Name: [Link]
Address: [Link]

real 0m0.00s
user 0m0.00s
sys 0m0.00s

Con las utilidades nslookup y dig se pueden hacer consultas de resolución de máquinas
de todo tipo, que combinándolas con el comando estándar time podemos tener los
tiempos de respuesta a consultas positivas y negativas, para poder llegar a conclusiones
definitivas —y de ahí a la solución a problemas aparentes de desempeño—. Note cómo
el sistema de caché de resolución de nombres hace que las consultas repetidas del
mismo dato prácticamente tomen 0.00s.

AIX Performance ● Ramón Barrios Lascar ® Ínodo 190