Cómo interpretar correctamente vmstat en Linux para un análisis eficaz del rendimiento

Te voy a enseñar a interpretar vmstat en Linux de forma eficaz: podrás detectar cuellos de botella en la CPU, presión en la memoria, uso del swap y tiempos de espera de E/S en cuestión de segundos. Así es como puedes interpretar con seguridad las columnas r, b, free, si/so, bi/bo y us/sy/id/wa/st, y deducir medidas concretas a partir de los patrones —sin tener que ir a ciegas, con borrar Normas.

Puntos centrales

• Cola de ejecución vs. bloqueos: «r» indica la carga de la CPU; «b» avisa de tiempos de espera de E/S.
• Memoria Valorar la realidad: que sea gratis no es lo único que cuenta; lo que decide es si... o si...
• E/S En resumen: bi/bo no son un problema si wa se mantiene bajo.
• Cuotas de mercado de CPU Significado: us+sy altos, id bajo → alta carga de trabajo.
• Líneas de base Elaborar: comparar los valores de la vida cotidiana con los de las etapas problemáticas.

¿Qué muestra realmente vmstat?

Vmstat agrupa los estados de los procesos, la memoria, el espacio de intercambio, las E/S de bloques y la distribución de la CPU en una salida compacta que, en cuestión de segundos, ofrece una a nivel del sistema Ofrece una buena visión general. Primero leo „procs“ para r/b, después „memory/swap“ para free, buff, cache y si/so. A continuación, compruebo „io“ con bi/bo y termino con „cpu“ para us, sy, id, wa y, opcionalmente, st. Este orden me ayuda a distinguir entre causa y efecto: un valor alto de r indica carga de cálculo, un valor alto de b apunta a tiempos de espera de E/S, y wa relaciona la inactividad de la CPU con la latencia de E/S. Así puedo detectar si el cuello de botella es la carga de cálculo, la escasez de memoria o el dispositivo de almacenamiento, y me ahorro Desvíos.

Comienza en 60 segundos: llamadas e intervalos

Para obtener una instantánea desde el arranque, ejecuto „vmstat“ sin parámetros; para análisis en tiempo real, utilizo „vmstat 1“ o „vmstat 5 12“ para obtener doce lecturas cada cinco segundos, y obtengo un temporal Fila. Importante: la primera línea refleja los valores medios desde el inicio del sistema, por lo que me fijo sobre todo en las líneas siguientes. Con „Delay/Count“ controlo la frecuencia de muestreo y la duración, por ejemplo, «vmstat 1 30» en picos breves. En cargas de trabajo irregulares, establezco entre 1 y 2 segundos; en escenarios tranquilos, más bien 5 segundos. Observo tendencias, no fotogramas individuales, porque los patrones son los que realmente Causas espectáculo.

Comprender los procesos: el «r» y el «b» en la vida cotidiana

La columna «r» muestra los hilos listos para ejecutarse que están a la espera de tiempo de CPU, mientras que «b» cuenta los hilos bloqueados, a menudo en espera de E/S. Si «r» se mantiene claramente por encima del número de núcleos físicos, se impone un Cuello de botella de la CPU ; en cuatro núcleos, un valor de r=8 durante un periodo prolongado se considera una señal clara. Un valor de b superior a 0 durante un periodo prolongado indica soportes de datos lentos, bases de datos sobrecargadas o rutas de red o almacenamiento lentas. Correlaciono r con us+sy e id: si id es bajo y r es alto, la CPU está sobrecargada; si wa es alto y b es alto, la E/S está ralentizando el sistema. Así decido si escalo la potencia de cálculo, optimizo las consultas o el Sistema de almacenamiento Compruébalo.

Interpretación de las memorias: free, buff, cache, swpd

Un valor bajo de «free» es normal en Linux, ya que el núcleo utiliza la RAM de forma intensiva como caché, lo que acelera el acceso a los archivos y proporciona una verdadera Rendimiento Por eso presto más atención a swpd y a los flujos de swap si/so que al valor de «free» por sí solo. Un nivel alto de caché es bueno, siempre y cuando si/so se mantenga casi siempre en 0; solo una actividad de swap constante indica una presión real. Si, además, se produce latencia o incluso un error OOM, intervengo: aumento la RAM, recorto procesos a tiempo o ajusto los tamaños de la caché y la JVM. El contexto sigue siendo importante: la carga de trabajo, el tamaño de la memoria y la disposición NUMA determinan lo que en tu entorno se considera saludable se aplica.

