OS X Server: Evaluación del rendimiento

Este artículo describe cómo utilizar un script para iniciar una evaluación del rendimiento de un servidor que ejecute Mac OS X Server v10.4 o posterior. El objetivo principal es identificar el uso de los recursos clave: las CPU, el almacenamiento en disco y el uso de la red.

Uso de recursos

Puedes utilizar este script perl (llamado "top_guide.pl") para evaluar el uso de los recursos clave a lo largo del tiempo en tu servidor. Este script funciona con Mac OS X Server v10.4 y posterior.

El script ejecuta top -d, pero extrae y resume el uso de recursos clave a lo largo del tiempo. Sin utilizar argumentos, los resultados de top_guide.pl tienen un aspecto similar a este:

--------  -----------  ------------  -------------  -------------  -------------  -------------  ------
          CPU usage:          300-s  Reads/sec:     Writes/sec:    Net in/sec:    Net out/sec:   kernel
Time:     user  sys    Idle   avg.   number MB      number MB      pkts   Mb      pkts   Mb      CPU%
--------  ----- -----  -----  -----  ------ ------  ------ ------  ------ ------  ------ ------  ------
08:44:36    0.1   0.1   99.8   99.8       0    0.0       0    0.0      11    0.0       0    0.0     0.4
08:44:46    0.1   0.3   99.6   99.8       0    0.0       0    0.1      12    0.0       0    0.0     0.4
08:44:56    0.0   0.2   99.8   99.8       0    0.0       0    0.0      17    0.0       0    0.0     0.4
08:45:06    0.0   0.2   99.8   99.8       0    0.0       0    0.0       6    0.0       0    0.0     0.4
08:45:16    0.0   0.2   99.8   99.8       0    0.0       0    0.0       9    0.0       0    0.0     0.4
08:45:26    8.7  24.6   66.7   98.6      43    0.8      98    0.6     803    1.0    1399    1.1     5.0
08:45:37    5.7  83.6   10.7   95.7      48    0.4    1085  116.9   95366 1053.1   61830   35.4    72.4
08:45:47   11.5  88.5    0.0   92.4      23    0.2    3228  426.9  337955 3843.6  207872  114.0   284.8
08:45:58    4.6  95.4    0.0   89.0       4    0.0     594  596.7  447499 5215.5  266449  140.9   370.0

Puedes ver las tres áreas clave identificadas: CPU, E/S de disco y red. Las columnas son:

  • Time (Tiempo): La hora de finalización de la línea más reciente del resumen. Por defecto, transcurren 10 segundos entre muestras.
  • CPU usage: user: (Uso de las CPU: usuario:) Uso de las CPU en modo usuario. El valor es un porcentaje de los recursos totales de las CPU disponibles en el equipo. Por ejemplo, en un equipo con 8 procesadores, un valor de 50 % para el uso de las CPU por parte del usuario significaría que el uso total de las CPU que hacen todas las aplicaciones en ejecución equivale a 4 procesadores.
  • CPU usage: sys: (Uso de las CPU: sistema:) Uso de las CPU en modo kernel como porcentaje del total de CPU disponibles.
  • Idle: (Inactivas:) CPU inactivas, como porcentaje del total de recursos disponibles.
  • 300-s avg: (Media de 300 segundos:) Media suavizada del porcentaje de CPU no utilizadas durante los últimos 300 segundos. (Ten en cuenta que esto cambia si utilizas la opción -r para ajustar el intervalo de promedio; el título de la columna cambia en consonancia).
  • Reads/sec - number: (Lecturas/segundo - número:) Número de operaciones de lectura de disco singulares emitidas durante el periodo de muestra.
  • Reads/sec - MB (Lecturas/segundo - MB:) Total de megabytes leídos en los discos durante el periodo de muestra.
  • Writes/sec - number: (Escrituras/segundo - número:) Número de operaciones de escritura en disco singulares emitidas durante el periodo de muestra.
  • Writes/sec - MB (Escrituras/segundo - MB:) Total de megabytes escritos durante el periodo de muestra.
  • Net in/sec - pkts: (Entrada de red/segundo - paquetes:) Cantidad de paquetes totales recibidos durante el periodo de muestra.
  • Net in/sec - Mb: (Entrada de red/segundo - Mb:) Entrada total de red en megabits por segundo durante el periodo de muestra.
  • Net out/sec - pkts: (Salidas de red/segundo - paquetes:) Cantidad de paquetes totales enviados durante el periodo de muestra.
  • Net out/sec - Mb: (Salidas de red/segundo - Mb:) Salida total de red en megabits por segundo durante el periodo de muestra.

