HADR высокий уровень использования рабочих потоков

Почему число рабочих потоков в группе доступности в пуле HADR значительно превысит минимальное использование « обычно существует 3–10 общих потоков » на реплику?

В одном случае мы наблюдали использование более 300 потоков с 3 группами доступности и 10 базами данных. SQL Server 2014 SP1.

Нашими руководителями являются резервные копии на вторичной реплике, высокая активность на первичной реплике, отчеты о вторичной реплике.

AG находятся в центре обработки данных на VMware. Всего 16 планировщиков, обычные рабочие потоки в диапазоне до 200. max_dop на сервере равно 2.

3 AG, 10 дБ, 4 реплики каждая - основная, 2 только для чтения, 1 не для чтения.
1 вторичная синхронизация, 2 асинхронная
16 виртуальных ядер на 32 физических ядра в большом кластере с несколькими узлами.
Нет чрезмерного обеспечения.
Другие меньшие виртуальные машины 4-8 ядер расположены совместно, но они не нагружают процессор

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

Ниже ссылки из блога SQL Server Premier Field Engineer, прочитанные в контексте, не дают мне полного ответа:

— Александр Тарасул
источник

Можете ли вы опубликовать скриншот примеры того, что вы видите? Здесь что-то не так, как будто вы запрашиваете рабочие потоки в целом, а не конкретно AG. (И другие рабочие потоки тоже могут выходить за пределы, не только AG).

— Брент Озар

Я охотюсь на похожую проблему. Уверен, я прибил его к вопросу MaxDop. Я использую сценарии Ola Hallengreens для IndexMaintenance, и для параметра MaxDOP было установлено значение NULL. Суть в том, могли бы вы получать запросы, которые перекрывают ваш MaxDOP 2?

— Каспер Бранденбург

Вы получили какое-нибудь решение для этого?

— Труша

-1

Поскольку ваш DC находится на ВМ, я подозреваю, что у вас низкая производительность диска. Низкая производительность диска может привести к более медленному времени записи журнала на вторичном устройстве, что может привести к более медленному подтверждению возврата к первичной реплике от вторичной реплики (истощающие рабочие потоки).

Задержка диска на вторичной реплике может привести к увеличению процесса фиксации синхронизации HADR, в результате чего основной поток удерживает открытые потоки, ожидая, пока вторичный сервер подтвердит транзакцию.

Пожалуйста, проверьте журнал ошибок для Deadlocked Schedulers и соберите некоторые показатели IO от PerfMon, чтобы увидеть задержку диска и длину очереди диска.

— Родриго Насчентес
источник