Увеличение количества ожиданий SOS_SCHEDULER_YIELD на виртуальных машинах

Автор: Paul Randal, Increased SOS_SCHEDULER_YIELD waits on virtual machines

Во время обучения работе со статистикой ожиданий, меня спросили, существуют ли какие-либо ожидаемые различия в этой статистике при работе SQL Server внутри виртуальной машины.

Я ответил утвердительно: время ожиданий может оказаться больше, если что-то мешает виртуальной машине выполнять работу. Дело в том, что продолжительность ожидания определяется разницей значений счётчика __rdtsc (по сути, счётчика тактов процессора) в момент начала и окончания ожидания.

В VMware или Hyper-V возможна следующая ситуация. Поток внутри SQLOS ожидает освобождения какого-либо ресурса, а в это время виртуальная машина сама вынуждена ждать разрешения гипервизора на выполнение. Такое происходит, когда физические процессоры хоста перегружены виртуальными процессорами (vCPU), назначенными виртуальным машинам.

В результате фактическое время ожидания ресурса, зарегистрированное SQL Server, включает и тот промежуток, в течение которого виртуальная машина вообще не могла выполнять инструкции. Поэтому продолжительность ожидания в статистике оказывается больше, чем была бы в случае, если бы виртуальная машина не испытывала таких задержек.

Это интересный вопрос: действительно ли подобная ситуация представляет проблему? На мой взгляд, она может привести к тому, что кто-нибудь начнёт искать причину снижения производительности SQL Server, хотя на самом деле проблема связана с производительностью виртуальной машины.

Обратите внимание: речь не идёт о неисправности или недостатках самого гипервизора. Причина заключается в неправильной настройке виртуальной среды.

После занятия я задумался о планировании потоков в виртуальной машине, выполнение которой периодически задерживается, и о том, могут ли такие задержки вызывать какие-либо другие интересные эффекты, связанные со статистикой ожиданий.

В частности, меня заинтересовали ожидания SOS_SCHEDULER_YIELD.

Это особый тип ожидания, возникающий в ситуации, когда поток способен использовать процессор в течение 4 мс, не приостанавливаясь для ожидания недоступного ресурса. Этот промежуток времени называется квантом времени потока (thread quantum).

Если говорить проще, поток должен через определённые промежутки времени обращаться к уровню SQLOS, чтобы проверить, не исчерпан ли отведённый ему квант времени. Если квант исчерпан, поток обязан добровольно уступить процессор другому потоку.

В этот момент происходит переключение контекста, поэтому необходимо зарегистрировать соответствующий тип ожидания — SOS_SCHEDULER_YIELD.

Более подробное объяснение этого типа ожидания приведено в моей библиотеке ожиданий здесь.

Моё предположение заключалось в следующем: если виртуальная машина не может выполнять работу в течение нескольких миллисекунд или дольше, работающий в ней поток может исчерпать свой квант времени, фактически не получив при этом 4 мс процессорного времени. В результате поток уступит процессор, и будет зарегистрировано ожидание SOS_SCHEDULER_YIELD.

Если такое происходит часто, статистика ожиданий виртуализированной системы может показать большое количество ожиданий SOS_SCHEDULER_YIELD. При этом создаётся впечатление, что проблема связана с работой SQL Server, хотя на самом деле причина заключается в производительности виртуальной машины, а сами ожидания SOS_SCHEDULER_YIELD оказываются, по сути, «ложными».

Я обсудил эту гипотезу со своим хорошим другом Бобом Уордом (Bob Ward) из подразделения SQL Product Group. После внутреннего обсуждения специалисты подтвердили, что такой сценарий действительно возможен.

Причина в том, что момент исчерпания кванта времени потока вычисляется с помощью встроенной инструкции __rdtsc в момент начала его выполнения. Поэтому любая задержка, препятствующая работе виртуальной машины, может привести к описанному мной эффекту.

Поскольку я сам не слишком хорошо знаком с устройством виртуальных машин, я попросил Джонатана провести несколько экспериментов в нашей лабораторной среде VMware и проверить, удастся ли воспроизвести эту проблему.

Он использовал известную нам рабочую нагрузку, которую мы применяем на учебных мероприятиях Immersion Events для демонстрации влияния чрезмерной нагрузки на физический хост. Такая нагрузка приводит к задержкам выполнения виртуальной машины.

И, к нашему удивлению, результаты подтвердили предположение: при выполнении этой рабочей нагрузки количество ожиданий SOS_SCHEDULER_YIELD оказалось значительно выше — примерно в 20 раз по сравнению с запуском той же нагрузки на той же виртуальной машине, но без задержек выполнения.

Мы повторили те же эксперименты в нашей лабораторной среде Hyper-V, которая по аппаратной конфигурации и настройкам виртуальных машин полностью соответствовала среде VMware.

Результаты оказались аналогичными: количество ожиданий SOS_SCHEDULER_YIELD также существенно возросло.

Таким образом, проблема совершенно не связана с каким-либо конкретным гипервизором или платформой виртуализации. Её причина исключительно в чрезмерной загрузке физического хоста выполняемыми задачами и в том, что виртуальная машина с SQL Server вынуждена ждать освобождения процессорных ресурсов, прежде чем продолжить работу.

Я намеренно не привожу здесь результаты экспериментов Джонатана. У меня недостаточно опыта, чтобы правильно объяснить показатели VMware esxtop или значения счётчиков производительности Hyper-V и показать, как они соотносятся с количеством ожиданий SOS_SCHEDULER_YIELD.

Джонатан подготовит отдельную статью в течение одной-двух следующих недель, в которой объяснит полученные результаты с точки зрения виртуализации.

Тем не менее с помощью достаточно простых экспериментов нам удалось доказать следующее: если выполнение виртуальной машины задерживается, рабочая нагрузка SQL Server может демонстрировать значительно большее количество ожиданий SOS_SCHEDULER_YIELD. Причина заключается в использовании встроенной инструкции __rdtsc для определения момента исчерпания кванта времени потока.

Это действительно интересный результат, поскольку в данном случае проблема производительности виртуальной машины не просто увеличивает продолжительность существующих ожиданий, а сама становится причиной появления определённого типа ожидания.

Поэтому обязательно учитывайте это явление, если вы расследуете ситуацию с большим количеством ожиданий SOS_SCHEDULER_YIELD, сталкиваетесь со снижением производительности рабочей нагрузки и при этом SQL Server работает внутри виртуальной машины.

О том, как сопоставить эти ожидания с признаками проблем производительности виртуальной машины, Джонатан рассказывает в своей статье о влиянии CPU Ready на SOS_SCHEDULER_YIELD.

Надеюсь, эта информация окажется полезной!