OS X Server: Evaluación del rendimiento

Este artículo describe cómo puedes usar un script para comenzar a evaluar el rendimiento de un servidor con Mac OS X Server v10.4 o versiones posteriores. El objetivo principal es identificar el uso de recursos clave: CPU, almacenamiento en disco y redes.

Uso de recursos

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

El script se ejecuta top -d, pero extrae y resume el uso de recursos clave a lo largo del tiempo. Sin argumentos, el resultado de top_guide.pl se parece a esto:

-------- ----------- ------------ ------------- ------------ ------------ ------------ ------ Uso de la CPU: 300 s Lecturas/s: Escrituras/s: Entrada neta/s: Salida neta/s: Tiempo kernel: prom. inact. usuario sis. número MB número 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, disco E/S y redes. Las columnas son:

• Hora: la hora de finalización de la línea de resumen más reciente. Por defecto, hay 10 segundos entre las muestras.

• Uso de la CPU: usuario: utilización de la CPU en modo usuario. El valor es un porcentaje del total de recursos de la CPU disponibles en este sistema. Por ejemplo, en un sistema de 8 procesadores, el 50 % de la CPU del usuario significaría que la utilización total de la CPU de todas las aplicaciones en ejecución es el equivalente a 4 procesadores.

• Uso de la CPU: sys: uso de la CPU en modo kernel como porcentaje del total de la CPU disponible.

• Inactivo: CPU inactiva, como porcentaje del total de recursos disponibles.

• Promedio de 300 segundos: promedio suavizado del porcentaje de CPU no utilizada en los últimos 300 segundos. (Ten en cuenta que esto cambia si utilizas -roption para ajustar el intervalo de promedio; el título de la columna cambia en consecuencia).

• Lecturas/s - número: el número de operaciones de lectura de disco únicas emitidas durante el periodo de muestra.

• Lecturas/s - MB:: el total de megabytes leídos de los discos durante el periodo de muestra.

• Escrituras/s - número: el número de operaciones de escritura únicas emitidas durante el periodo de muestra.

• Escrituras/s- MB: megabytes totales escritos durante el periodo de muestra.

• Entrada neta/s - pkts: total de paquetes recibidos durante el periodo de muestra.

• Entrada neta/s - Mb: entrada total de la red en megabits por segundo durante el periodo de muestra.

• Salida neta/s - pkts: total de paquetes de red enviados durante el periodo de muestra.

• Salida neta/s - Mb: salida total de la red en megabits por segundo durante el periodo de muestra.

Otras opciones que proporciona el script:

• -h: mostrar información completa sobre el uso.

• -o nombre de archivo: colocar una copia separada por tabulaciones de la salida en un archivo. Este formato de salida es adecuado para importarlo en una hoja de cálculo u otros scripts de análisis de datos. La primera línea incluye los encabezados de las columnas para garantizar que la salida siempre incluya su descripción.

• -d: mostrar la fecha y la hora. Esto es particularmente útil para llevar un registro a largo plazo en un servidor en el que el administrador desea un registro histórico.

• -S nombresDeProceso: supervisar los procesos de una sola instancia. Esto es útil si un servicio en particular que tiene un solo ID de proceso es particularmente interesante en un servidor. Un ejemplo podría ser un servidor utilizado principalmente como servidor AFP. En ese caso, utiliza los argumentos -S AppleFileServer para agregar una columna separada para el uso de la CPU de usuario del proceso de AppleFileServer. Se puede enumerar más de un proceso separando los nombres de los procesos por comas.

• -M nombresDeProceso: como -S, excepto para el uso cuando la aplicación utiliza varios procesos. Un ejemplo es el smbd, para el que tenemos uno por conexión. En un sistema muy utilizado para Samba, utiliza -M smbd para obtener una columna que resuma la CPU del usuario de toda la actividad de Samba.

Aunque un análisis completo del rendimiento del servidor está más allá del alcance de este artículo, la salida de top_guide.pl proporciona un resumen del uso de la CPU, el disco y los recursos de red en el sistema. Comparar eso con el hardware y la carga del sistema permite a un administrador decidir qué área investigar con más detalle. A continuación se discuten algunas herramientas adicionales que pueden ayudar a investigar cada área.

Utilización de la CPU

Si la utilización de la CPU es alta, entonces la principal vía de investigación es mejorar la eficiencia de la aplicación. Esto está fuera del alcance de este artículo; sin embargo, a veces no se está utilizando suficientemente la CPU. Hay varias herramientas disponibles para ayudarte a investigar la situación en la que hay suficientes recursos de red y disco para una carga más alta, pero una cantidad considerable de la CPU permanece inactiva.

Estas son dos formas en las que una CPU puede estar infrautilizada:

• Bloqueo de thread de la aplicación

• Bloqueo de recursos del kernel

