Використання ниток HADR на високому рівні

Чому кількість робочих ниток групи доступності в пулі HADR збільшиться набагато вище мінімального використання " зазвичай є 3–10 спільних потоків " на копію?

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

Наші потенційні результати - резервне копіювання вторинної репліки, висока активність у первинній репліці, звіти про вторинну репліку.

АГ знаходяться в центрі обробки даних на VMware. Всього 16 планувальників, звичайні робочі потоки знаходяться під діапазоном 200. max_dop на сервері 2.

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

Ми спостерігали сплеск робочих ниток, що призводить до відмови в обслуговуванні. Віднесення робочих ниток до АГ - наше припущення, оскільки лише ті робочі потоки можуть перетнути межу.

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

— Олександр Тарасул
джерело

Чи можете ви розмістити приклади скріншоту того, що ви бачите? Щось тут здається, на зразок ви запитуєте робочі нитки взагалі, а не AG. (І інші робочі потоки теж можуть переступити межу, не лише АГ.)

— Брент Озар

Я полюю на подібне питання. Досить впевнений, що я прибив це до проблеми MaxDop. Я використовую сценарії Ola Hallengreens для IndexMainnance, а для параметра MaxDOP встановлено значення NULL. Справа в тому, чи не могли б у вас з’являтися запити, які переосмислюють ваш MaxDOP 2?

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

Ви отримали для цього якесь рішення?

— труша

-1

Оскільки ваш постійний струм знаходиться на VM, я підозрюю, що ви відчуваєте погану продуктивність диска. Погана продуктивність диска може призвести до уповільнення часу запису журналу на вторинному, що може спричинити повільне підтвердження повернення до первинної репліки із вторинної репліки (виснажливі робочі потоки).

Затримка диска у вторинній репліку може призвести до збільшення процесу HADR синхронізації фіксації, що призводить до того, що Первинне тримає відкриті потоки під час очікування, щоб Вторинний підтвердив транзакцію.

Будь ласка, перевірте журнал помилок для Deadlocked Schedulers та зіберіть деякі показники IO від PerfMon, щоб побачити затримку диска та довжину черги диска.

— Родріго Насцентес
джерело