​​Некоторые вопросы производительности виртуальных машин и все такое прочее

В комментариях в очередной раз возникла дискуссия по поводу сравнительной производительности различных сред виртуализации. Хотя уже и не раз и не два твердили миру, что накладные расходы на виртуализацию в современных системах малы и ими можно пренебречь.

Но не все так просто, особенно когда начинают тестировать разные гипервизоры в «одинаковых» условиях.

Кстати, лицензионное соглашение VMware прямо запрещает такие исследования проводить и публиковать их результаты. Наверное, они что-то скрывают? Вовсе нет. Сегодня мы расскажем одну поучительную историю.

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

Чтобы не замусоривать свой домашний компьютер он нашел в закромах свободный диск на 2 ТБ и поставил на него виртуалку на Windows 10 при помощи бесплатной ныне VMware Workstation.

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

Т.е. если сильно не грузить диск, то он подтормаживал, но в целом работал. Но если задач ему накинуть – то уходил в 100% загрузку, при этом скорости обмена с диском были в это время очень скромные – несколько МБ/с.

Диск он поставил не самый плохой, но и не самый производительный - ST2000DM008 – черепица. Скажем сразу, диск очень даже неплохой и работает отлично, если не перегружать мелкоблочкой.

Но черепица – это для многих жупел, поэтому диск он поменял на WD20EARZ с классической технологией записи. Помогло? Нет.

Оба диска были проверены на бед-блоки, прогнаны через все возможные тесты, как синтетические, так и ручные – но никаких проблем выявлено не было.

В общем, коллега выбрал «помощь друга». А мы на эти грабли тоже наступали и тоже не могли сначала понять в чем дело.

Оказалось, что при создании виртуальной машины он выставил тип виртуального жесткого диска – NVMe.

Ну так он же виртуальный, мало ли чего он там выставил… А вот и нет. Вспомним про такую штуку как очереди. У классических ATA-дисков очередь одна, без всяких оптимизаций. Как команды послали – так диск их и выполнял, даже если это было не оптимально.

У SCSI и SATA появилась «умная очередь» с глубиной в 256 и 32 команды, это значило, что диск анализировал команды на указанную глубину и оптимизировал их выполнение, объединяя те, которые обращались с соседним областям диска.

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

SSD отчасти сняли эту проблему и часто система увидев в качестве носителя SSD начинает более агрессивно использовать случайные дисковые операции, т.к. они не являются для твердотельных дисков узким местом.

NVMе вообще принесло революционные изменения - 65536 очередей с глубиной 65536 команд каждая.

И вот мы говорим системе, что у нас под капотом NVMe, а сами ставим туда обычный жесткий диск, тем более черепицу.

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

Но даже поменяв черепицу на классику легче не станет. Это все равно, что попытаться без задержек трафик МКАД направить на проселочную грунтовую дорогу.

А помогло пересоздание виртуальной машины с указанием типа виртуального диска адекватно используемому железу, после чего даже черепичный Seagate стал работать полностью адекватно и без тормозов.

А всего-то какая-то одна настройка, а сколько таких настроек еще может быть?