¿VPS lento o con lag? Encuentra la causa en 10 minutos
Si tu VPS va lento, mira primero qué es exactamente lo que va lento y después revisa cuatro puntos: la CPU (carga, un núcleo al 100 % o steal time), la memoria (llena, swap o el OOM killer), el disco (iowait) y la red (ping y pérdida de paquetes). Con top, free, iostat y mtr sabrás en diez minutos cuál de los cuatro está frenando.
Instala las herramientas de antemano y así las tendrás a mano cuando algo falle:
sudo apt install htop sysstat mtr-tinySi quieres gráficas de un periodo más largo, Netdata te muestra segundo a segundo lo que hace tu VPS. Para un vistazo rápido también sirve htop, como en ver el uso de tu VPS.
¿VPS lento? Primero averigua qué va lento exactamente
«Lento» puede significar tres cosas muy distintas, y cada una apunta a un sitio diferente:
- Lag en un juego: los jugadores vuelven de golpe a una posición anterior, los bloques rotos reaparecen, los vehículos dan tirones. Normalmente el servidor no llega a sus ticks (CPU) o la conexión pierde paquetes (red).
- Una sesión SSH lenta: las letras aparecen con retraso. Eso apunta a la red, o a un VPS tan cargado que hasta tu shell tiene que esperar.
- Una web lenta: a menudo la base de datos o el disco, a veces la memoria.
Fíjate también en el patrón. ¿Va lento siempre, solo por la noche cuando todo el mundo está conectado, o siempre a la misma hora? Una hora fija suele apuntar a una tarea programada, como tu propio script de copias de seguridad o un cronjob. ¿Y se queja un jugador o todos? Si es un solo jugador, casi siempre es cosa de su propia conexión.

