Su SaaS se ejecuta en un VPS de cuatro vCPU. En un martes normal, la API p95 pasa de 120 ms a 800 ms sin implementación ni picos de tráfico. La CPU del “usuario” sigue siendo modesta, pero el “%robo” oscila entre el 12 y el 25%. El soporte responde: "Ningún incidente en la plataforma. » Tiene razón: es el modelo económico compartido, no una avería en el sentido clásico.
Robo de CPU (%st en top o vmstat) mide el tiempo en que su máquina virtual quería procesador pero el hipervisor lo entregó en otro lugar, a menudo a un vecino ruidoso que inicia copias de seguridad, compila en CI o satura el disco y la CPU al mismo tiempo.
Leer top, vmstat y monitoreo de la nube
En la línea superior de la CPU, la columna st (robar) debe leerse con el resto: us (usuario), sy (sistema), id (inactivo), wa (espera de E/S). Un alto robo con un bajo consumo y un aumento de la latencia de las aplicaciones son puntos para la contención del host, no de su código.
Correlacionarse con la hora: las copias de seguridad vecinas a las 02:00 UTC, las compilaciones nocturnas o las campañas de marketing de otro cliente en el mismo hipervisor producen firmas repetitivas. Un gráfico de robo durante siete días, con una granularidad de un minuto, vale más que una captura superior en el momento de la denuncia.
¿Robo u otra causa?
Antes de abrir un ticket, descarta pistas falsas:
| Síntoma | Pista probable |
|---|---|
| st alto, nosotros bajo, latencia api alta | Vecino ruidoso/host cargado |
| wa alto | Cuello de botella en disco o almacenamiento remoto |
| nosotros alto en casa | Código, consultas SQL, trabajadores |
| identificación baja en todas partes | Subdimensión general |
Perfila la aplicación un día completo. Acusar al anfitrión sin curva de robo es una opinión; Presentarle un robo correlacionado con p95, es una negociación.
Instancias ampliables versus instancias de robo puro
En instancias con créditos de CPU (familias T en ciertas nubes), distinga entre robo y agotamiento de créditos. Las métricas difieren, al igual que las soluciones: actualización de nivel ampliable, cambio a una instancia de CPU fija o migración a otro tipo de oferta. Combinar los dos diagnósticos genera actualizaciones innecesarias.
Compila CI en el mismo VPS que la API de producción: el robo afecta tanto a las compilaciones como a las solicitudes de los usuarios. Separe los corredores de CI tan pronto como el robo supere su umbral interno.
Soporte y evidencia de escalada.
Cree un paquete de evidencia: robo de gráficos durante siete días, API p95 en la misma ventana, tipo de instancia, identificador de host si se conoce, evaluación comparativa de CPU/disco antes y después de una posible migración. Solicite migración de host o crédito, no un "esto es normal en compartido" sin datos.
Antes de firmar, defina un SLO de robo interno (por ejemplo, menos del 3 % de soporte en producción, más tolerante en puesta en escena). En el momento de la renovación, compare tres hosts candidatos con la misma configuración: elección basada en datos, no sentida el viernes por la noche.
Decide y avanza sin puntos ciegos
Primer gráfico de "% robo" durante siete días con correlación de latencia de API. Luego perfile la aplicación por un día para descartar un cuello de botella interno. Abra un ticket con evidencia cifrada y solicite la migración del host o el cambio a un nivel de CPU garantizado. Documente su umbral de robo aceptable por entorno. Si el soporte se niega sin otra alternativa, compare los hosts a través del directorio y el comparador reproduciendo el mismo punto de referencia.
Preguntas frecuentes
¿Qué robo es aceptable?
Casi 0% vacío. Bajo carga sostenida, más del 5-10% amerita investigación. Siguen siendo posibles picos cortos en sistemas compartidos; un robo permanentemente alto indica una competencia real por parte del anfitrión.
¿Cómo medir el robo?
top o vmstat (%st), sar -u, monitoreo de la nube por un minuto durante varios días. Correlacione el robo y la latencia de las aplicaciones durante el mismo período.
¿Es suficiente aumentar el tamaño del VPS?
A veces (menos vecinos por corazón), pero eso no está garantizado. Prefiera vCPU dedicada o ofertas de CPU garantizadas si sus ingresos dependen de la API p95.
¿Diferencia con la aceleración explosiva?
El robo proviene del hipervisor. La limitación se refiere a los créditos de CPU de las instancias ampliables. Los dos se pueden combinar; diagnosticar por separado.
Archive un gráfico de robo antes de abrir el ticket de soporte; sin curva, es una opinión; con curva, es negociación.