Настройка энергонезависимой памяти (PMEM) для SQL Server на Linux

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

В этой статье описывается, как настроить постоянную память (PMEM) для SQL Server 2019 (15.x) и более поздних версий на Linux.

Overview

SQL Server 2019 (15.x) добавляет поддержку постоянной памяти для ускорения нескольких операций, требующих больших затрат на хранение.

С файловой системой, ориентированной на PMEM, отображение памяти (mmap()) предоставляет пользовательским приложениям прямой доступ к файловым данным. Когда для файла создаётся карта памяти, приложение может выдавать инструкции загрузки/сохранения, обходящие слой хранения.

Note

Этот прямой доступ называется просветлённым методом доступа к файлам с точки зрения расширения хоста, именно так SQL Server взаимодействует с операционной системой хоста с помощью SQL Platform Abstraction Layer (SQLPAL).

В этой статье показано, как настроить постоянную память для SQL Server на Linux.

Создание пространств имен для устройств PMEM

Настройка устройств

В Linux используйте служебную программу ndctl.

  • Установите ndctl для настройки устройства PMEM из раздела "Установка NDCTL".
  • Используйте ndctl для создания пространства имен. Пространства имен чередуются между микросхемами NVDIMM в PMEM и могут предоставлять различные типы доступа пользовательского пространства к областям памяти на устройстве. fsdax используется для SQL Server по умолчанию и в качестве предпочтительного режима.
ndctl create-namespace -f -e namespace0.0 --mode=fsdax --map=dev

Режим хранит fsdax метаданные на страницу в системной памяти. Этот --map=dev вариант рекомендуется, потому что он хранит метаданные непосредственно в пространстве имён. Хранение метаданных в памяти --map=mem — экспериментальное.

Проверьте пространство имен с помощью ndctl.

Пример выходных данных:

# ndctl list -N
{
  "dev":"namespace0.0",
  "mode":"fsdax",
  "map":"dev",
  "size":4294967296,
  "sector_size":512,
  "blockdev":"pmem0",
  "numa_node":0
}

Создание и подключение устройства PMEM

Например, с XFS:

mkfs.xfs -f /dev/pmem0
mount -o dax,noatime /dev/pmem0 /mnt/dax
xfs_io -c "extsize 2m" /mnt/dax

Например, с ext4:

mkfs.ext4 -b 4096 -E stride=512 -F /dev/pmem0
mount -o dax,noatime /dev/pmem0 /mnt/dax

Технические вопросы

  • Блокировка выделения 2 МБ для XFS или ext4, как описано ранее
  • Несоответствие между выделением блоков и mmap приводит к тихому возвращению к значению 4 КБ.
  • Размер файлов должен быть кратным 2 МБ (делиться на 2 МБ без остатка).
  • Не отключайте прозрачные огромные страницы (THP) (включено по умолчанию в большинстве дистрибутивов)

После ndctl настройки, создания и монтировки устройства можно разместить в него файлы базы данных или создать новую базу данных.

Вы можете хранить файлы данных SQL Server (.mdf, .ndf) и tempdb файлы на PMEM-устройстве в fsdax режиме следующей команды. Не используйте этот режим для хранения файлов журнала SQL Server (.ldf), потому что журнал транзакций требует хранилища с атомарными гарантиями секторов:

ndctl create-namespace -f -e namespace0.0 --mode=fsdax --map=dev

При настройке параметра map в приведенной выше команде учитывайте следующие моменты.

  • Для лучшей производительности при доступе и обновлении этих записей страниц NVDIMM для этого устройства используйте -map=mem
  • Если ёмкость NVDIMM слишком велика (больше 512 ГБ), установите -map=dev, что влияет на пропускную способность ввода/вывода и снижает производительность

Для файлов журналов SQL Server на устройствах PMEM настройте устройства PMEM на использование таблицы трансляции секторов/блоков (BTT). Эта конфигурация обеспечивает атомарность секторов, необходимую для лог-файлов SQL Server для этой технологии хранения. Проводите проверку производительности рабочей нагрузки. Сравните производительность логов SQL Server для вашей нагрузки между этим решением и лучшими NVMe SSD, а затем выберите тот, который лучше всего соответствует вашим потребностям.

ndctl create-namespace -f -e namespace0.0 --mode= sector

Отключение принудительного очистки

Так как устройства PMEM безопасны для прямого ввода-вывода (O_DIRECT), вы можете отключить принудительную очистку данных.

Note

Система хранения может гарантировать, что любые кэшированные или поэтапные записи безопасны и долговечны, гарантируя, что записи на устройство находятся на среде, который сохраняется при сбоях системы, сбросе интерфейса и отключениях питания, а сам носитель является аппаратно избыточным.

  • Файлы базы данных (.mdf и .ndf) и файлы журнала транзакций (.ldf) не используют writethrough и alternatewritethrough по умолчанию в SQL Server 2017 (14.x) с накопительным пакетом обновления 6 и более поздних версий, так как они используют принудительное поведение сброса. Флаг trace 3979 отключает принудительное промытие для файлов журналов баз данных и транзакций и использует writethrough логику and alternatewritethrough .

  • Другие файлы, которые открывает FILE_FLAG_WRITE_THROUGHSQL Server, такие как снимки базы данных, внутренние снимки для проверки согласованности базы данных (DBCC CHECKDB), файлы трассировки профайлера и расширенные файлы трассировки событий, используют writethrough оптимизацииalternatewritethrough.

Дополнительные сведения об изменениях, представленных в SQL Server 2017 (14.x) CU 6, см. статью в базе знаний 4131496. Дополнительные сведения о внутренних механизмах принудительного доступа единицы (FUA) см. в разделе «Внутреннее устройство FUA».

SQL Server и возможность принудительного доступа к устройствам (FUA) в подсистеме ввода-вывода

Некоторые поддерживаемые дистрибутивы Linux реализуют принудительный доступ к единицам (FUA) на уровне подсистемы ввода-вывода, чтобы обеспечить устойчивость данных. SQL Server использует эту возможность для обеспечения эффективной и надежной производительности ввода-вывода для рабочих нагрузок Linux. Дополнительные сведения о поддержке FUA в дистрибутивах Linux и её влиянии на SQL Server см. в статье SQL Server в Linux: внутренние компоненты принудительного доступа к блокам данных (FUA).

Поддержка FUA в подсистеме ввода-вывода появилась в SUSE Linux Enterprise Server 12 с пакетом обновления 5 (SP5), Red Hat Enterprise Linux 8.0 и Ubuntu 18.04. В SQL Server 2017 (14.x) с накопительным пакетом обновления 6 и в последующих версиях используйте следующую конфигурацию, чтобы обеспечить высокую производительность и эффективность операций ввода-вывода с помощью FUA в SQL Server.

Используйте эту рекомендуемую конфигурацию, если выполнены следующие условия:

  • SQL Server 2017 (14.x) CU 6 и более поздние версии

  • Дистрибутив Linux и версия, поддерживающие возможности FUA (начиная с Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 с пакетом обновления 5 (SP5) или Ubuntu 18.04)

    Note

    Начиная с SQL Server 2025 (17.x), SUSE Linux Enterprise Server (SLES) не поддерживается.

  • Файловая система XFS для хранилища SQL Server в ядрах Linux 4.18 или более поздних версиях.

  • файловая система ext4 для хранилища SQL Server в ядрах Linux 5.6 или более поздних версиях.

    Note

    Используйте файловую систему XFS для размещения файлов данных SQL Server и файлов журнала транзакций, если версия ядра Linux ниже 5.6. Начиная с ядра версии 5.6, вы можете выбрать между XFS и ext4 в зависимости от ваших требований.

  • Подсистема хранилища и оборудование, поддерживающие и настроенные для возможностей FUA

Рекомендуемая конфигурация:

  1. Включите флаг трассировки 3979 в качестве параметра запуска.

  2. Используется mssql-conf для настройки control.writethrough = 1 и control.alternatewritethrough = 0.

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

  1. Включите флаг трассировки 3982 в качестве параметра запуска (который используется по умолчанию для SQL Server в экосистеме Linux) и убедитесь, что флаг трассировки 3979 не включен в качестве параметра запуска.

  2. Используется mssql-conf для настройки control.writethrough = 1 и control.alternatewritethrough = 1.

Поддержка FUA для контейнеров SQL Server, развернутых в Kubernetes

  1. SQL Server должен использовать сохраненное подключенное хранилище, а не overlayfs.

  2. Хранилище должно использовать файловую систему XFS или ext4 и поддерживать FUA (ext4 не поддерживает FUA в ядре Linux до версии 5.6). Перед включением этого параметра обратитесь к поставщику дистрибутива и хранилища Linux, чтобы убедиться, что подсистема ОС и хранилища поддерживает параметры FUA. В Kubernetes вы можете запросить тип файловой системы, используя следующую команду, где <pvc-name> — это ваш PersistentVolumeClaim:

    kubectl describe pv <pvc-name>

    В выходных данных найдите fstype, который настроен на XFS.

  3. Рабочий узел, на котором размещены модули pod SQL Server, должен использовать дистрибутив Linux и версию, которая поддерживает функцию FUA (начиная с Red Hat Enterprise Linux 8.0, SUSE Linux Enterprise Server 12 с пакетом обновления 5 (SP5) или Ubuntu 18.04.

Если выполнены предыдущие условия, используйте следующие рекомендуемые параметры FUA:

  1. Включите флаг трассировки 3979 в качестве параметра запуска.

  2. Используется mssql-conf для настройки control.writethrough = 1 и control.alternatewritethrough = 0.

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

  • Last updated on