PIDSTAT Linux: analizar el consumo de CPU y memoria de cada proceso

Con pidstat En Linux, mido la actividad de la CPU, la memoria, las E/S y los subprocesos de cada proceso a intervalos fijos, lo que me permite detectar tendencias en lugar de solo instantáneas. Así es como encuentro Cuellos de botella Si es fiable, asígnalo a un PID o a un comando y determina si la causa es la CPU, la RAM, las E/S o un cambio de contexto.

Puntos centrales

• Medición por intervalos: Series temporales por proceso, en lugar de una simple instantánea.
• Amplia cobertura: CPU, memoria, E/S, subprocesos y cambios de contexto.
• Filtrado selectivo: Observar con enfoque fijo mediante PID o comando.
• Fácil de usar: Instalar sysstat y ejecutarlo directamente.
• Ventajas prácticas: Identificar rápidamente los picos de carga, las fugas y los cuellos de botella en las E/S.

¿Qué es pidstat? Una breve explicación

Utilizo pidstat, con el fin de visualizar el uso de recursos de cada proceso a lo largo del tiempo. La herramienta forma parte del paquete sysstat y proporciona, para cada proceso, datos sobre la CPU, la memoria, las E/S, los subprocesos y los cambios de contexto. A diferencia de «top», no obtengo una visión fugaz, sino puntos de medición continuos a intervalos regulares. Esto me permite detectar patrones como picos periódicos, cargas continuas o un crecimiento progresivo. Esta información temporal me ayuda a atribuir claramente las causas a un proceso concreto y a no perderme en el ruido de una instantánea.

Instalación y puesta en marcha rápida

Instalo sysstat con el gestor de paquetes de mi distribución y ejecuto pidstat inmediatamente sin necesidad de configuración adicional. La sintaxis básica sigue siendo sencilla: pidstat [opciones] [intervalo] [número]. Sin opciones, la herramienta muestra CPU-Valores por proceso; repite las mediciones de forma continua a intervalos. Ejemplo: pidstat 2 10 Recopila diez mediciones cada dos segundos. Así consigo crear rápidamente una línea temporal fiable para su posterior análisis.

Análisis de la CPU: visualizar la carga por proceso

Para preguntas sobre la CPU, empiezo por... pidstat con -u, por ejemplo pidstat -u 1 para el contador de segundos. Las columnas %usr, %system y %CPU me indican cuánto tiempo de usuario y de kernel consume un proceso. Si necesito centrarme en una aplicación, utilizo -p o -C para filtros de nombres. Si el %system aumenta considerablemente, compruebo las llamadas al sistema o los efectos de E/S; si predomina el %usr, el trabajo se realiza en el espacio de usuario. Para un análisis más detallado por proceso, remito, si es necesario, a Contabilidad por procesos, con el fin de analizar los datos de uso de forma estructurada.

Comprobar de forma específica el consumo de memoria

En lo que respecta a temas relacionados con la RAM, ofrece -r información valiosa, por ejemplo, con pidstat -r -p 1234 1. Observo cómo evoluciona la memoria ocupada virtualmente y la memoria residente a lo largo de varios minutos, y si aumentan los errores de página. Si el consumo aumenta de forma constante en pequeños incrementos, detecto posibles fugas a tiempo. Si la demanda se mantiene constante y solo aumenta en breves intervalos, eso indica un uso legítimo Almacenamiento en caché . Gracias a la medición por intervalos, puedo distinguir claramente los valores atípicos de las tendencias reales.

Comprender las operaciones de E/S y los cambios de contexto

Con -d Muestro la actividad de lectura y escritura por proceso y, de este modo, identifico las causas de los tiempos de espera elevados en el dispositivo de almacenamiento. Las altas velocidades de transferencia, junto con el aumento de las latencias, indican la existencia de cuellos de botella en el almacenamiento. Además, compruebo con -w los cambios de contexto por segundo, ya que un número excesivo de cambios puede generar una sobrecarga innecesaria. Un gran número de cambios voluntarios (vswch/s) indica sincronización; un gran número de cambios forzados (cswch/s) indica una fuerte competencia por el tiempo de CPU. Así es como detecto las cargas de trabajo ineficientes, que luego optimizo de forma específica.

Supervisar subprocesos e identificar puntos críticos

