Procedimientos recomendados de rendimiento: memoria de SQL Server en Linux

Se aplica a:SQL Server en Linux

En este artículo se describe la configuración de memoria para SQL Server en Linux, incluidos mssql-conf los límites de memoria, la configuración del grupo de control (cgroup), los ejemplos de memoria del contenedor de Docker y las consideraciones sobre el espacio de intercambio.

Note

Para obtener recomendaciones de almacenamiento, kernel, CPU y red, consulte Procedimientos recomendados de rendimiento: Almacenamiento, kernel, CPU y red para SQL Server en Linux.

Establecimiento de un límite de memoria mediante mssql-conf

Para asegurarse de que hay suficiente memoria física libre para el sistema operativo Linux, el proceso de SQL Server usa solo el 80 % de la RAM física de forma predeterminada. Para algunos sistemas con grandes cantidades de RAM física, el 20 por ciento podría ser un número significativo. Por ejemplo, en un sistema con 1 TB de RAM, la configuración predeterminada deja alrededor de 200 GB de RAM sin usar. En esta situación, es posible que quiera configurar el límite de memoria en un valor más alto.

Puede ajustar este valor mediante la mssql-conf herramienta o la variable de MSSQL_MEMORY_LIMIT_MB entorno. Para obtener más información, vea la configuración memory.memorylimitmb que controla la memoria visible para SQL Server (en unidades de MB). Para obtener instrucciones detalladas sobre el ajuste de tamaño, consulte Directrices para establecer límites de memoria en Linux y en contenedores.

Compatibilidad con el grupo de control (cgroup) v2

SQL Server detecta y respeta las restricciones del grupo de control (cgroup) v2, empezando por SQL Server 2025 (17.x) y SQL Server 2022 (16.x) Actualización acumulativa (CU) 20. Estas restricciones proporcionan un control específico en el kernel de Linux sobre los recursos de CPU y memoria, y mejoran el aislamiento de recursos en entornos de Docker, Kubernetes y OpenShift.

En versiones anteriores, las implementaciones en contenedores en clústeres de Kubernetes (por ejemplo, Azure Kubernetes Service v1.25 o posteriores) podían experimentar errores de memoria insuficiente (OOM) porque SQL Server no aplicaba límites de memoria definidos en las especificaciones del contenedor. La compatibilidad con cgroup v2 soluciona este problema.

Comprobación de la versión de cgroup

stat -fc %T /sys/fs/cgroup

Los resultados son los siguientes:

Result Description
cgroup2fs Usted utiliza cgroup v2.
cgroup Tú usas cgroup v1.

Cambiar a la versión 2 de cgroup

La ruta de acceso más sencilla es elegir una distribución que admita cgroup v2 de fábrica.

Si necesita cambiar manualmente, agregue el siguiente parámetro a la configuración de GRUB:

systemd.unified_cgroup_hierarchy=1

A continuación, actualice GRUB. Por ejemplo, en Ubuntu, ejecute:

sudo update-grub

En Red Hat Enterprise Linux (RHEL), ejecute:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Informes de límite de CPU con cgroup v2

Al configurar límites de CPU mediante cgroup v2, SQL Server no muestra el recuento de núcleos de CPU configurados en el registro de errores. En su lugar, continúa informando del número total de CPU de host.

Para alinear el programador y los planes de consulta de SQL Server (por ejemplo, las decisiones de paralelismo) con el recuento de CPU previsto definido en el grupo de control v2, aplique la siguiente configuración.

Configuración de la afinidad de procesador

Establezca explícitamente la afinidad del procesador de SQL Server para que se alinee con la cuota de ejecución del cgroup. En el ejemplo siguiente, la cuota de cgroup es de cuatro CPU en un host de ocho núcleos:

ALTER SERVER CONFIGURATION
SET PROCESS AFFINITY CPU = 0 TO 3;

Esta configuración garantiza que SQL Server crea planificadores solo para el número deseado de CPUs. Para obtener más información, consulte ALTER SERVER CONFIGURATION y Use PROCESS AFFINITY for Node and/or CPUs ( Usar PROCESS AFFINITY para node o CPU).

Active el indicador de seguimiento 8002 para usar la afinidad flexible en la capa de SQLPAL.

sudo /opt/mssql/bin/mssql-conf traceflag 8002 on

De forma predeterminada, los programadores están asignados a CPU específicas definidas en la máscara de afinidad. La marca de seguimiento 8002 permite que los planificadores se muevan entre CPUs, lo que generalmente mejora el rendimiento, a la vez que respeta las afinidades y las restricciones de cgroup. Para obtener más información, vea DBCC TRACEON: marcas de seguimiento.

Reinicie SQL Server después de habilitar la marca de seguimiento.

