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

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

  • Статья

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

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

Следующие рекомендации содержат рекомендации по настройке SQL Server и операционной системы Linux (ОС). Рекомендуется использовать эти параметры конфигурации, чтобы обеспечить оптимальную производительность для установки SQL Server.

Рекомендации по конфигурации хранилища

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

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

Как правило, в локальных средах поставщик хранилища поддерживает соответствующую конфигурацию аппаратного RAID с чередованием данных на нескольких дисках, чтобы обеспечить соответствующие IOPS, пропускную способность и избыточность. Хотя это может варьироваться у разных поставщиков хранилищ и различных предложений систем хранения с разной архитектурой.

Для сервера SQL Server на Linux, развернутого на Виртуальных машинах Azure, рекомендуется использовать программную реализацию RAID, чтобы обеспечить выполнение требований к скорости ввода-вывода и пропускной способности. При настройке SQL Server на виртуальных машинах Azure с аналогичными рекомендациями по хранению см. раздел "Настройка хранилища для SQL Server на виртуальных машинах Azure".

В следующем примере показано, как создать программный RAID-массив в Linux на виртуальных машинах Azure. Помните, что необходимо использовать соответствующее количество дисков данных для обеспечения требуемой пропускной способности и количества операций ввода-вывода для томов на основе требований данных, журнала транзакций и tempdb операций ввода-вывода. В следующем примере восемь дисков данных были подключены к виртуальной машине Azure; 4 для размещения файлов данных, 2 для журналов транзакций и 2 для tempdb рабочей нагрузки.

Чтобы найти устройства (например, /dev/sdc) для создания RAID, используйте lsblk команду.

# For Data volume, using 4 devices, in RAID 5 configuration with 8KB stripes
mdadm --create --verbose /dev/md0 --level=raid5 --chunk=8K --raid-devices=4 /dev/sdc /dev/sdd /dev/sde /dev/sdf

# For Log volume, using 2 devices in RAID 10 configuration with 64KB stripes
mdadm --create --verbose /dev/md1 --level=raid10 --chunk=64K --raid-devices=2 /dev/sdg /dev/sdh

# For tempdb volume, using 2 devices in RAID 0 configuration with 64KB stripes
mdadm --create --verbose /dev/md2 --level=raid0 --chunk=64K --raid-devices=2 /dev/sdi /dev/sdj

Рекомендации по разбиению дисков на разделы и их настройке

Для SQL Server следует использовать конфигурацию RAID. Развернутая единица полосы файловой системы (sunit) и ширина полосы должны соответствовать геометрии RAID. Например, это пример на основе XFS для тома журнала.

# Creating a log volume, using 6 devices, in RAID 10 configuration with 64KB stripes
mdadm --create --verbose /dev/md3 --level=raid10 --chunk=64K --raid-devices=6 /dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf

mkfs.xfs /dev/md3 -f -L log
meta-data=/dev/md3               isize=512    agcount=32, agsize=18287648 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1
data     =                       bsize=4096   blocks=585204384, imaxpct=5
         =                       sunit=16     swidth=48 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=285744, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Массив журналов представляет собой 6-дисковый RAID-10 с полосой размером 64 КБ. Вы можете видеть следующее.

  • Для sunit=16 blks, 16 * 4096 размер блока = 64 КБ, соответствует размеру полосы.
  • Для swidth=48 blks, swidth / sunit = 3, что означает количество дисков данных в массиве, не включая диски четности.

Рекомендация по настройке файловой системы

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

Форматирование тома с помощью файловой системы XFS:

mkfs.xfs /dev/md0 -f -L datavolume
mkfs.xfs /dev/md1 -f -L logvolume
mkfs.xfs /dev/md2 -f -L tempdb

При создании и форматировании тома XFS можно настроить файловую систему XFS без учета регистра. Это не часто используемая конфигурация в экосистеме Linux, но ее можно использовать по соображениям совместимости.

Например, можно выполнить следующую команду. -n version=ci используется для настройки файловой системы XFS, которая не учитывает регистр.

mkfs.xfs /dev/md0 -f -n version=ci -L datavolume

Рекомендация по файловой системе постоянной памяти

Для настройки файловой системы на устройствах с постоянной памятью следует установить выделение блоков размером в 2 MB. Дополнительные сведения об этой статье см. в статье "Технические рекомендации".

