Рекомендации по производительности: память SQL Server в Linux

Применимо к:SQL Server в Linux

В этой статье рассматривается конфигурация памяти для SQL Server в Linux, включая ограничения памяти mssql-conf, параметры control group (cgroup), примеры настройки памяти для контейнеров Docker и особенности использования пространства подкачки.

Установка ограничения памяти с помощью mssql-conf

Чтобы обеспечить достаточно свободного физического памяти для операционной системы Linux, процесс SQL Server использует только 80 процентов физической памяти по умолчанию. Для некоторых систем с большим объемом физической ОЗУ 20 процентов может быть значительным числом. Например, в системе с 1 ТБ ОЗУ параметр по умолчанию оставляет около 200 ГБ ОЗУ неиспользуемой. В таком случае может быть желательно установить более высокий предел памяти.

Это значение можно изменить с помощью mssql-conf средства или переменной MSSQL_MEMORY_LIMIT_MB среды. Дополнительные сведения см. в параметре memory.memorylimitmb , который управляет памятью, видимой для SQL Server (в единицах МБ). Подробные рекомендации по размеру см. в руководстве по настройке ограничений памяти на Linux и в контейнерах.

Поддержка группы управления (cgroup) версии 2

SQL Server обнаруживает и учитывает ограничения контрольной группы (cgroup) версии 2, начиная с накопительного обновления (CU) 20 для SQL Server 2025 (17.x) и SQL Server 2022 (16.x). Эти ограничения обеспечивают точное управление ядром Linux над ресурсами ЦП и памяти, а также улучшает изоляцию ресурсов в средах Docker, Kubernetes и OpenShift.

В более ранних версиях контейнерные развертывания в кластерах Kubernetes (например, Служба Azure Kubernetes версии 1.25+) могли сталкиваться с ошибками недостатка памяти (OOM), так как SQL Server не применял ограничения памяти, определенные в спецификациях контейнеров. Поддержка Cgroup версии 2 устраняет эту проблему.

Проверьте версию cgroup

stat -fc %T /sys/fs/cgroup

Результаты приведены следующим образом:

Переключение на cgroup версии 2

Самый простой путь — выбор дистрибутива, который поддерживает cgroup версии 2 из коробки.

Если необходимо переключиться вручную, добавьте следующий параметр в конфигурацию GRUB:

systemd.unified_cgroup_hierarchy=1

Затем обновите GRUB. Например, в Ubuntu выполните следующую команду:

sudo update-grub

В Red Hat Enterprise Linux (RHEL) выполните следующую команду:

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

Отчеты об ограничении ЦП с помощью cgroup версии 2

При настройке ограничений ЦП с помощью cgroup версии 2 SQL Server не отображает настроенное количество ядер ЦП в журнале ошибок. Вместо этого он продолжает сообщать общее количество ЦП узла.

Чтобы выровнять планировщик SQL Server и планы запросов (например, решения параллелизма) с предполагаемым числом ЦП, определенным в cgroup версии 2, примените следующую конфигурацию.

Настройка процессорного сродства

Явным образом задается сопоставление SQL Server процессора в соответствии с квотой выполнения cgroup. В следующем примере квота cgroup составляет четыре ЦП на восьмиъядерном хосте.

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

Эта конфигурация гарантирует, что SQL Server создает планировщики только для предполагаемого количества ЦП. Дополнительные сведения см. в ALTER SERVER CONFIGURATION и Использование PROCESS AFFINITY для узла и/или процессоров.

Включение флага трассировки 8002 (рекомендуется)

Включите флаг трассировки 8002 для использования мягкого аффинирования на уровне SQLPAL.

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

По умолчанию планировщики привязаны к определённым CPU, указанным в маске привязки. Флаг трассировки 8002 позволяет планировщикам переключаться между ЦП, что, как правило, повышает производительность, при этом соблюдая соответствие связей и ограничения cgroup. Дополнительные сведения см. в разделе DBCC TRACEON — флаги трассировки.

Перезапустите SQL Server после включения флага трассировки.

Ожидаемое поведение

После перезапуска:

• SQL Server создает только количество планировщиков, определенных настройкой аффинности (например, четыре планировщика).

• Ядро Linux продолжает поддерживать в силе квоту использования процессора cgroup версии 2.

• Решения по оптимизации запросов и параллелизму основаны на предполагаемом количестве ЦП, а не на общих ЦП узла.

Дополнительные сведения см. на следующих ресурсах:

• Быстрый старт: Развертывание контейнера SQL Server в Linux на Kubernetes с помощью диаграмм Helm
• Группа управления версии 2 (документация по ядрам Linux)

Рекомендации по настройке ограничений памяти на Linux и в контейнерах

SQL Server на Linux имеет несколько элементов управления памятью, которые работают на разных уровнях. В следующей таблице и схеме показано, как каждый уровень сужает доступную память, от ОЗУ узла до буферного пула.

При настройке ограничений памяти для SQL Server в Linux рассмотрите следующие рекомендации.

• В развертываниях контейнеров используйте cgroup для ограничения общего объема памяти, доступной для контейнера. Этот параметр устанавливает верхнюю границу для всех процессов внутри контейнера.

• Ограничение памяти (независимо от того, установлено ли оно с помощью memorylimitmb или задано переменной среды MSSQL_MEMORY_LIMIT_MB) контролирует общий объем памяти, который SQL Server на Linux может выделять для всех своих компонентов, таких как буферный пул, SQLPAL, агент SQL Server, LibOS, PolyBase, Full-Text Search, и любые другие процессы, использующиеся в SQL Server на Linux.

