SOS_SCHEDULER_YIELD шип в группе доступности

Question

Я собираюсь сойти с ума по этому вопросу.

У нас есть группа доступности из 3 серверов, из которой наши приложения читают со всех 3 серверов. Отлично работает 99,9% времени. Время от времени мы получаем всплеск SOS_SCHEDULER_YIELD. Когда это происходит, многие наши запросы перестают работать. Обычно не длится дольше минуты. У нас есть задача, которая фиксирует статистику ожидания каждые 2 минуты (изображение ниже).

8a - основной сервер в группе доступности. Как видите, SOS_SCHEDULER_YIELD резко возрастает с 122 000 в 10:40 до 4 000 000 в 10:42 и обратно до 85 000 в 10:44. Другие серверы достигли 2 000 000.

Эти серверы все виртуальные. 8a и 8c находятся на одном хосте, а 8b - в другом локальном центре данных. Серверы используют SAN в центре обработки данных, в котором они находятся, поэтому 8a и 8c используют одну и ту же SAN.

В то время работы не было. Администратор сервера не видел никаких проблем на самих серверах. Хост для загрузки процессора 8b вырос с 43% в 10:40 до 70% в 1045, а хост для остальных 2 - с 42% до 62% одновременно. Оба упали вниз на отметке 10:50.

Мне нужны идеи о том, что может вызвать этот тип поведения и / или идеи о том, как устранить неполадки. Я понимаю, что SOS_SCHEDULER_YIELD может быть индикатором, а не самой проблемой. Я просто знаю, что когда я начинаю получать тайм-ауты на этих серверах, SOS_SCHEDULER_YIELD пики и пики высокие. Заранее спасибо за идеи.

Answer 1

Я бы предложил вам прочитать эту статью Пола Рэндала. Это объясняет SOS_SCHEDULER_YIELD тип ожидания. Что является причиной SOS_SCHEDULER_YIELD показывать? Прочитайте это здесь.

Примерно во время 1042 утра попробуйте выполнить запрос ниже. Оттуда проверьте запрос и план запроса и проанализируйте его оттуда.

    SELECT
    [er].[session_id],
    [es].[program_name],
    [est].text,
    [er].[database_id],
    [eqp].[query_plan],
    [er].[cpu_time]
FROM sys.dm_exec_requests [er]
INNER JOIN sys.dm_exec_sessions [es] ON
    [es].[session_id] = [er].[session_id]
OUTER APPLY sys.dm_exec_sql_text ([er].[sql_handle]) [est]
OUTER APPLY sys.dm_exec_query_plan ([er].[plan_handle]) [eqp]
WHERE
    [es].[is_user_process] = 1
    AND [er].[last_Wait_type] = N'SOS_SCHEDULER_YIELD'
ORDER BY
    [er].[session_id];
GO

Answer 2

Мы испытали то же самое сегодня, и это было связано с проблемой виртуализации. У нас была еще одна виртуальная машина на том же физическом хосте, которая загрузила ЦП до 100% и из-за чрезмерной фиксации и отсутствия резервирования забрала с собой виртуальную машину базы данных. Я думаю, что это почти невозможно отследить из базы данных / виртуальной машины базы данных. Ожидания SOS_SCHEDULER_YIELD на самом деле представляли собой ожидание всей виртуальной машины по сравнению с циклами ЦП.