Ускоряем ext4. Убираем тормоза контейнера lxc в Proxmox
Дано: proxmox на свежеустановленном Debian. Созданный контейнер с ubuntu из шаблона. Установлен apache, php, mysql и движок mediawiki. Страницы mediawiki открывались дольше секунды. Если смотреть Network в DevTools Chrome — страница начинает отдаваться сервером спустя 900-1400 мс. На глаз эта задержка очень заметна.
Первичный осмотр показал, что нагрузка на процессор минимальна, оперативная память свободна. Остается файловая система. Она представляет собой два старых диска, собранных mdadm в RAID1. SMART по одному из дисков показывает, что он скорее мертв, чем жив, но массив работает.
Для проверки эффективности дисковой подсистемы я взял утилиту pveperf. Проблема подтвердилась:
# pveperf /var/lib/vz/ CPU BOGOMIPS: 19205.96 REGEX/SECOND: 965789 HD SIZE: 257.61 GB (/dev/mapper/pve-data) BUFFERED READS: 81.10 MB/sec AVERAGE SEEK TIME: 16.63 ms FSYNCS/SECOND: 43.83 DNS EXT: 1170.84 ms
Смотрим на параметр FSYNCS. По хорошему он должен быть больше в разы.
Попробуем вылечить это с помощью добавления опций монтирования в /etc/fstab: data=writeback,barrier=0.
Должно получиться так:
/dev/mapper/pve-data /var/lib/vz ext4 defaults,data=writeback,barrier=0 0 2
Что означают эти опции?
data — режим журналирования. Всего есть 3 режима:
-
Journal Mode (самый медленный, наиболее безопасный)
-
Ordered Mode (средняя скорость, очень безопасный, опция по умолчанию)
-
Writeback Mode (наиболее быстрый, относительно безопасный)
Мы выбрали последний режим. он самый быстрый, но и наименее безопасный для сохранности данных, в случае аварий.
barrier — по умолчанию, используются барьеры синхронизации в очереди запросов.
После перезагрузки проверяем результат:
# pveperf /var/lib/vz/ CPU BOGOMIPS: 19206.52 REGEX/SECOND: 929606 HD SIZE: 257.61 GB (/dev/mapper/pve-data) BUFFERED READS: 91.42 MB/sec AVERAGE SEEK TIME: 24.84 ms FSYNCS/SECOND: 1533.78 DNS EXT: 1059.63 ms
Теперь FSYNCS 1533.
Страницы вместо 900-1400 мс стали отдаваться за 80-130 мс.