CPU steal en VPS: detectar vecinos ruidosos

Qué mide realmente el tiempo de CPU steal

El tiempo de CPU steal es el porcentaje de tiempo durante el que la CPU virtual estaba lista para ejecutarse, sin nada que esperar, pero el hipervisor asignó el núcleo físico a otro guest. El trabajo quedó en la cola. El núcleo estaba asignado a otro guest. Linux cuenta esos ciclos por separado y los informa como st. Así puede distinguir entre «mi servidor está ocupado» y «mi servidor está esperando su turno».

Esa diferencia es el motivo por el que existe este contador. El tiempo que sus propios procesos pasan en la CPU se informa como us (user) o sy (system). El tiempo que una tarea pasa bloqueada esperando almacenamiento se informa como wa (I/O wait). Una vCPU (CPU virtual) que puede ejecutarse, está en la cola de ejecución, no tiene operaciones de E/S pendientes y todavía no se está ejecutando se informa como st. Nada dentro de su servidor puede eliminar ese estado, porque la decisión de planificación se toma un nivel por debajo, en el host.

Esto se deriva directamente de cómo un VPS comparte una máquina física entre varios guests. La causa habitual es un vecino: otro guest del mismo nodo está usando muchos recursos, por lo que el host reparte los núcleos entre ambos. Hay una segunda causa que suele pasarse por alto. Muchos proveedores limitan una vCPU compartida a una fracción de un núcleo físico y, en varios hipervisores, ese límite aplicado se contabiliza como steal dentro del guest. Por tanto, un valor alto de st indica que el núcleo no se le asignó. No siempre indica quién lo estaba usando.

De dónde procede el valor de steal

El kernel no puede medir steal por sí solo porque no puede ver el host. El hipervisor se lo comunica. En KVM, el host escribe un contador por vCPU en una página compartida con el guest, y el guest lo acumula cuando el kernel se compila con CONFIG_PARAVIRT_TIME_ACCOUNTING, como ocurre con todos los kernels de las distribuciones. Xen informa del mismo dato mediante su área de estado de ejecución. El total llega al espacio de usuario en un único lugar:

head -1 /proc/stat

La línea cpu contiene diez contadores, expresados en ticks de USER_HZ desde el arranque y en este orden: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice. steal es el octavo valor después de la etiqueta. Todas las herramientas siguientes, vmstat, top, mpstat y cualquier exportador de Prometheus, leen ese mismo campo y convierten dos muestras en un porcentaje.

Una consecuencia es más importante que las demás. Si el hipervisor nunca exporta el contador, el campo permanece en cero para siempre y todas las herramientas basadas en él informan de un 0.0 tranquilo mientras el host está sobrecargado. KVM y Xen lo exportan. Los guests en VMware y Hyper-V suelen informar de un cero constante. Compruebe la plataforma antes de confiar en un cero:

systemd-detect-virt

Muestra el nombre de la plataforma, como kvm, xen, vmware o microsoft, y none en bare metal. Dentro de un contenedor informa del runtime en su lugar, como lxc, docker o podman, lo que proporciona información sobre el contenedor, no sobre la máquina subyacente. En kvm, un cero es una evidencia real de que el host le está proporcionando un buen nivel de servicio. En una plataforma que nunca rellena el campo, un cero no demuestra nada, y la contención debe evaluarse midiendo el tiempo de ejecución de trabajo real.

¿Cómo compruebo el tiempo de espera de CPU en una VPS?

vmstat forma parte del paquete procps. Está presente en casi todas las imágenes de VPS de Ubuntu y Debian, pero falta en algunas imágenes mínimas de contenedores. Instálelo antes de depender de él.

sudo apt-get update
sudo apt-get install -y procps
vmstat --version
vmstat 1 5

vmstat --version muestra una línea como vmstat from procps-ng 4.0.4. Si aparece, la herramienta está instalada y está leyendo contadores reales del kernel. vmstat 1 5 toma después una muestra por segundo, cinco veces.

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 1  0      0 3216484  98304 1284360    0    0     4    18   62  110  3  1 96  0  0  0
 2  0      0 3216232  98304 1284360    0    0     0     0  248  431  6  2 84  0  8  0

