¿Tu instancia de SQL Server 2019 “olvida” el valor de max server memory
cada vez que reinicias el servicio y vuelve misteriosamente a 24 GB? A continuación descubrirás por qué ocurre, cómo rastrear al culpable y las acciones definitivas para asegurarte de que el ajuste se mantenga intacto.
Síntomas
Tras modificar max server memory
a 16 GB en un servidor con 32 GB de RAM, el valor persiste durante la sesión actual. Sin embargo, al reiniciar Windows o el servicio de SQL Server (ya sea manualmente, mediante un reinicio planificado o tras una actualización acumulativa), la configuración reaparece como 24 GB.
Entendiendo cómo SQL Server guarda max server memory
El parámetro se administra con sp_configure y se almacena en el registro de sistema de SQL Server. Cuando cambias un valor:
EXEC spconfigure 'show advanced options', 1;
RECONFIGURE;
EXEC spconfigure 'max server memory', 16384; -- en MB
RECONFIGURE;
Existen dos estados:
- Configuración en ejecución (columna running_value en
sys.configurations
), cargada en memoria. - Configuración persistente (columna value), grabada en disco.
Si se omite RECONFIGURE
, solo el valor en ejecución cambia; el registro en disco queda intacto y el ajuste se descartará al reiniciar.
Por qué el valor cambia a 24 GB
Durante la instalación, el asistente calcula un valor “recomendado” igual al 75 % de la RAM detectada. Así, en servidores con 32 GB establece 24 GB. Cualquier herramienta de aprovisionamiento que use esa fórmula (scripts de Chef, Ansible, SCCM, etc.) o un instalador silencioso con el parámetro /SQLMAXMEMORY=24576
puede reenviarlo en cada arranque. SQL Server no modifica el valor por iniciativa propia.
Proceso paso a paso para diagnosticar y corregir
Paso | Acción recomendada | Propósito |
---|---|---|
1. Verificar que el cambio se haya guardado correctamente. | Ejecuta los comandos con RECONFIGURE y confirma con:SELECT name, value, valueinuse FROM sys.configurations WHERE name = 'max server memory (MB)'; | Garantiza que la opción esté persistida en disco, no solo en memoria. |
2. Comprobar si hay scripts o herramientas que sobrescriben la configuración. | Revisa: • Trabajos de SQL Agent con sp_configure en los pasos. • Scripts de inicio en el motor (por ejemplo, Startup procedures). • Herramientas de automatización remota. • Políticas de Policy‑Based Management. | Identifica el componente externo que empuja 24 GB en cada ciclo. |
3. Auditar quién hace la modificación. | Crea una sesión de Extended Events:CREATE EVENT SESSION detectmemchange ON SERVER ADD EVENT sqlserver.sp_configure ( ACTION(sqlserver.sqltext, sqlserver.clientappname, sqlserver.ntusername) WHERE (sql_text LIKE '%max server memory%') ) ADD TARGET package0.event_file ( SET filename = N'C:\XE\DetectMaxMem.xel' ); ALTER EVENT SESSION detectmemchange ON SERVER STATE = START; | Captura la hora, cuenta de servicio y aplicación origen. |
4. Ajustar la memoria y reiniciar para validar. | Fija el valor deseado, detén‑inicia el servicio y verifica que persiste. | Corrobora si la causa era falta de RECONFIGURE o un script externo. |
5. Reservar memoria para el SO. | Sugerencia: deja 2‑4 GB + ≈10 % de la RAM total para Windows. | Evita paginación y mantiene estable el rendimiento. |
Detalle de cada paso
Verificar que el cambio quede guardado
Después de ejecutar el comando, consulta sys.configurations
. Si value y valueinuse difieren, significa que olvidaste RECONFIGURE
. Además, comprueba el registro de errores de SQL Server: cada arranque muestra la lista de startup options y los valores que aplica.
Detectar scripts o herramientas intrusas
- SQL Agent: filtra por
msdb.dbo.sysjobs
donde el paso contengamax server memory
. - Startup procedures: inspecciona
sys.procedures
con la columna isautoexecuted = 1. - Policy‑Based Management: abre Facet = Server Configuration; busca condiciones que obliguen a 75 % de RAM.
- Iniciativas DevOps: localiza playbooks o recetas que referencien
SQLMAXMEMORY
.
Auditar la modificación con Extended Events
La sesión anterior graba:
- Texto preciso de la sentencia (sql_text).
- Nombre del ejecutable y biblioteca cliente (clientappname).
- Cuenta NT que dispara el comando (nt_username).
Abre el archivo .xel
con SSMS (Menú Extended Events > Sessions > detectar… > View Target Data) y ordénalo por marca de tiempo; en minutos tendrás al responsable.
Reinicio controlado para validar
- Ejecuta
SHUTDOWN WITH NOWAIT;
(o detén el servicio desde Servicios). - Inicia otra vez y revisa
SELECT @@VERSION
para confirmar el arranque. - Comprueba
sys.configurations
; si sigue en 16 GB, el problema estaba en la falta de persistencia. Si regresa a 24 GB, lee la auditoría.
Asignación correcta de memoria al sistema operativo
Regla práctica:
- Hasta 64 GB físicos: reserva 4 GB + 10 % de la RAM total.
- De 64 GB a 256 GB: reserva 8 GB + 6 % de la RAM total.
- Más de 256 GB: reserva 16 GB + 4 % de la RAM total.
Para un servidor de 32 GB, 16 GB para SQL Server deja 16 GB libres, de los cuales Windows usará ≈10 GB reales y el resto queda de buffer. Esta distribución suele eliminar la paginación en sistemas con cargas mixtas (IIS, servicios de copia de seguridad, antivirus).
Buenas prácticas de configuración de memoria
- Documentar las directrices en un repositorio Git o Wiki interno.
- Automatizar comprobaciones con Custom Alerts en Management Studio o scripts de PowerShell que consulten WMI y
sys.dmossys_memory
. - Revisar tras actualizaciones: algunos paquetes de CU reescriben
sqlservr.ini
, aunque no deberían tocar el parámetro; confírmalo en ambientes críticos. - Monitorizar Target Server Memory vs. Total Server Memory en
sys.dmosperformance_counters
; si TSM <> TSM se estabiliza, ajusta. - No descuidar
min server memory
; si lo fijas alto, puede impedir que el motor libere RAM en situaciones de presión del SO.
Preguntas frecuentes
¿Puedo cambiar max server memory
sin reiniciar?
Sí. El ajuste es dinámico. Tras RECONFIGURE
, el motor libera o reserva memoria gradualmente.
¿Afecta al Buffer Pool Extension?
No directamente; aun así, si planificas un BPE en SSD, revisa que el porcentaje de memoria que dejas al SO cubra el tráfico de paginación del BPE.
¿Qué pasa en entornos de clúster Always On?
Configura todos los nodos con el mismo valor o con valores compatibles con sus RAM físicas. De lo contrario, ante un failover puedes quedar corto de memoria.
Checklist rápido
- Usar siempre
RECONFIGURE
. - Buscar trabajos o scripts que contengan la expresión “
sp_configure 'max server memory'
”. - Configurar Extended Events detectmemchange para capturar futuros cambios.
- Verificar el valor tras cada parche o reinicio.
- Documentar la justificación del valor elegido.
Conclusión
El retorno automático a 24 GB no es un “capricho” de SQL Server, sino la huella de un paso omitido (RECONFIGURE
) o de alguna herramienta que fuerza el valor por mayor comodidad. Siguiendo la guía podrás descubrir al responsable, asegurar la persistencia y, de paso, optimizar la distribución de memoria entre el motor y el sistema operativo para evitar sustos de rendimiento.