Ограничение на количество открытых файлов

В рабочей среде может потребоваться больше подключений, чем ограничение открытого файла по умолчанию — 1024. Вы можете установить мягкие и жесткие ограничения на значение 1 048 576. Например, в RHEL измените /etc/security/limits.d/99-mssql-server.conf файл, чтобы иметь следующие значения:

mssql - nofile 1048576

Примечание.

Этот параметр не применяется к службам SQL Server, запущенным systemd. Для получения дополнительной информации см. Как настроить ограничения для служб в RHEL и systemd.

Отключение временной метки последнего доступа для файлов данных и файлов журналов в файловых системах SQL Server

Чтобы убедиться, что диски, подключенные к системе, автоматически подключаются после перезагрузки, добавьте их в /etc/fstab файл. Вы также должны использовать UUID (универсальный уникальный идентификатор) для /etc/fstab ссылки на диск, а не только имя устройства (например /dev/sdc1, ).

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

Запись точки подключения в /etc/fstab:

UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" /data1 xfs rw,attr2,noatime 0 0

В предыдущем примере UUID представляет устройство, которое можно найти с помощью blkid команды.

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 by 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.

Параметры ядра и ЦП для высокой производительности

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

Настройка параметров ядра с помощью TuneD

Для пользователей Red Hat Enterprise Linux (RHEL) профиль пропускной способности TuneD настраивает некоторые параметры ядра и ЦП автоматически (за исключением C-States). Начиная с RHEL 8.0, профиль TuneD с именем mssql был совместно разработан с Red Hat и предлагает более точную настройку производительности Linux для повышения производительности рабочих нагрузок SQL Server. Этот профиль включает профиль производительности пропускной способности RHEL, и мы представляем его определения в этой статье для проверки с другими дистрибутивами Linux и выпусками RHEL без этого профиля.

Для SUSE Linux Enterprise Server 12 SP5, Ubuntu 18.04 и Red Hat Enterprise Linux 7.x пакет tuned можно установить вручную. Его можно использовать для создания и настройки mssql профиля, как описано в следующем разделе.

Предлагаемые параметры Linux с использованием профиля TuneD mssql

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

[main]
summary=Optimize for Microsoft SQL Server
include=throughput-performance

[cpu]
force_latency=5

[sysctl]
vm.swappiness = 1
vm.dirty_background_ratio = 3
vm.dirty_ratio = 80
vm.dirty_expire_centisecs = 500
vm.dirty_writeback_centisecs = 100
vm.transparent_hugepages=always
# For multi-instance SQL deployments, use
# vm.transparent_hugepages=madvise
vm.max_map_count=1600000
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
kernel.numa_balancing=0

Если вы используете дистрибутивы Linux с версиями ядра больше 4.18, закомментируйте следующие параметры, как показано ниже; в противном случае раскомментируйте следующие параметры, если вы используете дистрибутивы с версиями ядра до версии 4.18.

# kernel.sched_latency_ns = 60000000
# kernel.sched_migration_cost_ns = 500000
# kernel.sched_min_granularity_ns = 15000000
# kernel.sched_wakeup_granularity_ns = 2000000

Чтобы включить этот профиль TuneD, сохраните эти определения в файле в tuned.conf папке /usr/lib/tuned/mssql и включите профиль с помощью следующих команд:

chmod +x /usr/lib/tuned/mssql/tuned.conf
tuned-adm profile mssql

Убедитесь, что профиль активен, выполнив следующую команду:

tuned-adm active

Или сделайте так:

tuned-adm list

Рекомендации в отношении параметров ЦП

В приведенной ниже таблице представлены рекомендации по параметрам ЦП.

Настройка Значение Дополнительные сведения
Регулятор частоты ЦП производительность См. описание команды cpupower
ENERGY_PERF_BIAS производительность См. описание команды x86_energy_perf_policy
min_perf_pct 100 Посмотрите документацию по Intel P-state
C-States Только C1 См. документацию по Linux или вашей системе, чтобы узнать, как установить C-States только на C1.

Использование TuneD, как описано ранее, автоматически настраивает регулятор частоты ЦП и параметры min_perf_pct соответствующим образом, поскольку профиль throughput-performance используется как основа для профиля mssql. Параметр C-States необходимо настроить вручную в соответствии с документацией, предоставляемой сообществом Linux или распространителем системы.

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

