Configuración y presión de memoria en SQL Server

El valor predeterminado de max server memory puede dejar sin memoria a Windows y otros servicios. Un valor bajo causa lecturas, compilaciones y presión de grants.

Por qué este tema requiere atención deliberada

Un problema de este tipo rara vez existe aislado. Un cambio que mejora una consulta puede aumentar escrituras, registro, bloqueos, recuperación o complejidad en otro punto. Trata el trabajo como una decisión de ingeniería con objetivo medible, restricciones conocidas y responsable claro.

Una configuración sólida protege el host y deja a SQL Server memoria suficiente para su carga real.

Qué medir

Revisa memoria del proceso, memoria disponible, paginación, buffer, grants pendientes, esperas de workspace, stolen memory, columnstore y servicios compartidos.

Flujo de diagnóstico

• Define exactamente el síntoma, carga afectada, inicio, frecuencia e impacto visible.
• Captura evidencia durante periodos normales y degradados para la misma operación de negocio.
• Separa correlación de causa revisando planes, esperas, recursos, bloqueos, configuración y cambios recientes.
• Prueba grupos representativos de bases, consultas o parámetros, no solo el ejemplo más sencillo.
• Conserva configuración, plan, definición y contadores actuales antes de cambiar nada.
• Expresa numéricamente el resultado esperado: latencia, CPU, lecturas, rendimiento, cola o recuperación.

Cómo elegir la intervención

Prefiere el cambio más limitado que trate la causa demostrada. La configuración del servidor afecta muchas cargas, mientras que consultas, índices, estadísticas u horarios pueden ser más precisos. Considera licencia, versión, alta disponibilidad, ventanas y capacidad del equipo para supervisar.

Enfoque práctico

Reserva capacidad para Windows, controladores, agentes, copias y otros servicios. Trata max server memory como techo, investiga grants excesivos y mide picos, mantenimiento y failover.

Secuencia segura de implementación

• Reproduce el comportamiento en un entorno seguro con datos a escala de producción.
• Cambia una variable importante cada vez y conserva la definición original para revertir.
• Mide duración, CPU, lecturas, escrituras, esperas, memoria, registro y efectos posteriores.
• Prueba entradas normales, picos y extremos, además de reinicio o failover cuando corresponda.
• Despliega en una ventana adecuada con operador, propietario de aplicación y decisor conectados.
• Revisa el resultado de inmediato y durante el siguiente pico representativo.

Ejemplo de SQL Server

El siguiente ejemplo es un punto de partida para investigar o implementar de forma controlada. Adapta nombres, límites, retención y permisos antes de producción. Conserva la salida junto con la cronología del incidente y no trates una sola muestra como diagnóstico completo.

SELECT
    physical_memory_in_use_kb / 1024 AS sql_process_mb,
    locked_page_allocations_kb / 1024 AS locked_pages_mb,
    memory_utilization_percentage,
    process_physical_memory_low,
    process_virtual_memory_low
FROM sys.dm_os_process_memory;

SELECT COUNT(*) AS pending_memory_grants
FROM sys.dm_exec_query_memory_grants
WHERE grant_time IS NULL;

Qué evitar

No uses una fórmula fija para todos, no juzgues la presión solo por Page Life Expectancy y no ignores memoria fuera del buffer pool.

Supervisión después del cambio

Vigila la métrica que debía mejorar y al menos dos posibles efectos secundarios. Compara ventanas y volúmenes equivalentes. Observa el tiempo suficiente para incluir mantenimiento, copias, informes, failover y tareas periódicas. Documenta si la mejora persiste y si el cambio debe mantenerse, ajustarse o retirarse.

Reversión y responsabilidad

La reversión debe indicar el valor o definición anterior, quién decide y qué señal la activa. Conserva el plan y script originales para cambios de planes o metadatos. Para infraestructura, confirma capacidad y tiempo de mantenimiento antes de empezar.

Resultado operativo

Una configuración sólida protege el host y deja a SQL Server memoria suficiente para su carga real.

Lista de producción

Captura una línea base y define la mejora esperada. Prueba con datos y concurrencia representativos. Conserva la configuración o el plan original, prepara una reversión, despliega en una ventana adecuada y observa el siguiente pico normal de carga.

Preguntas antes de cerrar

• ¿Mejoró el síntoma original bajo la misma carga?
• ¿Aparecieron costes de escritura, almacenamiento, bloqueo, memoria o disponibilidad?
• ¿Sobrevivirá el resultado a reinicios, failover, estadísticas y crecimiento?
• ¿Las alertas detectarán una regresión antes que los usuarios?
• ¿Quedaron registrados la decisión, el responsable y la fecha de revisión?

Si quieres aplicar este método a un entorno SQL Server concreto, usa el formulario inferior e incluye la versión, el tamaño de la base, el patrón de carga y las evidencias ya recopiladas.