Introducido en Mac OS X 10.5 Leopard, el comando plockstat(1) se puede ejecutar en una aplicación en particular para investigar la contención de bloqueo de pthread. Puedes identificar los procesos que podrían tener contención de bloqueo de pthread examinando la salida top -d para procesos con un alto número de interruptores de contexto (columna CSW). Una vez que hayas identificado un proceso que desees investigar para la contención de bloqueo de pthread, usa: # plockstat -C -e 10 -p .

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 la cantidad total de nsec bloqueados detrás de varios bloqueos. Si este valor es alto en relación con el total, el tiempo de ejecución se ve afectado por la contención de bloqueo. Esa información puede ser útil para el escritor de la aplicación a la hora de aislar y mejorar el rendimiento de la aplicación. Si hay símbolos disponibles, el campo Caller (Llamador) contendrá el nombre simbólico de la función que se bloqueó. Además, si el recuento total de bloqueos es alto, más de aproximadamente 250 por segundo, entonces se está perdiendo algo de eficiencia al reprogramar entre threads. Aunque no es suficiente para concluir que es un factor limitante para el rendimiento, las altas tasas de bloqueos justifican la investigación porque en la mayoría de los casos indican que la aplicación puede que no sea tan eficiente como podría llegar a ser.

A veces, las incidencias de contención de recursos son para los recursos dentro del kernel. El kernel de Mac OS X gestiona la mayoría de los recursos de threads múltiples con mutexes del kernel y bloqueos de lector-escritor. La contención de mutex se puede evaluar 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, con los bloqueos y rutas con más contenciones en la parte inferior de cada bloqueo de salida impreso después de cinco segundos de muestreo. Aquí tenemos una muestra de la salida:

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 del kernel en 375517140 se está bloqueando a través de una ruta donde tcp_output() llama a tcp_setpersist(), que llama a ip_output_list(). El número de bloqueos por segundo es 0 en ambos casos, por lo que la contención de bloqueo no es un problema. Ten en cuenta que este formato de script no suma todas las instancias con un solo bloqueo. Si el script se cambió a:

lockstat:::adaptive-block { @often[arg0] = count(); } profile:::tick-5sec { normalize(@often, 5); printa(@often); }

La salida puede cambiar a:

1301055072 9 1417504384 9 353318336 10 359381776 10 1301055088 11 5387344 165

Esto indica que solo el bloqueo en la dirección del kernel 5387344 tiene una contención apreciable e incluso en este caso no tendría que ser preocupante porque es menor de 250.

Por último, el script puede centrarse en los bloqueos del lector-escritor del kernel cambiando ligeramente el script a:

lockstat:::rw-block { @often[arg0, stack(4)] = count(); } profile:::tick-5sec { normalize(@often, 5); printa(@often); clear(@often); }

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

• La recopilación de estadísticas de bloqueo tiene un impacto en el rendimiento. Estas herramientas pueden ralentizar el sistema. Ejecútalas con cuidado y recuerda que el impacto en el rendimiento añadirá una contención que no existe en el funcionamiento normal.

• Algunos diseños no se ven afectados simplemente por el bloqueo. Considera utilizar un bloqueo en un recurso que cambia muy lentamente, donde puedes optar por usar un bloqueo para administrarlo. El bloqueo puede dejarse en su lugar a la espera de que se complete una operación de larga duración.

Tales casos tendrían largos tiempos de espera que, en realidad, podrían no reducir el rendimiento.

Utilización del disco

iopending(1) da una indicación de la profundidad de las colas de E/S, como histograma de la profundidad de la cola. Por ejemplo:

21 de mayo de 2008 10:35:26, carga: 0.99, disk_r: 0 KB, disk_w: 392 KB

valor ------------- Distribución ------------- recuento < 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

Esto indica cierta actividad en el disco, pero no es preocupante, ya que casi todas las colas de E/S tienen una profundidad de 0. Además, puedes usar iopending para centrarte en un disco o volumen del sistema de archivos en particular. Por ejemplo, para centrarte en /Volumes/MyRAID, usa iopending -m MyRAID.

Por último, puedes atribuir E/S a procesos particulares y evaluar la latencia con fs_usage(1). Puedes obtener más información sobre el uso de Shark y fs_usage(1) en este documento de Conexión del desarrollador.

Utilización de la red

Muchos servidores pueden tener múltiples interfaces de red y clientes en varias distancias en toda la red. El análisis del rendimiento puede ser complejo. Sin embargo, en contextos de LAN en las que los clientes estén conectados directamente a través de una estructura de una velocidad conocida, las métricas comunicadas por top_guide.pl, así como netstat -i, proporcionarán información sobre cómo se está utilizando la capacidad. Al interpretar esos números, ten en cuenta estas pautas:

Redes Gigabit - dúplex completo: MTU de 1500 bytes

Velocidad máxima - paquetes pequeños: 1488 Kpps 762 Mbps

Velocidad máxima de paquetes - paquetes de 1500 bytes: 81 Kpps 987 Mbps

(Kpps = miles de paquetes por segundo)

Al analizar el rendimiento de la red, también es útil revisar la salida de netstat -s en busca de incidencias, como una velocidad excesiva de retransmisión de paquetes (que está fuera del alcance de este artículo).

Más información

• Para obtener información adicional sobre la supervisión del uso del sistema de archivos, consulta Examinar del uso del sistema de archivos (en inglés).

• Para obtener información sobre la herramienta de elaboración de perfiles de tiempo de Shark, consulta Manual del usuario de Shark (en inglés).

• Para obtener más información sobre cómo usar Dtrace, consulta: Cómo usar Dtrace (en inglés).