В приведенной ниже таблице представлены рекомендации по параметрам дисков.

Настройка Значение Дополнительные сведения
Диск readahead 4096 См. blockdev команду
Параметры sysctl kernel.sched_min_granularity_ns = 15000000
kernel.sched_wakeup_granularity_ns = 2000000
vm.dirty_ratio = 80
vm.dirty_background_ratio = 3
vm.swappiness = 1		 См. описание команды sysctl

Описание

  • vm.swappiness: этот параметр определяет относительный вес, данный для выгрузки памяти исполняемого процесса по сравнению с кэшем файловой системы. Значение этого параметра по умолчанию составляет 60, что означает обмен страницами памяти процесса среды выполнения по сравнению с удалением страниц кэша файловой системы в соотношении 60:140. Установка значения 1 указывает на сильное предпочтение сохранять память процесса выполнения в физической памяти за счет кэша файловой системы. Так как SQL Server использует буферный пул в качестве кэша страниц данных и преимущественно выполняет запись в физическую память в обход кэша файловой системы для надежного восстановления, конфигурация с агрессивной подкачкой может быть выгодна для высокопроизводительных и выделенных серверов SQL Server. Дополнительные сведения см. в документации для /proc/sys/vm/—#swappiness.

  • vm.dirty_*: Записи файлов SQL Server выполняются без кеширования, что удовлетворяет требованиям к целостности данных. Эти параметры позволяют обеспечивать эффективную асинхронную запись и снижать влияние операций ввода-вывода на кэширование в Linux, обеспечивая достаточно большой объем кэширования при ограничении очистки.

  • kernel.sched_*: Эти значения параметров представляют собой текущую рекомендацию по оптимальной настройке алгоритма полностью справедливого планирования (CFS) в ядре Linux, чтобы улучшить пропускную способность сетевых и складских вызовов ввода-вывода с учётом межпроцессного прерывания и возобновления потоков.

Использование профиля TuneD настраивает параметры vm.swappiness, vm.dirty_* и kernel.sched_*. Настройка readahead для диска с помощью команды blockdev производится на уровне устройства и должна выполняться вручную.

Настройка ядра для автоматической балансировки NUMA в системах с несколькими узлами NUMA

Если установить SQL Server в системе NUMA с несколькими узлами, по умолчанию включен следующий kernel.numa_balancing параметр ядра. Чтобы разрешить SQL Server работать с максимальной эффективностью в системе NUMA, отключите автоматическую балансировку NUMA в системе NUMA с несколькими узлами:

sysctl -w kernel.numa_balancing=0

mssql Использование профиля TuneD настраивает kernel.numa_balancing этот параметр.

Параметры ядра для виртуального адресного пространства

Параметр vm.max_map_count по умолчанию (65536) может быть недостаточно высоким для установки SQL Server. По этой причине измените значение параметра vm.max_map_count по крайней мере до 262144 для развертывания SQL Server и ознакомьтесь с разделом предлагаемых параметров Linux с помощью профиля TuneD mssql для дополнительной настройки этих параметров ядра. Максимальное значение для vm.max_map_count 2147483647.

sysctl -w vm.max_map_count=1600000

mssql Использование профиля TuneD настраивает vm.max_map_count этот параметр.

Сохранение параметра Transparent Huge Pages (THP) во включенном состоянии

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

echo madvise > /sys/kernel/mm/transparent_hugepage/enabled

Или измените профиль TuneD, добавив строку: mssql

vm.transparent_hugepages=madvise

И сделайте mssql профиль активным после изменения:

tuned-adm off
tuned-adm profile mssql

Использование профиля TuneD mssql конфигурирует transparent_hugepage данный параметр.

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

Как и в случае с хранилищем и ЦП, существуют рекомендации в отношении сети. Они приведены ниже для справки. Не все параметры в следующих примерах доступны в разных сетевых адаптерах. Обратитесь к поставщикам сетевых карт для консультации и получения указаний по каждому из этих вариантов. Протестируйте эти настройки в среде разработки перед их применением в рабочей среде. Ниже приведены примеры, а используемые команды относятся к типу сетевого адаптера и поставщику.

  1. Настройка размера буфера сетевого порта. В примере ниже сетевой адаптер называется eth0, и он является адаптером на основе Intel. Для сетевого адаптера на основе Intel рекомендуемый размер буфера составляет 4 КБ (4096). Проверьте предустановленные максимумы и настройте его с помощью следующего примера:

    Проверьте предварительные максимумы с помощью следующей команды. Замените eth0 на имя вашего NIC.

    ethtool -g eth0

    Задайте для буфера rx (получения) и tx (передачи) значение 4 КБ:

    ethtool -G eth0 rx 4096 tx 4096

    Убедитесь, что значение настроено правильно:

    ethtool -g eth0

  2. Включите джамбо-фреймы. Прежде чем включать большие кадры, убедитесь, что все сетевые коммутаторы, маршрутизаторы и другие важные элементы в сетевом пути передачи пакетов между клиентами и SQL Server поддерживают большие кадры. Только в этом случае включение кадров большего размера может повысить производительность. После включения увеличенных кадров подключитесь к SQL Server и установите размер сетевого пакета на 8060 байт с помощью sp_configure, как показано ниже.

    # command to set jumbo frame to 9014 for a Intel NIC named eth0 is
ifconfig eth0 mtu 9014
# verify the setting using the command:
ip addr | grep 9014

    EXECUTE sp_configure 'network packet size', '8060';
GO

RECONFIGURE WITH OVERRIDE;
GO

  3. По умолчанию рекомендуется задать порт для адаптивного объединения RX/TX IRQ, что означает, что доставка прерываний корректируется, чтобы повысить задержку при низкой скорости пакетов и повысить пропускную способность при высокой скорости пакетов. Этот параметр может быть недоступен во всех разных сетевых инфраструктурах, поэтому просмотрите существующую сетевую инфраструктуру и убедитесь, что она поддерживается. Ниже приведен пример для сетевого адаптера с именем eth0, который является сетевой картой на основе Intel:

    1. Задайте порт для адаптивного объединения RX/TX IRQ:

      ethtool -C eth0 adaptive-rx on
ethtool -C eth0 adaptive-tx on

    2. Подтвердите параметр:

      ethtool -c eth0

    Примечание.

    Для предсказуемого поведения в высокопроизводительных средах, таких как среды для тестирования производительности, отключите адаптивное объединение запросов на прерывание RX/TX и затем отдельно задайте объединение прерываний RX/TX. Чтобы отключить объединение запросов на прерывание RX/TX, воспользуйтесь примером команд, а затем установите конкретные значения.

    Отключите адаптивное объединение RX/TX IRQ:

    ethtool -C eth0 adaptive-rx off
ethtool -C eth0 adaptive-tx off

    Подтвердите изменение:

    ethtool -c eth0

    Установите параметры rx-usecs и irq. rx-usecs указывает, через сколько микросекунд после получения как минимум 1 пакета будет сгенерировано прерывание. Параметр irq указывает соответствующие задержки при обновлении состояния при отключении прерывания. Для сетевых карт компании Intel можно использовать следующие параметры.

    ethtool -C eth0 rx-usecs 100 tx-frames-irq 512

    Подтвердите изменение:

    ethtool -c eth0

  4. Мы также рекомендуем включить масштабирование на стороне получения (RSS) и по умолчанию объединить RX и TX-сторону очередей RSS. Существуют определенные сценарии при работе с служба поддержки Майкрософт, где отключение RSS также улучшило производительность. Протестируйте этот параметр в тестовой среде перед его применением в рабочих средах. В следующем примере используется сетевые адаптеры Intel.

    Получение предустановленных максимальных значений:

    ethtool -l eth0

    Объедините очереди с максимальным значением, указанным в предустановке "Объединенный". В этом примере значение установлено на 8:

    ethtool -L eth0 combined 8

    Проверьте настройки:

    ethtool -l eth0

  5. Работа с привязкой прерываний для портов сетевого интерфейса. Чтобы добиться ожидаемой производительности, настраивая привязку IRQ, рассмотрите несколько важных параметров, включая обработку серверной топологии в Linux, стек драйверов сетевой карты, параметры по умолчанию и настройку irqbalance. Оптимизация параметров привязки запросов на прерывание для портов сетевой карты выполняется с учетом топологии сервера, отключением irqbalance и использованием параметров конкретного поставщика сетевой карты.

    Следующий пример конкретной сетевой инфраструктуры Mellanox помогает объяснить конфигурацию. Дополнительные сведения о том, как скачать средства Mellanox для сетевых адаптеров Mellanox, см. в разделе "Средства настройки производительности". Команды изменяются в зависимости от среды. Обратитесь к поставщику сетевого адаптера, чтобы получить дополнительные рекомендации.

    Отключите irqbalanceили получите моментальный снимок параметров IRQ и принудительно завершите работу управляющей программы:

    systemctl disable irqbalance.service

    Или сделайте так:

    irqbalance --oneshot

    Убедитесь, что common_irq_affinity.sh это исполняемый файл:

    chmod +x common_irq_affinity.sh

    Отображение привязки IRQ для порта сетевого адаптера Mellanox (например, eth0):

    ./show_irq_affinity.sh eth0

    Оптимизируйте оптимальную производительность пропускной способности с помощью средства Mellanox:

    ./mlnx_tune -p HIGH_THROUGHPUT

    Установите привязку оборудования к узлу NUMA, на котором физически размещен сетевой адаптер и его порт.

    ./set_irq_affinity_bynode.sh `\cat /sys/class/net/eth0/device/numa_node` eth0

    Проверьте привязку IRQ:

    ./show_irq_affinity.sh eth0

    Улучшение оптимизаций объединения IRQ

    ethtool -C eth0 adaptive-rx off
