Tutoriales de VPS
Qué hacer si tu VPS está limitado (2026): cómo identificar la limitación de CPU, disco y red
Muchas personas, cuando un VPS se vuelve lento, atribuyen el problema directamente a una configuración demasiado baja o a que el proveedor sobrevende, pero la situación real no siempre es que los recursos estén realmente saturados; también puede ser que la plataforma, las cuotas, los créditos o la capa del host te estén frenando en algún límite. Este artículo gira en torno a la diferencia entre throttling y saturación normal, y desglosa las señales de limitación habituales en las tres capas de CPU, disco y red, para ayudarte a determinar si la máquina realmente no da abasto o si la instancia ya está siendo limitada.
Cuando un VPS se vuelve lento, la primera reacción de muchas personas es la misma:
- La CPU no alcanza
- La máquina es una porquería
- El proveedor sobrevende
- ¿Debería actualizar la configuración cuanto antes?
El problema es que un VPS lento no equivale necesariamente a "recursos realmente saturados".
A veces lo que ves no es una saturación normal, sino otra situación más difícil de diagnosticar: throttling (ser limitado, frenado o quedar atascado en algún límite).
Por ejemplo:
- La CPU al principio puede subir muy alto, y al rato cae de golpe a un nivel fijo
- En las pruebas de disco, por más presión que apliques, las IOPS no suben de ninguna manera
- La red está anunciada a 1Gbps, pero iperf3 siempre se queda atascado en algún valor muy redondo
- La carga de trabajo es ligera, pero la latencia empeora de repente y el monitoreo no muestra una saturación de CPU evidente
Lo más complicado de este tipo de problemas es que:
Si confundes el throttling con una falta de rendimiento normal, perderás mucho tiempo y dinero en la dirección equivocada.
Este artículo se dedica precisamente a aclarar esto: cómo distinguir "realmente saturado" de "limitado por la plataforma o la capa del host", y cómo analizar cada una de las tres capas: CPU, disco y red.
Muchos diagnósticos se desvían desde el principio porque se confunden estas dos situaciones.
| Situación | Lo que realmente estás enfrentando |
|---|---|
| Normal Saturation (saturación normal) | Tu carga de trabajo realmente agota los recursos |
| Throttling (limitación de velocidad/restricción) | La plataforma, las cuotas, los créditos, la QoS o la capa del host te frenan en algún límite |
La diferencia más intuitiva es:
- Saturación normal: el uso de recursos se acerca linealmente al cuello de botella a medida que sube la carga
- Throttling: el rendimiento "choca contra un muro" de repente cerca de cierto umbral y muestra un límite muy redondo
- Cuanto más presionas tu carga de trabajo, más suben en paralelo las métricas de recursos, hasta tope → más parece saturación normal
- Tu carga de trabajo quiere seguir subiendo, pero el rendimiento se queda atascado en un valor fijo → más parece throttling
Este es también el núcleo de todo el artículo:
Primero demuestra que te están limitando, y luego decide si actualizar, migrar o reclamar al proveedor.
Estas señales merecen que sospeches primero de throttling:
Por ejemplo:
- La CPU se queda atascada durante mucho tiempo en una línea base fija
- Las IOPS de disco siempre se detienen en un límite parecido
- El rendimiento de red se queda atascado durante mucho tiempo en un nivel fijo
La "redondez" en sí misma ya es una señal muy fuerte.
Esto se parece mucho al comportamiento cuando se agotan los créditos:
- Al principio hay burst
- Después te devuelven a la línea base
Por ejemplo:
- El uso de CPU no parece alto
- Pero los tiempos de respuesta empiezan a oscilar
- Las colas se alargan
- La sensación de lentitud del sistema es evidente
En este momento no basta con mirar solo %cpu; hay que mirar steal, iowait, créditos y el límite de rendimiento.
La fluctuación normal no será tan redonda cada vez. Chocar repetidamente con el mismo límite suele indicar que la restricción es "reglamentaria".
La CPU es la capa más común y la más fácil de diagnosticar mal.
En escenarios de VPS virtualizados, steal time es una señal clave.
Significa que:
- Tu CPU virtual quería ejecutarse
- Pero el host cedió la franja de tiempo a otra VM
Esto suele indicar contención en la capa del host, no que tu programa esté saturando la CPU.
top
vmstat 1
mpstat -P ALL 1
Fíjate sobre todo en:
st/%st
%stcerca de 0: normalmente normal%stpersistentemente alto y evidente: significa que estás esperando a que el host ceda CPU
Si tu carga de trabajo no es pesada pero %st se mantiene alto, esto no es algo que "optimizar el código" pueda resolver del todo.
Máquinas como la serie T de AWS o la serie B de Azure no están diseñadas para "ir siempre a toda velocidad", sino que:
- Acumulan créditos en condiciones normales
- Explotan cuando hace falta
- Vuelven a la línea base cuando se agotan los créditos
El error de diagnóstico más típico aquí es:
"¿Por qué la prueba de estrés fue tan fuerte los primeros 10 minutos y luego de repente ya no dio más?"
Puede que no sea que la máquina esté rota, sino que agotaste el burst.
- El rendimiento es normal o incluso muy bueno al principio
- Tras presión sostenida cae a un nivel fijo
- Los créditos se acercan a 0 en el monitoreo del proveedor
- La carga de trabajo no ha terminado, pero el límite de CPU parece haber quedado tapado
us/syson muy altos- El rendimiento sube cuando sube la carga
- Solo que al final la potencia de cálculo real es el tope
En este caso parece más "la máquina no da abasto" que "la plataforma te está frenando".
La capa de disco es la que más malentendidos genera, porque mucha gente solo mira un número: los MB/s del disco.
Pero el cuello de botella real a menudo no es el rendimiento secuencial, sino:
- IOPS
- Latencia
- Profundidad de cola
- Capacidad de lectura/escritura aleatoria
Comando habitual:
vmstat 1
iostat -x 1
Fíjate sobre todo en:
%wa%utilawait
Un iowait alto no equivale necesariamente a throttling.
Solo indica que:
- La CPU está esperando I/O
En cuanto a por qué espera, puede ser:
- El disco es realmente lento
- La cola es demasiado larga
- La latencia del almacenamiento es alta
- Las IOPS están limitadas por cuota
- Sigues aplicando presión, pero las IOPS ya no crecen
- La latencia empieza a subir de forma evidente
%utiles muy alto, pero el rendimiento no sube- Varios resultados de fio chocan con el mismo límite
fio --name=randwrite-test --ioengine=libaio --direct=1 --rw=randwrite --bs=4k --size=1G --iodepth=64 --numjobs=4 --runtime=120 --time_based --group_reporting
Lo que tienes que mirar no es "cuánto corrió en una sola vez", sino:
- Si las IOPS siguen creciendo cuando aumentan
iodepthynumjobs - Si la latencia p95 / p99 se deteriora de repente
- Si lo que se atasca es la lectura/escritura aleatoria o el rendimiento secuencial
Si aplicas presión continuamente y el resultado siempre se queda atascado en un umbral similar, se parece mucho a una cuota de I/O o a una limitación de velocidad de la capa de almacenamiento.
La capa de red es la que más errores de diagnóstico genera.
Mucha gente, en cuanto ve "velocidad lenta", lo atribuye directamente a rutas con desvíos, pérdida de paquetes o horas punta.
Esto es ciertamente habitual, pero también hay que considerar otra posibilidad:
- La propia plataforma impone restricciones a puertos, instancias, tráfico mensual o cierto tipo de protocolos
## 服务端
iperf3 -s
## 客户端
iperf3 -c <server_ip> -R
Si sospechas que un solo flujo no es preciso, también puedes probar con varios flujos.
- Un solo flujo se queda atascado en un límite fijo
- Varios flujos tampoco superan ese límite
- Pruebas en distintos momentos chocan con el mismo nivel
- Anunciado a 1Gbps, pero en la práctica parece limitado a un valor más bajo de forma sostenida
- Mala ruta
- Pérdida de paquetes
- Congestión en horas punta
- El extremo de destino es lento en sí mismo
- Problemas del ISP local
Por eso la capa de red siempre hay que mirarla en dos pasos:
- Calidad de la ruta
- Si el límite de rendimiento choca contra un muro de forma reglamentaria
Si solo fluctúa en horas punta, parece más congestión; si se queda atascado en el mismo nivel a cualquier hora, parece más una restricción.
Algunas no son throttling a nivel de instancia, sino restricciones de política del servicio, por ejemplo:
- Limitación de velocidad tras superar el tráfico mensual
- Puertos específicos / protocolos específicos frenados
- Bloqueo por defecto del puerto 25 de salida en escenarios de correo
Esto no es "preempción del host", sino una restricción en la capa de políticas del proveedor.
Si tu aplicación realmente satura la CPU, eso se llama saturación de recursos, no throttling.
Mala ruta, horas punta, pérdida de paquetes y destino lento pueden hacerte sentir "como si estuviera limitada".
También puede ser simplemente que el almacenamiento del host esté muy ocupado, o que tu patrón de acceso no sea amigable.
La puntuación es solo un síntoma, no una conclusión. Debes combinarla con:
- Métricas
- Línea temporal
- Modelo de cuotas
- Resultados reproducidos varias veces
para juzgar en conjunto.
Si ahora mismo sospechas que tu VPS está limitado, puedes seguir este orden:
Mira:
- Uso de CPU
- load
- Memoria
- iowait
- Rendimiento de red
Si la carga de trabajo en sí ya es pesada, no te apresures a culpar a la plataforma.
Fíjate sobre todo en:
- Si la CPU cae a una línea base fija
- Si las IOPS chocan contra un muro
- Si el rendimiento siempre se queda atascado en un nivel fijo
Fíjate sobre todo en:
- steal time
- créditos
- El panel de monitoreo del proveedor
- CPU: mira el comportamiento tras una prueba de estrés sostenida
- Disco: usa fio
- Red: usa iperf3
No lo ejecutes solo una vez, sino:
- En distintos momentos
- Con distintos niveles de presión
- Para ver si siempre choca con el mismo límite
Si confirmas que es throttling, entonces considera:
- Subir las especificaciones de la instancia
- Cambiar a un modelo no burstable
- Migrar de proveedor/centro de datos
- Contactar al proveedor con pruebas para comunicarte
- Comprueba si se agotaron los créditos
- Cambia a un modelo no burstable
- Evita ejecutar tareas de CPU alta a largo plazo en instancias compartidas de tipo burst
- Mira el tipo de disco actual y el modelo de IOPS
- Comprueba si necesitas almacenamiento de mayores especificaciones
- Evita meter bases de datos con muchas escrituras aleatorias en discos compartidos de baja configuración
- Mira si la descripción del plan incluye políticas de tráfico/ancho de banda/puertos
- Distingue entre enlace malo y limitación reglamentaria
- Para cargas de alto rendimiento, intenta no usar planes "baratos pero con muchas políticas de red"
Guarda pruebas antes de abrir un ticket.
No digas solo:
- "Siento que se ha vuelto más lento"
Sino que debes llevar:
- Franjas horarias
- Capturas de monitoreo
- Salidas de fio / iperf3 / vmstat / iostat
- Resultados de varias repeticiones
Así al proveedor le resultará más difícil despacharte con una respuesta de plantilla.
Estas cargas de trabajo son especialmente vulnerables a restricciones que "parecen pequeñas pero hacen mucho daño":
- Servicios de base de datos
- Sitios de descargas
- Servicios de proxy/gateway/retransmisión
- Servicios de API de alta concurrencia
- Nodos de compilación CI/CD
- Tareas de transcodificación de vídeo y procesamiento por lotes
Porque estos escenarios son muy sensibles a las siguientes métricas:
- Rendimiento estable
- Latencia de cola
- Capacidad de CPU sostenida
- I/O aleatorio
No es que vayan a ser limitados con seguridad, sino que:
una vez que se les aplica throttling, la sensación será muy evidente.
Sí. Por ejemplo, cuando el steal time es alto, los créditos se agotan o la espera de I/O es grave, la experiencia será mala, pero el uso de CPU que ves puede no ser exageradamente alto.
P2: ¿Cómo distinguir lo más rápido posible entre "la máquina es demasiado débil" y "la plataforma aplica throttling"?
Mira si existe un límite reglamentario. La saturación real se parece más a chocar contra un muro de forma lineal; el throttling se parece más a quedar atascado en un umbral redondo.
P3: ¿Una puntuación baja en benchmarks puede demostrar directamente que hay limitación de velocidad?
No. La puntuación es solo una pista, no una conclusión. Hay que juzgar junto con steal, créditos, iowait y los resultados de repetición de fio/iperf3.
Primero guarda las pruebas y los resultados de monitoreo, y luego decide si actualizar, cambiar de modelo, migrar o llevar los datos al proveedor para comunicarte.
Lo más difícil del throttling en un VPS no es "cómo resolverlo", sino cómo demostrar que lo que te ocurre no es un cuello de botella de rendimiento normal.
En realidad, todo el artículo solo quiere ayudarte a construir un marco de juicio:
- Capa de CPU: mira el steal time, mira los créditos, mira la caída de velocidad tras una prueba de estrés sostenida
- Capa de disco: mira el iowait, mira si las IOPS chocan contra un muro, mira si la latencia sube de forma anómala
- Capa de red: mira si el rendimiento se topa con un límite reglamentario, mira si existen restricciones de plan o de política de puertos
En una frase:
Primero distingue si "los recursos están realmente saturados" o si "la plataforma te está frenando", y luego decide si optimizar, actualizar o migrar.
Si ahora mismo sospechas que tu VPS está limitado, no te apresures a ejecutar solo una vez un script de prueba de velocidad. Lo realmente útil no es "creo que va lento", sino si puedes presentar un conjunto de pruebas suficientemente claras que demuestren que va lento de forma muy regular.