Las buenas herramientas de solución de problemas del sistema lo son todo. Las grandes herramientas, sin embargo, son más difíciles de encontrar. Afortunadamente, Linux viene con una gran cantidad de excelentes programas y utilidades que le permiten perfilar, analizar y resolver problemas de comportamiento del sistema, desde cuellos de botella en las aplicaciones hasta errores de configuración e incluso errores. Todo comienza con una herramienta que puede obtener las métricas necesarias y brindarle los datos que necesita.
Health-check es un programa ordenado que puede monitorear y perfilar procesos, para que pueda identificar y resolver el uso excesivo de recursos o problemas asociados. Donde se destaca en comparación con el resto de la multitud:su objetivo es ofrecer muchas facetas útiles de los datos del sistema simultáneamente, para que pueda buscar componentes en sus sistemas con mayor facilidad, solucionar problemas de rendimiento y corregir percances de configuración en su entorno. En lugar de tener que ejecutar cinco herramientas al mismo tiempo, o hacer cinco ejecuciones para obtener toda la información que necesita, simplemente use el control de salud y Bob es su pariente lejano. Bien. Muy bien, ¿listo? Proceder.
Chequeo de salud en acción
Antes de que ejecutemos la utilidad con ira, algunas notas pequeñas. Primero, necesita privilegios de sudo para ejecutar esta herramienta, aunque puede ejecutar la aplicación real en el contexto de otros usuarios en el sistema (con el indicador -u). Dos, necesita cierta comprensión de cómo funciona Linux para hacer uso de los resultados:tengo un montón de artículos sobre este tema, vinculados más abajo.
En esencia, como lo describí hace un momento, el control de salud combina la funcionalidad de una variedad de programas bajo un mismo paraguas. Combina muy bien los elementos que obtendría si ejecutara netstat, lsof, vmstat, iostat y examinara varias estructuras en /proc y /sys. Esto es algo así como dstat, que combina el poder de vmstat, iostat e ifstat. Puede comenzar con la ejecución simple (marca -b):
sudo ./health-check -u "usuario" -b "binario"
Habrá muchos resultados, incluso en este modo "breve", algo como:
Uso de CPU (en términos de 1 CPU):
Usuario:34,24 %, Sistema:13,30 %, Total:47,54 % (carga alta)
Primero, obtiene cifras básicas de CPU, normalizadas por núcleo (100 % =1 núcleo completo). Health-check tiene umbrales internos por los cuales indicará si se trata de carga baja, moderada o alta. Esto es solo para darle una idea de lo que debe esperar. Los detalles dependerán del tipo de aplicación y la carga de trabajo que esté perfilando. Habrá diferencias entre la GUI y las herramientas de línea de comandos, el software que lee de una base de datos a una que no lo hace, el software con una gran cantidad de bibliotecas compartidas, el uso de hardware, etc.
Errores de página:
Proceso PID Menor/seg Mayor/seg Total/seg
1043 google-chrome 16156,46 0,25 16156,71
Hablamos extensamente sobre fallas de página en el pasado (enlaces en la sección de más lectura a continuación). Si no sabe lo que se supone que debe hacer su aplicación, los números no le dirán mucho por sí solos. Pero pueden ser muy útiles para estudios comparativos, como dos programas diferentes del mismo tipo, o dos versiones diferentes del mismo programa, o el mismo programa ejecutándose en dos plataformas diferentes.
Cambios de contexto:
13687.53 cambios de contexto/seg (muy alto)
El valor de cambio de contexto indica con qué frecuencia el kernel abandona la cola de ejecución y cambia entre tareas. Para los procesos interactivos (como el navegador), que tienen un componente interactivo con el usuario, en realidad desea tantos cambios de contexto como sea posible (las tareas se ejecutan lo menos posible), porque no desea que estas tareas acaparen el procesador. De hecho, los cálculos largos son una señal de trabajos por lotes. Aquí, tener pocos cambios de contexto podría ser una indicación de un problema con una aplicación interactiva (GUI) como el navegador.
Operaciones de E/S de archivos:
Operaciones de E/S por segundo:312,80 apertura, 283,49 cierre, 768,71 lectura,
410,83 escritura
Los valores de E/S son útiles si tiene una línea de base y también dependen de la pila de E/S subyacente, incluido el hardware, el bus, el controlador, la elección del sistema de archivos y cualquier otra operación de disco que se ejecute al mismo tiempo.
Análisis de llamadas del sistema de sondeo:
google-chrome (1043), sondeo:
1555 llamadas con tiempo de espera agotado inmediato sin tiempo de espera (vistas sin bloqueo)
1 llamadas repetidas con tiempo de espera agotado sin cero tiempos de espera
(sondeo ligero)
1125 llamadas sondeadas inmediatas repetidas con tiempo de espera agotado sin tiempos de espera
(sondeo intenso)
Esta sección es otro indicador de la posible interacción con el usuario del binario perfilado. Las llamadas al sistema de sondeo son llamadas al sistema que esperan que las descripciones de los archivos estén listas para realizar operaciones de E/S. Por lo general, esto indicará conexiones de red. Examinaremos esto con más detalle cuando hagamos una ejecución completa.
Memoria:
Cambio en la memoria (K/segundo):
PID Proceso Tipo Tamaño RSS PSS
1043 google-chrome Stack 32.51 27.59 27.59 (creciendo
moderadamente rápido)
1043 google-chrome Heap 67550.94 9092.51 9112.70 (creciendo muy
rápido)
1043 google-chrome Mapeado 102764.33 27296.24 18781.80 (creciendo muy
rápido)
Para la mayoría de las personas y la mayoría de los tipos de aplicaciones, las operaciones de memoria no serán tan interesantes. Las cargas de trabajo con uso intensivo de memoria no son tan habituales en el software de escritorio. Pueden ser bastante importantes para bases de datos y cálculos complejos, algo que normalmente haría en un sistema de clase de servidor. Pero este conjunto de números se puede usar para examinar las diferencias entre plataformas, kernels y versiones de software.
Conexiones de red abiertas:
Proceso PID Proto Enviar Recibir Dirección
1043 google-chrome UNIX 531,52 K 35,16 K /run/user/1000/bus
1043 google-chrome UNIX 0,00 B 88,56 K /run /systemd/journal/...
1043 google-chrome 64,51 K 0,00 B socket:[2737924]
1043 google-chrome 30,55 K 0,00 B socket:[2746558]
1043 google-chrome Toma 3,98 K 0,00 B:[2742865]
...
El conjunto de números de conexiones de red le brinda resultados similares a lo que hacen netstat y lsof, pero también obtiene los valores de envío/recepción, que pueden ser bastante útiles. Si sabe qué debe hacer el programa en cuanto a la red, puede perfilar su ejecución y buscar posibles configuraciones incorrectas en la pila de red.
Ejecución más larga (detallada)
También puede optar por más estadísticas (por ejemplo, con banderas -c -f, sin bandera -b). Obtendrá resultados extendidos para cada una de las secciones que hemos discutido anteriormente, y esto puede brindarle información adicional sobre cómo se comporta su software. Si está rastreando procesos secundarios y bifurcaciones, puede ver la secuencia de ejecución. Las estadísticas de la CPU se enumerarán según el uso, con los delincuentes más altos en la parte superior.
Uso de CPU (en términos de 1 CPU):
Proceso PID USR% SYS% TOTAL% Duración
1715 vlc 47,04 8,17 55,21 14,71 (carga alta)
1720 vlc 46,91 7,96 54,87 14,43 (carga alta )
1723 vlc 46,77 7,96 54,74 14,35 (carga alta)
...
1721 vlc 1,69 1,08 2,77 1,21 (carga ligera)
1722 vlc 0,20 0,07 0,27 0,16 (carga muy ligera) )
1726 vlc 0.07 0.00 0.07 0.02 (carga muy ligera)
1742 vlc 0.00 0.00 0.00 0.07 (inactivo)
1732 vlc 0.00 0.00 0.00 0.02 (inactivo)
17280 vlc 0.0 0,00 0,06 (inactivo)
1719 vlc 0,00 0,00 0,00 0,06 (inactivo)
Total 971,80 161,72 1133,52 (CPU totalmente cargada)
En el ejemplo anterior, al ejecutar VLC (con una reproducción de clip HD de unos 14 segundos), utilizamos el 1133 % del tiempo de CPU, lo que se traduce en 11,33 núcleos de CPU. Eso suena mucho, pero dado que el sistema tiene ocho núcleos (subprocesos), esto significa que solo se usaron 1,5 núcleos para el video. También sería interesante saber qué núcleos se usaron.
Cambios de contexto:
Proceso PID Voluntario Involuntario Total
Ctxt Sw/Sec Ctxt Sw/Sec Ctxt Sw/Sec
1744 vlc 2500.09 1.15 2501.24 (alto)
1723 vlc 1493.47 1.82 1495.29 ( alto)
1740 vlc 1224.03 3.31 1227.33 (alto)
1717 vlc 947.43 0.40 947.84 (bastante alto)
1731 vlc 736.37 0.81 737.18 (bastante alto)
Para fallas de página, no hay nada nuevo. Con los cambios de contexto, también obtenemos una lista de CS voluntarios e involuntarios. El último grupo puede ser una indicación de tareas que exceden su porción asignada, lo que resultaría en que tengan una prioridad dinámica más baja la próxima vez que se ejecuten (lo que no es bueno para los procesos interactivos).
Operaciones de E/S de archivos:
PID Process Count Op Filename
1715 vlc 176 R /home/roger/developers.webm
1715 vlc 48 C /etc/ld.so.cache
1715 vlc 48 O /etc/ld.so.cache
1715 vlc 34 R /usr/share/X11/locale/locale.alias
La E/S de archivos ahora también muestra el número de operaciones por proceso, el tipo de operación y el nombre del archivo. Esto no tiene que ser un archivo real en el disco, también podría ser un bus. Las operaciones disponibles están impresas en la parte inferior de esta sección. La forma exacta en que se realizan las operaciones de lectura y escritura depende de muchos factores.
...
1715 vlc 1 C /lib/x86_64-linux-gnu/libnss_systemd.so.2
1715 vlc 1 O /usr/bin/vlc
Total 4352
Op :O=Abrir, R=Leer, W=Escribir, C=Cerrar
También obtiene la frecuencia de estas operaciones de E/S:
Operaciones de E/S de archivos por segundo:
Proceso PID Abrir Cerrar Leer Escribir
1715 vlc 100,57 96,72 89,77 1,75
1719 vlc 3,24 4,99 3,04 0,00
...
La siguiente sección trata sobre las llamadas al sistema y es muy detallada. La salida es similar a strace. Tendrá la identificación del proceso, el nombre del proceso, la llamada al sistema, el conteo, la tasa, el tiempo total (en nosotros) y el porcentaje que cada llamada al sistema tomó del tiempo total de ejecución. No puede interpretar estos números a menos que sepa qué debe hacer la aplicación, o puede compararlos con una línea de base.
Llamadas al sistema rastreadas:
Tasa de conteo de llamadas al sistema de proceso PID/seg. Total de uSecs % Tiempo de llamada
1715 vlc stat 429 28.9555 3004 0.0011
1715 vlc mmap 240 16.1989 4912 0.0017
1715 vlc mprotect 203 13.7015 4739 0.0017
...
La información es más útil cuando observa las llamadas del sistema de sondeo. Para abreviar, he editado ligeramente el resultado a continuación. Los últimos cuatro campos indican tiempos de espera, por ejemplo:Tiempo de espera cero, Tiempo de espera mínimo, etc. Esencialmente, le brindan un indicador de cuánto tiempo tardaron en finalizar estas llamadas al sistema. El campo Recuento infinito hace referencia a las llamadas al sistema que tenían una espera infinita (durante la ejecución de la aplicación). La información también se muestra como un histograma por proceso, de cero a infinito, dividido logarítmicamente, hasta 10us, 10-99 us, 100-99 us, etc.
Principales llamadas al sistema de sondeo:
Tasa de llamadas al sistema de proceso PID/Seg Inf Zero Min Max Avg
1715 vlc poll 3.2398 45 1 0.0 s 25.0 s 1.0 s
1715 vlc rt_sigtimed 0.1350 2 0 0.0 s 0.0 s 0,0 s
1717 sondeo vlc 124,7312 5 1 0,0 s 30,0 s 958,4 ms
...
El registro de salida más detallado también tendrá los datos de sincronización del sistema de archivos.
Sincronizaciones del sistema de archivos:
PID fdatasync fsync sync syncfs total total (Rate)
1723 0 2 0 0 2 0.13
Archivos sincronizados:
PID syscall # sync's filename
1723 fdatasync 1 /inicio/roger/.../vlc-qt-interface.conf.lock
1723 fdatasync 1 /inicio/roger/.../vlc-qt-interface.conf.XM1715
Por último, la salida detallada también tendrá información de conexión de red y memoria, pero la principal diferencia serán los resultados mostrados por proceso. Como hemos discutido anteriormente, el primero no suele ser útil para la mayoría de las cargas de trabajo de escritorio (a menos que sea el desarrollador del programa), mientras que el segundo puede ser útil para encontrar problemas en la pila de red.
Health-check crea un conjunto bastante grande de resultados, pero proporciona mucha información sobre cómo se comportan sus aplicaciones. Puede combinar su uso con otro software para obtener un análisis completo de su software y solucionar cualquier problema de rendimiento. Health-check también puede generar perfiles de tareas en ejecución (indicador -p), lo que lo hace muy útil como una adición a su caja de herramientas para resolver problemas.
Configuración manual
Si no está satisfecho con la versión disponible en los repositorios, puede compilar manualmente. Otra razón para hacer esto es solucionar los posibles problemas que puedan tener las versiones anteriores, como por ejemplo el error timer_stats, por el cual las herramientas intentan acceder a /proc/timer_stats, pero esta estructura ya no está expuesta en kernels recientes:
No se puede abrir /proc/timer_stats.
De hecho, si marca, obtiene:
cat /proc/timer_stats
cat:/proc/timer_stats:No existe tal archivo o directorio
Para compilar, ejecute:
clon de git https://kernel.ubuntu.com/git/cking/health-check.git/
control de estado de cd
hacer
Es posible que vea el siguiente error:
json.h:25:10:error fatal:json-c/json.h:No existe tal archivo o directorio
#include
Esto significa que te falta el paquete de desarrollo para JSON, que la herramienta necesita para compilar correctamente. El nombre real del paquete variará de una distribución a otra, pero en mi prueba en Kubuntu, lo siguiente resolvió el error de compilación:
sudo apt-get install libjson-c-dev
Más lectura
Si está interesado en herramientas adicionales para la solución de problemas del sistema, entonces:
Herramientas de administración super-duper de Linux:strace
Herramientas de administración super-duper de Linux:lsof
Herramientas de administración super-duper de Linux:gdb
¿Sistema lento? ¡Perf al rescate!
Súper tutorial de depuración del sistema LinuxTrucos geniales de Linux, partes uno a cuatro, que vinculan solo el último.
Por último, pero no menos importante, ¡mi libro de resolución de problemas!
Conclusión
Health-check es una herramienta muy útil y práctica. No reemplaza a strace, netstat o perf, pero puede ayudarlo a obtener una instantánea multidimensional muy precisa de lo que sea que esté perfilando. Este es un muy buen primer paso que puede orientarlo en la dirección correcta. Luego puede seleccionar una utilidad que examine específicamente la faceta relevante de la ejecución del software (tal vez Wireshark para la red o Valgrind para la memoria). En cierto modo, esto convierte el control de salud en un Jack o' All Trades.
Necesita cierta comprensión de cómo funcionan los sistemas Linux y la aplicación que está ejecutando. Pero incluso si no tiene ese conocimiento, la verificación de estado se puede utilizar para estudios comparativos y solución de problemas de cuellos de botella en el rendimiento. Si sabe que algo no funciona tan bien como debería, puede rastrearlo una vez en un buen sistema, una vez en un sistema malo (afectado) y luego comparar los dos. Los muchos tipos de datos que proporciona el control de salud serán de gran ayuda para resolver el problema. Y eso nos lleva al final de este tutorial. Con un poco de suerte, has aprendido algo nuevo y también fue un viaje agradable. Cuídate.