Requisitos de memoria RAM de un servidor dedicado: breve descripción general
La memoria RAM es el espacio de trabajo utilizado por el kernel de Linux, los procesos de las aplicaciones, la caché del sistema de archivos, las bases de datos, los contenedores y las tareas en segundo plano. Un servidor puede utilizar casi toda la memoria disponible sin presentar problemas, ya que Linux utiliza deliberadamente la RAM libre para la caché de páginas. Los signos preocupantes son la actividad constante de la memoria de intercambio, la finalización de procesos por falta de memoria, una alta latencia del disco y un aumento de la latencia al crecer el número de usuarios simultáneos.
Un buen objetivo al elegir una configuración es mantener el uso máximo habitual por debajo del 70–80% de la RAM física. Esto deja espacio para aumentos repentinos del tráfico, tareas programadas, la caché del sistema de archivos, los búferes de la base de datos y el reinicio de un proceso finalizado. Los servidores que funcionan constantemente con un uso de memoria superior al 90% pueden funcionar con normalidad hasta que una copia de seguridad, un despliegue, una consulta a la base de datos o un aumento repentino del número de jugadores provoque actividad de intercambio o el OOM killer del kernel finalice un proceso.
Conclusión: elija la cantidad de RAM según la escala de la carga de trabajo indicada a continuación y, después, añada un margen del 25–50% si el tráfico crece, las copias de seguridad se realizan localmente o varios servicios utilizan el mismo servidor dedicado.
| Escala de la carga de trabajo | Configuración recomendada | Distribución típica de la memoria | Ejemplos |
|---|---|---|---|
| Un servicio ligero | 4–8 núcleos CPU, 16 GB de RAM, 240 GB NVMe | 2–8 GB de uso activo | Grupo pequeño de sitios WordPress, VPN, nodo de monitorización, un servidor de juegos pequeño |
| Pequeño stack de producción | 6–8 núcleos CPU, 32 GB de RAM, 480 GB NVMe | 12–24 GB de uso activo | Alojamiento web, servidor de correo, host Docker, 2–4 instancias de juegos, una base de datos PostgreSQL o MySQL pequeña |
| Aplicación o base de datos en crecimiento | 8–12 núcleos CPU, 64 GB de RAM, 1 TB NVMe | 28–50 GB de uso activo | Tienda WooCommerce popular, aplicación SaaS, ejecutores de CI, caché Redis, base de datos de tamaño medio |
| Alta carga simultánea o varios servicios | 12–16 núcleos CPU, 128 GB de RAM, 2 TB NVMe | 60–100 GB de uso activo | Host de virtualización, comunidad de juegos grande, plataforma de correo, base de datos con mucho tráfico, procesamiento de vídeo |
| Plataforma con uso intensivo de memoria | 16–32 núcleos CPU, 256 GB de RAM o más, NVMe empresarial de 2 TB o más | 140–220 GB de uso activo | Grandes conjuntos de datos PostgreSQL/MySQL, clústeres Elasticsearch, análisis, alta densidad de máquinas virtuales, nodos de nube privada |
Cómo se utiliza la RAM en un servidor dedicado
La memoria de las aplicaciones es solo una parte del volumen total. Linux utiliza la RAM para la caché de páginas, que almacena archivos accedidos recientemente, páginas de bases de datos, registros y recursos, permitiendo acceder a ellos sin volver a leerlos del disco. Esto resulta útil: una base de datos que dispone de suficiente RAM para almacenar en caché el conjunto de datos activo puede realizar muchas operaciones de lectura considerablemente más rápido que una base que carga constantemente páginas desde el almacenamiento NVMe.
- Sistema operativo y servicios: una instalación mínima de Linux puede utilizar entre 500 MB y 2 GB, pero los paneles de control, antivirus, agentes de monitorización y clientes de copias de seguridad añaden carga.
- Stack web: Nginx suele consumir poca memoria, mientras que Apache con prefork PHP puede utilizar una cantidad considerable de memoria por cada solicitud simultánea. Los límites de PHP-FPM hacen que el uso de memoria sea más predecible.
- Bases de datos: MySQL, MariaDB y PostgreSQL utilizan búferes configurados, además de memoria para cada conexión. Unos límites de conexión configurados incorrectamente pueden agotar rápidamente la memoria.
- Contenedores y máquinas virtuales: los contenedores Docker utilizan el kernel compartido del host, pero cada máquina virtual requiere RAM de invitado asignada, además de una pequeña cantidad de memoria para el hipervisor.
- Cachés: Redis, Memcached, Elasticsearch y las cachés de las aplicaciones intercambian deliberadamente RAM por una menor latencia.
- Caché del sistema de archivos: Linux libera automáticamente la caché cuando falta memoria, pero esta caché es importante para los recursos web, la compilación de paquetes y los datos leídos con frecuencia.
Compruebe el estado real con free -h, vmstat 1 y ps aux --sort=-%mem | head -20. En la salida de free -h, preste atención al valor de available y no considere toda la caché como memoria no disponible.
Volumen de RAM según la carga de trabajo
Alojamiento web y sitios CMS: 16–64 GB
Un servidor dedicado con varios sitios WordPress, Laravel o sitios estáticos con poco tráfico puede funcionar bien con 16 GB de RAM si Nginx, PHP-FPM y una base de datos pequeña están configurados correctamente. Pase a 32 GB si el servidor aloja varios sitios dinámicos, funciona con un panel de control de alojamiento, procesa tareas cron frecuentes o gestiona el tráfico de una tienda en línea. Un servidor de 64 GB es una configuración básica razonable para muchos stacks populares de WooCommerce, Magento o aplicaciones personalizadas, ya que permite almacenar la base de datos en caché y deja espacio para los procesos de PHP.
Evalúe las capacidades de PHP-FPM según el tamaño real de los procesos. Si cada proceso de trabajo utiliza 120 MB y el servidor reserva de forma segura 6 GB para el sistema operativo, la base de datos, la caché y el margen en una máquina de 32 GB, asignar 12 GB a PHP permite utilizar aproximadamente 100 procesos de trabajo. No establezca automáticamente 100 procesos: el número de núcleos CPU, las capacidades de la base de datos externa y la duración de las solicitudes también limitan el paralelismo útil.
Bases de datos: de 32 a 256 GB o más
El tamaño de la base de datos está determinado por el conjunto de trabajo activo, no simplemente por el tamaño total del disco. Una base de datos de 500 GB puede funcionar bien con 64 GB de RAM si solo se utilizan activamente 30 GB de índices y filas consultadas recientemente. Por el contrario, una base de datos de 40 GB puede necesitar 128 GB si se ejecutan simultáneamente consultas analíticas, se utilizan muchas conexiones y se realizan grandes combinaciones.
Para MySQL o MariaDB, comience con un búfer de InnoDB de aproximadamente el 50–70% de la RAM en un servidor dedicado exclusivamente a la base de datos. En un servidor de base de datos dedicado con 64 GB, un rango inicial práctico sería un búfer de 36–44 GB. Deje memoria para el sistema operativo, los búferes de conexión, las tablas temporales, las copias de seguridad y la monitorización. PostgreSQL requiere un enfoque similar: shared buffers es solo uno de los componentes, mientras que work_mem se multiplica por el número de ordenaciones, operaciones hash y consultas paralelas.
Servidores de juegos: 16–128 GB
El uso de memoria de un servidor de juegos depende más del motor del juego, las modificaciones, el tamaño del mapa y el número de jugadores que de la velocidad de la red. Un servidor de Minecraft sin modificaciones puede funcionar con 4–8 GB, pero los modpacks y los mundos grandes suelen requerir 10–16 GB por instancia. Un servidor dedicado con 32 GB de RAM puede admitir una comunidad pequeña y su panel web asociado, mientras que 64 GB son más adecuados para varias instancias modificadas o una audiencia de jugadores mayor.
Rust, ARK: Survival Evolved y los servidores de supervivencia con muchas modificaciones pueden utilizar 16–32 GB o más por cada instancia activa. Para una comunidad que trabaja con varios mundos de juego, 128 GB proporcionan un margen más seguro para la consolidación. El rendimiento de CPU en un solo núcleo sigue siendo fundamental para los juegos sensibles a la frecuencia de actualización, por lo que una mayor cantidad de RAM no debe sustituir a un número suficiente de núcleos CPU de alta frecuencia.
Servidores de correo: 16–64 GB
Un servidor de correo pequeño con Postfix, Dovecot, Rspamd, análisis antivirus y filtrado de spam puede comenzar con 16 GB. Utilice 32 GB para una plataforma de correo de producción con muchos buzones activos, análisis de archivos adjuntos y colas de mensajes locales. Elija 64 GB si el servidor procesa grandes volúmenes entrantes, almacena amplios datos de filtrado de spam o ejecuta localmente servicios de base de datos y webmail. Los sistemas de correo también requieren almacenamiento rápido y una configuración cuidadosa de DNS, DNS inverso, SPF, DKIM y DMARC; la cantidad de RAM por sí sola no determina la calidad de entrega.
Streaming y servicios multimedia: 32–128 GB
La transmisión de vídeo suele estar limitada por el rendimiento de la CPU durante la transcodificación, pero la RAM es importante para las tareas simultáneas de ffmpeg, las miniaturas, las bases de datos de metadatos y el almacenamiento en caché. Un servidor multimedia con reproducción directa puede comenzar con 16–32 GB. Un servidor que realice varias transcodificaciones de 1080p debería tener 32–64 GB, mientras que la transcodificación 4K, las grandes bibliotecas multimedia o varias tareas de codificación simultáneas pueden justificar 128 GB. La codificación por hardware reduce la carga de la CPU, pero no elimina la necesidad de disponer de memoria adicional.
CI/CD, compilación y plataformas de desarrollo: 32–128 GB
Las tareas de compilación, la creación de imágenes de contenedores, las pruebas de navegador y los ejecutores de CI paralelos consumen memoria en ráfagas. Un servidor dedicado con 32 GB es adecuado para uno o dos ejecutores con carga moderada. Utilice 64 GB para compilaciones paralelas y servicios Git autohospedados, y 128 GB cuando varios ejecutores compilen simultáneamente proyectos grandes en Java, Android, Rust, C++ o proyectos frontend. Configure el paralelismo de los ejecutores teniendo en cuenta tanto la CPU como la RAM: ocho tareas en ocho núcleos no son seguras si cada una puede consumir 6 GB.
Virtualización y stacks de aplicaciones autohospedados: 64–256 GB
Un host de virtualización requiere RAM física para cada sistema invitado, además de memoria para el propio host y la caché. Por ejemplo, seis máquinas virtuales de 6 GB requieren al menos 36 GB, sin contar el hipervisor, la caché del sistema de archivos y el crecimiento de la carga. Un servidor dedicado con 64 GB es un punto de partida razonable para varias máquinas virtuales de producción. Elija 128 o 256 GB para una mayor densidad de máquinas virtuales, nodos de trabajo de Kubernetes o stacks autohospedados con Nextcloud, GitLab, monitorización, bases de datos y almacenamiento de objetos.
Metodología y herramientas de pruebas de rendimiento
Las decisiones sobre la cantidad de RAM deben verificarse mediante una prueba reproducible, en lugar de basarse en un único gráfico del panel de monitorización. El perfil de referencia siguiente utiliza un servidor dedicado con una CPU de 8 núcleos, 64 GB de memoria DDR5, una unidad NVMe de 1 TB y un puerto de red de 1 Gbit/s. Las pruebas se ejecutan en un host Linux sin carga, utilizando almacenamiento local, y se repiten tres veces; se indica el resultado mediano. Los resultados dependen de la generación de la CPU, el modelo NVMe, el esquema RAID, la ruta hasta el centro de datos, la versión del kernel y la carga impredecible de las aplicaciones.
- CPU:
sysbench cpu --cpu-max-prime=20000 --threads=8 runmide el rendimiento de los cálculos de números primos. - Memoria:
sysbench memory --memory-block-size=1M --memory-total-size=100G runprueba el rendimiento de copia de memoria. - Entrada/salida de disco:
fio --name=randread --filename=/srv/fio.test --size=20G --bs=4k --rw=randread --iodepth=32 --numjobs=4 --direct=1 --runtime=60 --time_basedprueba los IOPS de lectura aleatoria sin utilizar la caché de páginas. - Red:
iperf3 -c benchmark.example.net -P 4 -t 30mide el rendimiento TCP hasta un punto remoto adecuado. Pruebe varias ubicaciones geográficas. - Carga de la aplicación:
wrk -t4 -c100 -d60s https://server.example/mide las capacidades de respuesta web con 100 conexiones simultáneas.
Resultados de referencia de las pruebas de CPU, disco, red y memoria
| Prueba | Resultado de referencia | Qué muestra | Impacto de la RAM |
|---|---|---|---|
| Sysbench CPU, 8 hilos | 1 180 eventos por segundo | Potencia de cálculo para el código de las aplicaciones, la compresión y los ciclos de juego | Una mayor cantidad de RAM no aumenta este resultado si no se produjo intercambio |
| Copia de memoria Sysbench | 31,6 GiB/s | Ancho de banda de memoria para cargas intensivas en caché y tareas paralelas | Útil para bases de datos, compilaciones y máquinas virtuales |
| fio, lectura aleatoria de bloques de 4 KiB | 286 000 IOPS, 1,09 GiB/s | Capacidad de respuesta del almacenamiento al trabajar con bloques pequeños | La falta de RAM hace que más operaciones de lectura alcancen este nivel |
| fio, escritura secuencial de bloques de 1 MiB | 1,72 GiB/s | Ancho de banda de escritura de copias de seguridad, multimedia y archivos grandes | Los búferes de escritura suavizan los aumentos breves, pero no sustituyen a un almacenamiento fiable |
| iperf3, 4 flujos, puerto de 1 Gbit/s | 941 Mbit/s | Ancho de banda TCP práctico después de considerar la sobrecarga del protocolo | Un gran número de conexiones requiere memoria para los búferes de sockets |
| wrk, 100 conexiones, endpoint PHP en caché | 1 850 solicitudes por segundo, p95 74 ms | Tiempo de respuesta del stack web bajo una carga controlada | La caché de páginas y los búferes de la base de datos reducen la espera del disco |
Estas cifras muestran por qué la RAM influye indirectamente en el rendimiento de las aplicaciones. La unidad NVMe funciona rápidamente, pero una página de base de datos servida desde la memoria elimina por completo el acceso al almacenamiento. Si la falta de RAM obliga a utilizar intercambio, la latencia bajo carga puede aumentar de milisegundos a cientos de milisegundos.
Impacto en el rendimiento de las aplicaciones en condiciones reales
Sitio con base de datos: Un servidor con 32 GB que asigna 16 GB a los búferes de MySQL, 6 GB a PHP-FPM y el resto al sistema operativo y la caché puede gestionar de forma predecible un tráfico dinámico moderado. Si el mismo sitio recibe un aumento de tráfico debido a una campaña publicitaria y el uso de memoria alcanza el 95%, los nuevos procesos de trabajo de PHP y las tablas temporales de la base de datos pueden llevar al host a utilizar intercambio. Una configuración con 64 GB suele mejorar más la latencia p95 que añadir núcleos CPU, ya que mantiene en la caché las páginas de la base de datos y los recursos web utilizados con frecuencia.
Comunidad de Minecraft: Un servidor con 16 GB puede ejecutar una instancia modificada de 10 GB, pero los guardados programados del mundo y la actividad de los plugins dejan poco margen. Un servidor con 32 GB proporciona suficiente espacio al heap de Java y conserva memoria para la caché de Linux y las herramientas de gestión. Asignar cada gigabyte disponible al heap de Java resulta contraproducente, ya que el host también necesita memoria.
Carga analítica de PostgreSQL: Un servidor de informes con 100 GB de índices y tablas utilizados con frecuencia obtiene un beneficio considerable de 128 GB de RAM. Puede mantener más datos solicitados en la caché, reduciendo el número de lecturas aleatorias de NVMe durante el funcionamiento de los paneles de monitorización y la generación de informes. Los planes de consulta y los índices siguen siendo necesarios; añadir RAM no corregirá un escaneo completo e ineficiente de la tabla.
Host de compilación de CI: Cuatro compilaciones paralelas de contenedores que utilizan 7 GB cada una pueden superar la capacidad de un servidor de 32 GB después de tener en cuenta el host, la caché de Docker y los procesos de prueba. Una configuración con 64 GB admite las mismas tareas con un margen práctico, mientras que 128 GB son adecuados si se ejecutan en paralelo pruebas de navegador y compilaciones.
Recomendaciones de optimización
Mida la presión de memoria, no solo la cantidad de RAM utilizada
Ejecute free -h, vmstat 1 y sar -r 1 60 durante la carga máxima. En vmstat, los valores de si y so constantemente distintos de cero indican actividad de carga y descarga de la memoria de intercambio. Compruebe los eventos OOM del kernel mediante journalctl -k | grep -i oom.
Establezca límites para cada servicio
Utilice pm.max_children de PHP-FPM, límites de memoria de Docker, MemoryMax= de systemd, grupos de conexiones de bases de datos y límites de paralelismo de los ejecutores de CI. Una cola controlada es más segura que una situación en la que un servicio consume toda la memoria física y finaliza procesos no relacionados.
Configure la memoria de la base de datos de forma conservadora
Establezca los tamaños de los búferes según la carga medida y deje margen para la memoria de las conexiones. Supervise MySQL mediante mysqladmin extended-status o PostgreSQL mediante pg_stat_database. Añada índices y corrija las consultas costosas antes de considerar el aumento de RAM como la única solución.
Utilice almacenamiento NVMe rápido y evite el intercambio constante
NVMe reduce las pérdidas por fallos de caché, copias de seguridad y lecturas de bases de datos, pero no hace que el intercambio sea aceptable para un servicio de producción cargado. Deje una pequeña partición de intercambio para protección de emergencia, establezca un valor conservador de swappiness cuando corresponda e investigue cualquier operación de intercambio persistente.
Separe las cargas de trabajo incompatibles
Una base de datos, un procesador de transcodificación, un ejecutor de CI y un servidor de juegos pueden competir por la RAM y la CPU en momentos impredecibles. Para cargas permanentes que requieran aislamiento, utilice servidores dedicados independientes. Un VPS suele ser suficiente para una VPN con poco tráfico, un nodo de monitorización, un sitio estático pequeño o un único servicio ligero, pero el hardware dedicado es más adecuado para bases de datos activas, comunidades de juegos, sistemas de compilación grandes y plataformas de producción con varios servicios.
Planifique el crecimiento y el mantenimiento
Reserve memoria para la recuperación de bases de datos, las copias de seguridad, las actualizaciones de paquetes, el procesamiento de registros, las comprobaciones de seguridad y los aumentos repentinos del tráfico. Si el uso máximo ya supera el 80% de la RAM, pase al siguiente nivel antes de que un incidente urgente obligue a realizar una actualización.