Мне любопытно, проводил ли кто-нибудь эксперименты или сравнения между файловыми системами и производительностью баз данных. В Linux мне интересно, какая файловая система является оптимальной для базы данных postgres. Кроме того, какие настройки (индексный дескриптор и т. Д.) Идеально подходят для этого? Это что-то, что может сильно отличаться в зависимости от данных в базе данных?
Если вы ищете вопрос, касающийся общей производительности файловой системы / базы данных, эта почта есть хорошая информация.
Однако я хотел бы получить как можно больше советов по вставить производительность в отличие от производительности чтения, насколько это возможно. Спасибо за прекрасные ответы!
Купите копию "postgresql high performance" Грега Смита. Это отличная книга, и две или более глав посвящены дисковым аппаратным средствам и файловым системам. Вы многому научитесь.
Вкратце: короткого ответа нет.
Но я постараюсь резюмировать:
Но поскольку вы действительно спрашиваете себя, какую ФС использовать, вам следует прочитать книгу!
Прежде всего, вам нужна сначала надежная файловая система, а потом быстрая. Что исключает некоторые варианты ...
Тестирование производительности показывает, что часто XFS дает лучшую производительность. Когда вы дойдете до сценария «очень близкий к полному», у него возникнут некоторые проблемы со стабильностью, но пока вы не будете следить за тем, чтобы этого не происходило, это даст вам немного лучшую производительность.
Теоретически вам не нужна журналируемая файловая система для каталога pg_xlog, но разница в скорости обычно настолько мала, что не стоит того. Для каталога данных вам действительно всегда следует иметь файловую систему журналирования метаданных.
Системы управления базами данных реализуют собственное ведение журнала через журналы базы данных, поэтому установка такой СУБД в журналируемой файловой системе снижает производительность за счет двух механизмов:
Избыточное ведение журнала увеличивает объем дисковой активности
Структура физического диска может быть фрагментирована (хотя в некоторых файловых системах с журналированием есть механизмы для устранения этой проблемы).
Журнал может быть заполнен из-за большой активности диска, вызывая ложные состояния «диск заполнен».
Несколько лет назад я видел пример, когда это было сделано в файловой системе LFS при установке Baan в системе HP / UX. В системе постоянно возникали проблемы с производительностью и повреждением данных, которые не диагностировались, пока кто-то не выяснил, что файловые системы были отформатированы с помощью LFS.
Тома, содержащие файлы базы данных, обычно содержат небольшое количество больших файлов. Серверы СУБД обычно имеют параметр, определяющий, сколько блоков читается за один ввод-вывод. Меньшие числа будут подходить для систем обработки транзакций большого объема, поскольку они минимизируют кэширование избыточных данных. Большие числа будут подходящими для таких систем, как хранилища данных, которые выполняют много последовательных операций чтения. Если возможно, настройте размер блока распределения файловой системы, чтобы он был того же размера, что и для многоблочного чтения, установленного для СУБД.
Некоторые системы управления базами данных могут работать с необработанными разделами диска. Это дает различную степень прироста производительности, обычно в меньшей степени в современной системе с большим объемом памяти. В старых системах с меньшим объемом места для кэширования метаданных файловой системы экономия на дисковом вводе-выводе была весьма значительной. Необработанные разделы усложняют управление системой, но обеспечивают наилучшую доступную производительность.
Тома RAID-5 несут больше накладных расходов на запись, чем тома RAID-10, поэтому загруженная база данных с большим объемом трафика записи будет работать лучше (часто намного лучше) на RAID-10. Журналы следует помещать в данные физически отдельных дисковых томов. Если ваша база данных большая и в основном предназначена только для чтения (например, хранилище данных), ее можно разместить на томах RAID-5, если это не слишком замедляет процесс загрузки.
Кэширование с обратной записью на контроллере может дать вам выигрыш в производительности за счет создания некоторых (разумно маловероятных, но возможных) режимов отказа, в которых данные могут быть повреждены. Самый большой выигрыш в производительности достигается при высокой степени произвольного доступа. Если вы хотите это сделать, рассмотрите возможность размещения журналов на отдельном контроллере и отключения кэширования с обратной записью для томов журналов. В этом случае журналы будут иметь лучшую целостность данных, и единичный сбой не сможет удалить и журнал, и тома данных. Это позволяет выполнять восстановление из резервной копии и повторять транзакции из журналов.
Я сделал такой подробный отчет, но это только на французском. Если вы читаете по-французски или довольны инструментами автоматического перевода ... Вы можете повторно использовать методологию и запустить ее самостоятельно.
Краткое содержание: я использовал pgbench. Планировщик ввода-вывода Linux имеет очень небольшое значение для производительности, а файловая система - совсем немного. Так что, если вы торопитесь, просто выберите значение по умолчанию. Я выбрал JFS.
Файловая система - это только часть проблемы. Вы можете значительно повысить производительность, изменив планировщик ввода-вывода. К счастью, это довольно легко проверить, так как вы можете изменить планировщик ввода-вывода на лету. Я предлагаю попробовать каждый из них в течение нескольких дней при обычной нагрузке и посмотреть, какой из них дает лучшую производительность.
Несколько месяцев назад я провел несколько тестов:
У меня была небольшая тестовая программа, которая создавала 50 потоков, где каждый поток вставлял 1000 (или, если это было 10000) строк в одну и ту же таблицу.
Но наличие pg___xlog на программном ramdisk - не вариант: если вы потеряете содержимое каталога pg_xlog, postgres не запустится. (Но существуют аппаратные RAM-диски с резервным аккумулятором, которые могут представлять интерес.)
ИМХО: используйте наиболее удобную файловую систему для файлов базы данных. Переместите pg_xlog (с символической ссылкой, см. Документацию) на самое быстрое устройство, которое у вас есть.
Я видел, как вспомнил, что измененная FreeBSD даст вам немного больше производительности по сравнению с другими ОС. Хотя я уверен, что эта информация устарела и, возможно, в первую очередь миф. Но вы, тем не менее, можете попробовать это, см. Это руководство по настройкам ядра: http://developer.postgresql.org/pgdocs/postgres/kernel-resources.html