Actividad de swap: clasificar de una forma u otra

Las columnas «si/so» miden el flujo constante entre la RAM y el espacio de intercambio en KB/s y permiten visualizar la presión real sobre la memoria, no solo la que se percibe. Deficiencia. Los picos breves son normales, por ejemplo, cuando se trasladan páginas que se utilizan con poca frecuencia. La situación se vuelve crítica cuando estos valores se mantienen por encima de 0 de forma permanente; esto ralentiza todo el sistema, ya que cada operación de paginación genera una carga adicional de E/S. Los valores elevados de «so» indican una paginación activa, y los tiempos de respuesta aumentan de forma notable. En este punto, me pongo a buscar las causas: reducir el consumo de memoria, ampliar la RAM o optimizar los servicios que consumen mucha memoria. sintonizar.

Entender el E/S en bloque: bi y bo

Con bi/bo puedo determinar la velocidad de lectura y escritura en bloques por segundo, pero sin contexto no la evalúo; lo decisivo es la interacción con wa. Un valor alto de bi/bo y, al mismo tiempo, un valor alto de wa indican que el almacenamiento no da abasto. Si un valor alto de bi se da junto con una base de datos, compruebo los perfiles de consulta y las coincidencias en la caché antes de cambiar el hardware. Para un análisis más detallado de los tiempos de respuesta, utilizo iostat y analizo la longitud de las colas y las latencias, de modo que pueda Analizar la espera de E/S y pueda abordar los cuellos de botella de forma específica. Solo si wa se mantiene bajo, pero bi/bo se dispara de forma permanente, me plantearé Escala del sistema de almacenamiento.

Componentes de la CPU: us, sy, id, wa, st

Los valores altos de us con un wa bajo indican un trabajo útil productivo, mientras que los valores altos de sy apuntan a una gran sobrecarga del núcleo, como innumerables operaciones pequeñas de E/S o muchas Cambio de contexto. Si id se sitúa cerca de 0 y se mantiene ahí, la CPU está funcionando al límite; si a esto se le suma un valor alto de r, es indicativo de una elevada carga de cálculo. Si wa aumenta, la CPU está a la espera de E/S; en este caso, el ajuste fino del almacenamiento suele aportar más beneficios que las actualizaciones de la CPU. En las máquinas virtuales, presto atención a st (steal): unos valores altos de st indican que el hipervisor está desviando tiempo de CPU, por lo que hablo con el operador sobre la carga del host. Siempre evalúo us+sy como suma, ya que esto muestra la actividad Trabajo en el sistema.

Guía rápida: Columnas y valores orientativos

Utilizo la siguiente tabla como guía rápida cuando analizo los resultados de vmstat para una primera Evaluación lectura cruzada.

Columna	Significado	A qué presto atención
r	Hilos listos para ejecutarse	Permanentes > Núcleos → Presión de la CPU
b	Hilos bloqueados	Constante > 0 + wa al alza → Problema de E/S
gratis	RAM libre	Un valor bajo está bien, siempre y cuando si/so se mantenga ≈ 0
buff/caché	Búfer FS/Caché de páginas	Una gran cantidad de caché es buena; se puede publicar convertirse en
si/so	Intercambio de entrada/salida	Valor constante > 0 → presión real del acumulador
bi/bo	E/S en bloque	Solo es crítico si «wa» también es alto
us/sy	Usuario/Núcleo	us+sy de forma permanente > 80% → alta Carga
id	marcha en vacío	Cerca de 0 a lo largo del tiempo → CPU saturada
wa	Espera de E/S	Valor alto con «b» alto → El almacenamiento como causa
st	Robar (máquinas virtuales)	Alto → El hipervisor toma CPU-Hora

Líneas de referencia y seguimiento continuo