Busque la columna st en el bloque cpu de la derecha. Las compilaciones actuales de procps-ng muestran después una columna gu para el tiempo de invitado de KVM. Por eso, st es la segunda columna empezando por la derecha y no la última. Lea la columna por el nombre de su encabezado, porque esa posición ha cambiado entre versiones.

Dos hábitos permiten interpretar el dato correctamente. La primera línea de datos es el promedio desde el arranque, así que ignórela y lea las líneas siguientes. Una sola muestra tampoco es una medición, porque el tiempo de espera aparece en ráfagas. Ejecute vmstat 1 60 y monitorícelo durante un minuto completo antes de sacar conclusiones.

top muestra el mismo valor en su línea de resumen %Cpu(s), en el campo marcado como st:

%Cpu(s):  6.2 us,  2.1 sy,  0.0 ni, 83.9 id,  0.0 wa,  0.0 hi,  0.3 si,  7.5 st

Para ver los detalles por núcleo, añada sysstat:

sudo apt-get install -y sysstat
mpstat -P ALL 1 5

mpstat muestra una fila por CPU con una columna %steal. Esta indica si todas las vCPU están afectadas o sólo una. Para conservar el historial que necesita un ticket de soporte, guarde las muestras en lugar de leerlas directamente en pantalla:

date -u | tee -a ~/steal.log
mpstat -P ALL 1 5 | tee -a ~/steal.log

Ejecute esto desde cron durante las horas en las que sospecha que ocurre el problema. El archivo marcará la diferencia entre decirle a un proveedor «anoche funcionaba lento» y mostrarle los diez minutos exactos.

¿Qué significan los valores de steal?

• Un 0.0 estable. Es un estado normal, o la plataforma no informa de steal. Confírmelo con systemd-detect-virt antes de sacar conclusiones.
• Picos de unos pocos puntos porcentuales durante varios segundos. Es normal en cualquier nodo compartido. Se inicia la compilación de otro usuario o el host ejecuta sus copias de seguridad.
• Entre 1 y 5 por ciento de forma sostenida en un plan compartido. Es lo esperado. El precio refleja que la CPU es compartida.
• Entre 5 y 10 por ciento de forma sostenida. Es una ralentización que puede medir. Empiece a recopilar evidencias y compare las mismas horas durante varios días.
• Más del 10 por ciento durante varias horas seguidas. El nodo está sobreasignado para su carga de trabajo. Este nivel justifica abrir un ticket de soporte o migrar a otro nodo.

Considere estos intervalos como una guía de interpretación, no como una especificación, porque ningún proveedor publica una garantía de steal para un plan compartido. Evalúelos en función de lo que ejecuta. Un trabajo por lotes nocturno puede absorber un 15 por ciento de steal sin que nadie lo note. Un servicio sensible a la latencia lo refleja en p99 mucho antes de que el promedio resulte alarmante. Por eso, las cargas de trabajo sensibles a la latencia, como los bots de trading deben ejecutarse en núcleos dedicados.

¿Cuánto le cuesta el steal time?

El cálculo es breve. Si se toma una fracción s de su tiempo de CPU, un trabajo que necesita una cantidad fija de CPU tarda 1 / (1 - s) veces más tiempo de reloj. Para un trabajo que necesita 60 segundos de CPU:

[
  {
    "steal_percent": 0,
    "wall_clock_seconds": "60.0"
  },
  {
    "steal_percent": 3,
    "wall_clock_seconds": "61.9"
  },
  {
    "steal_percent": 8,
    "wall_clock_seconds": "65.2"
  },
  {
    "steal_percent": 15,
    "wall_clock_seconds": "70.6"
  },
  {
    "steal_percent": 25,
    "wall_clock_seconds": "80.0"
  },
  {
    "steal_percent": 40,
    "wall_clock_seconds": "100.0"
  }
]

Con 3 por ciento, un valor habitual en un plan compartido, el trabajo tarda 61.9 segundos en lugar de 60.0. Nadie abre un ticket por eso. Con 8 por ciento, tarda 65.2 segundos. Con 40 por ciento, el mismo trabajo necesita 100.0 segundos, y una cola que antes se vaciaba empieza a crecer.

