Сравнение скорости PostgreSQL 15 на различных файловых системах (ext4, xfs, btrfs - в том числе со сжатием)
Постановка задачи
Не знаю как у вас, а у меня время от времени, по мере появления и выпуска 'в продакшн' новых файловых систем Linux, возникает тяга протестировать на них работу сервера 1С. Задавать вопросы на форумах 1С бесполезно - ответов по существу нет.
В качестве подопытного была взята реальная база ЗУП КОРП, в качестве сервера СУБД служит довольно слабенький компьютер на Arch Linux с процессором на 2 ядра и 4 потока с пассивным охлаждением. Во всех тестах база данных располагается на одном и том же механическом HDD-диске, а WAL вынесен на диск SSD. WAL я трогать не буду, все опыты производятся только на диске с данными и временными таблицами.
Замеры производительности буду делать с помощью многократного выполнения реальных операций в ЗУП с использованием подсистемы оценки производительности APDEX и настройкой профилей операций по умолчанию. К сожалению, лицензия разработчика не позволяет прогнать настоящий многопользовательский тест, поэтому будет однопользовательский. Хотя бы так, чем никак - надеюсь общая картина будет понятной, ну и к тому же в качестве оправдания можно сказать что для ЗУП нехарактерна высокая параллельная нагрузка.
BTRFS со сжатием
За хвост не тянем - сразу берём за рога и начинаем с самого интересного варианта: btrfs со сжатием. Забыл сказать - все подопытные файловые системы форматируем по умолчанию, без каких-либо оптимизирующих опций. Размер блока везде будет 4k. Опции монтирования в fstab такие:
/dev/sdb2 /sqldata btfrs defaults,noatime,autodefrag,compress-force=zstd 0 0
После загрузки базы смотрим его размер:
df -h /dev/sdb2
Файловая система Размер Использовано Дост Использовано% Cмонтировано в
/dev/sdb2 444G 891M 441G 1% /sqldata
Предварительный вывод: PostgreSQL на диске со сжатием работает, файлы данных занимают в сумме примерно столько же места, как и файл выгрузки в DT.
Результаты APDEX:
BTRFS без сжатия и CoW
Для чистоты эксперимента форматируем диск заново, опции монтирования меняем:
/dev/sdb2 /sqldata btfrs defaults,noatime,autodefrag,nodatacow 0 0
После загрузки базы смотрим его размер:
df -h /dev/sdb2
Файловая система Размер Использовано Дост Использовано% Cмонтировано в
/dev/sdb2 444G 1.7G 440G 1% /sqldata
Вполне ожидаемо размер вырос, примерно чуть больше размера 1CD в файловой базе. Результаты APDEX:
EXT4
Форматируем в старый добрый EXT4, применяем новые опции монирования:
/dev/sdb2 /sqldata ext4 defaults,noatime 0 0
Размер после загрузки:
df -h /dev/sdb2
Файловая система Размер Использовано Дост Использовано% Cмонтировано в
/dev/sdb2 436G 1,6G 412G 1% /sqldata
Изменений мало, разве что APDEX стал чуть лучше:
XFS
XFC такая же старая как EXT4, если не старее. В CentOS 7 она была основной (что там сейчас в Stream даже знать не интересно). В тесты попал в связи с тем, что я где-то в сети встречал мнение что XFS самая оптимальная файловая система для PostgreSQL. Ну что-ж, проверим.
/dev/sdb2 /sqldata xfs defaults,noatime 0 0
Размер после загрузки DT сразу напряг:
df -h /dev/sdb2
Файловая система Размер Использовано Дост Использовано% Cмонтировано в
/dev/sdb2 444G 4,8G 437G 2% /sqldata
На всякий случай прогнал VACUUM FULL, но размер нисколько не уменьшился. В итоге выяснилось, что 3.2 GB уже было занято на пустом диске до загрузки базы, так что занято полезными данными получается 1.6 GB, что вполне соответствует реальному размеру. Может удивит скоростью?
Увы, всё на среднем уровне.
Общие выводы
- Все протестированные файловые системы работают с одинаковой производительностью, отличие на уровне погрешности замеров. Попытки ускорения заменой типа ФС - замена шила на мыло.
- BTRFS со сжатием - на удивление оказался вполне рабочим вариантом. Даже самый никчёмный процессор справляется и какого-то роста нагрузки CPU особо не было замечено. Можно очень прилично сэкономить место на диске, на уровне файла mdb в MSSQL. Проблема только одна - стойкое годами неверие в его надёжность. Даже сейчас на любом форуме можно наткнуться на историю про потерю данных на BTRFS.
- EXT4 вполне себе на белом коне, пожалуй буду продолжать использовать его.
- XFS ничем не удивил, только тем что честно показал расход объёма служебными данными. На самом деле самым прожорливым и 'нечестным' оказывается EXT4, если внимательнее посмотреть на размер файловой системы и свободное место.