¿Cuánta RAM necesita un servidor? Planificar capacidad, ECC y margen disponible

Comprender primero el cuello de botella

La RAM contiene datos y estados de los programas a los que los procesadores deben acceder rápidamente. Si escasea la memoria utilizable, el sistema puede intercambiar páginas de memoria con el disco, reducir las cachés o terminar procesos. El resultado puede ser un sistema de gestión empresarial lento aunque la CPU parezca apenas ocupada. En cambio, 64 GB adicionales no acelerarán una aplicación que espera una interfaz externa o un único núcleo del procesador completamente ocupado.

Un uso elevado de memoria no es motivo suficiente para comprar más: los sistemas operativos aprovechan la RAM libre como caché. Lo importante es la memoria disponible, la presión recurrente sobre ella, la actividad de intercambio y el tiempo de respuesta de la aplicación medidos simultáneamente. Linux ofrece Pressure Stall Information para medir cuánto esperan las tareas por escasez de CPU, memoria o recursos de E/S. Esto ayuda a distinguir un cuello de botella real de un uso productivo de la caché. Kernel de Linux: información sobre esperas por presión de recursos ↗

Registre al menos un ciclo empresarial representativo: jornadas normales, copias de seguridad, informes y procesos de cierre de mes. Una tranquila mañana de martes no representa una importación de datos nocturna. Anote junto a las mediciones el número de usuarios, el volumen de datos y la versión del software. Así podrá explicar los cambios de requisitos después de una actualización.

Ejemplo: RAM para un pequeño host de virtualización

El siguiente plan es un ejemplo hipotético para una empresa que ejecuta varios servicios internos. Los valores son presupuestos de memoria supuestos que se necesitan simultáneamente. No son requisitos mínimos de productos concretos. El punto de partida son 64 GB de memoria física y si dejan margen suficiente para el funcionamiento diario, el mantenimiento y el crecimiento.

Al aplicar un margen de planificación elegido por nosotros del 25 por ciento, obtenemos 50 × 1.25 = 62.5 GB. Una configuración de 64 GB podría ser aquí una primera fase de ampliación, pero queda cerca de este límite de planificación. Los 14 GB de reserva equivalen al 28 por ciento de la necesidad inicial. Si solo el presupuesto de la base de datos crece 12 GB, la reserva inicial queda prácticamente agotada. Entonces sería necesario ampliar o trasladar una carga de trabajo a otro lugar.

Las bases de datos necesitan su propio presupuesto de memoria

El tamaño de una base de datos en SSD no determina directamente su necesidad de RAM. Una base grande puede trabajar con un conjunto pequeño de datos de uso frecuente. Una base menor puede necesitar de repente mucha memoria para numerosas ordenaciones simultáneas. Por eso consideramos conjuntamente los datos activos, los índices, las consultas concurrentes y el mantenimiento habitual.

Para un servidor dedicado de bases de datos con al menos 1 GB de RAM, PostgreSQL propone alrededor del 25 por ciento como valor inicial de shared_buffers. Es un punto de partida de configuración, no una recomendación para dimensionar todo el servidor únicamente según esa proporción. work_mem puede asignarse por cada operación de ordenación o hash; varias operaciones y sesiones pueden multiplicar la necesidad total. Otros servicios y la caché del sistema operativo necesitan espacio adicional. PostgreSQL: parámetros de memoria y consumo de recursos ↗

Compruebe primero las consultas, los índices y la concurrencia innecesaria. Una exportación que coincide con una importación y una copia de seguridad puede producir picos mucho menores si se separan sus horarios. Más RAM tiene sentido cuando las mediciones muestran un conjunto activo de datos creciente. En una aplicación defectuosa cuyo consumo de memoria crece sin límite, puede limitarse a retrasar el fallo.

ECC es una propiedad de todo el sistema

La memoria ECC puede detectar y corregir determinados errores de memoria. Los errores cubiertos y la reacción del sistema dependen de la plataforma. Intel señala que ECC requiere compatibilidad tanto del procesador como del chipset. Antes de realizar el pedido también deben coincidir las homologaciones de la placa base, el firmware y los módulos de memoria concretos. Intel: requisitos de compatibilidad con ECC ↗

DDR5 con ECC dentro del chip no convierte automáticamente un servidor en un sistema con protección ECC integral. Esa corrección interna cubre errores dentro del chip DRAM. La protección adicional a nivel de sistema requiere módulos ECC adecuados y compatibilidad de la plataforma. Tampoco se pueden intercambiar libremente módulos ECC UDIMM y RDIMM. Compre según la lista de compatibilidad del sistema, no solo por capacidad y frecuencia. Kingston: DDR5 y ECC dentro del chip ↗

Planificar juntos módulos, canales de memoria y ampliación

La misma capacidad total puede proporcionar distintos anchos de banda de memoria según la distribución de los módulos. Importan los canales de memoria de la CPU y la distribución recomendada por el fabricante. Muchas ranuras vacías pueden resultar atractivas para el futuro, pero una configuración muy desequilibrada hoy puede desaprovechar ancho de banda. Los módulos adicionales también pueden exigir otra velocidad permitida. Siga el manual de la plataforma elegida.

• Compruebe la capacidad máxima y los tamaños de módulo compatibles tanto con la CPU como con la placa base.
• Registre por escrito el tipo de DIMM, la cantidad de módulos por canal y las combinaciones permitidas.
• Planifique la distribución inicial y una segunda fase concreta de ampliación con una lista de componentes.
• Compruebe los módulos homologados y su disponibilidad antes de elegir una configuración inicial ajustada.
• Después de la instalación, compruebe la capacidad reconocida, el funcionamiento de ECC y los mensajes del hardware.

Considerar por separado la sobreasignación y las reservas ante fallos

Las máquinas virtuales pueden recibir nominalmente más memoria de la que existe físicamente. Que esto sea sostenible en un entorno concreto depende de la concurrencia real, el hipervisor y los mecanismos de recuperación de memoria. Para bases de datos sensibles a la latencia, el cálculo no debería depender de que otro invitado necesite casualmente poca RAM. Un host que parece holgado durante el funcionamiento normal puede sufrir presión cuando varios invitados se reinician.

Con dos hosts y conmutación automática ante fallos, el total de GB también puede engañar. Si las VM esenciales necesitan juntas 80 GB, deben caber en la capacidad restante después de perder un host, incluida la necesidad del propio host. Dos hosts de 64 GB cada uno no cumplen este objetivo solo porque durante el funcionamiento diario haya 128 GB disponibles. Apagar deliberadamente sistemas de prueba menos importantes puede ser una alternativa documentada.

Cuándo el plan es fiable

Defina el éxito antes de comprar: por ejemplo, un informe mensual dentro del plazo acordado, ningún fallo de proceso por falta de memoria y margen suficiente durante copias de seguridad simultáneas. Después pruebe exactamente ese flujo con datos realistas adecuados para la prueba. Repita las mediciones tras cambios importantes en el software o los datos.

El resultado debería caber en una página: supuestos de carga, picos medidos, presupuesto de memoria, requisitos ante fallos y límite de ampliación. Así una segunda persona puede entender la decisión. Cuando llegue la siguiente oferta, será posible comparar si un sistema más caro resuelve un problema concreto o simplemente vende capacidad adicional sin valor operativo.