Son valores calculados, no mediciones. El modelo supone un único hilo ejecutable y que el steal time se distribuye de forma uniforme durante el intervalo. Los servicios reales suelen verse más afectados que lo que muestra la curva, porque una pausa causada por steal time puede producirse en mitad de una solicitud, y todo lo que espera a esa solicitud vuelve a pagar ese retraso. Para obtener su propio valor en lugar de usar una fórmula, compare el rendimiento de la VPS durante una hora de poca actividad y de nuevo durante una hora de mucha actividad, registrando st en ambas ventanas.

¿Es steal o es otra cosa?

Steal se confunde fácilmente con otros síntomas. Lea los contadores juntos, en la misma línea de vmstat.

• st alto mientras r y us se mantienen bajos: el host no le está asignando el core. Eso es steal.
• r muy por encima del número de vCPU, con us alto y st cerca de cero: está ejecutando más trabajo del que sus propias CPU pueden procesar. Compare r con la salida de nproc. Esto es una sobreasignación propia, no un vecino.
• wa alto con st cerca de cero: las tareas están bloqueadas esperando al almacenamiento. Es otro problema y requiere otra solución.
• La carga media es alta mientras st y us son bajos: la cifra de carga también cuenta las tareas no interrumpibles, por lo que normalmente indica un dispositivo bloqueado o un montaje de red colgado, no un problema de CPU.

Los planes burstable requieren una consideración aparte. Proporcionan un saldo de créditos que aumenta cuando está inactivo y disminuye cuando está ocupado. Cuando se agota, el proveedor limita la instancia a una tasa base. En algunas plataformas, esa limitación se informa como steal. En otras, no es visible desde el interior y simplemente obtiene menos ciclos por segundo. Lea la descripción del plan antes de concluir que el problema lo causa un vecino.

Por qué un contenedor no muestra tiempo de steal

Steal es una propiedad de la máquina virtual, no de un contenedor que se ejecuta dentro de ella. Un contenedor de Docker en su propio VPS comparte el /proc del host, por lo que el valor de st leído dentro del contenedor corresponde al steal del VPS, que es lo que necesita. La virtualización basada en contenedores que se ofrece como VPS funciona de otra manera. Cuando lxcfs está habilitado, /proc/stat dentro del contenedor se genera a partir de la contabilidad de cgroups, y steal es cero por diseño. Una pila de monitorización que recopila datos sólo desde dentro puede mostrar un cero constante y aparentemente normal mientras la máquina física subyacente no tiene CPU disponible.

Dentro de un contenedor, el contador con un significado equivalente es la limitación por cuota de CPU. En cgroup v2:

cat /sys/fs/cgroup/cpu.stat

nr_throttled cuenta los periodos de aplicación en los que el grupo alcanzó su cuota de CPU, y throttled_usec suma el tiempo que permaneció congelado. Un valor creciente de nr_throttled significa que el proceso estaba listo para ejecutarse, pero no estaba ejecutándose. La experiencia es la misma que con steal, pero la causa es un límite que usted mismo configuró. Compruebe sus propios límites antes de culpar al host, especialmente si ejecuta sus servicios en Docker en un VPS con límites de CPU en el archivo compose. La virtualización anidada añade otro punto en el que puede perderse tiempo, porque una máquina virtual dentro de su VPS soporta el steal del VPS más su propia latencia de planificación. Téngalo en cuenta si ejecuta virtualización anidada en un VPS.

Qué hacer ante un steal sostenido

Ningún ajuste dentro del guest corrige el steal, porque el planificador que toma la decisión se ejecuta fuera del guest. Actualizar el kernel tampoco cambia la situación: la planificación consciente de la caché añadida en Linux kernel 7.2 reorganiza las tareas entre los cores que realmente se le asignaron y no puede recuperar los ciclos que ya tomó un vecino. Hay cuatro medidas efectivas.