No me baso en datos puntuales, sino que comparo los valores con las referencias de épocas tranquilas para poder descartar correctamente los valores atípicos reconocer. „vmstat 1 60“ me proporciona un perfil de carga de un minuto, que comparo con las fases normales conocidas. Para obtener una perspectiva histórica, utilizo Supervisión de sar/sysstat, para evaluar las tendencias a lo largo de varios días y ajustar los valores límite. Configuro las alertas de forma conservadora: r en relación con los núcleos, si/so distinto de 0 en varios intervalos, wa notablemente elevado. Así puedo reaccionar a tiempo, antes de que los usuarios notifiquen retrasos y antes de que Pico-Las fases se agravan.

Vmstat junto con otras herramientas

Empiezo con vmstat, analizo los patrones y profundizo de forma específica con iostat, mpstat, pidstat o métricas de aplicaciones, para poder identificar las causas borrar asigna. Mientras que vmstat muestra los tiempos de espera de E/S, yo mido con iostat las latencias y las colas de cada dispositivo. Si «r» indica un límite del núcleo, mpstat muestra las asimetrías del núcleo. En momentos de máxima carga de procesos, proporciona Análisis de procesos pidstat los hilos más intensos sobre el tiempo. Solo la correlación con los registros y los tiempos de las aplicaciones aclara el panorama y me lleva a la verdadera Causa.

Detectar patrones y actuar

Si veo que «r» es alto, «id» bajo y «wa» moderado, la aplicación suele optimizar de forma que requiere un gran esfuerzo de cálculo, por lo que compruebo el código o el paralelismo y planifico los recursos de la CPU antes de Hardware Si aparecen juntos «b alto», «wa alto» y «bi/bo alto», tengo en cuenta el ajuste del almacenamiento, la optimización de consultas y el almacenamiento en caché. Si el valor de «free» es bajo y «si/so» es mayor que 0, reduzco el consumo de memoria, transmito los resultados en tiempo real o aumento la RAM. Si los valores de «us» son moderados y los de «sy» muy altos, reviso los filtros de paquetes, las opciones del sistema de archivos o los controladores. Con esta lista de comprobación, actúo con rapidez y dedico el tiempo a lo que más cuenta.

Cómo evitar errores de medición: muestreo, unidades, primera línea

A propósito, no tengo en cuenta la primera línea para detectar fallos agudos, ya que lleva promediando los datos desde el arranque y suaviza completamente los picos. Además, baso la frecuencia de muestreo en la hipótesis de la causa: capto los picos de CPU con intervalos de 1 segundo, y las fugas de memoria lentas con intervalos de 5 a 10 segundos. Tengo en cuenta las unidades: si/so son KB/s, bi/bo son „bloques/s“ (históricamente 1 KB por bloque, variable según la versión de vmstat). Compruebo si „vmstat -w“ (salida amplia) evita el recorte de columnas y si los cambios en la frecuencia de reloj (estados P, Turbo) influyen en la percepción de la carga a corto plazo. Sincronizo las mediciones con los picos de la aplicación, en lugar de fijarme ciegamente en „minutos completos“.

Descifrar la sección «System»: «in» y «cs»

Además de procs/memory/swap/io/cpu, vmstat también muestra „system“: en (interrupciones/s) y cs (Cambios de contexto/s). Estos dos valores me dan mucha información sobre la sobrecarga del núcleo.

• cs muy alto con una carga de trabajo moderada: oscilaciones de subprocesos, lotes de trabajadores demasiado pequeños o conflictos de bloqueo. Aumento el tamaño de los lotes, regulo el paralelismo (grupos de subprocesos) y compruebo los puntos críticos del programador y los mutex.
• Aumento repentino: tormentas de interrupciones de red o de almacenamiento, efectos NAPI/polling o interrupciones de temporizador. Lo comparo con el porcentaje de sy y los resultados de iostat para comprobar los controladores o las rutas de red.
• cs es proporcional a r: esto apunta a una presión constante por el cambio de contexto debido a un paralelismo excesivo. Reduzco el paralelismo activo o asigno los hilos activos a núcleos específicos.

Siempre correlaciono in/cs con sy y b/wa: solo en conjunto se obtiene una imagen clara de si el trabajo del núcleo es útil (p. ej., el rendimiento) o si se trata de una mera sobrecarga.

Variantes y opciones útiles de vmstat

Utilizo vmstat de forma flexible para obtener perspectivas adicionales sin tener que cambiar de herramienta:

• vmstat -s: Contadores acumulativos (por ejemplo, procesos iniciados desde el arranque del sistema, fallos de página mayores y menores). Ideales para comparar fugas o recuentos en intervalos de tiempo.
• vmstat -m: Uso de Slab: ayuda a clasificar las cachés del núcleo (Dentry/Inode, red) como consumidores de RAM.
• vmstat -d: Eventos de disco a nivel de totales. No sustituye a iostat, pero es útil para hacer una rápida comprobación de la situación real.
• vmstat -S M: Cambiar las unidades (M/K) para facilitar la lectura de los números.
• vmstat -w: Las columnas más anchas evitan que se corten las columnas de números largas.

Combino estas opciones con intervalos cortos para no perderme ningún evento y, aun así, mantener una visión general.

Contenedores, máquinas virtuales y cgroups: particularidades

En los contenedores, interpreto vmstat con cautela: muchos datos del núcleo son válidos para todo el host, mientras que los límites provienen de los Cgroups. Los valores altos de r en un contenedor reflejan la perspectiva del espacio de nombres, pero el tiempo real de CPU puede verse limitado por las cuotas de CPU o las cuotas compartidas de CPU. Me baso en st (Steal) en máquinas virtuales: un valor alto de st significa que el hipervisor me resta tiempo; en ese caso, ni siquiera una optimización perfecta de la aplicación sirve de mucho mientras el host esté sobrecargado. En el caso de los límites de memoria en Cgroups, puede que no se produzca ningún efecto, aunque el contenedor esté „agitado“ al llegar al límite (terminaciones por OOM en lugar de swap). Por eso, compruebo además los registros de OOM y las estadísticas de Cgroup, y comparo las imágenes de vmstat con los límites.

NUMA y afinidad: cuando la localidad es importante

En los hosts NUMA, compruebo los valores de r y us/sy por núcleo (con mpstat) y observo si algunos sockets se „sobrecalientan“, mientras que otros permanecen inactivos. Una localización de memoria inadecuada provoca un aumento de cs/sy y de b/wa debido a los accesos a memoria lejana. Pruebo la afinidad de CPU y memoria (cpuset, numactl), configuro los montones grandes como „intercalados“ o estrictamente locales y me aseguro de que los hilos activos se ejecuten allí donde se encuentra su huella de datos. Una distribución NUMA estable suaviza el cs, reduce los valores atípicos de wa y aumenta la Planificabilidad bajo carga.

Evitar malentendidos: „wa“ y «b» son algo más que «soportes de datos lentos»

El valor de wa no solo aumenta con las latencias clásicas de disco: también lo elevan las redes NFS o de alta latencia, el almacenamiento de objetos saturado, los volúmenes en la nube que provocan bloqueos o las lentas operaciones de reescritura en la caché de páginas. b cuenta las tareas en estado de suspensión ininterrumpida (estado D), entre las que se incluyen los bloqueos en controladores, rutas de red o bloqueos del sistema de archivos. Por eso nunca evalúo wa/b de forma aislada, sino siempre junto con bi/bo y los tiempos de respuesta de las aplicaciones. Si wa es alto, pero bi/bo es bajo, a menudo se debe a una Dependencia de la espera más allá de la mera cuestión del rendimiento de los dispositivos (por ejemplo, bloqueo, E/S remota, atascos de reescritura).

Optimización con sentido de la proporción: Swappiness, Writeback, Scheduler

Solo modifico Kernel-Tuner después de realizar las mediciones y con un plan de reversión:

• vm.swappiness: Un valor bajo reduce el intercambio proactivo, lo cual es bueno para aplicaciones en las que la latencia es fundamental; si es demasiado bajo, puede aumentar la presión sobre la caché de páginas.
• vm.dirty_background_ratio / vm.dirty_ratio (o *_bytes): Influyen en los momentos de reescritura. Los valores demasiado altos provocan ráfagas de escritura prolongadas (picos de wa), mientras que los valores demasiado bajos aumentan los pequeños flushinges constantes (aumentan sy/bo).
• Programador de E/S/Profundidad de la cola: En NVMe, los ajustes de Optima son diferentes a los de HDD/RAID. Mido las compensaciones entre latencia y rendimiento con iostat antes de realizar ningún cambio.
• Rutas de red: Hay muchos paquetes pequeños e interrupciones que llegan a /cs/sy. Los ajustes generales son GRO/LRO, RPS/RFS y IRQ-Affinity; realizo mediciones antes y después.

Mi objetivo es conseguir curvas estables y predecibles en vmstat: us/sy más estables, wa/b más bajas y si/so cercanas a 0. Solo entonces amplío el hardware.

Guía práctica: Análisis de 3 minutos con vmstat

• 0:00–0:30 – „vmstat 1 30“: ignora la primera línea y, a continuación, examina r/b, us/sy/id/wa. Pregunta: ¿límite de CPU (r alto, id bajo) o límite de E/S (b/wa altos)?
• 0:30–1:00 – Vista del acumulador: comprobar swpd y si/so. ¿si/so constantemente > 0? → Presión real del acumulador. free es secundario.
• 1:00–1:30 – Contexto de E/S: bi/bo frente a wa. ¿Valores altos de bi/bo sin wa? → La E/S se desconecta. ¿Valores altos de wa con valores moderados de bi/bo? → Latencia/bloqueo/E/S remota.
• 1:30–2:00 – Sección «system»: ¿in/cs en relación con sy. cs muy alto? → Presión por cambio de contexto; comprobar paralelismo/bloqueo.
• 2:00–3:00 – Consolidar la hipótesis y elegir la herramienta adecuada: iostat para el índice de E/S, mpstat para las asimetrías del núcleo y pidstat para los puntos críticos de los procesos. Solo después, pasar al ajuste y al escalado.

Ejemplos prácticos avanzados

• Saturación de la CPU sin un r elevado: us+sy en 90%+, id ≈ 0, pero r moderado → punto crítico de un solo hilo o problema de afinidad. Solución: paralelizar la ruta crítica, comprobar el «core pinning».
• Swap-Thrash: tanto si como si, al mismo tiempo, claramente > 0; b/wa aumentan, us disminuye → la RAM es claramente insuficiente o el heap está mal dimensionado. Medidas: aumentar la RAM, reducir el conjunto de trabajo, ajustar el swappiness.
• Sobrecarga del núcleo: sy alto, cs/in alto, us moderado → muchas llamadas al sistema y operaciones de E/S pequeñas. Solución: procesar por lotes, reducir las llamadas al sistema, comprobar las opciones de montaje del sistema de archivos.
• Atasco de reversiones: wa alto, bo alto, ondas cortas → los límites de «dirty» son demasiado altos, la latencia de almacenamiento varía. Revisar el ajuste de «writeback» y el programador de E/S.
• Presión por la virtualización: st visible, r fluctúa, id „salta“ → El host comparte la CPU. Solución: comprobar la asignación y la ubicación de las vCPU, reducir el overcommit.

Conocer los límites de vmstat

Vmstat es una excelente Sensor de alerta temprana, pero no es un microscopio. Me muestra que hay un atasco y dónde se produce, pero no me indica el archivo concreto, la consulta o el hilo que lo provoca. Por eso, tras el diagnóstico con vmstat, recurro sistemáticamente a herramientas más avanzadas, confirmo hipótesis desde varios ángulos y luego modifico solo una cosa tras otra. De este modo, las mejoras siguen siendo medibles y reproducibles.

Resumen de la práctica

Con vmstat puedo detectar en cuestión de segundos si la CPU, la RAM, el espacio de intercambio o las E/S están ralentizando el sistema, analizando la interacción entre r, b, si/so, bi/bo y us/sy/id/wa/st leer. Analizo las tendencias en lugar de los valores individuales, comparo con los valores de referencia y, si es necesario, recurro a iostat, mpstat, pidstat y a mediciones históricas. Ignoro la primera línea en caso de fallos agudos y me centro en las líneas siguientes, que tienen una frecuencia de muestreo fija. Tomo decisiones basadas en los datos: r en relación con los núcleos, si/so permanentemente distinto de 0, wa persistentemente elevado, us+sy cerca de la plena capacidad. De este modo, deduzco rápidamente medidas concretas y mantengo los sistemas notablemente reactivo.