Comportamiento esperado

Después del reinicio:

  • SQL Server crea solo el número de programadores definidos por la configuración de afinidad (por ejemplo, cuatro programadores).

  • El kernel de Linux sigue aplicando la cuota de ejecución de CPU de cgroup v2.

  • Las decisiones de optimización y paralelismo de consultas se basan en el recuento de CPU previsto, en lugar de en el total de CPU del host.

Note

El SQL Server registro de errores puede seguir mostrando el número total de CPU del host. Este comportamiento de registro y visualización no afecta al uso real de la CPU, la creación del programador ni la aplicación de CPU por cgroup v2 o afinidad de procesador.

Para obtener más información, consulte los siguientes recursos:

Directrices para establecer límites de memoria en Linux y en contenedores

SQL Server en Linux tiene varios controles de memoria que funcionan en diferentes niveles. En la tabla y diagrama siguientes se muestra cómo cada nivel reduce la memoria disponible, desde la RAM del host hasta el grupo de búferes.

Level Establecido por Description
Host Configuración de hardware o máquina virtual RAM física en el servidor o la máquina virtual (VM).
Límite de cgroup (docker run --memory, systemdo manual) Entorno de ejecución de contenedor, systemd segmentación o configuración manual cgroup Límite máximo aplicado por kernel (memory.max) para todos los procesos de cgroup. Opcional en Linux sin sistema operativo.
proceso de SQL Server (memorylimitmb / MSSQL_MEMORY_LIMIT_MB) mssql-conf o variable de entorno Memoria total en todos los componentes de SQL Server. Debe ser inferior al cgroup límite (si está presente) o la memoria del host.
Grupo de búferes (max_server_memory) sp_configure Caché de páginas de datos de 8 KB. Debe ser inferior a memorylimitmb.
Espacio para la cabeza Calculado (diferencia entre límites) La diferencia entre el límite cgroup (o la memoria del host) y memorylimitmb, reservada para la sobrecarga del SO y los procesos auxiliares.

Diagrama en el que se muestran las capas de control de memoria anidadas.

Al establecer límites de memoria para SQL Server en Linux, tenga en cuenta las instrucciones siguientes:

  • En las implementaciones de contenedores, use cgroup para limitar la memoria general disponible para el contenedor. Esta configuración establece el límite superior para todos los procesos dentro del contenedor.

  • El límite de memoria (ya sea establecido por memorylimitmb o la MSSQL_MEMORY_LIMIT_MB variable de entorno) controla la memoria total que SQL Server en Linux puede asignar en todos sus componentes, como el grupo de búferes, SQLPAL, Agente SQL Server, LibOS, PolyBase, Full-Text Search y cualquier otro proceso cargado en SQL Server en Linux.

  • La MSSQL_MEMORY_LIMIT_MB variable de entorno tiene prioridad sobre memorylimitmb la definida en mssql.conf.

  • memorylimitmb no puede superar la memoria física real del sistema host.

  • Establezca memorylimitmb un valor inferior a la memoria del sistema host y el cgroup límite (si está presente), para asegurarse de que hay suficiente memoria física libre para el sistema operativo Linux. Si no establece memorylimitmbexplícitamente , SQL Server usa el 80 % del valor menor entre la memoria total del sistema y el cgroup límite (si está presente).

  • La opción de configuración del servidor max_server_memory limita solo el tamaño del grupo de búferes de SQL Server y no rige el uso general de memoria para SQL Server en Linux. Establezca siempre este valor por debajo de memorylimitmb para asegurarse de que la memoria suficiente permanece para los demás componentes descritos en la viñeta anterior.

Límites de espacio entre SQL Server y memoria de contenedor

Al ejecutar SQL Server en un contenedor con un límite de memoria configurado (por ejemplo, la cgroup configuración memory.max), mantenga el espacio de espera entre memory.memorylimitmb y el límite de memoria del contenedor. Este margen proporciona capacidad para la sobrecarga del sistema operativo y los procesos auxiliares dentro del contenedor.

  • Para la mayoría de las implementaciones, reserve entre el 10 y el 20 por ciento de la memoria del contenedor para el sistema operativo y los procesos que no sean de SQL Server y establezca memory.memorylimitmb por debajo de la capacidad restante.

  • Para configuraciones de memoria de gran tamaño, un búfer basado en porcentajes puede reservar más memoria de la necesaria. Por ejemplo, el 10 % de un contenedor de 256 GB es de aproximadamente 25 GB, lo que es razonable para la sobrecarga del sistema operativo. Sin embargo, el 10 % de un contenedor de 512 GB es de aproximadamente 51 GB, lo que probablemente es más que lo que requiere el sistema operativo. En estos casos, use un búfer fijo en su lugar, el tamaño adecuado para la carga de trabajo y la sobrecarga del sistema operativo, y asigne el resto a SQL Server.

  • Ajuste el búfer en función de las características de la carga de trabajo, otros servicios que se ejecutan en el contenedor y la configuración del host.

