diamond АШ Tlg

Сравнение скорости 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:

APDEX btrfs compress

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:

APDEX btrfs no compress no cow

EXT4

Форматируем в старый добрый EXT4, применяем новые опции монирования:

/dev/sdb2  /sqldata  ext4  defaults,noatime  0  0

Размер после загрузки:

df -h /dev/sdb2
Файловая система Размер Использовано  Дост Использовано% Cмонтировано в
/dev/sdb2          436G         1,6G  412G            1% /sqldata

Изменений мало, разве что APDEX стал чуть лучше:

APDEX ext4

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, что вполне соответствует реальному размеру. Может удивит скоростью?

APDEX ext4

Увы, всё на среднем уровне.

Общие выводы

Мем Ты не дооцениваешь мою мощь!
  • Все протестированные файловые системы работают с одинаковой производительностью, отличие на уровне погрешности замеров. Попытки ускорения заменой типа ФС - замена шила на мыло.
  • BTRFS со сжатием - на удивление оказался вполне рабочим вариантом. Даже самый никчёмный процессор справляется и какого-то роста нагрузки CPU особо не было замечено. Можно очень прилично сэкономить место на диске, на уровне файла mdb в MSSQL. Проблема только одна - стойкое годами неверие в его надёжность. Даже сейчас на любом форуме можно наткнуться на историю про потерю данных на BTRFS.
  • EXT4 вполне себе на белом коне, пожалуй буду продолжать использовать его.
  • XFS ничем не удивил, только тем что честно показал расход объёма служебными данными. На самом деле самым прожорливым и 'нечестным' оказывается EXT4, если внимательнее посмотреть на размер файловой системы и свободное место.