Linux файловая система для postgresql
С точки зрения файловой системы кластер баз данных представляет собой один каталог, в котором будут храниться все данные. Мы называем его каталогом данных или областью данных. Где именно хранить данные, вы абсолютно свободно можете выбирать сами. Какого-либо стандартного пути не существует, но часто данные размещаются в /usr/local/pgsql/data или в /var/lib/pgsql/data . Прежде чем с каталогом данных можно будет работать, его нужно инициализировать, используя программу initdb , которая устанавливается в составе PostgreSQL .
Если вы используете PostgreSQL в виде готового продукта, в нём могут быть приняты определённые соглашения о расположении каталога данных, и может также предоставляться скрипт для создания этого каталога данных. В этом случае следует воспользоваться этим скриптом, а не запускать непосредственно initdb . За подробностями обратитесь к документации используемого вами продукта.
Чтобы инициализировать кластер баз данных вручную, запустите initdb , передав в параметре -D путь к желаемому расположению данных кластера в файловой системе, например:
Заметьте, что эту команду нужно выполнять от имени пользователя PostgreSQL , о котором говорится в предыдущем разделе.
Подсказка
В качестве альтернативы параметра -D можно установить переменную окружения PGDATA .
Также можно запустить команду initdb , воспользовавшись программой pg_ctl , примерно так:
Этот вариант может быть удобнее, если вы используете pg_ctl для запуска и остановки сервера (см. Раздел 18.3), так как pg_ctl будет единственной командой, с помощью которой вы будете управлять экземпляром сервера баз данных.
Команда initdb попытается создать указанный вами каталог, если он не существует. Конечно, она не сможет это сделать, если initdb не будет разрешено записывать в родительский каталог. Вообще рекомендуется, чтобы пользователь PostgreSQL был владельцем не только каталога данных, но и родительского каталога, так что такой проблемы быть не должно. Если же и нужный родительский каталог не существует, вам нужно будет сначала создать его, используя права root, если вышестоящий каталог защищён от записи. Таким образом, процедура может быть такой:
Команда initdb не будет работать, если указанный каталог данных уже существует и содержит файлы; это мера предохранения от случайной перезаписи существующей инсталляции.
Так как каталог данных содержит все данные базы, очень важно защитить его от неавторизованного доступа. Для этого initdb лишает прав доступа к нему всех пользователей, кроме пользователя PostgreSQL и, возможно, его группы. Если группе разрешается доступ, то только для чтения. Это позволяет непривилегированному пользователю, входящему в одну группу с владельцем кластера, делать резервные копии данных кластера или выполнять другие операции, для которых достаточно доступа только для чтения.
Заметьте, чтобы корректно разрешить или запретить доступ группы к данным существующего кластера, необходимо выключить кластер и установить соответствующий режим для всех каталогов и файлов до запуска PostgreSQL . В противном случае в каталоге данных возможно смешение режимов. Для кластеров, к которым имеет доступ только владелец, требуется установить режим 0700 для каталогов и 0600 для файлов, а для кластеров, в которых также разрешается чтение группой, режим 0750 для каталогов и 0640 для файлов.
Однако даже когда содержимое каталога защищено, если проверка подлинности клиентов настроена по умолчанию, любой локальный пользователь может подключиться к базе данных и даже стать суперпользователем. Если вы не доверяете другим локальным пользователям, мы рекомендуем использовать один из параметров команды initdb : -W , —pwprompt или —pwfile и назначить пароль суперпользователя баз данных. Кроме того, воспользуйтесь параметром -A md5 или -A password и отключите разрешённый по умолчанию режим аутентификации trust ; либо измените сгенерированный файл pg_hba.conf после выполнения initdb , но перед тем, как запустить сервер в первый раз. (Возможны и другие разумные подходы — применить режим проверки подлинности peer или ограничить подключения на уровне файловой системы. За дополнительными сведениями обратитесь к Главе 20.)
Команда initdb также устанавливает для кластера баз данных локаль по умолчанию. Обычно она просто берёт параметры локали из текущего окружения и применяет их к инициализируемой базе данных. Однако можно выбрать и другую локаль для базы данных; за дополнительной информацией обратитесь к Разделу 23.1. Команда initdb задаёт порядок сортировки по умолчанию для применения в определённом кластере баз данных, и хотя новые базы данных могут создаваться с иным порядком сортировки, порядок в базах-шаблонах, создаваемых initdb, можно изменить, только если удалить и пересоздать их. Также учтите, что при использовании локалей, отличных от C и POSIX , возможно снижение производительности. Поэтому важно правильно выбрать локаль с самого начала.
Команда initdb также задаёт кодировку символов по умолчанию для кластера баз данных. Обычно она должна соответствовать кодировке локали. За подробностями обратитесь к Разделу 23.3.
Для локалей, отличных от C и POSIX , порядок сортировки символов зависит от системной библиотеки локализации, а он, в свою очередь, влияет на порядок ключей в индексах. Поэтому кластер нельзя перевести на несовместимую версию библиотеки ни путём восстановления снимка, ни через двоичную репликацию, ни перейдя на другую операционную систему или обновив её версию.
18.2.1. Использование дополнительных файловых систем
Во многих инсталляциях кластеры баз данных создаются не в « корневом » томе, а в отдельных файловых системах (томах). Если вы решите сделать так же, то не следует выбирать в качестве каталога данных самый верхний каталог дополнительного тома (точку монтирования). Лучше всего создать внутри каталога точки монтирования каталог, принадлежащий пользователю PostgreSQL , а затем создать внутри него каталог данных. Это исключит проблемы с разрешениями, особенно для таких операций, как pg_upgrade , и при этом гарантирует чистое поведение в случае, если дополнительный том окажется отключён.
18.2.2. Файловые системы
Вообще говоря, для PostgreSQL может использоваться любая файловая система с семантикой POSIX. Пользователи предпочитают различные файловые системы по самым разным причинам, в частности, по соображениям производительности, изученности или поддержки поставщиком. Как показывает практика, в результате лишь смены файловой системы или корректировки её параметров при прочих равных не следует ожидать значительного изменения производительности или поведения.
18.2.2.1. NFS
Использовать параметр монтирования sync не обязательно. Поведения режима async достаточно, так как PostgreSQL вызывает fsync в нужные моменты для сброса кеша записи (так же, как и с локальной файловой системой). Однако параметр sync настоятельно рекомендуется использовать при экспортировании файловой системы на сервере NFS в тех ОС, где он поддерживается (в основном это касается Linux). В противном случае не гарантируется, что в результате выполнения fsync или аналогичного вызова NFS-клиентом данные действительно окажутся в надёжном хранилище на сервере, вследствие чего возможно повреждение данных, как и при выключенном параметре fsync. Значения по умолчанию параметров монтирования и экспортирования меняются от производителя к производителю и от версии к версии, поэтому рекомендуется перепроверить их или, возможно, явно задать нужные значения во избежание неоднозначности.
В некоторых случаях внешнее устройство хранение может быть подключено по NFS или посредством низкоуровневого протокола, например iSCSI. В последнем случае такое хранилище представляется в виде блочного устройства, и на нём можно создать любую файловую систему. При этом администратору не придётся иметь дело со странностями NFS, но надо понимать, что сложности управления удалённым хранилищем в таком случае просто перемещаются на другие уровни.
Источник
PostgreSQL на разных фс (ext3, ext4, xfs)
Статья — заметка, выросшая из вопроса, заданного в Q&A. Вкратце дело было так… Был предложен вариант тестирования PostgreSQL на определенной файловой системе и стоял вопрос, нормальный ли это подход и можно ли хоть как-то доверять результатам этого теста. В ходе обсуждения вопроса альтернативных вариантов не нашлось и я решил тестировать как и задумал изначально.
Собственно, что было и как все проходило:
Есть средненький сервер следующей комплектации:
- HP Proliant DL160 G5
- 1x Intel Xeon CPU E5405 @ 2.00GHz (L1 128KiB, L2 12MiB)
- 4x FB-DIMM DDR2 Synchronous 667 MHz (1.5 ns) итого 8GB RAM
- RAID LSI SAS1064E 4-Port PCI-E 3Gb/s
- 4x SAS HP DF146BABUE 146GB 3.5″ LFF 3G 15K RPM
- Gentoo Linux kernel-3.7.1, glibc-2.15-r3, gcc-4.5.4
- PostgreSQL Server 9.2.1
Из четырех дисков было собрано два RAID1, на одном из них размещена операционная система, второй том является полигоном для испытаний. Этот диск используется в качестве LVM PV и для теста выделен LVM том размером 55GB. Тест проходит следующим образом:
- форматируем том и монтируем в каталог;
- запускаем инициализацию postgresql-кластера;
- копируем в кластер заранее подготовленный конфигурационный файл postgresql.conf;
- запускаем postgresql и создаем тестовую базу pgbench;
- запускаем инициализацию таблиц с помощью pgbench;
- циклически в режиме «SELECT’s only» запускаем pgbench с разным количество клиентских подключений, результаты сохраняем (каждый тест длится 2 часа)
- циклически в режиме «TPC-B» запускаем pgbench с разным количество клиентских подключений, результаты сохраняем (каждый тест длится 2 часа).
Количество клиентов в каждом тесте вариируется от 8 до 96 (8,16,32,64,96)
Итого для одной файловой системы мы получим 10 результатов (5 SELECT’s only, 5 TPC-B)
Несколько деталей, имеющих значение:
- RAID работает без WriteCache;
- все процессы/сервисы были остановлены/выключены за исключением PostgreSQL, таблица процессов практически пуста (за исключением ядерных процессов);
- WAL журналы живут на том же разделе что и данные;
- тестовая база инициализировалась таким образом, чтобы занять 80% пространства всего диска;
- перед каждым запуском pgbench выполнялся сброс кэшей.
Настройки postgresql.conf
max_connections = 100
shared_buffers = 1500MB
work_mem = 16MB
maintenance_work_mem = 128MB
effective_io_concurrency = 1
checkpoint_segments = 32
checkpoint_timeout = 10min
checkpoint_completion_target = 0.9
Результаты для «SELECT’s only» и TPC-B
Выводы: вобщем как и ожидалось прорывных и революционных разрывов в результатах нет, все файловые системы вобщем имеют приблизительно одинаковый уровень производительности. Если же приглядываться, то можно отметить несколько моментов:
— ext4 показывает чуть большую производительность чем ext3 (в среднем на 1-3%);
— ext4 показывает наибольшую производительность в TPC-B тесте (от 1% до 8%);
— xfs показывает наибольшую производительность в SELECT’s only (от 1% до 3%);
В целом можно сказать «а можно ставить любую фс, разница настолько мала, что ею можно пренебречь». Но помните что (тут можно вставить любую пафосную фразу про важность мелочей). В общем, не пренебрегайте мелочами))
На этом все. Можно кидаться какашками, критиковать, высказывать мысли, выносить свои идеи…
Источник
Какова лучшая файловая система для производительности вставки в PostgreSQL?
Мне любопытно, проводил ли кто-нибудь какие-либо эксперименты или сравнения между файловыми системами и производительностью базы данных. В Linux мне интересно, какова оптимальная файловая система для базы данных postgres. Кроме того, какие настройки (inode и т. Д.) Идеально подходят для этого? Может ли это что-то существенно отличаться в зависимости от данных в базе данных?
Если вы ищете вопрос, касающийся общей производительности файловой системы / базы данных, этот пост содержит полезную информацию.
Однако я хотел бы получить как можно больше советов по производительности вставки, а не по производительности чтения. Спасибо за все отличные ответы!
33% от общего размера БД, к новой машине, где общий объем ОЗУ был больше, чем размер БД. Теперь мы можем кэшировать всю БД в памяти. Наш самый медленный SQL-запрос теперь на 2 порядка быстрее.
Купите копию «postgresql high performance» Грега Смита. Это отличная книга, и две или более главы посвящены дисковому оборудованию и файловым системам. Вы многому научитесь.
Короче говоря: нет короткого ответа.
Но я постараюсь подвести итог:
- не используйте ext2, пока не узнаете, что делаете.
- с ext3 остерегайтесь пиков контрольных точек из-за вызовов fsync, см. стр. 113 и 82 и 79
- используйте ext4 или xfs
- есть другие варианты
Но поскольку вы действительно спрашиваете себя, какую FS использовать, вам следует прочитать книгу!
Прежде всего, вы хотите сначала надежную файловую систему и быструю секунду. Что исключает некоторые варианты .
Тестирование производительности показывает, что часто XFS дает лучшую производительность. Есть некоторые проблемы со стабильностью, когда вы достигнете сценариев «диск очень близок к полному», но если вы будете следить за тем, чтобы этого не происходило, это даст вам немного лучшую производительность.
Теоретически вам не нужна журналируемая файловая система для каталога pg_xlog, но разница в скорости обычно настолько мала, что просто не стоит. Для каталога данных у вас всегда должна быть файловая система ведения журнала метаданных.
Системы управления базами данных реализуют свое собственное журналирование через журналы базы данных, поэтому установка такой СУБД в журнализированную файловую систему снижает производительность благодаря двум механизмам:
Избыточное журналирование увеличивает объем дисковой активности
Структура физического диска может быть фрагментирована (хотя некоторые журнализируемые файловые системы действительно имеют механизмы для ее очистки).
Много дисковой активности может заполнить журнал, вызывая ложные условия «диск заполнен».
Несколько лет назад я видел пример, когда это делалось в файловой системе LFS при установке Baan на коробке HP / UX. В системе постоянно возникали проблемы с производительностью и повреждением данных, которые не диагностировались до тех пор, пока кто-то не определил, что файловые системы были отформатированы с использованием LFS.
Тома, содержащие файлы базы данных, обычно содержат небольшое количество больших файлов. Серверы СУБД обычно имеют параметр, который определяет, сколько блоков считывается за один ввод / вывод. Меньшие числа будут подходящими для систем обработки транзакций большого объема, поскольку они минимизируют кеширование избыточных данных. Большие числа были бы уместны для систем, таких как хранилища данных, которые выполняли много последовательных чтений. Если возможно, настройте размер блока выделения файловой системы так, чтобы он совпадал с размером многоблочного чтения, установленного для СУБД.
Некоторые системы управления базами данных могут работать с необработанными разделами диска. Это дает разную степень прироста производительности, как правило, меньше в современной системе с большим объемом памяти. В старых системах с меньшим пространством для кэширования метаданных файловой системы экономия на дисковых операциях ввода-вывода была довольно значительной. Необработанные разделы усложняют управление системой, но обеспечивают наилучшую доступную производительность.
Тома RAID-5 требуют больше затрат на запись, чем тома RAID-10, поэтому занятая база данных с большим объемом трафика записи будет работать лучше (часто намного лучше) на RAID-10. В журналы следует помещать физически отдельные тома диска с данными. Если ваша база данных велика и в основном предназначена только для чтения (например, хранилище данных), может возникнуть необходимость поместить ее на тома RAID-5, если это не приведет к чрезмерному замедлению процесса загрузки.
Кэширование с обратной записью на контроллере может дать вам выигрыш в производительности за счет создания некоторых (довольно маловероятных, но возможных) режимов отказов, где данные могут быть повреждены. Наибольший выигрыш в производительности это при нагрузках с очень произвольным доступом. Если вы хотите сделать это, рассмотрите возможность размещения журналов на отдельном контроллере и отключения кэширования обратной записи на томах журналов. В этом случае журналы будут иметь лучшую целостность данных, и один сбой не сможет уничтожить журнал и тома данных. Это позволяет восстановить из резервной копии и выполнить откат от журналов.
Источник
