Хто використовує мої робочі теми? SQL Server 2014 - HADR


10

Нещодавно у нас виникло завдання в середовищі HADR SQL Server 2014, де на одному з серверів не було робочих потоків.

Ми отримали повідомлення:

Пул потоків для груп AlwaysOn Availability не вдалося запустити новий робочий потік, оскільки недостатньо доступних робочих потоків.

Повідомлення про помилку під час його запуску

Я вже відкрив ще одне запитання, щоб отримати твердження, яке (я думав) повинно допомогти мені проаналізувати проблему ( чи можливо побачити, який SPID використовує який планувальник (робочий потік)? ). Хоча зараз у мене є запит на пошук потоків, які використовують систему, я не розумію, чому на цьому сервері не вистачало робочих потоків.

Наше оточення таке:

  • 4 Windows Server 2012 R2
  • SQL Server 2014 Enterprise
  • 24 Процесори -> 832 Робочі нитки
  • 256 ГБ оперативної пам’яті
  • 12 груп доступності (загалом)
  • 642 Бази даних (загалом)

Отже, сервер, який мав проблему, мав таку конфігурацію:

  • 5 груп доступності (3 основні / 2 вторинні)
  • 325 баз даних (127 первинних / 198 вторинних)
  • MAXDOP = 8
  • Cost Threshold for Parallelism = 50
  • План електроживлення встановлено на "Висока продуктивність"

Щоб "вирішити" проблему, ми вручну не змогли перенести одну групу доступності на вторинний сервер. Конфігурація цього сервера зараз:

  • 5 груп доступності (2 основні / 3 вторинні)
  • 325 баз даних (77 первинних / 248 вторинних)

Я контролюю доступні теми з цим твердженням:

declare @max int
select @max = max_workers_count from sys.dm_os_sys_info

select 
    @max as 'TotalThreads',
    sum(active_Workers_count) as 'CurrentThreads',
    @max - sum(active_Workers_count) as 'AvailableThreads',
    sum(runnable_tasks_count) as 'WorkersWaitingForCpu',
    sum(work_queue_count) as 'RequestWaitingForThreads' ,
    sum(current_workers_count) as 'AssociatedWorkers'
from  
    sys.dm_os_Schedulers where status='VISIBLE ONLINE'

Зазвичай на сервері є близько 250 - 430 робочих ниток, але коли випуск розпочався, працівників не залишилось.

-119 доступних ниток

Сьогодні, з нізвідки, наявні робітники знизилися з 327 до 50, але лише на хвилину і повернулися назад до близько 400.

Я вже бачив інше питання (використання HADR з високою робочою ниткою ), але воно мені не допомагає.

Наша система працювала стабільно протягом року без проблем. У нас не було жодних відмов та інших істотних змін у розподілі баз даних.

Ми використовуємо "Синхронний фіксатор" між репліками. Наскільки я розумію, компресія не задіяна, див. Налаштування стиснення для групи доступності в документації.

Хтось має уявлення, для чого використовують усі робочі нитки?

EDIT: Знайдено цю сторінку, де є багато інформації про саме ці проблеми http://www.techdevops.com/Article.aspx?CID=24

Відповіді:


1

Відповідь вікі спільноти :

У вас є велика кількість баз даних у групах доступності, саме там збираються ваші потоки. У стисканні, шифруванні та транспортній вартості багато залучено. Спробуйте вимкнути стиснення, це зменшить використання потоку приблизно на третину (залежно від кількості реплік).

Питання позначено тегом SQL Server 2014, який за замовчуванням використовує стиснення. За замовчуванням SQL Server 2016 не буде використовувати компресію для синхронізації.

Можливо, вам потрібно буде збільшити робочі потоки на екземплярі, а ще краще: збалансувати найактивніші та неактивні на декількох серверах. Дивіться відповідні запитання групи Q & A AlwaysON доступності дуже повільно .

Ви також можете виявити, що це програма, яка не може правильно закрити запити. Це може призвести до безлічі сеансів сну, що лежать навколо (що споживає працівників).

Кількість фактично використаних потоків залежить від активності баз даних. Ви можете мати 1000 баз даних, і якщо більшість непрацюючих 95% часу, у вас не виникне жодних проблем. Здається, ваші бази даних активізуються частіше і з'їли більше ваших потоків. Ось це довге і коротке.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.