
Комментарии 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 дисков?
Установите 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
Самое короткое руководство по базовой настройке производительности Microsoft SQL Server