Inicias sesión en un servidor Linux con un problema de rendimiento: ¿qué compruebas en el primer minuto?

Primeros 60 segundos: resumen

En esta publicación, se te mostrará los primeros 60 segundos de una investigación de rendimiento optimizada en la línea de comandos, utilizando herramientas estándar de Linux que debería tener disponibles. En 60 segundos, puede obtener una idea de alto nivel sobre el uso de recursos del sistema y los procesos en ejecución, ejecutando los siguientes diez comandos. Busque errores y métricas de saturación, ya que ambas son fáciles de interpretar, y luego de la utilización de recursos. La saturación es cuando un recurso tiene más carga de la que puede manejar y puede quedar expuesto como la longitud de una cola de solicitudes o el tiempo de espera.

uptime
dmesg | tail
vmstat 1
mpstat -P ALL 1
pidstat 1
iostat -xz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top

Algunos de estos comandos requieren que esté instalado el paquete sysstat. Las métricas que exponen estos comandos le ayudarán a completar parte del método USE : una metodología para localizar cuellos de botella en el rendimiento. Esto implica verificar las métricas de utilización, saturación y error de todos los recursos (CPU, memoria, discos, etc.). También preste atención a cuándo ha verificado y exonerado un recurso, ya que mediante el proceso de eliminación esto reduce los objetivos a estudiar y orienta cualquier investigación de seguimiento.

Las siguientes secciones resumen estos comandos, con ejemplos de un sistema de producción. Para obtener más información sobre estas herramientas, consulte sus páginas de manual.

1. Uptime

[simterm]$ uptime
23:51:26 hasta 21:31, 1 usuario, carga promedio: 30.02, 26.43, 19.02 [/simterm]

Esta es una forma rápida de ver los promedios de carga, que indican la cantidad de tareas (procesos) que se desean ejecutar. En los sistemas Linux, estos números incluyen procesos que desean ejecutarse en la CPU, así como procesos bloqueados en E/S ininterrumpidas (normalmente E/S de disco). Esto da una idea de alto nivel de la carga (o demanda) de recursos, pero no se puede entender correctamente sin otras herramientas. Sólo vale la pena echarle un vistazo rápido.

Los tres números son promedios de sumas móviles amortiguados exponencialmente con una constante de 1 minuto, 5 minutos y 15 minutos. Los tres números nos dan una idea de cómo cambia la carga con el tiempo. Por ejemplo, si se le pidió que verificara un servidor con problemas y el valor de 1 minuto es mucho menor que el valor de 15 minutos, es posible que haya iniciado sesión demasiado tarde y no haya detectado el problema.

En el ejemplo anterior, los promedios de carga muestran un aumento reciente, alcanzando 30 para el valor de 1 minuto, en comparación con 19 para el valor de 15 minutos. Que las cifras sean tan grandes significa mucho de algo: probablemente demanda de CPU; vmstat o mpstat lo confirmarán, que son los comandos 3 y 4 en esta secuencia.

2. dmesg | tail

