Удерживать на удержании
Хоча аспекти продуктивності та ліцензування цікаві, вони не є єдиним аспектом навантаження.
Одне, що може вплинути на вибір процесора - це робочі потоки.
Робочі нитки?
Да приятель! Це те, що ваш SQL Server буде використовувати для запуску ваших запитів і виконувати всі фонові речі, які йому потрібно зробити, щоб підтримувати речі у формі.
Коли у вас закінчуються робочі нитки, ви натискаєте THREADPOOL чекає
РІЗНИК?
РІЗНИК. Це одне з найгучніших очікувань, які ви можете мати на своєму сервері, а також RESOURCE_SEMAPHORE та RESOURCE_SEMAPHORE_QUERY_COMPILE . Але це очікування пам'яті, і це питання процесора.
Тож повернемось до того, чому це віггітське пробудження.
Ось як SQL Server обчислює робочі потоки :
Зверніть увагу, як подвоєне число ядер не подвоюється Макс робочих ниток, і ви отримуєте те саме число з 1 ядром, як у 4 ядер? Рівняння:512 + ((logical CPUs - 4) * 16)
Це прикро, тому що, коли число ядер збільшується, тактова частота, як правило, носить покоління чи два назад.
Огляд будь-якої недавньої лінійки мікросхем Intel покаже подібну тенденцію.
Як дізнатися, скільки ниток мені потрібно?
Від цього багато що залежатиме:
- Кількість користувачів
- Кількість паралельних запитів
- Кількість послідовних запитів
- Кількість баз даних та синхронізації даних (Mirroring, AG, резервні копії для доставки журналу)
- Якщо ви залишите MAXDOP та CTFP за замовчуванням
Якщо сьогодні у вас не вичерпається, ви, мабуть, добре.
Але як дізнатися, чи є ти?
Є хороші запитання, і є великі запитання, і лемме вам щось скаже, це ВЕЛИКИЙ ПИТАННЯ .
THREADPOOL може проявлятись як проблеми з підключенням , і ви можете побачити повідомлення в журналі помилок про неможливість нерестування потоку .
Ви також можете переглянути статистику очікування вашого сервера, використовуючи безкоштовний інструмент, наприклад sp_Blitz або sp_BlitzFirst (повне розкриття інформації, я сприяю цьому проекту).
EXEC sp_Blitz
EXEC sp_BlitzFirst @SinceStartup = 1
Не можу я просто збільшити Макс робочих ниток?
Збільшення МВТ може призвести до збільшення SOS_SCHEDULER_YIELDочікування.
Це ще не кінець світу, але думайте про це, як додати бунчу, що кричить дітям, до класу вчителя.
Раптом кожному малюкові буде важче привернути увагу.
Коли процес вичерпує свій квант 4 мс , потенційно перед ним буде більше потоків, які чекають, щоб увійти в процесор.
Виступ може відчувати приблизно те саме.
Як я можу використовувати менше робочих ниток?
Ви жорстокий [іменник] [іменник], це робітники з сім’ями для підтримки! Іпотечні! Мрії!
Але добре, треба дотримуватися нижнього рядка. Ти начальник.
Найпростішим місцем для початку є зміна параметрів, таких як MAXDOP та Порогова вартість для паралельності з параметри за умовчанням.
Якщо у вас є питання, як їх встановити, перейдіть сюди:
Після цього ваша робота стає набагато жорсткішою. Ви повинні зрозуміти, що використовує всі ці теми. Іноді це можна зробити, переглянувши статистику очікування.
Більш конкретно, якщо у вас велика чека на паралелізм ( CXPACKET) І велике очікування на блокування ( LCK_), ви, можливо, зіткнетеся з довгими блокуючими ланцюжками, що включають паралельні запити.
Ви знаєте, що смердить? Хоча всі ці паралельні запити чекають, щоб отримати свої блокування, вони не повертають виділені нитки назад.
Ви майже можете почути, що чотири основні VM, які ваш адміністратор запевнив, вам більше ніж достатньо для будь-якого робочого навантаження, задихаючись повітря, так?
На жаль, тип налаштування запитів та індексів, які ви повинні виконати, щоб вирішити ці речі, виходить за межі питання.
Сподіваюся, це допомагає!