Note

No se aplica ningún valor de espacio de cabeza recomendado a todos los entornos. Valide la configuración de memoria mediante pruebas para garantizar la estabilidad del sistema en la carga máxima.

Evitar la configuración de límites de memoria superiores a la memoria disponible

No configure memory.memorylimitmb con un valor superior a la memoria física disponible en el host ni al límite de memoria impuesto por el contenedor. Si lo hace, SQL Server podría consumir memoria de forma agresiva, dejando insuficiente capacidad para el sistema operativo y los procesos auxiliares. Esta configuración puede dar lugar a:

  • Aumento de la presión de memoria.
  • Se ha reducido la estabilidad del sistema y las interrupciones inesperadas del servicio.
  • Terminación del proceso sqlservr por parte del sistema operativo debido a condiciones de falta de memoria (OOM).

Configure los límites de memoria de SQL Server por debajo de la memoria efectiva disponible para el anfitrión o el contenedor, y deje un margen suficiente para el sistema operativo y los servicios de tiempo de ejecución.

Ejemplos de configuración de memoria de Docker

La docker run --memory opción establece el cgroup límite de memoria para el contenedor. Este límite es el tope máximo estricto impuesto por el kernel para todos los procesos del contenedor. MSSQL_MEMORY_LIMIT_MB(o memory.memorylimitmb) controla la cantidad de memoria que SQL Server puede usar. Como se describe en las instrucciones anteriores, establezca MSSQL_MEMORY_LIMIT_MB siempre más bajo que el límite de memoria del contenedor para dejar espacio para el sistema operativo y los procesos auxiliares.

En los ejemplos siguientes se usa un host con 16 GB de RAM. Ajuste los valores del entorno.

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" \
   -e "MSSQL_MEMORY_LIMIT_MB=14336" \
   -p 1433:1433 \
   -d mcr.microsoft.com/mssql/server:2022-latest

Sin --memory, el contenedor no tiene techo cgroup. MSSQL_MEMORY_LIMIT_MB restringe SQL Server, pero otros procesos dentro del contenedor aún pueden consumir memoria del host sin límites.

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" \
   -e "MSSQL_MEMORY_LIMIT_MB=12288" \
   --memory 12g \
   -p 1433:1433 \
   -d mcr.microsoft.com/mssql/server:2022-latest

Ambos límites se establecen en 12 GB (--memory 12g = 12 288 MB). No queda espacio para la sobrecarga del sistema operativo ni los procesos auxiliares, lo que puede provocar la eliminación de OOM.

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" \
   -e "MSSQL_MEMORY_LIMIT_MB=14336" \
   --memory 12g \
   -p 1433:1433 \
   -d mcr.microsoft.com/mssql/server:2022-latest

MSSQL_MEMORY_LIMIT_MB (14 GB) supera el límite de contenedor (12 GB). Este escenario conduce a las condiciones de OOM descritas en Evitar la configuración de límites de memoria mayores que la memoria disponible.

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" \
   -e "MSSQL_MEMORY_LIMIT_MB=10240" \
   --memory 12g \
   -p 1433:1433 \
   -d mcr.microsoft.com/mssql/server:2022-latest

El contenedor está limitado a 12 GB (--memory 12g) y SQL Server está configurado para usar hasta 10 GB (MSSQL_MEMORY_LIMIT_MB=10240). El resto de 2 GB (aproximadamente el 17 por ciento) proporciona espacio para el sistema operativo y otros procesos.

Consideraciones sobre el espacio de intercambio

Al ejecutar SQL Server en un contenedor, habilite el espacio de intercambio en el nivel de host para ayudar a proteger el sistema operativo y los procesos que no son de SQL Server. Sin embargo, configure SQL Server para que funcione dentro de sus límites de memoria configurados y no confíe en el intercambio durante el funcionamiento normal.

  • Siga las instrucciones de límite de memoria para asegurarse de que SQL Server funciona dentro de la memoria física o el límite de memoria aplicablecgroup.

  • Si la memoria de intercambio está habilitada, trátela como una red de seguridad para picos transitorios de presión de memoria en el host, no como capacidad para cargas de trabajo estables de SQL Server.

Importante

El rendimiento de SQL Server puede degradarse significativamente si la presión de memoria provoca el intercambio de memoria. El ajuste de tamaño de memoria adecuado es el mecanismo principal para evitar errores relacionados con la memoria.

Contenido relacionado

  • Last updated on