Cómo saber si tu VPS se quedó chico antes de pagar más

Medí cuando duele, no a la mañana siguiente

Un VPS que anda lento a las 11 de la mañana no muestra nada raro a las 3 de la tarde. Las mediciones sirven si las tomás durante el problema, o si el sistema las guarda para mirarlas después. Para eso está sysstat: una vez activo, registra CPU, memoria y disco cada diez minutos, y sar muestra cómo estuvo el servidor a cualquier hora del día.

# Debian y Ubuntu
sudo apt install sysstat
sudo sed -i 's/ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
sudo systemctl enable --now sysstat
# AlmaLinux
sudo dnf install sysstat
sudo systemctl enable --now sysstat
# después: CPU, memoria y disco del día
sar -u
sar -r
sar -d

Las cuatro señales y cómo leerlas

iostat viene con sysstat. Si ninguna de las cuatro está al límite y el sitio igual tarda, el problema está en la aplicación o en la base, y un plan mayor no lo arregla.

Los números que engañan

• La carga de Linux incluye procesos que esperan al disco, no solo los que usan CPU. Una carga alta con el procesador ocioso apunta al disco.
• La memoria libre de free casi siempre es baja, porque Linux usa lo que sobra como caché de archivos. La que importa es available.
• Swap en uso no es alarma por sí sola: pueden ser páginas viejas estacionadas ahí. La alarma es que si y so, en vmstat, muestren movimiento constante.
• En top, la columna st (steal) es el tiempo que el hipervisor le dio a otras máquinas. En los Cloud VPS de InHosting los recursos están garantizados, no sobrevendidos, así que tendría que estar en cero o casi; si la ves alta de forma sostenida, avisanos.
• Si el kernel se quedó sin memoria, lo deja escrito: journalctl -k | grep -i "out of memory" muestra qué proceso cerró y cuándo.

Lo que parece falta de recursos y es otra cosa

Para ver quién pide tantas páginas, esta línea cuenta las IP con más pedidos en el registro de accesos de Nginx. En Apache, el registro suele estar en /var/log/apache2/ o en /var/log/httpd/.

sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

En qué orden actuar

1. Encontrá el proceso: top ordena por CPU con P y por memoria con M, y ps aux --sort=-%mem | head da la lista quieta.
2. Si es la base, revisá las consultas lentas antes que nada; en servidor para bases de datos está cómo medirla.
3. Si es PHP, averiguá qué dirección se estaba ejecutando: el registro lento de PHP-FPM (request_slowlog_timeout) anota el script y la función que tardaron.
4. Si es un proceso que no reconocés, revisá la seguridad antes de ampliar nada.
5. Con la causa identificada, decidí: corregir, ajustar la configuración o crecer.

Cuándo sí toca crecer, y hacia dónde

Si el recurso que se agota es el mismo todas las semanas y ya no queda nada que optimizar, el plan quedó chico. En InHosting, un Cloud VPS pasa a un plan mayor sin reinstalar: el sistema, los datos y la configuración quedan como estaban. Si lo que crece es el disco, después hay que extender la partición para usar el espacio nuevo, como se explica en ampliar el disco de tu VPS.

Cuando el plan más grande de VPS no alcanza, o necesitás hardware dedicado, RAID y más memoria, el paso siguiente es un servidor cloud. A veces rinde más separar: la base en un equipo y la web en otro, cada uno dimensionado para lo suyo.

Con el 10 % de descuento del código INH, que ya va en los enlaces de contratación. Los precios se leen de la tienda. Ver el detalle de cada plan.