Записки оптимизатора 1С (часть 4). Параллелизм в 1С, настройки, ожидания CXPACKET / Comments / Habr

Сам по себе CXPACKET не является проблемой. По факту это практически только индикатор параллельного выполнения: при параллельном плане почти всегда будет часть веток, которые выполнились быстрее, часть - медленно, поэтому SQL Server часть времени проведёт в CXPACKET. Хорошее объяснение есть тут. Бороться с CXPACKET как таковым обычно не нужно.
С параллельными планами запросов проблемы другие

В распараллеливание отдаётся план до прохождения всех оптимизаций. Чаще всего это очень неэффективный план. И получаются весы: с одной стороны n ядер, но план с с лишними сканами и неэффективными соединениями, с другой - лишние m миллисекунд на оптимизацию и может быть план с нормальными поисками и соединениями.
Очень низкая граница на распараллеливание. 5 "попугаев" - это "как бы 5 секунд на компьютере 2000 года", причём планировщик запросов редко попадает точно в кост, чем бы он ни был. Для 1С я эмпирически пришёл к тому, что Cost Threshold for Parallelism стоит ставить от 100 до 5000 примерно. Так жирные отчеты пойдут параллелиться, а в проведении SQL будет лучше оптимизировать.
(И это упомянуто в статье) По умолчанию параллелизм съедает все ядра. Ну так MS уже лет 10 (как появились сервера с 64 потоками) советует для многоядерных CPU ставить макс. параллельность 8, если нет особых обстоятельств. Ну от себя могу добавить, что какие-то операции, явно сканирующие большие талицы, можно вручную указывать OPTION MAXDOP по максимуму. В том числе, например, построение статистики и перестроение индексов.