Как мы настроили планировщик, чтобы разогнать виртуальные серверы

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

В чем проблема

Мы занимаемся облачными решениями для 1С. Клиенты, которые работают в клиент-серверном режиме, иногда начали замечать торможение программ на Windows Server. Хотя проверка нагрузки на сеть, хранилище, оперативную память, ЦПУ и прочее, говорит, что все должно быть в пределах нормы.

Решили поработать с виртуальными серверами и попытаться аппаратными средствами снизить потери производительности.

Где нашли решение

Начали копать, и после серии тестов добрались до платформы Microsoft Hyper-V, которая используется для создания виртуальных серверов. У нее есть собственный шедулер, который может работать в трех разных режимах: classic, core и root. Каждый из которых по-разному использует ресурсы аппаратного хоста.

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

The classic scheduler — наиболее сбалансированный режим, хорошо адаптированный под большое количество виртуальных серверов и их одновременный запуск. Вплоть до Windows Server 2016 Hyper-V этот режим был установлен по умолчанию.

The core scheduler — использует метод одновременной многопоточности (SMT). Планировщик ориентирован на создание границы безопасности для изоляции на уровне выделенного ядра процессора гостевой рабочей нагрузки и поддержание стабильной пропускной способности. А вот производительность у этого режима не в приоритете, так что может приноситься в жертву безопасности и стабильности. Начиная с Windows Server 2019 Hyper-V, этот режим стал использоваться по умолчанию.

The root scheduler — больше нацелен на управления логическими процессами (LP) и отдает все заботы по планированию работы разделу root. Режим подходит для клиентских систем, но на серверах его не рекомендует использовать и сам MS.

За подробностями о разнице между режимами отсылаю на официальную страницу MS ^[1].

Что показали тесты

На одном из аппаратных узлов решили протестировать смену режима. Сам узел был пустой. По умолчанию стоял режим core scheduler, мы его сменили на classic scheduler. Собрали метрики и заметили значительные изменения.

Результаты тестов по Гилеву в рамках «Хорошо», хоть и ближе к границе «Удовлетворительно». Вроде жить можно, но учтем, что тест запускается на пустой платформе и не отражает реального быстродействия при загруженных базах 1С. Так что надо быть готовым к задержкам отклика программ.

Потом сменили режим на classic scheduler и провели повторные замеры.

Вроде тоже в рамках «Хорошо», но теперь уже почти на верхней границе, ближе к замечательно. И прирост производительности более 50%.

Сами удивились такой большой разнице и постепенно стали приводить к настройкам classic scheduler все наши аппаратные машины.

Выводы

Проблем с большой потерей производительности не было, так как в более ранних версиях Microsoft Hyper-V по умолчанию использовался режим classic scheduler, и необходимости лезть в настройки не было. Но начиная с версии 2019 по умолчанию стоит core scheduler и это кардинально изменило распределение ресурсов машины. В критические моменты виртуальные серверы теперь могли подтормаживать, что, конечно, не нравится клиентам.

Мы не вмешивались всерьез в работу серверов, не изменяли глобальные параметры. Простая смена одного режима работы на другой, позволила Microsoft Hyper-V по-другому использовать ресурсы процессора, и производительность выросла.