Обновить

Самое короткое руководство по базовой настройке производительности Microsoft SQL Server

Уровень сложностиПростой
Время на прочтение4 мин
Охват и читатели5.3K
Всего голосов 7: ↑5 и ↓2+4
Комментарии18

Комментарии 18

Если на журнал транзакций не действует Instant File Initialization, то зачем ему ставить прирост с шагом 1–4Gb? Тем более, что с MSSQL 2022 IFI распростанятеся и на лог (но только если прирост не больше 64 MB)

Задача его инициализировать сразу нормального размера. Но мы знаем, что жизнь всегда богаче, и вырасти он может. На сколько прибавлять? И тут понеслись компромиссы. Прибавить 10Gb - это задержка на зануление. Прибавить 100Mb - избыточное число VLF. Сам обычно ставил примерно одну десятую от целевого размера файла, но Короткевич приводит цифру 1-4Gb. Кто я что бы спорить с экспертом.

О MS SQL 2022 нам только мечтать, спасибо за информацию. Могу еще несколько trace флагов для 2008 написать, вот реальность нашей жизни.

Насколько вообще количество VLF реально влияет на производительность? Какой-то оверхед, несомненно, есть, но насколько он значим на современном железе? Может это уже как те пресловутые рекомендации о 5% и 30% для реогра\ребилда, которые тянутся из глубины веков и не сильно релевантны для реалий NVME дисков?

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

Установите MAXDOP равным половине доступных ядер...

...и получите постоянные взаимоблокировки внутри одного (!) запроса в подарок. Практический беспроблемный максимум - 6...8, не более.

Значение по-умолчанию в этом случае работает лучше?

Так же отвратительно, как и ваша половина ядер.

Значит, например, на сервере с 24 ядрами и max dop 12 и ценой в 50 блокировки гарантированы?

Не понимаю, про какую цену речь, а на сервере с 24 ядрами и maxdop=12 регулярные дурные блокировки на многопоточных запросах будут возникать регулярно.

UPD: добавлю, что в свежих релизах это так и ниасилено. Все, что MS родили - чуть больше диагностики добавили в 2016sp2 (см. тут п.19). Объяснения примерно такие. И да, не видел буквально ни одной инсталляции без хорошего ограничения maxdop, где бы это не стреляло постоянно.

При парралелизме взаимоблокировки в рамках одного spid это не блокировки вообще, а координация процессов (главный ждёт подчинённых ). Я обычно ставлю 4 чтобы тяжёлый scan не скушал очень много

Именно взаимоблокировки, с соответсвующей записью в логе. Причина, видимо, обычно как раз указанная вами (и приводимая тут самой ms), но, похоже, и они сами в этом не слишком уверены. Так что это не просто "чтобы не скушал много" - это бы лвдно, если ядер с запасом, но это вынужденная мера против внутрипроцессных клинчей со всеми вытекающими.

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

Я не то чтобы настаиваю на такой формулировке, и с удовольствием поменяю её на другое число, если более опытные товарищи могут дать разумную, обоснованную рекомендацию. Подход по этой ссылке вы считаете разумным?
https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/configure-the-max-degree-of-parallelism-server-configuration-option?view=sql-server-ver17

С той частью, где говорится про 8, согласен, но 6 железно без проблем. 16 - нет, конечно, уже железно будут блокироваться.

Спасибо, исправил.

А есть ли рекомендации по включению QUERY_OPTIMIZER_HOTFIXES на уровне баз?

В ИТС довольно расплывчатое описание с намёком на установку T4199 или права sysadmin для подключения к СУБД. У @Maxpiter в статьях этот момент тоже опущен с общей рекомендацией ставить саму новую версию сервера.

Вот что пишет Дмитрий Короткевич:

флаг Т4199 и параметр базы данных QUERY_OPTIMIZER_HOTFIXES

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

То есть включение этой настройки нельзя отнести к универсальному совету, положительно влияющему производительность.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации