Cuando un servidor Linux empieza a responder con lentitud, top y htop suelen ser los primeros comandos que ejecuta un administrador. Son útiles para localizar procesos que consumen CPU o memoria, pero vmstat permite responder antes a una pregunta más importante: qué recurso está frenando realmente al sistema. En una sola línea reúne colas de ejecución, procesos bloqueados, memoria, swap, entrada/salida, interrupciones, cambios de contexto y utilización de CPU.
Las claves de vmstat en 20 segundos
vmstatofrece una fotografía conjunta de CPU, memoria, swap, procesos e I/O.r,b,si,so,waystpermiten localizar rápidamente varios cuellos de botella.- Para diagnosticar un problema actual conviene tomar varias muestras, no ejecutar solo
vmstat. vmstat -y 1evita el informe inicial basado parcialmente en estadísticas acumuladas desde el arranque.- Después toca confirmar la hipótesis con herramientas como
iostat,pidstat,freeosar.
La ventaja de vmstat no consiste en reemplazar a top. De hecho, top también proporciona estadísticas globales de CPU, incluido el tiempo de espera de I/O en las versiones habituales de procps-ng.
La diferencia está en cómo presenta la información.
vmstat permite observar simultáneamente si se acumulan tareas esperando CPU, si existen procesos bloqueados, si el kernel está intercambiando páginas con swap, cuánto I/O se mueve y cómo se distribuye el tiempo de CPU.
Eso permite decidir qué herramienta ejecutar después, en lugar de empezar buscando procesos culpables sin saber todavía si el problema está realmente en ellos.
Cómo leer vmstat sin perderse entre columnas
En Debian y Ubuntu vmstat forma parte habitualmente del paquete procps. En distribuciones de la familia Red Hat se distribuye mediante procps-ng. En muchas instalaciones estará disponible sin necesidad de añadir nada.
La ejecución más sencilla es:
vmstatPero para diagnosticar una ralentización actual resulta más útil obtener varias muestras:
vmstat 1 10El primer número indica el intervalo en segundos y el segundo, la cantidad de informes.
Una salida típica tiene esta estructura:
procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 0 2456784 128432 5234560 0 0 2 5 120 250 5 2 92 1 0El manual oficial de procps-ng agrupa las métricas en seis bloques:
| Bloque | Columnas principales | Qué ayuda a detectar |
|---|---|---|
| Procesos | r, b | Presión de CPU y tareas bloqueadas |
| Memoria | swpd, free, buff, cache | Distribución de RAM |
| Swap | si, so | Intercambio activo con almacenamiento |
| I/O | bi, bo | Lecturas y escrituras de bloques |
| Sistema | in, cs | Interrupciones y cambios de contexto |
| CPU | us, sy, id, wa, st | Dónde emplea tiempo el procesador |
Hay un detalle importante sobre la primera muestra.
La documentación de vmstat explica que el primer informe contiene medias acumuladas desde el último arranque para las estadísticas que se expresan como tasas, mientras que los datos de procesos y memoria son instantáneos. Las muestras siguientes representan el intervalo indicado.
Por eso no es completamente correcto decir que toda la primera línea describe únicamente el promedio desde el arranque.
Cuando interesa eliminarla directamente puede utilizarse:
vmstat -y 1La opción -y (--no-first) omite ese primer informe.
r: ¿hay procesos esperando CPU?
r representa el número de tareas ejecutables, tanto las que están corriendo como las que esperan tiempo de CPU.
r b
8 0Un r elevado de manera sostenida puede apuntar a presión sobre la CPU.
La comparación habitual consiste en observarlo frente al número de CPU lógicas disponibles:
nprocSi un servidor dispone de cuatro CPU lógicas y r permanece continuamente en 10, 15 o 20 mientras us o sy son elevados y id se aproxima a cero, existe una señal bastante clara de saturación de CPU.
No debe utilizarse como un límite rígido.
Un pico ocasional de r superior al número de CPU no implica necesariamente un problema. Importa la persistencia y su relación con el resto de métricas.
b: procesos esperando I/O
b contabiliza procesos bloqueados esperando que termine una operación de entrada/salida.
Un valor elevado y persistente merece atención, especialmente si aparece acompañado de un wa alto.
Por ejemplo:
r b ... us sy id wa
1 12 ... 3 4 20 73Aquí probablemente interesa dejar de mirar CPU por proceso y estudiar el subsistema de I/O.
Un siguiente paso razonable sería:
iostat -xz 1vmstat ayuda a identificar la dirección de la investigación; no indica por sí solo qué SSD, volumen, almacenamiento de red o proceso está provocando el problema.
free bajo no significa automáticamente falta de RAM
La sección de memoria suele provocar diagnósticos erróneos:
swpd free buff cache
0 180000 95000 6200000Linux utiliza deliberadamente RAM disponible como caché.
Por eso un valor pequeño en free no basta para diagnosticar presión de memoria.
Para una visión más intuitiva conviene complementar el análisis con:
free -hy prestar especial atención a la memoria available.
En vmstat, las columnas especialmente interesantes cuando existe sospecha de presión son si y so.
si y so: cuando la memoria empieza a provocar I/O
si muestra memoria recuperada desde swap hacia RAM por segundo y so, memoria enviada desde RAM a swap.
si so
0 0Tener espacio swap utilizado tampoco significa automáticamente que el servidor esté sufriendo.
Linux puede mantener en swap páginas poco utilizadas aunque en ese momento exista RAM disponible.
La señal más útil es encontrar actividad sostenida en si y especialmente en so al mismo tiempo que el sistema presenta problemas de rendimiento.
Por ejemplo:
si so
3500 5200
4200 6100
3900 5800En esa situación, parte del I/O observado puede ser consecuencia de la presión de memoria.
Culpar inmediatamente al almacenamiento podría llevar al diagnóstico equivocado.
Conviene comprobar:
free -hy revisar si se ha producido una intervención del OOM killer:
journalctl -k | grep -i -E 'oom|out of memory|killed process'Lenguaje del código: JavaScript (javascript)En sistemas donde corresponda también puede utilizarse dmesg, aunque el acceso al búfer del kernel puede estar restringido para usuarios no privilegiados.
Cinco patrones de vmstat que ayudan a encontrar el cuello de botella
El valor real de vmstat aparece cuando se combinan columnas.
Una cifra aislada rara vez basta para demostrar qué está ocurriendo.
1. Mucho r, CPU ocupada y poco wa
Un patrón parecido a este:
r b us sy id wa
12 0 86 8 5 1
14 0 88 7 4 1en un sistema con pocos núcleos apunta hacia una carga limitada por CPU.
Hay muchas tareas listas para ejecutarse, la CPU apenas está ociosa y el tiempo de espera de I/O es bajo.
El siguiente paso puede ser:
toppidstat -u 1o un perfilador como perf si hay que llegar al código que está consumiendo los ciclos.
2. Mucho b y wa
r b us sy id wa
1 14 3 5 18 74Aquí las tareas pasan tiempo bloqueadas y la CPU contabiliza mucho tiempo de espera de I/O.
Es un buen momento para investigar discos y dispositivos:
iostat -xz 1pero con una precaución: un wa alto no demuestra por sí solo que exista un disco físicamente lento.
Puede haber almacenamiento de red, límites de IOPS impuestos por una plataforma cloud, cargas sincronizadas, problemas de filesystem o diferentes patrones de I/O.
vmstat revela el síntoma; iostat y otras herramientas ayudan a encontrar su origen.
3. si y so aparecen constantemente
Si el sistema intercambia páginas continuamente entre RAM y swap mientras se ralentiza, la memoria pasa a ser uno de los primeros sospechosos.
Puede deberse a una aplicación que consume demasiado, a una carga superior a la dimensionada o a una configuración específica de memoria.
Aquí es más útil estudiar procesos y memoria que empezar optimizando el SSD.
4. st es elevado dentro de una máquina virtual
La columna st, de steal time, es especialmente interesante en máquinas virtuales.
Indica tiempo de CPU que el hipervisor empleó atendiendo otros trabajos cuando la máquina virtual podría haberlo utilizado.
us sy id wa st
35 5 25 0 35Un st elevado y sostenido puede apuntar a contención en el host físico.
La aplicación que se ejecuta dentro de la VM no siempre tiene capacidad para resolver esa situación.
Dependiendo de la infraestructura puede ser necesario cambiar el tamaño de instancia, revisar la sobreasignación del host, migrar la máquina virtual o analizar las características de la plataforma cloud.
5. Una cantidad anormal de cambios de contexto
cs muestra cambios de contexto por segundo.
in cs
3200 85000Un número grande no es necesariamente malo.
Servidores con muchos núcleos, conexiones y procesos pueden realizar miles o decenas de miles de cambios de contexto perfectamente normales.
Lo relevante es encontrar un incremento anormal respecto al comportamiento habitual del mismo sistema, especialmente si coincide con caída de rendimiento y mayor tiempo de CPU del kernel.
Entonces puede ser útil:
pidstat -w 1para estudiar cambios de contexto voluntarios e involuntarios por proceso.
No existe un número universal de cs a partir del cual un servidor esté saturado.
vmstat no sustituye a iostat, pidstat ni top
Una buena forma de utilizar la herramienta es considerarla un triaje inicial.
Cuando aparece una alerta de rendimiento, se puede empezar con:
vmstat -y 1 10A partir de ahí, el patrón observado indica por dónde continuar:
Lo que aparece en vmstat | Siguiente herramienta posible |
|---|---|
r alto + CPU ocupada | top, pidstat -u, perf |
b + wa elevados | iostat -xz, iotop |
si/so sostenidos | free, ps, smem, logs del kernel |
st elevado | Hipervisor o métricas del proveedor cloud |
cs anormal | pidstat -w, perf |
| Problema intermitente | sar, monitorización histórica |
Ese flujo evita uno de los problemas más habituales del diagnóstico de rendimiento: confundir el síntoma con el cuello de botella.
Un proceso puede aparecer esperando en top sin ser responsable del problema. Un disco puede registrar mucho tráfico porque el sistema se está quedando sin memoria. Una VM puede mostrar la CPU ocupada mientras el verdadero problema está fuera de ella, en el hipervisor.
Opciones de vmstat que merece la pena recordar
Para el trabajo diario no es necesario memorizar decenas de parámetros.
Algunos son especialmente prácticos:
# Una muestra cada segundo, omitiendo la acumulada inicial
vmstat -y 1Lenguaje del código: PHP (php)# Diez muestras con intervalo de dos segundos
vmstat -y 2 10Lenguaje del código: PHP (php)# Añadir fecha y hora
vmstat -t 1Lenguaje del código: PHP (php)# Formato más ancho
vmstat -w 1Lenguaje del código: PHP (php)# Memoria activa e inactiva
vmstat -a 2 5Lenguaje del código: PHP (php)# Estadísticas acumuladas
vmstat -sLenguaje del código: PHP (php)# Estadísticas de discos
vmstat -dLenguaje del código: PHP (php)# Estadísticas de una partición concreta
vmstat -p /dev/sda1Lenguaje del código: PHP (php)# Mostrar memoria en MiB
vmstat -S M 1Lenguaje del código: PHP (php)Aquí merece la pena corregir un detalle que aparece con frecuencia en chuletas de Internet: en la versión de procps-ng documentada actualmente, -S acepta k, K, m y M.
k y m emplean múltiplos decimales, mientras que K y M utilizan 1.024 y 1.048.576 bytes respectivamente.
vmstat -S G no figura entre las unidades admitidas por la documentación oficial actual.
La opción -S, además, no modifica las unidades de bi y bo, que el manual de procps-ng documenta en KiB por segundo.
El comando importante no es solo vmstat, sino cómo se interpreta
vmstat tiene una ventaja difícil de apreciar hasta que aparece un incidente real: obliga a observar el servidor como un sistema.
CPU, memoria e I/O no funcionan de forma independiente.
La falta de RAM puede generar swap. El swap puede disparar el I/O. Ese I/O puede bloquear procesos. Los procesos bloqueados pueden hacer parecer que la aplicación simplemente está «lenta». Una VM puede disponer de suficiente memoria y almacenamiento y aun así sufrir porque el hipervisor no le entrega el tiempo de CPU esperado.
Mirar únicamente el proceso que encabeza top puede esconder esa cadena.
Por eso una secuencia razonable ante un servidor que acaba de ralentizarse puede empezar así:
vmstat -y 1 10No porque vmstat sea capaz de explicar por sí solo cualquier incidencia, sino porque en unos segundos permite decidir si el siguiente paso debe mirar CPU, memoria, almacenamiento, procesos o virtualización.
Después llegará top, iostat, pidstat, sar, perf, iotop o la herramienta especializada que corresponda.
Ese orden importa: primero localizar la clase de cuello de botella y después buscar quién lo está provocando.