Otras opciones ofrecidas por el script incluyen:

  • -h: Mostrar la información completa de uso.
  • -o nombredearchivo: Guarda una copia separada por tabulaciones de los resultados en un archivo. Este "formulario de salida" resulta adecuado para importarlo en hojas de cálculo y otros scripts de análisis de datos. La primera línea incluye los encabezados de las columnas para garantizar que los resultados puedan analizarse siempre de forma autónoma.
  • -d: Muestra la fecha y la hora. Esto resulta particularmente útil para el registro a largo plazo de un servidor cuyo administrador desee conservar un registro histórico.
  • -S NombresDeProcesos: Hace un seguimiento de procesos de instancia única. Esta opción es útil si un servicio concreto que tiene un único ID de proceso es particularmente interesante en un servidor. Un ejemplo podría ser un servidor empleado principalmente como servidor AFP. En ese caso, utiliza los argumentos -S AppleFileServer para añadir una columna independiente para el uso de las CPU del proceso AppleFileServer. Se puede listar más de un proceso separando los nombres de los procesos mediante comas.
  • -M NombresDeProcesos: Como -S, excepto que se usa cuando la aplicación utiliza varios procesos (por ejemplo:smbd, que tiene un proceso por conexión). En un equipo en el que se utilice mucho Samba, usa -M smbd para obtener una columna que resume la CPU de usuario para toda la actividad de Samba.

Aunque un análisis exhaustivo del rendimiento de un servidor supera el ámbito de este artículo, los resultados de top_guide.pl ofrecen un resumen del uso de los recursos de las CPU, los discos y la red en el equipo. Comparar estos datos con el hardware y la carga del sistema permite al administrador decidir qué área investigar con más detalle. A continuación se comentan algunas herramientas adicionales que pueden resultar de ayuda para investigar cada área.

Uso de las CPU

Si el uso de las CPU es elevado, entonces la primera ruta de investigación es mejorar la eficiencia de la aplicación. Esto queda fuera del ámbito de este artículo; no obstante, en ocasiones las CPU no se están utilizando. Existen varias herramientas que te ayudarán a investigar una situación en la que existan suficientes recursos de disco y de red para asumir una carga mayor pero, pese a ello, una gran parte de las CPU permanecen inactivas.

Existen dos formas de infrautilizar una CPU:

  • Cierre de subprocesos de aplicación
  • Cierre de recursos del kernel

Introducido en Mac OS X v10.5 Leopard, el comando plockstat(1) puede ejecutarse con referencia a una aplicación concreta para investigar la contención de cierre de subprocesos POSIX. Puedes identificar procesos que quizás experimenten contención de cierre de subprocesos POSIX examinando los resultados de top -d para procesos con un número elevado de cambios de contexto (columna CSW). Una vez que hayas identificado un proceso que quieras investigar debido a contención de cierre de subprocesos POSIX, utiliza: # plockstat -C -e 10 -p <pid>.

 Mutex block
   
   Count     nsec Lock                       Caller
   -------------------------------------------------------------------------------
  8540    29622 0x805eb0                     a.out`process_request+0x3d1
  8361    28284 0x805eb0                     a.out`release_block+0xac
  
 R/W reader block
 
 Count     nsec Lock                         Caller
 -------------------------------------------------------------------------------
     1  3014987 0xa781e8                     a.out`key_find+0x121
     5    78831 0xa3d158                     a.out`key_find+0x121
     2   120532 0xa3d158                     a.out`key_delete+0x137
 
 R/W writer block
 
 Count     nsec Lock                         Caller
 -------------------------------------------------------------------------------
    10  5336318 0xa781e8                     a.out`key_replace+0x80
    13  3827632 0xa75fe8                     a.out`key_replace+0x80
     3  3644946 0xa5fde8                     a.out`key_create+0x37
     6   161055 0xa3d158                     a.out`key_replace+0x80
     1   785267 0xa37758                     a.out`key_create+0x37

Puedes examinar este resultado y revisar el número total de nsec bloqueados detrás de varios cierres. Si ese valor es alto en comparación con el total, el tiempo de ejecución se está viendo afectado por contención de cierres. Esa información puede resultar de utilidad para el programador a la hora de aislar y mejorar el rendimiento de la aplicación. Si los símbolos están disponibles, el campo Caller contendrá el nombre simbólico de la función bloqueada. Además, si el recuento total de bloqueos es alto, más de unos 250 por segundo aproximadamente, entonces se está perdiendo algo de eficacia en la renegociación entre subprocesos. Aunque esto no basta para concluir que se trata de un factor limitador del rendimiento, las tasas elevadas de bloqueos merecen ser investigadas, porque en muchos casos apuntan a que la aplicación no es tan eficaz como podría ser.

En ocasiones, los problemas de contención de recursos tienen que ver con los recursos dentro del kernel. El kernel de Mac OS X gestiona la mayoría de recursos de subprocesos múltiples mediante mutex de kernel y cierres de lector-escritor. La contención de mutex puede evaluarse mediante scripts dtrace (1M) como:

lockstat:::adaptive-block

{

        @often[arg0, stack(5)] = count();

}


profile:::tick-5sec

{

        normalize(@often, 5);

        printa(@often);

}

Esto imprime una lista ordenada. Las rutas y los cierres más disputados aparecen al final de cada bloqueo de salida impreso tras cinco segundos de muestreo. He aquí un ejemplo de resultado:

        375517140

              mach_kernel`lck_mtx_lock_wait_x86+0x1c7

              mach_kernel`lck_mtx_lock+0x217

              mach_kernel`ip_output_list+0xd34

              mach_kernel`tcp_setpersist+0x18b

              mach_kernel`tcp_output+0x17a0

                0

        375571960

              mach_kernel`lck_mtx_lock_wait_x86+0x1c7

              mach_kernel`lck_mtx_lock+0x217

              mach_kernel`vnode_ref+0x32

              mach_kernel`fcntl_nocancel+0x4b3

              mach_kernel`unix_syscall64+0x26d

                0