ethtool -C eth0 adaptive-tx off
ethtool -C eth0  rx-usecs 750 tx-frames-irq 2048

    Проверьте параметры:

    ethtool -c eth0

  6. После внесения указанных выше изменений проверьте скорость работы сетевой карты, чтобы удостовериться, что она соответствует ожиданиям, с помощью следующей команды:

    ethtool eth0 | grep -i Speed

Расширенная конфигурация ядра и ОС

  • Для оптимальной производительности операций ввода-вывода хранилища используйте многозапускное планирование Linux для блочных устройств, что позволяет производительности блочного слоя масштабироваться с быстрыми твердотельными дисками (SSD) и многоядерными системами. Проверьте документацию, если она включена по умолчанию в дистрибутиве Linux. В большинстве случаев запуск ядра с параметром scsi_mod.use_blk_mq=y активирует его, хотя документация по дистрибутиву Linux может содержать дополнительные рекомендации на этот счёт. Это соответствует вышестоящему ядру Linux.

  • Так как для развертываний SQL Server часто используются многопаточные операции ввода-вывода, настройте целевой объект многострочной схемы устройств (DM) для использования blk-mq инфраструктуры, включив dm_mod.use_blk_mq=y параметр загрузки ядра. Значение по умолчанию — n (отключено). Когда базовые устройства SCSI используют blk-mq, этот параметр сокращает затраты на блокировку на уровне DM. Дополнительные сведения о настройке многопатокового ввода-вывода см. в документации по дистрибутиву Linux.

Настройка файла подкачки

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

Виртуальные машины и динамическая память

Если SQL Server на Linux выполняется в виртуальной машине, настройте фиксированный размер памяти, резервируемой для виртуальной машины. Не используйте такие функции, как динамическая память Hyper-V.

Конфигурация SQL Server

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

Лучшие практики

Использование PROCESS AFFINITY для узлов и ЦП

Используйте ALTER SERVER CONFIGURATION для настройки PROCESS AFFINITY для всех NUMANODE и/или ЦП, которые вы используете для SQL Server (как правило, для всех NODE и ЦП) в ОС Linux. Соответствие процессоров помогает эффективно планировать работу Linux и SQL. NUMANODE Использование параметра является самым простым методом. Используйте PROCESS AFFINITY даже если на компьютере есть только один узел NUMA. Дополнительные сведения о настройке PROCESS AFFINITYсм. в статье ALTER SERVER CONFIGURATION .

Настройка нескольких tempdb файлов данных

Так как установка SQL Server на Linux не предоставляет возможность настройки нескольких tempdb файлов, рекомендуется создать несколько tempdb файлов данных после установки. Дополнительные сведения см. в статье Рекомендации по сокращению состязания за выделяемые ресурсы в базе данных tempdb SQL Server.

Расширенная конфигурация

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

Настройка предельного объема памяти с помощью mssql-conf

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

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

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