¿Utilizo -t, pidstat proporciona además valores de subprocesos por cada proceso. Así puedo ver si algún trabajador concreto de una aplicación se sale de lo normal. En el caso de Java, PHP-FPM, bases de datos o trabajadores de colas, esto me permite detectar subprocesos que consumen demasiada CPU o que hacen que aumente el uso de memoria. Si detecto desequilibrios, ajusto los grupos de subprocesos, las afinidades o Límites . Esta perspectiva me ayuda a optimizar no solo los procesos, sino también su paralelismo interno.

Resumen de las opciones más importantes

Utilizo los interruptores principales de forma específica para Análisis conducir de forma centrada y mantener los resultados legibles. La siguiente tabla resume de forma concisa las opciones principales y los usos típicos. Así puedo seleccionar rápidamente el conmutador adecuado para la CPU, la memoria, las E/S, los subprocesos o los filtros. Los ejemplos me ayudan a empezar sin rodeos. Cada línea me ofrece una visión clara Nota en función del uso previsto.

Opción	Función	Ejemplo
-u	Mostrar el uso de la CPU por proceso	pidstat -u 1
-r	Valores de memoria y de fallos de página	pidstat -r -p 1234 2
-d	Actividad de E/S de lectura/escritura	pidstat -d 1
-w	Cambio de contexto por proceso	pidstat -w -p 1234 1
-t	Mostrar estadísticas del hilo	pidstat -t -p 1234 1
-p	Limitar a un ID de proceso concreto	pidstat -u -p 1234 1
-C	Filtrar procesos mediante comandos	pidstat -C php-fpm 2

Filtros, intervalos y seguimiento específico

Tengo previsto realizar mediciones con Intervalos, que se ajustan a la pregunta: segundos para los velocistas, minutos para los fondistas. Sobre -p y -C De este modo, limito la salida a los procesos relevantes y mantengo la consola ordenada. pidstat 2 10 Es ideal para pruebas breves; si no se especifica un número, la medición se prolonga hasta que la detengo. Para comprobaciones periódicas, guardo los comandos en scripts y documento los Línea de base de un sistema. Esta rutina ahorra tiempo si vuelven a surgir problemas de carga.

Comparación con Top, PS y demás.

Para echar un vistazo rápido, utilizo top o P.D., pero para ver la evolución y el nivel de detalle recurro a pidstat. Los valores por intervalos me permiten identificar las causas a lo largo del tiempo, en lugar de limitarme a ver los síntomas. Si necesito un análisis más detallado de los cuellos de botella de la CPU, complemento el análisis con Linux perf para muestras aleatorias de las pilas de llamadas. Así es como combino las estadísticas de procesos con el análisis de rendimiento cuando los valores de carga de trabajo por sí solos no son suficientes. Esta combinación me proporciona indicaciones rápidas y una base sólida Diagnóstico.

Consejos prácticos para el día a día

Tengo preparados unos comandos que han dado buenos resultados y los adapto según la situación para Sistemas de producción. Carga de la CPU en tiempo real: pidstat -u 1. Memoria con enfoque: pidstat -r -p 2. Comprobar si hay un cuello de botella en E/S: pidstat -d 1. Hilos destacados: pidstat -t -p 1. Para una instrumentación más detallada del sistema, recomiendo además Consejos sobre bpftrace cuando los eventos del núcleo requieran Spotlight.

Cómo interpretar correctamente los resultados: líneas temporales y sistemas multinúcleo

Me fijo en cómo pidstat establece las referencias temporales: El primer bloque de mediciones Muestra, de forma predeterminada, los valores medios desde el inicio del proceso (o desde el arranque del sistema); todos los bloques siguientes se refieren al Intervalo. Para realizar análisis detallados, a menudo ignoro el primer bloque y solo tengo en cuenta los valores de los intervalos comparables en el tiempo.

En Sistemas multinúcleo Siempre interpreto el valor %CPU en el contexto de los núcleos disponibles. Un único proceso puede alcanzar teóricamente hasta 800% en un host de 8 núcleos si se escala a través de varios hilos. Los valores elevados de %system me hacen pensar en llamadas al sistema, contienda por bloqueos o colas de espera de E/S; los valores elevados de %usr indican rutinas que requieren un gran esfuerzo de cálculo en el espacio de usuario. La marca de tiempo que precede a cada línea permite identificar claramente los valores atípicos en la evolución y facilita la correlación con registros o métricas de otras fuentes.

