Однажды мы с Полом обсуждали ожидания SOS_SCHEDULER_YIELD и пытались разобраться, могут ли показатели этих ожиданий в SQL Server искажаться из-за проблем с планированием выполнения виртуальной машины гипервизором.
Я провёл первые эксперименты в своей лаборатории виртуальных машин, используя как Hyper-V, так и VMware. В результате удалось воспроизвести именно ту ситуацию, о которой говорил Пол и которую он описал в своей статье.
Недавно я занимался воспроизведением другой проблемы, также связанной с планированием выполнения виртуальных машин. Она тоже проявляется в SQL Server и приводит к ошибочным выводам из-за чрезмерной нагрузки на гипервизор. Но на этот раз перегружена была не виртуальная машина с SQL Server, а серверы приложений.
Пока я готовил в лаборатории условия для воспроизведения этой ситуации, решил выделить время и повторить эксперименты с SOS_SCHEDULER_YIELD. Заодно захотелось подготовить статью, в которой можно было бы подробно показать полученные результаты.
Для экспериментов я использовал переносную лабораторную среду, которую на протяжении последних восьми лет применяю для демонстрации работы виртуальных машин на наших учебных мероприятиях Immersion Events.
На физическом сервере ESX установлены четыре процессорных ядра и 8 ГБ оперативной памяти. На нём работают три виртуальные машины: сервер SQL Server с четырьмя виртуальными процессорами (vCPU) и 4 ГБ оперативной памяти, а также две виртуальные машины Windows Server, каждая с двумя vCPU и 2 ГБ оперативной памяти. Последние используются исключительно для запуска Geekbench, создающего нагрузку на процессор.
Внутри SQL Server я использовал воспроизводимую рабочую нагрузку, которая активно задействует параллельное выполнение. Она стабильно воспроизводит одинаковые условия и уже много лет применяется мной на учебных занятиях.
Сначала я провёл контрольный эксперимент. В этот момент единственной виртуальной машиной, выполнявшей какие-либо задачи или рабочую нагрузку, была машина с SQL Server. Две остальные виртуальные машины были включены, но просто бездействовали на хосте.
Этот эксперимент позволил получить исходные показатели производительности физического хоста. Во время выполнения рабочей нагрузки среднее время готовности процессора (CPU Ready) составляло 1%. После завершения нагрузки я собрал статистику ожиданий SOS_SCHEDULER_YIELD.
Затем я повторил эксперимент, но на одной из виртуальных машин серверов приложений запустил сразу четыре экземпляра Geekbench. Это позволило создать высокую нагрузку на процессор этой виртуальной машины и заставить её постоянно ожидать предоставления процессорного времени гипервизором.
После этого я снова запустил рабочую нагрузку SQL Server.
Во время эксперимента время готовности процессора виртуальной машины с SQL Server достигло 5% по данным гипервизора. Это нижняя граница, начиная с которой, на мой взгляд, уже можно ожидать появления проблем с производительностью.
После завершения рабочей нагрузки я повторно собрал статистику ожиданий.
Затем я повторил эксперимент ещё раз, но теперь четыре экземпляра Geekbench работали на каждой из двух виртуальных машин серверов приложений.
Среднее время готовности процессора виртуальной машины с SQL Server составило 28%. После завершения рабочей нагрузки я в последний раз собрал статистику ожиданий.
Как видно из приведённых ниже результатов, с увеличением показателя RDY% непосредственно возрастает и количество ожиданий.
| Экспери-мент | Среднее RDY% | Тип ожидания | Количество ожидающих задач | Время ожидания, мс | Макси-мальное время ожидания, мс | Время сигнального ожидания, мс | Продол-жительность |
|---|---|---|---|---|---|---|---|
| 2 ВМ приложений | 28,4 | SOS_SCHEDULER_YIELD | 10455 | 22893 | 124 | 22803 | 3:59 |
| 1 ВМ приложений | 5,1 | SOS_SCHEDULER_YIELD | 2514 | 3618 | 62 | 3608 | 1:57 |
| Контрольный эксперимент | 1,2 | SOS_SCHEDULER_YIELD | 1392 | 974 | 12 | 963 | 1:32 |
Высокое значение времени готовности процессора (CPU Ready) необходимо постоянно контролировать на виртуальных машинах с SQL Server, если от них требуется быстрое реагирование на запросы. То же самое относится и к виртуальным машинам серверов приложений, для которых время отклика также имеет большое значение.
Есть ещё один важный момент, который следует учитывать при анализе любых типов ожиданий на виртуализированном сервере SQL Server, а не только SOS_SCHEDULER_YIELD.
Время ожидания, зарегистрированное SQL Server, будет включать также промежуток, в течение которого виртуальная машина была вынуждена ждать, пока гипервизор предоставит ей возможность выполнения.
Однако у ожидания SOS_SCHEDULER_YIELD есть особенность: из-за сдвигов во времени, возникающих при задержках выполнения виртуальной машины, увеличивается не только продолжительность ожиданий, но и само количество их возникновений.
Это происходит потому, что внутри SQLOS поток может ошибочно исчерпать свой процессорный квант по результатам расчёта времени, уступить процессор и тем самым зарегистрировать ожидание SOS_SCHEDULER_YIELD, даже если из-за задержки со стороны гипервизора он фактически не успел продвинуться в выполнении своей работы.
Комментариев нет:
Отправить комментарий