Поделиться через


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

Область применения: SQL Server — Linux

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

Обзор

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

Примечание.

Термин просвещение был введен для того, чтобы описать понятие работы с файловой системой, поддерживающей энергонезависимую память. Прямой доступ к файловой системе из приложений в пользовательском пространстве упрощается с помощью сопоставления памяти (mmap()). При создании сопоставления памяти для файла приложение может выдавать инструкции по загрузке или хранению, полностью обходя стек ввода-вывода. Это считается "усовершенствованным" методом доступа к файлам с точки зрения приложения для расширения хоста (который позволяет SQLPAL взаимодействовать с ОС Windows или Linux).

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

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

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

  • Установите ndctl, чтобы настроить устройство PMEM. Его можно найти здесь.
  • Используйте 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 (MDFS, NDFS) и tempdb файлы можно хранить на устройстве PMEM при настройке режима fsdax с помощью следующей команды. Не используйте это для хранения файлов журнала SQL Server (LDFS), так как журнал транзакций должен находиться в хранилище, которое обеспечивает атомарные гарантии сектора:

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

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

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

Настройте устройство(а) PMEM для файлов журналов SQL Server на использование сектора или таблицы перевода блоков (BTT). Это обеспечивает для этой технологии запоминающих устройств атомарность секторов, необходимую для файлов журналов SQL Server. Мы также рекомендуем выполнить проверку производительности рабочей нагрузки. Вы можете сравнить производительность журналов SQL Server для рабочей нагрузки между этим решением и лучшими в классе SVMe SSD, а затем выбрать решение, которое наилучшим образом соответствует вашим потребностям и обеспечивает лучшую производительность.

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

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

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

Примечание.

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

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

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

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

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

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

SUSE Linux Enterprise Server 12 с пакетом обновления 5 (SP5), Red Hat Enterprise Linux 8.0 и Ubuntu 18.04 представили поддержку возможностей FUA в подсистеме ввода-вывода. Если вы используете 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)

  • Файловая система XFS для хранилища SQL Server

  • Подсистема хранения и (или) оборудование, которое поддерживает и настраивается для возможностей 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 и поддерживать FUA. Перед включением этого параметра следует работать с поставщиком дистрибутива и хранилища 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 SP5 или Ubuntu 18.04).

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

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

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