Metodología: formular hipótesis, seleccionar el intervalo de medición

Nunca empiezo a ciegas, sino que formulo una Hipótesis En cuanto a la causa: „Limitado por la CPU en el espacio de usuario“, „Atasco en la cola de E/S“, „La memoria crece constantemente“. A partir de ahí, determino el intervalo de medición: en el caso de picos breves, utilizo intervalos de 1 a 2 segundos; en el caso de Esquiadores de fondo más bien entre 10 y 60 segundos. Lo importante es ajustar la ventana a la Dinámica del sistema para no perder detalles ni captar un ruido excesivo.

Además, mido antes y después Cambios (por ejemplo, lanzamiento, ajuste de la configuración), para que los efectos se reflejen en las métricas. Una clara Línea de base por entorno (DEV, STAGE, PROD) me ayuda a distinguir las desviaciones reales de los patrones normales.

Registro permanente y seguimiento

Cuando se trata de problemas difíciles de abordar, tomo notas durante un periodo de tiempo determinado y luego las analizo. Ejemplo: pidstat -udwt 2 900 > /var/log/pidstat_$(date +%F_%H%M).log Recopila datos sobre la CPU, las E/S, los cambios de contexto y los subprocesos durante 30 minutos, con una frecuencia de 2 segundos. Puedo generar un texto estructurado con grep, awk o un guion breve procesos posteriores, marcar picos y extraer los PID más destacados. Para las observaciones recurrentes, tengo previsto un Esquema de rotación y reserva solo los intervalos de tiempo relevantes para ahorrar espacio.

Cuando necesito varias perspectivas, combino los cambios en una sola ejecución, en lugar de iniciar varias herramientas en paralelo. Esto mantiene la precisión de los resultados de medición sincrónico y facilita el análisis.

Contenedores, espacios de nombres y PID

En entornos de contenedores se aplica lo siguiente: Los PID tienen un espacio de nombres. Si realizo la medición en el host, veo los PID del host; si la realizo en el contenedor, veo los PID del contenedor. Por eso, para una identificación inequívoca, prefiero filtrar por nombre de comando con -C que con un único PID, que cambia tras un reinicio. Si trabajo desde el host, completo el contexto del proceso (por ejemplo, mediante el nombre del servicio o del pod en los registros) para poder asignar posteriormente los valores de medición de forma clara a un Carga de trabajo asignar. En el caso de los registros de larga duración, evito la trampa del PID (Reutilización de PID) también mediante filtros de nombres o mediante registros complementarios que documentan la duración del PID.

Mediciones fiables en la producción: costes generales, derechos y protección de datos

Sobrecarga: pidstat lee principalmente de /proc y apenas requiere esfuerzo de medición. Cuando los intervalos son muy cortos en hosts muy cargados, aumento ligeramente el intervalo (por ejemplo, de 1 a 2 segundos) para reducir aún más el impacto en la CPU. Mido de forma selectiva (¡filtros!) en lugar de „todo, en todas partes“.

Derechos y seguridad: Dependiendo de la configuración del sistema (hidepid en /proc) los detalles no son visibles para todos los usuarios. En el entorno de producción, trabajo con derechos ampliados cuando es necesario, mantengo la duración de la medición breve y compruebo si se muestran los datos completos Líneas de comandos podría revelar parámetros sensibles. Los registros con datos de diagnóstico solo deben almacenarse en lugares donde se guarden y se eliminen de forma segura.

Reconocer rápidamente los patrones típicos

• Sistema 1TP1 elevado con %usr moderado: Indicación de puntos críticos cercanos al núcleo (uso intensivo de llamadas al sistema, contienda por bloqueos, rutas de controladores de red y almacenamiento). Lo correlaciono con los valores de E/S y los cambios de contexto.
• Muchos cambios de contexto forzados (cswch/s): Fuerte competencia por el tiempo de CPU, a menudo debido a una escasez de recursos de CPU o a un exceso de subprocesos activos. Reducir la carga, ajustar el tamaño de los pools o Afinidades Compruébalo.
• Muchos cambios de contexto voluntarios (vswch/s): Sincronización marcada o rendimientoColas de espera basadas en [...]. Analizo los bloqueos, las estrategias de retroceso y el comportamiento de los grupos de subprocesos.
• Almacenamiento en constante aumento: Sospecha de fuga. Voy a comprobar si Fallos de página (en particular majflt) y si el proceso libera memoria tras los picos de carga. Si no lo hace, lo compruebo con una medición a intervalos más largos.
• Altas velocidades de transferencia de E/S con un rendimiento reducido del sistema: Si se tienen en cuenta los tiempos de espera, los valores de E/S del proceso indican que hay cuellos de botella en la pila de almacenamiento subyacente. Doy prioridad a las medidas de optimización de la E/S (procesamiento por lotes, almacenamiento en caché, E/S asíncrona).
• Hay algunos hilos que destacanCon -t identifico el „hilo activo“ y ajusto el grupo de hilos o analizo de forma específica su ruta de ejecución.

