Читая книгу “Mastering Proxmox” в одном из разделов я нашел описание параметров вариантов кеширования образа виртуальной машины. Там было общее описание каждого из режимов кеширования с типовыми сценариями применения. Но не было количественных характеристик при изменении режима кеширования. Любопытство взяло верх. Я решил проверить на практике зависимость производительности дисков Proxmox от режима кеширования.
Политики кеширования диска в Proxmox
Всего в Proxmox есть пять режимов кеширования образа диска:
- default (No Cache)
- Direct Sync
- Write through
- Write back
- Write back (unsafe)
У каждого из этих режимов есть свои особенности. На форуме Proxmox есть даже соответствующее обсуждение. Ниже я приведу таблицу с кратким описанием и особенностями каждого из режимов.
| Режим кеширования | Возможная потеря данных | Описание |
| default (No Cache) | Только асинхронные записи | Хост Proxmox не использует кеширование, но для образа диска используется режим кеширования write-back. Диск ВМ получает подтверждения о записи напрямую от устройства хранения |
| Direct Sync | Нет | Хост Proxmox не использует кеширование, но для образа диска используется режим кеширования write-through. Это наиболее безопасный метод, т.к. потери данных не происходит. В тоже время это наиболее медленный режим |
| Write through | Нет | Хост Proxmox испольузет кеш для чтения, но не для записи. Хорошие показатели на чтение, но запись медленнее. Рекомендуемый режим для локальной подключенных дисков (DAS – direct attached store) |
| Write back | Только асинхронные записи | Хост Proxmox испольузет кеш как для чтения, так и для записи. Запись на диск считается подтвержденное, если она подтверждена в кеше, независимо от фактической записи на диск. Следовательно, при отключении питания возможны потери данных. |
| Write back (unsafe) | Да | Практически идентичен режиму write-back, но подтверждении о записи не используется вообще. Даже в кеше. Самый быстрый режим, но и самый ненадежный в плане отказоустойчивости. Однако, можно применять его в момент установки ОС для ускорения процесса. Только потом поменять редим кеширования. |
Описание окружения
В качестве тестового стенда я использовал сервер Proxmox, который установлен поверх физического сервера HP DL360 G8 с аппаратным RAID-контроллером HP Smart Array P420i.
Ниже приведу более дательные параметры.
Версия гипервизора: Proxmox VE 7.4.17
Версия ядра: Linux 5.15.116-1-pve
Физический сервер: HP DL360 G8.
ЦП: 2 х Intel Xeon E5-2670 v2
RAID-контроллер: HP Smart Array P420i + 1 ГБ кэш + BBU.
Логический диск: RAID5 3 x 900 GB SAS 10k собранный средствами аппаратного RAID контроллера Smart Array. Дополнительной нагрузки на этом диске нет.
Методика тестирования
Для тестирования я буду использовать виртуальную машину с Ubuntu Server 20.04, которая расположена непосредственно на сервере Proxmox. Для тестирования я подключил второй диск, отдельный от системного диска.
Тестирование я буду осуществлять утилитой ioping.
Я решил выполнить следующие тесты.
Производительность операции чтения с размеров блока 512 байт.
ioping -c 10 -s 512b /dev/sdbПроизводительность операции чтения с размеров блока 4 килотайта.
ioping -c 10 -s 4k /dev/sdbПроизводительность операции чтения с размеров блока 64 килотайта.
ioping -c 10 -s 64k /dev/sdbПроизводительность операции чтения с размеров блока 1 мегабайт.
ioping -c 10 -s 1024k /dev/sdbПроизводительность операции записи с размеров блока 512 байт.
ioping -WWW -c 10 -s 512b /dev/sdbПроизводительность операции записи с размеров блока 4 килотайта.
ioping -WWW -c 10 -s 4k /dev/sdbПроизводительность операции записи с размеров блока 64 килотайта.
ioping -WWW -c 10 -s 64k /dev/sdbПроизводительность операции записи с размеров блока 1 мегабайт.
ioping -WWW -c 10 -s 1024k /dev/sdbПроизводительность операции последовательного чтения с диска с размером блока 4 мегабайта:
ioping -L -s 4m -с 10 /dev/sdbПроизводительность операции последовательной записи на диск с размером блока 4 мегабайта:
ioping -WWW -L -s 4m -с 10 /dev/sdbДля более объективного результата каждый из тестов я буду выполнять 10 раз и высчитывать среднее значение для результата. В качестве метрик я решил использовать количество iops и скорость чтения (записи) на диск. Например:
Зависимость производительности дисков Proxmox ВМ от режима кеширования – результаты тестирования
В этом разделе я предоставлю сводные результаты тестирования, которые я получил. Стоит отметить, что эти результаты характерны именно для того окружения и нагрузки, которая была указана в методике тестирования. Вполне вероятно, что в на другом “железе” или с другим профилем нагрузки результаты могут отличаться. Прошу рассматривать полученные результаты сугубо в познавательных целях и выполнять тестирования именно под ваши рабочие нагрузки.
Случайной чтение блоками 512 байт
Результаты приведены на диаграмме ниже.
Каких-то разительных отличий в производительности для режимов кеширования зафиксировано не было. Самый быстрый режим – Write back (unsafe). Самый медленный – Write through. Но даже различия между самым быстрым и самым медленным режимом в данном случае вы вряд ли увидите невооруженным взглядом.
Случайное чтение блоками по 4 килобайта
Результаты:
Опять же самый быстрый режим оказался Write back (unsafe). Но он не ощутимо быстрее. Остальные режимы показали примерно одинаковый результат.
Случайное чтение блоками по 64 килобайта
Диаграмма с результатами:
Результаты всех режимов примерно одинаковые. Можно даже сказать, что почти в пределах погрешности измерений.
Случайное чтение блоками 1 мегабайт
Сводная диаграмма с результатами ниже.
Это первый тест, где уже есть разительные отличия. Самый быстрый режим опять же Write back (unsafe). Он быстрее примерно на 15%, чем самый медленный режим Write back. Режим default (No Cache) примерно идентичен самому быстрому режиму (Wrote back (unsafe)) по количеству iops, но опять же, примерно на 15% медленнее по скорости чтения с диска.
Случайная запись блоками по 512 байт
Теперь переходим к операциям записи. Результаты:
Режим default (No Cache) чуть-чуть быстрее всех остальных, но не более чем на 10% в среднем.
Случайная запись блоками по 4 килобайта
Привожу результаты моего тестирования.
По скорости чтения все режимы примерно одинаковы, но по количеству iops очень выделяет в большую сторону режим Write back (unsafe). Он более чем на 25% быстрее, чем самый медленный режим по количеству iops – Write back.
Случайное чтение блоками по 64 килобайта
Результирующая диаграмма:
К моему удивлению самым быстрым режимом оказался default (No Cache), а самым медленным (к еще большему удивлению) Write back (unsafe).
Случайное чтение блоками по 1 мегабайту
Результаты во много повторяют результаты прошлого теста:
Самые быстрые режимы – Direct Sync и default (No Cache). Чуть медленнее Write back (unsafe). Остальные режиме примерно равны.
Линейное чтение блоками по 4 мегабайта
График получился довольно красноречивый.
Похоже, что тут уже начинает работать кеш и между различными режимами разница может быть уже пятикратной. Самые быстрые режимы – Write back (unsafe) и Write through. Чуть медленнее Write back. Оставшиеся два режима оказались в разы медленнее.
Линейная запись блоками по 4 мегабайта
Результаты последнего теста привожу на диаграмме ниже.
Как и в прошлом тесте различия легко прослеживаются, но они не такие ярко выраженные. Самый шустрый режим – Direct Sync. Остальные режимы показали примерно одинаковый результат.
Выводы
Результаты полученные мною были для меня немного неожиданными – я ожидал более ярко выраженное отличие между режимами кеширования во всех тестах. Но это дало понимание того, что итоговые результаты могут сильно отличаться от выбранных параметров тестирования – случайное или последовательное чтение, размер блоков и т.д. Исходя из этого можно сделать вывод, что выбирать режим кеширования необходимо исходя из характера рабочей нагрузки и устройчивости режима кеширования к аварийному выключению питания. Идеально будет проводить какие-то замеры производительности тестами из того прикладного ПО, которое будет генерировать нагрузку на дисковую подсистему.
Результаты выше носят ознакомительный характер и могут отличаться в зависимости от оборудования и профиля нагрузки на дисковую подсистему.
Коллеги, если вы осведомлены о тонкостях оптимизации производительности дисковой подсистемы для Proxmox или у вас есть объяснение (уточнения, критика) результатов выше – пишите, буду явно выносить информацию в публикацию. Думаю, это поможет другим нашим с вами коллегам при тонком тюнинге производительности дисковой подсистемы Proxmox.