• Переменная MSSQL_MEMORY_LIMIT_MB среды имеет приоритет над memorylimitmb определенным в mssql.conf.

• memorylimitmb не может превышать фактическую физическую память хост-системы.

• Установите значение memorylimitmb ниже объёма памяти хост-системы и ограничения cgroup (если задано), чтобы обеспечить достаточный объём свободной физической памяти для операционной системы Linux. Если вы явно не задаетеmemorylimitmb, SQL Server использует 80 процентов меньшего значения между общей системной памятью и ограничением cgroup (при наличии).

• Параметр конфигурации сервера max_server_memory ограничивает только размер буферного пула SQL Server и не управляет общим использованием памяти для SQL Server в Linux. Всегда устанавливайте это значение ниже memorylimitmb, чтобы обеспечить достаточный объём памяти для других компонентов, описанных в предыдущем пункте.

Запас памяти между SQL Server и ограничениями памяти контейнера

При запуске SQL Server в контейнере с заданным ограничением памяти (например, с параметром cgroupmemory.max) оставляйте запас между memory.memorylimitmb и ограничением памяти контейнера. Этот запас ресурсов покрывает накладные расходы операционной системы, а также вспомогательные процессы внутри контейнера.

• Для большинства развертываний зарезервируйте от 10 до 20 процентов памяти контейнера для операционной системы и процессов, не относящихся к SQL Server, и установите значение memory.memorylimitmb меньше оставшегося объема памяти.

• Для конфигураций большого объема памяти буфер на основе процента может зарезервировать больше памяти, чем необходимо. Например, 10 процентов контейнера размером 256 ГБ составляет около 25 ГБ, что является разумным для затрат на операционную систему. Однако 10 процентов контейнера размером 512 ГБ составляет около 51 ГБ, что, скорее всего, больше, чем требует операционная система. В этих случаях вместо этого используйте фиксированный буфер, размер которого должен соответствовать вашей рабочей нагрузке и накладным расходам операционной системы, а остальной объём выделите SQL Server.

• Настройте буфер на основе характеристик рабочей нагрузки, других служб, работающих в контейнере, и конфигурации узла.

Избегайте настройки ограничений памяти, превышающих доступную память

Не задавайте для memory.memorylimitmb значение выше доступного объёма физической памяти на хосте или выше лимита памяти контейнера. В этом случае SQL Server может агрессивно потреблять память, оставляя недостаточно объема памяти для операционной системы и сопутствующих процессов. Эта конфигурация может привести к следующему:

• Увеличение давления памяти.
• Снижение стабильности системы и непредвиденные прерывания службы.
• Завершение операционной системой sqlservr процесса при нехватке памяти (OOM).

Настройте SQL Server ограничения памяти ниже эффективной памяти, доступной для узла или контейнера, и оставьте достаточное буферное пространство для служб операционной системы и среды выполнения.

Примеры конфигурации памяти Docker

Параметр docker run --memory задает cgroup ограничение памяти для контейнера. Это ограничение является жестким верхним пределом, принудительно применяемым ядром ко всем процессам в контейнере. MSSQL_MEMORY_LIMIT_MB(илиmemory.memorylimitmb) определяет, сколько памяти SQL Server может использовать. Как описано в предыдущих рекомендациях, всегда устанавливайте MSSQL_MEMORY_LIMIT_MB ниже предела памяти контейнера, чтобы оставить запас для операционной системы и вспомогательных процессов.

В следующих примерах используется хост с 16 ГБ ОЗУ. Настройте значения для вашей среды.

Не рекомендуется: отсутствует ограничение памяти контейнера

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

Без --memory у контейнера нет cgroup потолка. MSSQL_MEMORY_LIMIT_MBограничивает SQL Server, но другие процессы внутри контейнера по-прежнему могут использовать несвязанную память узла.

Не рекомендуется: ограничение памяти равно SQL Server ограничению памяти

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

Оба ограничения имеют значение 12 ГБ (--memory 12g = 12 288 МБ). Не остается запаса ресурсов для служебных нужд операционной системы или вспомогательных процессов, что может привести к принудительному завершению процессов из-за нехватки памяти (OOM).

Не рекомендуется: SQL Server предел памяти превышает ограничение контейнера

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 ГБ) превышает ограничение контейнера (12 ГБ). Этот сценарий приводит к условиям OOM, описанным в разделе "Избегайте настройки ограничений памяти выше доступной памяти".

Рекомендуется: лимит контейнера с запасом для операционной системы

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

Контейнер ограничен 12 ГБ (--memory 12g), а SQL Server настроено на использование до 10 ГБ (MSSQL_MEMORY_LIMIT_MB=10240). Оставшиеся 2 ГБ (около 17 процентов) обеспечивают запас для операционной системы и других процессов.

Рекомендации по замене пространства

При запуске SQL Server в контейнере включите пространство буфера на уровне узла, чтобы защитить операционную систему и процессы, отличные от SQL Server. Однако настройте SQL Server так, чтобы он работал в пределах заданных ограничений по памяти, и не полагайтесь на подкачку во время обычной работы.

• Следуйте рекомендациям по ограничению памяти, чтобы убедиться, что SQL Server работает в физической памяти или применимом ограничении cgroup памяти.

• Если подкачка включена, рассматривайте её как страховочный механизм на случай кратковременной нехватки памяти на хосте, а не как постоянный ресурс для стабильных рабочих нагрузок SQL Server.

Связанный контент

• Рекомендации по производительности: хранилище, ядро, ЦП и сеть для SQL Server на Linux
• Связанные динамические административные представления и функции Linux (Transact-SQL)
• Пошаговое руководство по функциям производительности SQL Server на Linux
• Что такое SQL Server на Linux?