Recopile pruebas primero. Registre las marcas de tiempo en UTC, la duración de cada episodio, la frecuencia con que se repite y si mpstat muestra que afecta a una vCPU o a todas. Una semana de muestras registradas vale más que una captura de pantalla.

Abra un ticket con esos datos. Haga dos preguntas directas: si el nodo está sobresuscrito durante esas franjas y si pueden mover su instancia. Incluya la salida de vmstat y las horas exactas. Los proveedores actúan cuando reciben una franja reproducible, y un ticket que sólo indica que el servidor está lento recibe como respuesta una solicitud para obtenerla. Cuánto de este trabajo puede delegar es una de las diferencias prácticas entre un VPS gestionado y uno no gestionado.

Solicite una migración. Mover un guest a un nodo con menos carga es una tarea habitual para un proveedor y normalmente requiere un reinicio breve. Esta solución no tiene coste y resuelve el caso común, en el que un nodo acaba alojando varios vecinos con mucha carga al mismo tiempo.

Elimine la contención mediante un plan específico. Un plan con vCPU dedicada reserva cores físicos para su instancia, por lo que el contador permanece en cero. Cuesta más cada mes y es la respuesta adecuada para una carga de trabajo que no puede tolerar esa variación. Si aún no es suficiente, o también quiere disponer en exclusiva del ancho de banda de memoria, el siguiente paso es un servidor dedicado en lugar de un VPS.

Mientras espera cualquiera de esas medidas, reduzca el impacto del steal. Ejecute menos hilos de trabajo que vCPUs tenga, porque los hilos que no pueden obtener un core sólo añaden cambios de contexto. Traslade las tareas por lotes a las horas en que el nodo está menos ocupado; ahora puede identificarlas con sus propios registros. Después, vuelva a medir con el mismo comando durante las mismas horas para determinar si el cambio funcionó, en lugar de hacer suposiciones.

FAQ

¿Cuál es un valor normal de tiempo de CPU robado en un VPS?

En un plan compartido, los picos breves y un valor sostenido inferior a aproximadamente 5 por ciento son normales, porque la CPU compartida implica que el host distribuye los núcleos físicos entre los invitados. Un valor sostenido de dos dígitos durante varias horas no es normal y justifica abrir un ticket. En un plan con vCPU dedicada, el valor esperado es 0.0, por lo que cualquier otro valor debe notificarse como un fallo. Evalúe el valor según su propia carga de trabajo: un trabajo por lotes nocturno puede tolerar tiempo robado que una API sensible a la latencia no puede.

¿Un plan más grande resolverá el tiempo de CPU robado elevado?

No por sí solo. Tener más vCPU en el mismo nodo compartido implica que hay más CPU virtuales compitiendo por los mismos núcleos físicos congestionados, y el porcentaje puede mantenerse exactamente igual. Lo que elimina el tiempo robado es una asignación de CPU dedicada o una migración a un nodo menos cargado. Una cuota mayor de una máquina ocupada sigue siendo una cuota de una máquina ocupada.

¿Por qué mi VPS muestra 0 de tiempo robado si es claramente lento?

Hay dos motivos habituales. Es posible que el hipervisor no exporte el contador, algo habitual en plataformas VMware y Hyper-V, por lo que el campo permanece en cero independientemente de lo que haga el host. Ejecute systemd-detect-virt para comprobar qué plataforma utiliza. Si no es así, el cuello de botella está en otro componente: compruebe wa para detectar esperas de almacenamiento, compare r con nproc para evaluar su propia sobrecarga y consulte /sys/fs/cgroup/cpu.stat dentro de los contenedores para detectar limitaciones de cuota.

¿Puedo reducir el tiempo de CPU robado desde mi servidor?

No puede cambiar la planificación del host desde el invitado. Sólo puede reducir su impacto. Ejecute menos hilos de trabajo que vCPU tenga, para que haya menos trabajo en la cola de ejecución esperando un núcleo disponible. Traslade los trabajos por lotes a las horas en que el nodo esté menos ocupado. Almacene los resultados en caché para que menos solicitudes necesiten CPU. Los cambios que realmente eliminan el tiempo robado, como migrar a otro nodo o usar núcleos dedicados, dependen del proveedor.