Diagnóstico del tiempo de CPU robado (steal time) en hosts Linux virtualizados con mpstat y vmstat

Objetivo

Distinguir el agotamiento real de CPU del tiempo que la vCPU de una máquina virtual pasó esperando a que su host la planificara, antes de buscar una solución a nivel de aplicación que no puede existir.

Requisitos previos

Un invitado Linux que se ejecute bajo un hipervisor (KVM, Xen, VMware o una VM en la nube) que exponga al invitado un reloj de steal time (KVM y Xen lo hacen; no todos los hipervisores ni todos los kernels invitados lo reportan). Se necesita el paquete sysstat para mpstat y procps para vmstat; normalmente vienen preinstalados o se pueden instalar de forma no interactiva (DEBIAN_FRONTEND=noninteractive apt-get install -y sysstat / dnf install -y sysstat).

Pasos

1. Obtén un desglose por CPU en una ventana corta: mpstat -P ALL 1 5. El manual de sysstat define %steal como el porcentaje de tiempo que la CPU virtual pasó en espera involuntaria mientras el hipervisor atendía a otro procesador virtual: es tiempo en el que el kernel del invitado quería ejecutar algo pero no pudo, no tiempo dedicado a hacer algo.
2. Contrasta con una segunda herramienta: vmstat 1 5. La columna st está documentada como tiempo robado a una máquina virtual; debería seguir aproximadamente el valor de %steal en la fila all de mpstat. Ignora la primera línea de vmstat, que es un promedio desde el arranque y no del intervalo actual.
3. Fíjate en el patrón, no solo en el número: si el steal se reparte de forma uniforme entre todas las CPU durante el intervalo, sugiere contención de planificación en todo el host; si solo aparece mientras tu propia carga está limitada por CPU, sugiere que el host está sobreasignado para ese tipo de carga. El steal se acumula únicamente mientras una vCPU tiene trabajo por ejecutar, así que un invitado mayormente inactivo muestra poco steal incluso en un host saturado.
4. Trátalo como una cuestión de ubicación o de capacidad, no como un error de código: nada en el invitado puede mostrar qué hacían las máquinas virtuales vecinas en ese momento. Un steal sostenido y significativo (muy por encima de las fluctuaciones breves de un solo dígito) merece plantearse a quien controle el hipervisor. En tipos de instancia en la nube con rendimiento "burstable" (ráfagas), el agotamiento de los créditos de CPU también puede aparecer como steal.
5. En hardware físico (bare metal), %steal y st son estructuralmente cero, ya que no hay hipervisor que retenga CPU; una lectura distinta de cero sugiere que el sistema es en realidad un invitado, al contrario de lo que se suponía.
6. Si además controlas el hipervisor, correlaciona con sus propias métricas por VM de CPU-ready o de espera del planificador, que confirman desde el otro lado lo que el invitado solo puede inferir.

Resultado esperado

Una separación clara entre "la aplicación usó toda la CPU que se le asignó" (steal bajo, us/sy altos) y "a la aplicación se le negó CPU que pedía" (steal significativo y sostenido), lo que cambia el siguiente paso: de perfilar código a una conversación sobre capacidad.

Límites y base de verificación

Ambos comandos son de solo lectura; no hay nada que respaldar ni deshacer. Ninguna de las dos herramientas puede señalar qué inquilino causa la contención. Además, algunas configuraciones de hipervisor (CPU pinning, núcleos dedicados) nunca producen steal ni siquiera bajo carga, y algunos hipervisores no reportan el steal al invitado, de modo que un steal igual a cero no prueba por sí solo que no haya contención en el host. Las definiciones citadas son las de las propias herramientas, no un umbral de gravedad universal.