Какова лучшая файловая система для производительности вставки в PostgreSQL?

Мне любопытно, проводил ли кто-нибудь какие-либо эксперименты или сравнения между файловыми системами и производительностью базы данных. В Linux мне интересно, какова оптимальная файловая система для базы данных postgres. Кроме того, какие настройки (inode и т. Д.) Идеально подходят для этого? Может ли это что-то существенно отличаться в зависимости от данных в базе данных?

Если вы ищете вопрос, касающийся общей производительности файловой системы / базы данных, этот пост содержит полезную информацию.

Однако я хотел бы получить как можно больше советов по производительности вставки, а не по производительности чтения. Спасибо за все отличные ответы!

Купите копию «postgresql high performance» Грега Смита. Это отличная книга, и две или более главы посвящены дисковому оборудованию и файловым системам. Вы многому научитесь.

Короче говоря: нет короткого ответа.

Но я постараюсь подвести итог:

• не используйте ext2, пока не узнаете, что делаете.
• с ext3 остерегайтесь пиков контрольных точек из-за вызовов fsync, см. стр. 113 и 82 и 79
• используйте ext4 или xfs
• есть другие варианты

Но поскольку вы действительно спрашиваете себя, какую FS использовать, вам следует прочитать книгу!

Прежде всего, вы хотите сначала надежную файловую систему и быструю секунду. Что исключает некоторые варианты ...

Тестирование производительности показывает, что часто XFS дает лучшую производительность. Есть некоторые проблемы со стабильностью, когда вы достигнете сценариев «диск очень близок к полному», но если вы будете следить за тем, чтобы этого не происходило, это даст вам немного лучшую производительность.

Теоретически вам не нужна журналируемая файловая система для каталога pg_xlog, но разница в скорости обычно настолько мала, что просто не стоит. Для каталога данных у вас всегда должна быть файловая система ведения журнала метаданных.

Системы управления базами данных реализуют свое собственное журналирование через журналы базы данных, поэтому установка такой СУБД в журнализированную файловую систему снижает производительность благодаря двум механизмам:

1. Избыточное журналирование увеличивает объем дисковой активности

2. Структура физического диска может быть фрагментирована (хотя некоторые журнализируемые файловые системы действительно имеют механизмы для ее очистки).

3. Много дисковой активности может заполнить журнал, вызывая ложные условия «диск заполнен».

Несколько лет назад я видел пример, когда это делалось в файловой системе LFS при установке Baan на коробке HP / UX. В системе постоянно возникали проблемы с производительностью и повреждением данных, которые не диагностировались до тех пор, пока кто-то не определил, что файловые системы были отформатированы с использованием LFS.

Тома, содержащие файлы базы данных, обычно содержат небольшое количество больших файлов. Серверы СУБД обычно имеют параметр, который определяет, сколько блоков считывается за один ввод / вывод. Меньшие числа будут подходящими для систем обработки транзакций большого объема, поскольку они минимизируют кеширование избыточных данных. Большие числа были бы уместны для систем, таких как хранилища данных, которые выполняли много последовательных чтений. Если возможно, настройте размер блока выделения файловой системы так, чтобы он совпадал с размером многоблочного чтения, установленного для СУБД.

Некоторые системы управления базами данных могут работать с необработанными разделами диска. Это дает разную степень прироста производительности, как правило, меньше в современной системе с большим объемом памяти. В старых системах с меньшим пространством для кэширования метаданных файловой системы экономия на дисковых операциях ввода-вывода была довольно значительной. Необработанные разделы усложняют управление системой, но обеспечивают наилучшую доступную производительность.

Тома RAID-5 требуют больше затрат на запись, чем тома RAID-10, поэтому занятая база данных с большим объемом трафика записи будет работать лучше (часто намного лучше) на RAID-10. В журналы следует помещать физически отдельные тома диска с данными. Если ваша база данных велика и в основном предназначена только для чтения (например, хранилище данных), может возникнуть необходимость поместить ее на тома RAID-5, если это не приведет к чрезмерному замедлению процесса загрузки.

Кэширование с обратной записью на контроллере может дать вам выигрыш в производительности за счет создания некоторых (довольно маловероятных, но возможных) режимов отказов, где данные могут быть повреждены. Наибольший выигрыш в производительности это при нагрузках с очень произвольным доступом. Если вы хотите сделать это, рассмотрите возможность размещения журналов на отдельном контроллере и отключения кэширования обратной записи на томах журналов. В этом случае журналы будут иметь лучшую целостность данных, и один сбой не сможет уничтожить журнал и тома данных. Это позволяет восстановить из резервной копии и выполнить откат от журналов.

Я сделал такой подробный отчет, но он только на французском языке . Если вы читаете по-французски или довольны инструментами автоматического перевода ... Вы можете повторно использовать методологию и запустить ее для себя.

Резюме: я использовал pgbench. Планировщик ввода / вывода в Linux имеет очень мало значения для производительности, а файловая система - совсем немного. Так что, если вы спешите, просто выберите значение по умолчанию. Я выбрал JFS.

Файловая система - это только часть проблемы. Вы можете значительно повысить производительность, изменив планировщик ввода-вывода. К счастью, это довольно легко проверить, так как вы можете изменить планировщик ввода-вывода на лету. Я бы посоветовал попробовать каждый из них в течение нескольких дней при обычной нагрузке и посмотреть, какая из них дает наилучшую производительность.

Я провел несколько тестов несколько месяцев назад:

У меня была небольшая тестовая программа, которая создала 50 потоков, где каждый поток вставлял 1000 (или если это было 10000) строк в одну и ту же таблицу.

• С базой данных на EXT3 и 4-х дисковом RAID5 это заняло 50 секунд.
• С таблицей на виртуальном диске (с использованием табличного пространства) это все равно заняло 50 секунд. Причина, по которой это не было быстрее, состоит в том, что все записывается в каталог pg_xlog, который все еще находится на том же RAID 5.
• Я переместил pg_xlog на 4-х дисковый RAID0 (чередующийся), и та же программа запустилась за 40 секунд.
• В целях тестирования я переместил pg_xlog на виртуальный диск, а все остальное было на диске EXT3 4 RAID. Программа была завершена менее чем за 5 секунд.

Но наличие pg___xlog на программном виртуальном диске не вариант: если вы потеряете содержимое каталога pg_xlog, postgres не запустится. (Но существуют аппаратные диски с резервной батареей, которые могут представлять интерес.)

ИМХО: Используйте наиболее подходящую для файлов базы данных файловую систему. Переместите pg_xlog (с символической ссылкой, см. Документацию) на самое быстрое устройство, которое у вас есть.

Я видел, что помнил, что измененный FreeBSD даст вам немного больше производительности, чем другие ОС. Хотя я уверен, что эта информация устарела и, вероятно, вообще миф. Но вы можете все же попробовать, см. Это руководство для настроек ядра: http://developer.postgresql.org/pgdocs/postgres/kernel-resources.html