MAXDOP и порог стоимости параллелизма

Значения по умолчанию редко отражают осознанный дизайн нагрузки. Избыточный параллелизм усиливает давление на CPU и workers, а чрезмерное ограничение замедляет аналитику.

Что измерять

Оценивайте CPU, runnable tasks, нехватку workers, длительность, частоту параллельных планов, exchange waits, NUMA и соотношение коротких OLTP-запросов и отчетов.

Практический подход

Выберите начальный MAXDOP по топологии и нагрузке, постепенно повышайте cost threshold, измеряйте tail latency и throughput и применяйте исключения только при доказанной необходимости.

Чего следует избегать

Не считайте CXPACKET доказательством проблемы, не ставьте MAXDOP 1 глобально и не меняйте обе настройки без baseline.

Эксплуатационный результат

Настройка успешна, когда одновременно улучшаются throughput и tail latency, а не просто исчезает одно ожидание.

Проверка перед production

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

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