«El servidor va lento, dupliquemos la RAM» es el reflejo más caro del hosting. A veces acierta. Muchas veces la máquina está esperando al disco o la CPU va al límite, y la memoria nueva se queda sin hacer nada mientras la factura se duplica.
Así que antes de hablar de quién necesita 64 GB, veamos qué te falta de verdad. Si solo buscas cifras típicas de memoria por tipo de carga, están en nuestra guía anterior Cuánta RAM necesita un VPS, incluida la fórmula para modelos de lenguaje. Este artículo va de diagnóstico: RAM, disco o CPU.
Tres comandos, dos minutos
Ejecútalos en el servidor lento mientras va lento, no a las cuatro de la madrugada cuando no pasa nada:
free -m
vmstat 1 10
cat /proc/pressure/cpu /proc/pressure/memory /proc/pressure/io
Así se leen sin manual.
free -m. Ignora la columna free; Linux llena a propósito la memoria sobrante con caché de disco. Mira available. Si en una máquina de 2 GB marca unos pocos cientos de megas y el used del swap no para de crecer, vas justo de memoria.
vmstat 1 10. Cuatro columnas cuentan casi toda la historia:
| Columna | Qué significa | Apunta a |
|---|---|---|
si / so | páginas que entran y salen del swap por segundo | RAM |
wa | % del tiempo en que la CPU espera al disco | disco |
us + sy | % del tiempo en que la CPU trabaja | CPU |
st | % del tiempo en que el hipervisor dio tu CPU a otro | CPU (vCPU repartida con otros) |
Algún valor distinto de cero en si/so de vez en cuando es normal. La señal real es un swap constante, segundo a segundo.
/proc/pressure/*. El más honesto de los tres. Cada archivo muestra qué parte del tiempo hubo tareas paradas esperando ese recurso. some avg60=25.00 en memory significa que durante el último minuto algo estuvo esperando memoria una cuarta parte del tiempo. El archivo con los números más altos es tu cuello de botella.
Si es el disco
wa alto, mucha presión de io, poco swap. La causa típica es una base de datos o una aplicación con muchos logs que lee más de lo que cabe en caché.
Aquí viene el giro: más RAM puede arreglarlo, porque Linux cacheará más disco. Si tu base de datos ocupa 6 GB y la parte caliente son 3 GB, pasar de 2 GB a 8 GB de memoria puede hacer desaparecer el problema de disco. Pero si la base ocupa 300 GB y cada consulta toca una parte distinta, ninguna cantidad razonable de RAM la va a cachear. Entonces la solución son mejores índices, consultas más pequeñas o una organización de datos distinta. Todas las tarifas aquí van sobre NVMe, así que el disco en sí rara vez es lo lento. El patrón de acceso, normalmente sí.
Si es la CPU
us+sy altos, presión de cpu, sin swap, poca espera de disco. Compresión, compilaciones, codificación de vídeo, procesamiento de imágenes, cálculo criptográfico. Más memoria no ayuda en absoluto.
Vigila también st. En un VPS, una vCPU es una porción del tiempo de un núcleo físico, no el núcleo entero: la cifra de la tarifa es un techo para picos, y una carga completa sostenida puede limitarse para que sea justo para todos en la máquina. Si tu tarea necesita todos los núcleos al 100 % durante horas, es una cuestión de la carga, y preferimos decírtelo ahora que después de que compres una tarifa mayor.
Si de verdad es la RAM
Swap constante, presión de memoria al alza, el OOM killer en dmesg. Ahora la pregunta es cuánta.
2 GB bastan, a menudo durante años, para: uno o unos cuantos bots, una API pequeña, una VPN, una web estática detrás de Nginx, unos scrapers con cron, un agente de monitorización. Micro te da 2 vCPU, 2 GB y 25 GB por 5 $ al mes con NAT, o 10 $ con su propia IPv4.
4–8 GB es el punto medio cómodo: una aplicación web con su base de datos, un índice de búsqueda pequeño, automatización de navegador headless, un par de agentes funcionando a la vez.
32–64 GB es para datos que tienen que vivir en memoria:
- una base de datos cuyo conjunto de trabajo ocupa decenas de gigabytes, para que la caché retenga de verdad los datos calientes;
- una caché o cola en memoria grande que no puede pasar a disco sin ralentizarlo todo;
- un índice vectorial para búsqueda sobre millones de fragmentos (cifras reales en RAG autoalojado a gran escala);
- la inferencia en CPU de un modelo de lenguaje mediano, donde los pesos tienen que caber en la RAM;
- consolidación: diez servicios que antes vivían en diez servidores pequeños.
Para eso está Pro-64: 12 vCPU, 64 GB de RAM, 600 GB de NVMe y una IPv4 dedicada por 70 $ al mes. Los escalones intermedios son Pro-32 por 40 $ y Pro-48 por 55 $; por encima, Pro-80 por 90 $. La disponibilidad de ubicaciones para las tarifas Pro se ve al hacer el pedido.
Dónde no encaja una máquina grande
Tres casos en los que 64 GB es la respuesta equivocada, aunque te lo puedas permitir.
Trabajo con GPU. Ninguna de estas tarifas tiene GPU. Si tu modelo la necesita para entrenar o para inferencia rápida, una máquina con CPU y mucha RAM lo ejecutará, despacio, y pagarás por la paciencia.
Tareas sostenidas a CPU completa. Como antes: las vCPU son capacidad para picos. Doce de ellas al 100 % las veinticuatro horas no es para lo que está pensado un VPS.
Y el «por si acaso». Si los tres comandos no muestran presión de memoria, los 60 GB extra son caché para archivos que no lees. Empieza más pequeño. Pasar a una tarifa mayor del mismo tipo de red añade vCPU, RAM y disco sin moverte, con un reinicio, como se explica en Cambiar de tarifa. Bajar en el sitio no se puede, así que comprar de más tiene un coste real: para reducir migras a un servidor nuevo, y mudar un VPS sin cortes es una tarea que preferirías no necesitar.
Si comparas tarifas de distintos proveedores, cómo leer las especificaciones de un VPS explica lo que prometen de verdad las cifras de vCPU, disco y puerto.
Comentarios
Aún no hay comentarios. Sé el primero.