[simterm]$ dmesg | tail
[1880957.563150] perl invocado oom-killer: gfp_mask = 0x280da, orden = 0, oom_score_adj = 0
[…]
[1880957.563400] Fuera de la memoria: proceso de matar 18694 (perl) puntaje 246 o sacrifice hijo
[1880957.563400 (perl) total-vm:1972392kB, anon-rss:1953348kB, file-rss:0kB
[2320864.954447] TCP: Posible inundación SYN en el puerto 7001. Solicitud de abandono. Verifique los contadores SNMP. [/simterm]

Esto ve los últimos 10 mensajes del sistema, si los hay. Busque errores que puedan causar problemas de rendimiento. El ejemplo anterior incluye el oom-killer y TCP descartando una solicitud.

¡No te pierdas este paso! Siempre vale la pena comprobar dmesg.

3.vmstat 1

[simterm]$ vmstat 1
procs ———memoria———- —swap– —–io—- -sistema– —— cpu—–
rb swpd caché de buff libre si so bi bo en cs us sy id wa st
34 0 0 200889792 73708 591828 0 0 0 5 6 10 96 1 3 0 0
32 0 0 200889920 73708 591860 0 0 0 5 92 13284 4282 98 1 1 0 0
32 0 0 200890112 73708 591860 0 0 0 0 9501 2154 99 1 0 0 0 32 0 0 200889568 73712 591856 0 0
0 48 11900 2 459 99 0 0 0 0 32 0 0 200890208 73712 591860 0 0 0
0 15898 4840 98 1 1 0 0
^C [/simterm]

Abreviatura de estadística de memoria virtual, vmstat(8) es una herramienta comúnmente disponible (creada por primera vez para BSD hace décadas). Imprime un resumen de las estadísticas clave del servidor en cada línea.

vmstat se ejecutó con un argumento de 1, para imprimir resúmenes de un segundo. La primera línea de salida (en esta versión de vmstat) tiene algunas columnas que muestran el promedio desde el inicio, en lugar del segundo anterior. Por ahora, omita la primera línea, a menos que quiera aprender y recordar qué columna es cuál.

Columnas a comprobar:

• r : Número de procesos ejecutándose en la CPU y esperando un turno. Esto proporciona una mejor señal que los promedios de carga para determinar la saturación de la CPU, ya que no incluye E/S. Para interpretar: un valor de «r» mayor que el recuento de CPU es saturación.
• libre : memoria libre en kilobytes. Si hay demasiados dígitos para contar, tienes suficiente memoria libre. El comando “free -m”, incluido como comando 7, explica mejor el estado de la memoria libre.
• si, so: Intercambios y intercambios. Si son distintos de cero, te has quedado sin memoria.
• us, sy, id, wa, st : estos son desgloses del tiempo de CPU, en promedio en todas las CPU. Son tiempo de usuario, tiempo del sistema (kernel), inactivo, E/S en espera y tiempo robado (por otros invitados o con Xen, el dominio de controlador aislado del propio invitado).

Los desgloses del tiempo de CPU confirmarán si las CPU están ocupadas sumando el tiempo del usuario + del sistema. Un grado constante de E/S en espera indica un cuello de botella en el disco; Aquí es donde las CPU están inactivas, porque las tareas están bloqueadas esperando E/S de disco pendientes. Puede tratar la E/S en espera como otra forma de CPU inactiva, una que da una pista de por qué están inactivas.

El tiempo del sistema es necesario para el procesamiento de E/S. Puede ser interesante explorar más a fondo un promedio de tiempo del sistema alto, superior al 20%: tal vez el núcleo esté procesando la E/S de manera ineficiente.

En el ejemplo anterior, el tiempo de CPU está casi en su totalidad a nivel de usuario, lo que apunta al uso a nivel de aplicación. Las CPU también se utilizan en promedio por encima del 90%. Esto no es necesariamente un problema; verifique el grado de saturación usando la columna «r».

4. mpstat -P ALL 1

[simterm]$ mpstat -P ALL 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 14/07/2015 _x86_64_ (32 CPU)
07:38:49 PM CPU %usr %nice %sys %iowait %irq %soft %steal %invitado %gnice %inactivo
07:38:50 PM todos 98.47 0.00 0.75 0.00 0.00 0.00 0.00 0.00 0.00 0.78
07:38:50 PM 0 96.04 0.00 2.97 0.00 0.00 0.00 0.00 0. 00 0,00 0,99 19:38:50
1 97,00 0,00 1,00 0.00 0.00 0.00 0.00 0.00 0.00 2.00
07:38:50 PM 2 98.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00 07:38:50
PM 3 96.97 0.00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 3,03
[…] [/simterm]

Este comando imprime desgloses de tiempo de CPU por CPU, que se pueden utilizar para comprobar si hay un desequilibrio. Una única CPU activa puede ser evidencia de una aplicación de un solo subproceso.

5. pidstat 1

[simterm]$ pidstat 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 14/07/2015 _x86_64_ (32 CPU)
07:41:02 p. m. UID PID %usr %system %guest %CPU Comando de CPU
07:41:03 p.m. 0 9 0.00 0.94 0.00 0.94 1 rcuos/0
07:41:03 PM 0 4214 5.66 5.66 0.00 11.32 15 mesos-slave
07:41:03 PM 0 4354 0.94 0.94 0.00 1.89 8 java
07: 41:03 p.m. 0 6521 1596.23 1.89 0,00 1598,11 27 java
19:41:03 0 6564 1571,70 7,55 0,00 1579,25 28 java
19:41:03 60004 60154 0,94 4,72 0,00 5,66 9 pidstat
19:41:03 U ID PID %usr %sistema %invitado %CPU Comando de CPU
19:41:04 0 4214 6.00 2.00 0.00 8.00 15 mesos-esclavo
19:41:04 0 6521 1590.00 1.00 0.00 1591.00 27 java
19:41:04 0 6564 1573.00 10.0 0 0,00 1583,00 28 java
19:41:04 108 6718 1,00 0,00 0,00 1,00 0 snmp-pass
19:41:04 60004 60154 1,00 4,00 0,00 5,00 9 pidstat
^C [/simterm]

Pidstat es un poco como el resumen por proceso de top, pero imprime un resumen continuo en lugar de borrar la pantalla. Esto puede ser útil para observar patrones a lo largo del tiempo y también registrar lo que vio (copiar y pegar) en un registro de su investigación.

El ejemplo anterior identifica dos procesos de Java como responsables del consumo de CPU. La columna %CPU es el total de todas las CPU; El 1591% muestra que los procesos de Java consumen casi 16 CPU.

6. iostat -xz 1

[simterm]$ iostat -xz 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 14/07/2015 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
73,96 0,00 3,73 0,03 0,06 22,21
Dispositivo: rrqm/s wrqm/sr/sw/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util xvda 0,00 0,23 0,21 0,18 4,52 2,08 34,37 0,00 9,98 13,80 5. 42 2,44 0,09 xvdb 0,01 0,00 1,02
8,94
127,97 598,53 145,79 0,00 0,43 1,78 0,28 0,25 0,25
xvdc 0,01 0,00 1,02 8,86 127,79 595,94 146,50 0,00 0,45 1,82 0,30 0,27 0,26
dm-0 0,00 0,00 0,69 2,32 10,47 31,69 28,01 0,01 3,23 0,71 3,98 0,13 0,04
dm-1 0,00 0,00 0,00 0,94 0,01 3,78 8,00 0,33 345,8 4 0,04 346,81 0,01 0,00 dm-2 0,00 0,00 0,09 0,07 1,35 0,36 22,50 0,00 2,55 0,23 5,62
1,78 0,03
[. ..]
^C [/simterm]

Esta es una gran herramienta para comprender los dispositivos de bloques (discos), tanto la carga de trabajo aplicada como el rendimiento resultante. Buscar:

• r/s, w/s, rkB/s, wkB/s : estas son las lecturas, escrituras, Kbytes de lectura y Kbytes de escritura entregados por segundo al dispositivo. Utilícelos para la caracterización de la carga de trabajo. Un problema de rendimiento puede deberse simplemente a una carga excesiva aplicada.
• await : el tiempo promedio de E/S en milisegundos. Este es el tiempo que sufre la aplicación, ya que incluye tanto el tiempo en cola como el tiempo en servicio. Los tiempos promedio mayores a los esperados pueden ser un indicador de saturación del dispositivo o problemas en el dispositivo.
• avgqu-sz : el número promedio de solicitudes enviadas al dispositivo. Los valores superiores a 1 pueden ser evidencia de saturación (aunque los dispositivos generalmente pueden operar en solicitudes en paralelo, especialmente los dispositivos virtuales que enfrentan múltiples discos de back-end).
• %util : utilización del dispositivo. Este es realmente un porcentaje de ocupación, que muestra el tiempo cada segundo que el dispositivo estuvo funcionando. Valores superiores al 60% suelen dar lugar a un rendimiento deficiente (lo que debería observarse en await), aunque depende del dispositivo. Valores cercanos al 100% suelen indicar saturación.

Si el dispositivo de almacenamiento es un dispositivo de disco lógico que se encuentra frente a muchos discos back-end, entonces una utilización del 100% puede simplemente significar que algunas E/S se están procesando el 100% del tiempo; sin embargo, los discos back-end pueden estar lejos de estar saturados. y es posible que pueda manejar mucho más trabajo.

Tenga en cuenta que el bajo rendimiento de E/S del disco no es necesariamente un problema de la aplicación. Generalmente se utilizan muchas técnicas para realizar E/S de forma asincrónica, de modo que la aplicación no se bloquee ni sufra la latencia directamente (por ejemplo, lectura anticipada para lecturas y almacenamiento en búfer para escrituras).

7. free -m

[simterm]$ free -m
total utilizado buffers compartidos gratuitos almacenados en caché
Mem: 245998 24545 221453 83 59 541
-/+ buffers/caché: 23944 222053
Intercambio: 0 0 0 [/simterm]

Las dos columnas de la derecha muestran:

• buffers : para el caché del búfer, utilizado para la E/S del dispositivo de bloque.
• cached : Para el caché de la página, utilizado por los sistemas de archivos.

Solo queremos comprobar que estos no tengan un tamaño cercano a cero, lo que puede provocar una mayor E/S del disco (confirmar usando iostat) y un peor rendimiento. El ejemplo anterior se ve bien, con muchos Mbytes en cada uno.

El “-/+ buffers/cache” proporciona valores menos confusos para la memoria utilizada y libre. Linux utiliza memoria libre para las cachés, pero puede recuperarla rápidamente si las aplicaciones la necesitan. Entonces, en cierto modo, la memoria caché debe incluirse en la columna de memoria libre, lo cual hace esta línea. Incluso hay un sitio web, linuxatemyram , sobre esta confusión.

Puede resultar además confuso si se utiliza ZFS en Linux, como hacemos con algunos servicios, ya que ZFS tiene su propio caché de sistema de archivos que no se refleja correctamente en las columnas -m libres. Puede parecer que el sistema tiene poca memoria libre, cuando esa memoria en realidad está disponible para su uso desde la caché de ZFS según sea necesario.

8. sar -n DEV 1

[simterm]$ sar -n DEV 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 14/07/2015 _x86_64_ (32 CPU)
12:16:48 a. m. IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/ s txcmp/s rxmcst/s %ifutil
12:16:49 a.m. eth0 18763.00 5032.00 20686.42 478.30 0.00 0.00 0.00 0.00
12:16:49 a.m. lo 14.00 14.00 1.36 1.36 0.00 0,00 0,00 0,00 12:16:49
a. m. docker0 0,00 0,00 0,00 0,00 0.00 0.00 0.00 0.00
12:16:49 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil 12:16:50 a.m. eth0 19763.00 5101.00 21999.10 4 82,56 0,00 0,00 0,00
0,00
12:16:50 lo 20.00 20.00 3.25 3.25 0.00 0.00 0.00 0.00
12:16:50 docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
^C [/simterm]

Utilice esta herramienta para comprobar el rendimiento de la interfaz de red: rxkB/s y txkB/s, como medida de la carga de trabajo, y también para comprobar si se ha alcanzado algún límite. En el ejemplo anterior, la recepción eth0 está alcanzando los 22 Mbytes/s, que son 176 Mbits/s (muy por debajo, digamos, de un límite de 1 Gbit/s).

Esta versión también tiene %ifutil para la utilización del dispositivo (máximo de ambas direcciones para dúplex completo), que es algo que también usamos la herramienta nicstat de Brendan para medir. Y al igual que con nicstat, esto es difícil de hacer bien y parece no funcionar en este ejemplo (0.00).

9.sar -n TCP,ETCP 1

[simterm]$ sar -n TCP,ETCP 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)