En este caso, el script informa de que el mutex de kernel en 375517140 está siendo bloqueado mediante una ruta desde la que tcp_output() llama a tcp_setpersist(), que a su vez llama a ip_output_list(). El número de bloqueos por segundo es 0 en ambos bloqueos, así que la contención de cierres no es un problema. Ten en cuenta que esta forma del script no arroja el total de todas las instancias para un único cierre. Si el script se modificase así:

lockstat:::adaptive-block

{

        @often[arg0] = count();

}


profile:::tick-5sec

{

        normalize(@often, 5);

        printa(@often);

}

el resultado podría pasar a ser:

       1301055072                9

       1417504384                9

        353318336               10

        359381776               10

       1301055088               11

          5387344              165

lo que indica que solo el cierre en la dirección de kernel 5387344 exhibe una contención reseñable, y aun así no supone motivo de preocupación, al ser inferior a 250.

Por último, el script puede centrarse en cierres de lector-escritor del kernel modificándolo levemente:

lockstat:::rw-block

{

    @often[arg0, stack(4)] = count();

}


profile:::tick-5sec

{

    normalize(@often, 5);

    printa(@often);

    clear(@often);

}

Algunas cuestiones que recordar sobre el uso de scripts dtrace(1M) lockstat y plockstat(1):

  • La obtención de estadísticas de cierres tiene un impacto sobre el rendimiento. Estas herramientas pueden ralentizar el sistema. Ejecútalas con precaución y recuerda que el impacto sobre el rendimiento añadirá contención que no está presente durante el funcionamiento normal.
  • Algunos diseños no se ven afectados por el mero bloqueo de cierres. Imagina el caso de un cierre en un recurso que cambia muy lentamente; podrías optar por usar un cierre para gestionarlo. El cierre puede dejarse asignado, a la espera de que se complete una operación larga.

Instancias como esta podrían tener tiempos de retención largos pero que en realidad no reducen el rendimiento.

Uso de disco

iopending(1) ofrece indicaciones sobre la profundidad de las colas de E/S como un histograma de profundidad de colas. Por ejemplo:

2008 May 21 10:35:26,  load: 0.99,  disk_r:      0 KB,  disk_w:    392 KB
           value  ------------- Distribution ------------- count   
             < 0 |                                         0       
               0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 9298    
               1 |                                         12      
               2 |                                         5       
               3 |                                         4       
               4 |                                         2       
               5 |                                         3       
               6 |                                         2       
               7 |                                         2       
               8 |                                         3       
               9 |                                         2       
              10 |                                         3       
              11 |                                         2       
              12 |                                         2       
              13 |                                         2       
              14 |                                         2       
              15 |                                         0       

revela algo de actividad de disco, pero no es motivo de preocupación, ya que casi todas las colas de E/S tienen profundidad 0. Además, puedes usar iopending para centrarte en un disco o volumen de sistema de archivos concreto. Por ejemplo, para centrarte en /Volumes/MiRAID, utiliza: iopending -m MiRAID.

Por último, puedes asignar E/S a procesos concretos y evaluar la latencia utilizando fs_usage(1). Puedes aprender más acerca de cómo usar Shark y fs_usage(1) en este documento de conexión de Developer.

Uso de la red

Muchos servidores cuentan con varios clientes e interfaces de red a diferentes distancias por toda la red. El análisis de rendimiento puede resultar complejo. No obstante, en entornos LAN en los que los clientes están conectados directamente por un tapiz de velocidad conocida, los valores arrojados por top_guide.pl y por netstat -i ofrecerán información acerca de cuánto se está aprovechando la capacidad. A la hora de interpretar estas cifras, ten en cuenta las siguientes directrices:

Redes Gigabit - Dúplex, MTU de 1500 bytes
Tasas máximas - paquetes pequeños:    1488 Kpps   762 Mbps
Tasa máxima de paquetes - 1500 bytes:  81 Kpps   987 Mbps
(Kpps = miles de paquetes por segundo)

A la hora de analizar el rendimiento de la red también resulta útil examinar los resultados de netstat -s en busca de problemas, como tasas excesivas de retransmisión de paquetes (algo que está fuera del ámbito de este artículo).

Más información

La información sobre productos no fabricados por Apple, o sobre sitios web independientes no controlados ni comprobados por Apple, se proporciona sin ningún tipo de recomendación ni respaldo. Apple no se responsabiliza de la selección, rendimiento o uso de sitios web o productos de terceros. Apple no emite ninguna declaración sobre la exactitud o fiabilidad de sitios web de terceros. El uso de Internet conlleva riesgos inherentes. Ponte en contacto con el proveedor para obtener información adicional. Otros nombres de empresas o productos pueden ser marcas registradas de sus respectivos propietarios.

Fecha de publicación: