No escribo esto como una reseña negativa de AVA Hosting.
Es simplemente uno de esos días de trabajo como desarrollador: un servidor funciona mal, las explicaciones obvias no encajan y, al final, Linux termina mostrando qué está ocurriendo.
Tenía un pequeño VPS KVM de AVA Hosting con:
1 vCPU
2 GB RAM
25 GB NVMeEjecutaba una carga normal de producción. Nginx estaba activo. El backend estaba activo. Había memoria disponible. El disco no estaba lleno.
Pero el servidor no conseguía seguir el ritmo.
Así que hice una observación pasiva de 60 segundos con tráfico normal de producción. Sin pruebas de estrés, sin inundación HTTP sintética y sin benchmark de disco.
El resultado:
vCPU count: 1
Average CPU user: 52.52%
Average CPU system: 8.07%
Average CPU softirq: 6.69%
Average CPU steal: 32.73%
Average CPU iowait: 0.00%
Average CPU idle: 0.00%
Maximum runnable queue: 11El dato decisivo fue 32,73 % de CPU steal. A partir de ahí, el diagnóstico cambió por completo.
Por qué me sorprendió
AVA Hosting anuncia actualmente sus VPS con la frase “Guaranteed resources — no sharing”. Sus páginas de VPS también describen una asignación de vCPU fija o dedicada y afirman que el rendimiento no debería verse afectado por otros clientes. En el material sobre Linux VPS, AVA va todavía más lejos: afirma que una carga intensiva de CPU de otro tenant alojado en el mismo host no puede introducir steal time en tu instancia. En otra página asegura que el CPU steal se elimina a nivel del hipervisor.
Son afirmaciones muy específicas. No era simplemente una página que indicaba 1 vCPU sin explicar cómo se repartían los recursos de CPU. AVA anunciaba explícitamente protección frente al mismo tipo de contención de CPU que Linux parecía estar registrando dentro de mi VM.
Qué significa CPU steal
steal es una métrica normal de Linux en entornos virtualizados. Representa tiempo de CPU durante el cual el guest tenía trabajo ejecutable, pero la CPU virtual no estaba ejecutándose realmente.
Eso es distinto de que mi aplicación consuma toda la CPU disponible. Si hubiese visto aproximadamente un 100 % en user/system, 0 % de steal y 0 % de idle, habría concluido que mi carga simplemente necesitaba más potencia de cálculo.
En cambio, aproximadamente un tercio de la contabilidad de CPU aparecía como steal.
Desde dentro del guest no puedo ver el hipervisor de AVA. No puedo conocer la carga del nodo físico, el número de VM vecinas, la política de CPU pinning ni la proporción de overcommit. Lo que sí puedo ver es lo que Linux notificaba a mi VM: la vCPU dejaba de ejecutarse repetidamente mientras había trabajo esperando.
No fue un pico de un segundo
Una única muestra mala de CPU no me habría convencido. Por eso medí la máquina de forma continua durante 60 segundos. No lancé deliberadamente ninguna prueba de estrés, tráfico HTTP sintético ni benchmark de disco.
Las muestras por segundo se repetían así:
%usr %sys %soft %steal %idle
53.54 10.10 5.05 31.31 0.00
56.44 6.93 5.94 30.69 0.00
51.52 7.07 6.06 35.35 0.00
55.45 6.93 5.94 31.68 0.00
51.49 8.91 5.94 33.66 0.00
52.53 7.07 7.07 33.33 0.00
52.48 6.93 7.92 32.67 0.00Cerca del final de la observación, el patrón seguía presente:
50.98 10.78 6.86 31.37 0.00
48.48 8.08 9.09 34.34 0.00
55.00 5.00 7.00 33.00 0.00La media completa fue:
user: 52.52%
system: 8.07%
softirq: 6.69%
steal: 32.73%
iowait: 0.00%
idle: 0.00%No era, por tanto, una anomalía breve del scheduler. Durante la mayor parte del minuto, el steal se mantuvo alrededor del 30 % o más mientras el CPU idle permanecía en cero.
Para ponerlo en perspectiva, el 32,73 % de un minuto son unos 19,64 segundos. Eso no significa que el VPS quedara congelado durante 19,64 segundos seguidos; significa que los pequeños intervalos en los que la vCPU no fue programada sumaron aproximadamente ese tiempo.
El backend no conseguía ponerse al día
El problema de CPU también era visible a nivel de aplicación. Antes de la observación, la cola de escucha del backend era:
Recv-Q: 168
Send-Q: 511Después de 60 segundos:
Recv-Q: 166
Send-Q: 511Las cifras exactas no son lo importante. Lo importante es que la cola prácticamente no se vació. La aplicación tuvo un minuto entero para recuperar terreno y siguió atrasada.
También había muchas conexiones en CLOSE-WAIT. No atribuiría ese estado por sí solo al host, porque también puede estar relacionado con la gestión de conexiones de la aplicación. Pero el conjunto era coherente:
1 vCPU
32.73% steal
0% idle
~99% CPU pressure
elevated runnable queue
backend queue not drainingEl servidor estaba vivo, pero no estaba sano.
RAM y disco no parecían ser los cuellos de botella
Comprobé las causas habituales. La memoria era:
RAM total: ~1.9 GiB
RAM available: ~959 MiB
Swap total: 2 GiB
Swap used: ~33 MiBSeguía habiendo bastante memoria disponible y no había un evento OOM evidente que explicara el comportamiento.
El sistema de archivos:
24 GB total
14 GB used
9.4 GB available
60% usedEl CPU I/O wait medio fue de 0.00%. Mientras tanto, la presión de CPU se mantuvo cerca del 99 %, el load average rondaba 3,5–4 en una VM con una sola vCPU y la runnable queue llegó a 11.
Todas las mediciones apuntaban en la misma dirección: la máquina estaba limitada por disponibilidad de CPU, no bloqueada de forma evidente por RAM o almacenamiento.
La contradicción con lo que afirma AVA
Esta es la parte que me parece más interesante.
AVA dice “Guaranteed resources — no sharing”. Afirma que el rendimiento no debería verse afectado por otros clientes. Su material sobre Linux VPS dice que otro tenant no puede introducir steal time, y otra página afirma que el CPU steal se elimina en el hipervisor.
Mi VPS de AVA mostraba:
Average CPU steal: 32.73%Desde dentro de la VM no puedo demostrar por qué ocurrió exactamente. No puedo demostrar un overselling intencionado, identificar una carga vecina concreta ni reconstruir la configuración de CPU del host de AVA.
Tampoco afirmo que todos los VPS de AVA Hosting se comporten así. Probé uno.
Pero sí puedo decir que el comportamiento medido resulta muy difícil de conciliar con esas afirmaciones concretas sobre aislamiento de CPU. Eso basta para este artículo.
Por qué no actualicé el plan
La respuesta obvia habría sido comprar más vCPU.
Si el VPS hubiese mostrado prácticamente cero steal y mi aplicación simplemente hubiese consumido un núcleo completo, la ampliación habría tenido sentido. Pero aproximadamente un tercio de la CPU observada estaba registrado como steal.
No quería pagar por más CPU virtual antes de entender por qué una parte tan grande del tiempo de ejecución de la primera vCPU ya aparecía como no disponible. Así que cancelé el VPS y pedí un reembolso.
AVA devolvió todo el dinero rápidamente
Esta parte de la experiencia fue buena.
AVA Hosting me devolvió el importe completo. Gestionaron el reembolso rápidamente y no pasaron días discutiendo conmigo sobre las mediciones de CPU. Expliqué el problema, pedí la devolución y la procesaron.
Lo agradezco.
Así que de mi experiencia salen dos conclusiones separadas: el VPS que recibí tenía un problema serio de disponibilidad de CPU, y AVA gestionó correctamente mi reembolso. Ambas cosas son ciertas.
Lo que me llevé de esta experiencia
Ya no juzgo un VPS únicamente por especificaciones como 1 vCPU / 2 GB RAM / NVMe / KVM. Esos números me dicen qué se ha provisionado, pero no cuán predecible será la disponibilidad de CPU bajo carga real.
Ahora, una de las primeras cosas que compruebo en una VM nueva es:
mpstat 1 60
vmstat 1 60
cat /proc/pressure/cpu
ss -ltnp
free -h
df -h
iostat -xz 1 60La lección más útil de mi experiencia con AVA Hosting no fue que una vCPU sea demasiado poco. Fue que un proceso en ejecución, RAM disponible y un disco aparentemente sano pueden ocultar un problema completamente distinto.
En mi caso, Linux lo dejó especialmente claro:
CPU steal: 32.73%
CPU idle: 0.00%
CPU pressure: ~99%AVA Hosting anuncia recursos de CPU sin compartir y afirma que no debería haber steal causado por cargas vecinas. Mi VPS mostró otra cosa.
Lo cancelé. AVA me devolvió todo el dinero rápidamente y sin discutir.
Y ahí terminó este día de depuración.