12:17:19 AM active/s passive/s iseg/s oseg/s
12:17:20 AM 1.00 0.00 10233.00 18846.00

12:17:19 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:20 AM 0.00 0.00 0.00 0.00 0.00

12:17:20 AM active/s passive/s iseg/s oseg/s
12:17:21 AM 1.00 0.00 8359.00 6039.00

12:17:20 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:21 AM 0.00 0.00 0.00 0.00 0.00
^C
[/simterm]

Esta es una vista resumida de algunas métricas clave de TCP. Éstas incluyen:

• active/s : Número de conexiones TCP iniciadas localmente por segundo (por ejemplo, a través de connect()).
• pasive/s : Número de conexiones TCP iniciadas remotamente por segundo (por ejemplo, mediante aceptar()).
• retrans/s : Número de retransmisiones TCP por segundo.

Los recuentos activos y pasivos suelen ser útiles como medida aproximada de la carga del servidor: número de nuevas conexiones aceptadas (pasivas) y número de conexiones descendentes (activas). Podría ser útil pensar en activo como saliente y pasivo como entrante, pero esto no es estrictamente cierto (por ejemplo, considere una conexión de localhost a localhost).

Las retransmisiones son una señal de un problema de red o servidor; puede ser una red poco confiable (por ejemplo, la Internet pública) o puede deberse a que un servidor está sobrecargado y pierde paquetes. El ejemplo anterior muestra solo una nueva conexión TCP por segundo.