CPU: carga, un núcleo al 100 % y steal time
Empieza con dos cifras:
nproc
uptimenproc te da tu número de vCores, y uptime, la carga media (load average) de 1, 5 y 15 minutos. Si la carga se mantiene un buen rato por encima del número de vCores, hay trabajo en cola. Linux cuenta ahí también los procesos que esperan al disco, así que mira después en top qué está pasando. Pulsa 1 en top para ver cada vCore por separado. Normalmente verás uno de estos tres patrones:
- Todos los núcleos llenos, con valores altos en
usysy: te falta potencia de cálculo o hay un proceso desbocado. Mira enhtopqué proceso está arriba del todo. - Un núcleo al 100 % y el resto tranquilo: el problema clásico de los servidores de juegos. El hilo principal de Minecraft, FiveM o Valheim ha llegado a su techo. Más vCores no ayudan; un núcleo más rápido, sí. Por qué lo explicamos en ¿Qué es un vCore? y ¿Ryzen o EPYC para tu servidor de juegos?
- Un
stalto: steal time, el tiempo en que el hipervisor hizo esperar a tu vCore porque el núcleo físico estaba trabajando en otra cosa. Unos pocos puntos porcentuales de vez en cuando son normales con vCores compartidos. Sistse mantiene claramente alto durante un buen rato mientras tu servidor va lento, guarda la salida devmstat 1 30y adjúntala en un ticket; nuestro soporte te echa una mano.
Memoria: llena, swap o el OOM killer
free -hMira la columna available, no free. Linux usa la memoria libre como caché (buff/cache) y la devuelve en cuanto un programa la necesita, así que un free bajo es normal. Si available está casi a cero, de verdad estás lleno. Dos señales lo confirman:
- Swap: en
vmstat 1, las columnassiysoestán siempre por encima de cero. Tu VPS mueve memoria al disco y de vuelta, y eso se nota en todo. - El OOM killer: el kernel detiene un proceso cuando se acaba la memoria. Tu servidor de juegos parece entonces caerse sin mensaje de error. Compruébalo con
sudo dmesg -T | grep -i -E 'out of memory|killed process'.
Un error muy habitual con servidores Java: poner -Xmx igual a toda la memoria del VPS. Java usa más que solo el heap y el sistema operativo también necesita espacio, así que deja al menos 1 GB libre. Si tienes Minecraft con mods en menos de 8 GB, aquí la solución es simplemente más memoria.
Disco: iowait y tareas programadas
En top, wa es el tiempo que la CPU espera a que el disco termine. Si suele estar alto, mira por disco:
iostat -x 1Fíjate en r_await y w_await: el tiempo medio en milisegundos que tarda una operación de lectura o escritura, incluida la espera en la cola. En NVMe deberían ser bajos; si suben mucho, hay un proceso que tiene ocupado el disco. La columna %util dice poco en NVMe: según el manual de iostat, en dispositivos que procesan peticiones en paralelo no muestra su límite. Qué proceso usa el disco lo ves con sudo iotop (paquete iotop).
Los culpables habituales son tu propio script de copias de seguridad o un cronjob que comprime una carpeta de mundo entera, un archivo de log que crece sin control y una consulta a la base de datos sin índice. Comprueba también con df -h que el disco no esté lleno: un disco lleno provoca errores raros y bloqueos mucho antes de que te des cuenta de por qué.
Red: ping, mtr y pérdida de paquetes
Mide desde tu propio ordenador hacia el VPS:
ping -c 20 tu-ip
mtr -rwc 100 tu-ipEn Windows usas ping -n 20 tu-ip; para mtr existe allí WinMTR. mtr envía 100 rondas de un segundo y muestra la pérdida y el retardo de cada salto intermedio. Léelo así: la pérdida en un salto intermedio que no continúa hasta la última línea suele venir de un router que da baja prioridad a los pings, y es inofensiva. La pérdida que continúa hasta tu VPS incluido es real. Si se queja un solo jugador, mide también desde el VPS hacia su dirección IP.
Si todos los jugadores tienen tirones a la vez, mira primero en status.mc-node.net si pasa algo con los nodos. Todos los VPS están en Hengelo (Países Bajos); cómo determina el ping la distancia hasta tus jugadores lo explicamos en Ubicación del servidor y ping.
Específico de servidores de juegos: TPS, MSPT y hitches
Un servidor de juegos mide su propia salud, y esas cifras suelen ser más claras que top. Un servidor de Minecraft quiere llegar a 20 ticks por segundo, es decir, 50 ms por tick como máximo (MSPT). Si el MSPT sube mientras un núcleo está al 100 %, es la CPU. Si los TPS y el MSPT están bien pero todo el mundo tiene lag, es más bien la red. Por juego:
Cuándo ayuda mejorar el plan (y cuándo no)
Un plan más grande solo soluciona el cuello de botella que has encontrado:
| Lo que ves | Cuello de botella | Qué ayuda |
|---|---|---|
available casi a cero, swap o avisos de OOM | memoria | un plan más grande dentro de tu línea |
| un núcleo al 100 %, MSPT alto | velocidad por núcleo | pasar del VPS KVM al VPS Premium, o atacar los plugins y scripts pesados |
| todos los núcleos llenos | potencia de cálculo | más vCores, o repartir la carga |
st alto de forma prolongada | núcleos compartidos | ticket con la salida de vmstat, o un VDS con núcleos dedicados |
wa y await altos | uso del disco | encontrar la tarea y moverla; mejorar el plan rara vez ayuda |
| pérdida de paquetes hasta el último salto | red | revisar la página de estado, adjuntar mtr; mejorar el plan no ayuda |
Dentro de tu línea, mejoras desde el panel de cliente y pagas la diferencia por el resto de tu periodo. Si tu cuello de botella es la velocidad por núcleo, el VPS Premium con Ryzen 9 es el paso lógico: un AMD Ryzen 9 9950X* con DDR5, hasta 5,7 GHz frente a los 4,0 GHz como máximo del EPYC 7443P del VPS KVM. Si es el steal time, mira un VDS con núcleos dedicados. Cambiar de línea no se hace con un clic: cuenta con un VPS nuevo y una mudanza. Si dudas qué línea encaja, lee ¿Qué servidor VPS elegir?
* o AMD Ryzen 9 7950X3D, según el nodo.
Preguntas frecuentes
¿Por qué mi VPS va lento?
Normalmente por uno de cuatro cuellos de botella: la CPU (un núcleo al 100 % o steal time), la memoria (llena o usando swap), el disco (mucho iowait por un proceso o un disco lleno) o la red (pérdida de paquetes). Con top, free -h, iostat -x 1 y mtr ves en diez minutos cuál es. Un servidor de juegos con lag suele tener un cuello de botella de CPU en el hilo principal.
¿Qué es el steal time y es grave?
El steal time (st en top) es el tiempo en que tu vCore quería calcular, pero el hipervisor dio el núcleo físico a otro VPS. Unos pocos puntos porcentuales de vez en cuando son normales con vCores compartidos. Si se mantiene alto durante un buen rato mientras tu servidor va lento, adjunta la salida de vmstat 1 30 en un ticket, o elige un VDS con núcleos dedicados.
¿Más RAM ayuda contra el lag?
Solo si la memoria está realmente llena: available en free -h está casi a cero, tu VPS usa swap o el OOM killer detiene procesos. El lag por un hilo principal atascado en un núcleo no se soluciona con más RAM; entonces ayuda un núcleo más rápido, o menos plugins y scripts pesados.
¿Cómo sé si hay una incidencia?
Mira status.mc-node.net; ahí está el estado en directo de los nodos. Si ahí no aparece nada y solo tu servidor da tirones, busca la causa con top, free, iostat y mtr. Adjunta la salida de mtr desde tu propio ordenador cuando abras un ticket.