Una de las preguntas peor respondidas en foros de Moodle es “¿qué servidor necesito para X alumnos?”: mal formulada desde el principio, porque el número que realmente importa no es cuántas cuentas tienes registradas, sino cuántas personas acceden al mismo tiempo. Un Moodle con 5.000 cuentas y baja concurrencia real puede funcionar en un servidor modesto; uno con 300 alumnos que hacen examen todos a la vez necesita bastante más.
En esta guía vas a ver cómo dimensionar correctamente CPU, RAM y disco según la concurrencia real, y qué hacer cuando tu instalación crece más allá de lo que un único servidor puede sostener.
La métrica correcta: usuarios concurrentes, no cuentas totales
Usuarios concurrentes es el número de personas usando activamente la plataforma en un mismo momento, no cuántas tienen cuenta creada. Este dato varía mucho según el tipo de uso: un curso asíncrono con acceso disperso a lo largo del día tiene mucha menos concurrencia real que un examen sincronizado donde todos entran a la misma hora.
Referencia de dimensionamiento por concurrencia
| Usuarios concurrentes | CPU | RAM | Arquitectura |
|---|---|---|---|
| Hasta ~100 | 2-4 vCPU | 4-8 GB | Todo en un mismo servidor, con almacenamiento NVMe |
| 200-500 | 4-8 vCPU | 8-16 GB | Base de datos idealmente en servidor separado |
| Más de 500-1.000 | Varios nodos web | Según carga distribuida | Base de datos dedicada + Redis en su propio nodo |
Estas cifras son un punto de partida orientativo, no una garantía, el tipo de actividad (navegación de contenido frente a envío simultáneo de exámenes con adjuntos, por ejemplo) puede mover estos números en cualquier dirección.
Por qué añadir más CPU no siempre ayuda
Superados los 8-16 vCPU, añadir más núcleos rara vez aporta mejoras proporcionales para una carga de trabajo típica de Moodle. Una vez que la RAM es suficiente y el almacenamiento es rápido, el cuello de botella suele desplazarse hacia otro punto (la base de datos, el I/O de disco) antes que hacia la CPU. Invertir en más núcleos sin haber resuelto esos otros puntos no suele traducirse en mejoras reales.
RAM: para qué se usa exactamente
La memoria RAM de un servidor Moodle no es un recurso único indiferenciado, se reparte entre varios consumidores que compiten entre sí:
- Caché de base de datos (el buffer pool de InnoDB, idealmente en torno al 70% de la RAM disponible en el servidor de base de datos).
- Pools de trabajadores de PHP-FPM, que procesan las peticiones activas.
- Almacenes de caché en memoria (Redis o similar).
- Buffers del propio sistema operativo.
Cuando el buffer pool de la base de datos no cabe completamente en la RAM disponible, es una señal clara de que necesitas más memoria antes que más CPU.
Disco: por qué NVMe marca una diferencia real
Moodle ejecuta habitualmente entre 200 y 500 consultas a base de datos por cada carga de página. Cuando esos datos no están en caché en memoria, el servidor tiene que leerlos de disco, y la diferencia de velocidad entre un disco NVMe y un disco duro tradicional (o incluso un SSD SATA más antiguo) es sustancial en este escenario de lecturas frecuentes y pequeñas.
Cuándo separar servicios en distintos servidores
No hace falta separar base de datos, caché y aplicación desde el primer día. La separación tiene sentido cuando:
- La concurrencia supera los cientos de usuarios simultáneos de forma habitual, no solo en picos puntuales.
- El buffer pool de la base de datos ya no cabe en la RAM del servidor combinado.
- Quieres aislar el impacto de un pico de tráfico en una capa (por ejemplo, muchas conexiones web) sin que afecte a la estabilidad de la base de datos.
Cómo confirmar que tu dimensionamiento actual es correcto
- Mide la concurrencia real en tus picos históricos más exigentes (inicio de curso, exámenes), no solo el tráfico medio diario.
- Haz una prueba de carga sobre los flujos reales más críticos (login, inicio de cuestionario, envío de tarea) antes de un evento importante, no después de que algo falle.
- Revisa el ratio de aciertos del buffer pool de tu base de datos, un ratio bajo indica que necesitas más RAM dedicada a esa capa.
- Monitoriza el uso de CPU durante los picos, no solo en el uso medio diario, para detectar si realmente se satura en los momentos críticos.
Errores comunes de dimensionamiento
- Dimensionar según cuentas totales en vez de concurrencia real, sobreinvirtiendo o infrainvirtiendo según el caso.
- Añadir más CPU como primera respuesta ante lentitud, sin haber revisado antes RAM, caché y configuración de base de datos.
- No hacer pruebas de carga antes de un pico previsible, descubriendo los límites reales del servidor en el peor momento.
- Usar almacenamiento en disco duro tradicional para una instalación con tráfico significativo, subestimando el impacto real en tiempos de respuesta.
- No revisar el dimensionamiento tras un crecimiento de matrícula, asumiendo que la configuración inicial sigue siendo suficiente indefinidamente.
Preguntas frecuentes
¿Cuántos usuarios concurrentes soporta un servidor de 4 vCPU y 8 GB de RAM? Como referencia orientativa, entre 100 y 200 usuarios concurrentes bien gestionados, aunque el número exacto depende de la actividad concreta (navegación simple frente a cuestionarios con adjuntos, por ejemplo) y de cuánto esté afinada el resto de la configuración.
¿Necesito separar la base de datos del servidor web desde el principio? No para instalaciones pequeñas o medianas. La separación aporta beneficio real a partir de varios cientos de usuarios concurrentes habituales, no como configuración por defecto desde el primer día.
¿Más vCPU siempre mejora el rendimiento? No proporcionalmente más allá de 8-16 vCPU para cargas de trabajo típicas de Moodle, superado ese punto, el cuello de botella suele estar en otro lado.
¿Qué tipo de disco debería usar para un servidor Moodle con tráfico real? NVMe, siempre que sea posible, por la diferencia sustancial de velocidad en las lecturas frecuentes y pequeñas que genera el patrón de consultas típico de Moodle.
¿Cómo sé si necesito más RAM en vez de más CPU? Si el buffer pool de tu base de datos no cabe en la RAM disponible, o si el servidor empieza a usar memoria de intercambio (swap) bajo carga, son señales claras de que la RAM es el recurso limitante, no la CPU.
¿Debo dimensionar para el pico más alto o para el uso medio? Para el pico más exigente que sea previsible (un examen con toda la matrícula conectada a la vez), no para el promedio diario, que suele ser mucho menor.
¿Con qué frecuencia debería revisar el dimensionamiento de mi servidor? Cada vez que crezca significativamente el número de alumnos o la actividad concurrente esperada, y siempre antes de un evento crítico como un examen masivo.
Conclusión
Dimensionar correctamente un servidor Moodle no depende de cuántas cuentas tienes registradas, sino de cuánta gente accede al mismo tiempo en tus momentos más exigentes. RAM suficiente para caché y base de datos, disco NVMe, y una arquitectura que escale por capas cuando la concurrencia lo exige, no más CPU como primera respuesta ante cualquier síntoma de lentitud.
Si prefieres que alguien calcule esto por ti según tu uso real, en Avantys lo evaluamos como parte de la auditoría de cada Moodle que gestionamos. Puedes pedirla gratis en Moodle Gestionado.
Artículos relacionados
- Mantenimiento y hosting Moodle: guía completa
- Por qué mi Moodle va lento: causas más comunes
- Optimizar la base de datos de Moodle
- BigBlueButton en Moodle: requisitos de servidor
¿Y si tu Moodle lo lleváramos nosotros?
Actualizaciones, backups verificados, rendimiento y trazabilidad FUNDAE, gestionado de forma continua por una persona que responde. Auditoría gratuita de tu plataforma actual.
