Обновить

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

Уровень сложностиПростой
Время на прочтение4 мин
Охват и читатели4.4K
Всего голосов 3: ↑2 и ↓1+2
Комментарии15

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

Если на журнал транзакций не действует 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 - нет, конечно, уже железно будут блокироваться.

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

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

Публикации