Flujos de trabajo en la práctica

Identificar los procesos limitados por la CPU: En primer lugar pidstat -u 1 a nivel global, y luego de forma específica con -p o -C. Si suben %usr, busco el hilo destacado con -t y, a continuación, si es necesario, lo analizo con el Sampling Profiler. Si predominan los sistemas %s, echo un vistazo adicional a las E/S y a los cambios de contexto.

Confirmar la fuga de memoria: Durante varios minutos con pidstat -r -p 5 observar. Estoy documentando un aumento constante sin descensos tras las fases de carga. Al mismo tiempo, compruebo si las tasas de errores de página o los patrones de E/S explican este comportamiento. Si la tendencia persiste sin una justificación válida, se trata de un claro Indicador de fugas.

Detectar atascos de E/SCon pidstat -d 1 Identifico los puntos críticos de lectura y escritura. Si observo una carga de escritura significativa provocada por unos pocos procesos, me centro en sus rutas de vaciado y sincronización, así como en los tamaños de los lotes. La correlación con los cambios de contexto me ayuda a ver si la CPU se ve sometida a presión al mismo tiempo.

Corregir el desequilibrio de la rosca: pidstat -t -p 1 Me muestra la carga y los cambios de contexto por cada hilo. Si un trabajador se calienta mucho más que el resto, ajusto el tamaño de los grupos, la distribución de tareas o Afinidad y comprueba si la distribución se normaliza en los siguientes intervalos.

Limitaciones de pidstat y complementos útiles

pidstat muestra qué consume recursos y cuando sucede; eso no explica automáticamente lo por qué en la ruta del código. Para averiguar el „porqué“, utilizo además el perfilador de muestreo o los puntos de seguimiento del kernel. En cuestiones relacionadas con la memoria, pidstat muestra las tendencias, pero no los ciclos de vida de los objetos. Por lo tanto, considero que pidstat es Personal de primera intervención, que me permite identificar las áreas problemáticas con el mínimo esfuerzo. Cuando los valores de carga de trabajo por sí solos ya no son suficientes, profundizo en el análisis de forma específica con las herramientas ya mencionadas.

Lista de comprobación para una puesta en marcha rápida

• Concretar la pregunta: ¿CPU, RAM, E/S, subprocesos o cambios de contexto?
• Seleccionar intervalo: Segundos para los picos, minutos para las tendencias.
• Aplicar filtros: -p o -C utilizarlo para que la salida sea concisa.
• Primero, una visión general; después, centrarse en lo esencial: Empezar de forma global, filtrar los procesos que llaman la atención.
• Colocar el primer bloque: La primera línea es el promedio desde el inicio; a partir de ahí, se comparan los valores de cada intervalo.
• Limitar la duración de la medición: Recopilar suficientes datos para detectar tendencias, pero sin perder el control sobre los registros.
• Documentar: Registrar la línea de base, la hipótesis, los parámetros de medición y las observaciones: eso es lo que hace que los análisis sean reproducibles.

Brevemente resumido

Con pidstat Obtengo datos de proceso basados en el tiempo sobre la CPU, la RAM, las E/S, los subprocesos y los cambios de contexto, lo que me permite identificar las verdaderas causas de los patrones de carga. La combinación de filtros, intervalos e indicadores claros hace que los análisis sean específicos y reproducibles. Detecto tendencias, en lugar de dejarme engañar por instantáneas, y aplico las medidas correctivas adecuadas. Comandos como pidstat -u 1, -r, -d y -w cubren los casos más habituales. De este modo, consigo que los sistemas sean transparentes, las decisiones rápidas y los diagnósticos comprensible.