10. Top

[simterm]$ top
top – 00:15:40 up 21:56, 1 user, load average: 31.09, 29.87, 29.92
Tasks: 871 total, 1 running, 868 sleeping, 0 stopped, 2 zombie
%Cpu(s): 96.8 us, 0.4 sy, 0.0 ni, 2.7 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 25190241+total, 24921688 used, 22698073+free, 60448 buffers
KiB Swap: 0 total, 0 used, 0 free. 554208 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20248 root 20 0 0.227t 0.012t 18748 S 3090 5.2 29812:58 java
4213 root 20 0 2722544 64640 44232 S 23.5 0.0 233:35.37 mesos-slave
66128 titancl+ 20 0 24344 2332 1172 R 1.0 0.0 0:00.07 top
5235 root 20 0 38.227g 547004 49996 S 0.7 0.2 2:02.74 java
4299 root 20 0 20.015g 2.682g 16836 S 0.3 1.1 33:14.42 java
1 root 20 0 33620 2920 1496 S 0.0 0.0 0:03.82 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:05.35 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:06.94 kworker/u256:0
8 root 20 0 0 0 0 S 0.0 0.0 2:38.05 rcu_sched
[/simterm]

El comando superior incluye muchas de las métricas que verificamos anteriormente. Puede resultar útil ejecutarlo para ver si algo se ve muy diferente de los comandos anteriores, lo que indicaría que la carga es variable.

Una desventaja importante es que es más difícil ver patrones a lo largo del tiempo, lo que puede ser más claro en herramientas como vmstat y pidstat, que proporcionan resultados continuos. La evidencia de problemas intermitentes también se puede perder si no pausa la salida lo suficientemente rápido (Ctrl-S para pausar, Ctrl-Q para continuar) y la pantalla se borra.