Administrás un VPS donde alojás varias webs de distintos clientes, y de un día para el otro uno de esos sitios empieza a tirar error 500, otro carga a los tirones y vos ni siquiera sabés cuál de todos es el que está consumiendo de más. Cuando tenés un solo servidor con varias cuentas adentro, la memoria RAM se convierte en un recurso compartido que hay que repartir con cabeza, porque un solo cliente mal configurado puede afectar a todos los demás. La buena noticia es que este problema tiene un diagnóstico ordenado y una solución que no exige comprar un servidor nuevo apenas aparece la primera alerta.
Por qué en un VPS con varios clientes el problema se nota más rápido
Cuando manejás reventa de hosting o simplemente varios proyectos propios en el mismo VPS, cada sitio suma su propia carga de PHP, su propia base de datos y, muchas veces, sus propios plugins pesados. Si uno de tus clientes instala algo que dispara el consumo de memoria, no solo se cae su web: puede arrastrar a las demás cuentas que comparten el mismo servidor. Por eso, en un esquema multi-cliente, medir y repartir la memoria no es un lujo técnico, es lo que sostiene tu reputación frente a todos ellos al mismo tiempo.
Cómo detectarlo antes de que te llamen los clientes
- Conectate por SSH y corré free -m para ver cuánta memoria disponible queda en el total del servidor.
- Usá htop filtrando por usuario del sistema (si cada cliente tiene su propio usuario) para ver qué cuenta específica está consumiendo más.
- Revisá los logs de PHP-FPM por sitio: los errores de tipo “out of memory” quedan registrados y te dicen exactamente cuál cuenta está al límite.
- Anotá el consumo de cada cliente un día normal, así después podés comparar y detectar el cambio.
Qué significa cada número que te muestra el servidor
La salida de free -m tiene varias columnas que conviene entender bien antes de tomar decisiones: “total” es la RAM física del VPS, “used” es lo que están usando los procesos activos en ese instante, “free” es lo que nadie está tocando y “available” es lo que realmente podés usar sin que el sistema empiece a apretar. El dato que importa casi siempre es “available”, porque Linux usa memoria libre para cachear archivos y eso hace que “free” parezca bajo aunque el servidor esté sano. En htop, conviene mirar la columna “RES” de cada proceso -la memoria física real que ocupa- y no “VIRT”, que incluye memoria reservada pero no necesariamente en uso. Cuando administrás varias cuentas, filtrar por usuario del sistema en htop (tecla U) te permite ver de un vistazo cuánto le corresponde a cada cliente sin mezclar los números de todos.
Solución paso a paso
Paso 1: separá pools de PHP-FPM por cliente
En vez de un único pool de PHP compartido por todas las cuentas, configurar un pool independiente por cliente te permite ponerle un tope de memoria a cada uno. Así, si un sitio se descontrola, consume su propio límite y no le quita recursos al resto. Esto también te da un dato valioso a la hora de facturar o de conversar con un cliente sobre un upgrade: podés mostrarle exactamente cuánta memoria está usando su cuenta en particular.
Paso 2: revisá pm.max_children cuenta por cuenta
El error típico en un VPS multi-cliente es copiar la misma configuración de procesos PHP para todos los sitios, sin importar si uno recibe mil visitas al día y otro recibe cien. Ajustá ese número según el tráfico real de cada cuenta, no según una plantilla genérica. De paso, revisá pm.start_servers y pm.max_spare_servers de cada pool: es habitual encontrarlos copiados de una guía sin adaptar al tamaño real del VPS.
Paso 3: aislá o limitá la base de datos por cliente
Si todas las bases conviven en el mismo motor MySQL o MariaDB, un parámetro como innodb_buffer_pool_size mal calculado para el total del servidor puede hacer que una sola base pesada deje sin memoria a las demás. Calculalo sobre la RAM total del VPS, no sobre lo que “sobra” a ojo. Revisá también max_connections: si un cliente deja conexiones abiertas sin cerrar, eso también resta memoria disponible para el resto de las cuentas.
Paso 4: sumá caché por sitio, no una caché genérica para todos
Cada cliente tiene un patrón de tráfico distinto. Activar caché de página o de objetos (por ejemplo con Redis) en las cuentas de mayor movimiento reduce el trabajo que le pedís a PHP y a la base de datos en simultáneo, que es lo que más rápido agota la memoria cuando hay varios sitios activos a la vez. No hace falta aplicar la misma configuración a un cliente con poco tráfico: ahí alcanza con una caché más simple.
Paso 5: escalonar tareas automáticas entre cuentas
Backups, actualizaciones o tareas programadas de distintos clientes disparándose todas a la misma hora son una causa muy común de que el VPS se quede sin memoria de golpe. Programá esas tareas en horarios distintos para cada cuenta, idealmente en horarios de bajo tráfico general del servidor.
Paso 6: definí un umbral claro para ofrecer un upgrade
Una vez optimizado todo lo anterior, si seguís cerca del límite con el uso normal de tus clientes (no en un pico aislado), ese es el momento de sumar RAM al plan o de mover a algún cliente grande a un VPS propio. Tenerlo definido de antemano, con un número concreto de memoria disponible como umbral, te evita decisiones apuradas en medio de una caída y te da un argumento claro para conversarlo con el cliente.
Errores comunes que agravan el problema
- Sumar cuentas nuevas sin medir margen disponible: aceptar un cliente más sin revisar cuánta RAM libre queda es la forma más rápida de terminar todos afectados.
- Usar la misma configuración para cuentas grandes y chicas: un sitio de mucho tráfico necesita parámetros distintos a uno que recibe pocas visitas por día.
- No reiniciar servicios después de ajustar valores: cambiar pm.max_children o innodb_buffer_pool_size sin reiniciar el servicio hace que el ajuste no se aplique.
- Permitir paneles de control pesados por cliente: algunas herramientas de administración consumen por sí solas varios cientos de MB.
- No avisar a los clientes sobre buenas prácticas: un plugin mal elegido en una sola cuenta puede terminar afectando a todas las demás.
Cómo evitar que vuelva a pasar
- Llevá un registro simple del consumo de memoria por cliente, aunque sea una planilla básica.
- Definí, antes de sumar una cuenta nueva al VPS, cuánta RAM libre necesitás dejar de margen.
- Avisales a tus clientes qué plugins o funciones consumen más recursos, para anticipar problemas.
- Revisá el consumo total una vez por semana, no solo cuando algo falla.
Preguntas frecuentes
¿Cuántos clientes puedo alojar en un mismo VPS sin problemas de memoria?
No hay un número fijo: depende del tráfico de cada cuenta, de si usan WordPress con muchos plugins o sitios estáticos livianos, y de cuánta RAM tiene tu plan. Una referencia práctica es calcular cuánta memoria consume cada cliente en un día normal y sumar un margen de al menos 20% libre antes de aceptar una cuenta nueva.
¿Conviene mover a un cliente grande a su propio VPS?
Sí, cuando una sola cuenta empieza a consumir una porción desproporcionada de la memoria total en relación al resto, moverla a un VPS propio suele ser más rentable que seguir escalando el servidor compartido para acomodarla, además de que reduce el riesgo de que su tráfico afecte a tus demás clientes.
¿Reiniciar el VPS es una solución válida cuando un cliente se queda sin memoria?
Sirve como alivio de corto plazo, pero si el pool de PHP o los límites de base de datos de esa cuenta no están ajustados, el problema vuelve a aparecer pronto. Lo más eficiente es aplicar los límites por cliente descritos en esta guía, así el reinicio deja de ser necesario.
¿Cómo le explico a un cliente que su plan necesita más recursos?
Mostrale datos concretos: cuánta memoria consume su cuenta en un día normal comparado con el límite disponible, y qué mejoras ya aplicaste de tu lado (caché, ajuste de procesos) antes de proponerle un upgrade. Esa transparencia genera mucha más confianza que simplemente avisarle que “el servidor anda lento”, además de dejar en claro que ya optimizaste todo lo que estaba a tu alcance antes de pedirle una inversión adicional. Un reporte simple, con capturas de los comandos que corriste y la fecha en que hiciste cada ajuste, alcanza para respaldar esa conversación sin generar desconfianza.
Conclusión
Manejar varias cuentas en un mismo VPS multiplica los beneficios de la reventa de hosting, pero también multiplica la responsabilidad de repartir bien la memoria disponible. Con un diagnóstico ordenado y límites claros por cliente, podés sostener a todos tus proyectos activos sin que uno solo tire abajo al resto, y decidir cuándo escalar con información real en vez de con apuro. Ese mismo criterio, aplicado de manera constante, es lo que te va a permitir seguir sumando cuentas sin que la administración del servidor se te complique.
