Як час очікування може бути більшим за годинний?

15

Коли я відстежую очікування з sp_BlitzFirst, я отримую цю деталь:

<?ClickToSeeDetails -- 
For 20 seconds over the last 5 seconds, SQL Server was waiting on this 
particular bottleneck.


 -- ?>

Чи слід це читати "протягом 20 секунд 20 разів?" Знахідку було CLR_SEMAPHORE.

— Роберт Райс
джерело

24

Ні - статистика очікування може (і частіше за все буде) загалом більше, ніж фізичний час, витрачений на сам сервер.

Уявіть ситуацію, коли 2 окремі нитки витрачають одну і ту ж секунду, чекаючи деякого ресурсу - у вас буде 2 секунди часу очікування на 1 секунду часу.

Кожен потік має своє власне очікування - повідомлення повідомляє вам, що за останні 5 секунд годинного часу відбулося 20 секунд часу очікування цього конкретного ресурсу.

Або кажучи інакше, кожне ядро може виконувати одночасно кілька запитів, і кілька ядер можуть додавати ще більше очікувань. Що означає, одиниця дійсно є потоком · секунд, а не секунд.

— Джордж.Палачіос
джерело

8

Це також може бути корисним для прикладу. Розглянемо три найпоширеніші стани працівника :

RUNNING = Наразі працівник працює або без попередження, або з попередженнями.

RUNNABLE = Працівник готовий бігти за допомогою планувальника.

SUSPENDED = Працівник наразі відсторонений, чекаючи події, щоб надіслати йому сигнал.

Працівники, які мають стан, RUNNINGможуть генерувати час очікування. Наприклад, якщо працівнику потрібно запустити код в ОС замість SQLOS, він може ввести попереднє або зовнішнє очікування. За цей час він буде працювати кодом на його пов'язаному процесорі, але він все ще генерує час очікування.

Працівники, які мають стан, RUNNABLEможуть генерувати час очікування (наскільки я знаю, що вони завжди роблять). Якщо працівникові було повідомлено, що ресурс доступний, він може накопичувати час очікування сигналу на основі останнього очікування. Якщо працівник вичерпав попередній квант 4 мс, то він може накопичити SOS_SCHEDULER_YIELDчас очікування.

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

Мій робочий стіл має чотири логічні ядра, тому максимальна кількість робітників за замовчуванням - 512 . Це майже напевно непрактично, але на цій машині я теоретично міг генерувати 512 секунди часу очікування в секунду, якби мені вдалося змусити кожного працівника, що чекає на щось одразу. Зі збільшенням кількості ядер / робітників це число може стати ще більшим.

Ви можете бачити більше однієї секунди очікування в секунду, навіть якщо ви не виконуєте жодних запитів щодо SQL Server. На моїй машині, схоже, такий запит генерує між 9-14 рядками:

SELECT [state], last_wait_type, wait_started_ms_ticks
FROM sys.dm_os_workers
WHERE [state] IN ('SUSPENDED', 'RUNNABLE')
AND task_address IS NOT NULL
AND wait_started_ms_ticks <> 0
AND wait_started_ms_ticks >= start_quantum;

Я можу зробити знімок загального часу очікування з моменту останнього перезапуску сервера та порівняти його з новим загальним після очікування десяти секунд:

DECLARE @start_wait_time_ms BIGINT;

SELECT @start_wait_time_ms = SUM(wait_time_ms)
FROM sys.dm_os_wait_stats
WHERE wait_type <> 'WAITFOR';

WAITFOR DELAY '00:00:10';

SELECT SUM(wait_time_ms) - @start_wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type <> 'WAITFOR';

Іноді математика спрацьовує. Востаннє я його запускав, дельта - 101339 мс. Іншими словами, у мене було більше 10 секунд очікування на секунду саме від системних завдань.

— Джо Оббіш
джерело