Дано: 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 мс.