PostgreSQL/Optimum

Оптимизация работы PostgreSQL

Настройка конфигурации

параметр - значение - рекомендации

Настройка ресурсов

shared_buffers

Размер разделяемой между процессами PostgreSQL памяти, которая нужна для выполнения активных операций. Не следует указывать слишком большой объём, так как PostgreSQL использует также дисковый кэш (см. effective_cache_size).

Значения:

Средний объём данных и 256-512 МБ доступной памяти: 16-32 МБ
Большой объём данных и 1-4 ГБ доступной памяти: 64-256 МБ

temp_buffers

Буфер под временные объекты, в основном для временных таблиц.

Можно установить порядка 16 МБ.

max_prepared_transactions

Количество одновременно подготавливаемых транзакций.

Для работы 1С этот параметр значения не имеет, PREPARE TRANSACTION там не используются.

Можно оставить по дефолту - 5

work_mem

Специальная память, используется для сортировки и кэширования таблиц, для одного запроса.

При задании этого параметра следует учитывать количество конкурентных запросов, выполняемых в один момент времени (для каждого запроса используется своя память размером до work_mem).

При памяти 1-4Gb рекомендуется устанавливать 32-128MB

maintenance_work_mem

Память использующаяся для операций VACUUM, CREATE INDEX, ALTER TABLE и FOREGIN KEY.

Следует устанавливать большее значение, чем для work_mem. Слишком большие значения приведут к использованию свопа.

При памяти 1-4Gb рекомендуется устанавливать 128-512MB

Обратите внимание, что когда запускается autovacuum, то может потребоваться до autovacuum_max_worker раз такого количества памяти, так что не задавайте это значение слишком большим.

max_stack_depth

Специальный стек для сервера, в идеале он должен совпадать с размером стека, выставленном в ядре ОС. Установка большего значения, чем в ядре, может привести к ошибкам.

Рекомендуется устанавливать 2-4MB

max_fsm_relations

Максимальное количество таблиц, для которых будет отслеживаться свободное место в общей карте свободного пространства. Эти данные собираются VACUUM.

Выставьте параметр в соответствии с количеством таблиц в вашей базе с запасом. (Применимо для версий до 8.4)

max_fsm_pages

Количество блоков, для которых будет хранится информация о свободном месте. Информация хранится в разделяемой памяти, для каждой записи требуется по 6 байт.

Использование этого параметра позволяет избежать использования VACUUM FULL для базы, достаточно будет VACUUM. (Применимо для версий до 8.4)

Этот параметр должен быть не меньше чем 16*max_fsm_relations

Данный параметр задается автоматически при создании базы утилитой initdb

Можно задать его и вручную: в качестве начального приближения можно взять половину от среднего количества записей, изменяемых (UPDATE или DELETE) между запусками команды VACUUM.

Оценить это значение (база должна проработать уже какое-то время) можно выполнив:

vacuum full analyze;

NOTICE: number of page slots needed (196272) exceeds max_fsm_pages (153600)

HINT: Consider increasing the configuration parameter "max_fsm_pages" to a value over 196272.

max_files_per_process

Максимальное количество файлов, открываемых процессом и его подпроцессами в один момент времени.

Уменьшите данный параметр, если в процессе работы наблюдается сообщение "Too many open files".

Запись транзакционных логов на диск

commit_delay и commit_siblings

Значение commit_delay выражается в микросекундах (0 по умолчанию). Значение commit_siblings выражается в штуках (5 по умолчанию).

commit_delay определяют задержку между попаданием записи в буфер журнала транзакций и сбросом её на диск. Если при успешном завершении транзакции активно не менее commit_siblings транзакций, то запись будет задержана на время commit_delay. Если за это время завершится другая транзакция, то их изменения будут сброшены на диск вместе, при помощи одного системного вызова. Эти параметры позволят ускорить работу, если параллельно выполняется много «мелких» транзакций.

fsync

Данный параметр отвечает за сброс данных из кэша на диск при завершении транзакций.

Если установить его значение

fsync=off

то данные не будут записываться на дисковые накопители сразу после завершения операций. Это может существенно повысить скорость операций insert и update, но есть риск повредить базу, если произойдет сбой (неожиданное отключение питания, сбой ОС, сбой дисковой подсистемы).

Используйте эту возможность только если у вас имеются надежные ИБП и программное обеспечение, завершающее работу системы при низком заряде батарей.

Не следует отключать fsync при работе PostgreSQL на Windows платформе, из-за нестабильности системы

wal_sync_method

Метод, который используется для принудительной записи данных на диск.

Если fsync=off, то этот параметр не используется.

Возможные значения:

open_datasync - запись данных методом open() с параметром O_DSYNC

fdatasync - вызов метода fdatasync() после каждого commit

fsync_writethrough - вызывать fsync() после каждого commit игнорирую паралельные процессы

fsync - вызов fsync() после каждого commit

open_sync - запись данных методом open() с параметром O_SYNC

Не все методы доступны на определенных платформах. По умолчанию устанавливается первый, который доступен в системе.

full_page_writes

Установите данный параметр в off, если fsync=off. Иначе

Когда этот параметр on, PostgreSQL записывает содержимое каждой страницы в журнал транзакций во время первой модификации таблицы после контрольной точки. Это необходимо потому что страницы могут записаться лишь частично если в ходе процесса ОС "упала". Это приволит к тому, что на диске оказаываются новые данные смешанные со старыми. Строкового уровня записи в журнал транзакций может быть не достаточно, что бы полность восстановить данные после "падения". full_page_writes гарантирует корректное восстановление, ценой увелечения записываемых данных в журнал транзакций.(Потому что журнал транзакций все время начинается с контрольной точки. Единственный способ снижения объема записи заключается в увеличении checkpoint interval).

wal_buffers

Количество памяти используемое в SHARED MEMORY для ведения транзакционных логов.

При доступной памяти 1-4GB рекомендуется устанавливать 256-1024kb

Оптимизация запросов

enable_nestloop

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

random_page_cost

Устанавливает у планировщика оценку "стоимоти" не последовательного перебора данных. По умолчанию 4.0. Уменьшение этого значения по отношению к seq_page_cost вызовет у планировщика предпочтение сканирования индекса, увеличение -- наобород сделает сканирование индекса "дороже". Вы можете изменить оба значения чтобы изменить отношение "стоимости" дисковых операций ввода/выдода, по отношениб с "стоимости" использования процессора, которая бадет описана следующими параметрами.

На серверах с быстрыми дисковыми массивами имеет смысл уменьшать изначальную настройку до 3.0, 2.5 или даже до 2.0. Если же активная часть вашей базы данных много больше размеров оперативной памяти, попробуйте поднять значение параметра. Можно подойти к выбору оптимального значения и со стороны производительности запросов. Если планировщик запросов чаще, чем необходимо, предпочитает последовательные просмотры (sequential scans) просмотрам с использованием индекса (index scans), понижайте значение. И наоборот, если планировщик выбирает просмотр по медленному индексу, когда не должен этого делать, настройку имеет смысл увеличить. После изменения тщательно тестируйте результаты на максимально широком наборе запросов. Никогда не опускайте значение random_page_cost ниже 2.0; если вам кажется, что random_page_cost нужно еще понижать, разумнее в этом случае менять настройки статистики планировщика.

cpu_tuple_cost

Устанавливает у планировщика оценку "стоимоти" затрат на обработку каждой строки во время выполнения запроса. По умолчанию 0,01.

cpu_index_tuple_cost

Устанавливает у планировщика оценку "стоимоти" затрат на обработку каждого индекса во время операции сканирования индекса. По умолчанию 0,005

cpu_operator_cost

Устанавливает у планировщика оценку "стоимоти" затрат на выполнение каждого оператора или функции во время выполнения запроса. По умолчанию 0.0025.

effective_cache_size

Передает данные планировщику запросов об объёме памяти, которая используется ОС для кэширования файлов, для одного запроса.

Этот параметр в ОС можно посмотреть в настройках:

Для Windows: в Диспетчере задач, Закладка Быстродействие, Физическая память-Системный кэш.

Для Linux: наберите команду free, необходимое значение в столбце cached (в kB)

Под вопросом: Данное значение необходимо разделить на количество конкурентных запросов в один момент времени (среднее количество подключений к базе + запас).

default_statistics_target

Устанавливает глубину статистики по таблицам. БОльшие значения могут повысить время выполнения команды ANALYZE, но улучшат построение плана запроса.

Рекомендуется устанавливать порядка 100.

constraint_exclusion

Включает или отключает использование планером ограничений CONSTRAINT в таблицах при построении запросов.

Рекомендуется установить значение on, при этом, если Вы изменяете CONSTRAINT у таблиц, необходимо обновить их статистику выполнив ANALYZE, в противном случае будут построены неверные планы запросов.

Сбор статистики

stats_command_string

Передавать ли сборщику статистики информацию о текущей выполняемой команде и времени начала её выполнения.

Устанавливать on

stats_start_collector

Включать ли сбор статистики.

Устанавливать on

stats_row_level, stats_block_level

Собирать ли информацию об активности на уровне записей и блоков соответственно.

Устанавливать

stats_row_level=on

stats_block_level=off

stats_reset_on_server_start

Обнулять ли статистику при перезапуске сервера

Устанавливать off

Автовакуум

VACUUM - сборка "мусора". VACUUM восстанавливает место занятые "мертвыми" данными. При выполнении обычных операций с данными, PostgreSQL не удаляет данные физически из таблиц, это происходит с операцией VACUUM.

autovacuum

Включать ли автовакуум (автоматического запуска VACUUM), устанавливать on

autovacuum_naptime

Пауза между запусками Автовакуума.

Зависит от того, как часто обновляются данные в ваших таблицах. Может составлять порядка 5min, по умолчанию 1min

autovacuum_analyze_threshold

Определяет минимальное количество вставок, обновлений или удалений необходимых для посылки сигнала на запуск ANALYZE в любой таблице. Этот параметр может быть изменен для отдельных таблиц путем изменения параметров хранения.

autovacuum_vacuum_threshold

Определяет минимальное количество вставок, обновлений или удалений необходимых для посылки сигнала на запуск VACUUM в любой таблице. Этот параметр может быть изменен для отдельных таблиц путем изменения параметров хранения.

Блокировки

max_locks_per_transaction

Количество блокировок за одну транзакцию: установить порядка 250

deadlock_timeout

Время жизни взаимных блокировок. Установить порядка 2 секунд.

Возможная ошибка

После исправления файла конфигурации PostgreSQL может не запуститься, выдав ошибку:

FATAL:  could not create shared memory segment:...

Failed system call was shmget(key=5432001, size=140075008, 03600).

This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter.  You can either reduce the request size or reconfigure the kernel with larger SHMMAX.  To reduce the request size (currently 140075008 bytes), reduce PostgreSQL's shared_buffers parameter (currently 16384) and/or its max_connections parameter (currently 10).

        If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter, in which case raising the request size or reconfiguring SHMMIN is called for.

        The PostgreSQL documentation contains more information about shared memory configuration.

Для исправления необходимо увеличить параметр SHMMAX в системе. Сделать это можно следующим образом (для ОС Linux):

Выполните команду:

echo 150829120 > /proc/sys/kernel/shmmax

указав свое новое значение для параметра (какое именно - можно посмотреть в логе ошибки PostgreSQL). Данная операция устанавливает параметр на лету, но после перезагрузки системы изменения будут потеряны. Чтобы этого не происходило, внесите в файл /etc/sysctl.conf следующую строку:

kernel.shmmax = 150829120

указав своё значение.

Пример конфигурации для сервера с 2G оперативной памяти

/var/lib/pgsql/data/postgresql.conf:

to be done

/etc/sysctl.conf:

to be done

Средняя настройка

Среднестатическая настройка для максимальной производительности. Возможно для конкретного случая лучше подойдут другие настройки. Внимательно изучите данное руководство и настройте PostgreSQL, опираясь на эту информацию.

RAM -- размер памяти

* shared_buffers = 1/8 RAM или больше (но не более 1/4);

* work_mem в 1/20 RAM;

* maintenance_work_mem в 1/4;

* max_fsm_relations в планируемое кол-во таблиц в базах * 1.5;

* max_fsm_pages в max_fsm_relations * 2000;

* fsync = true;

* wal_sync_method = fdatasync;

* commit_delay = от 10 до 100 ;

* commit_siblings = от 5 до 10;

* effective_cache_size = 0.9 от значения cached, которое показывает free;

* random_page_cost = 2 для быстрых cpu, 4 для медленных;

* cpu_tuple_cost = 0.001 для быстрых cpu, 0.01 для медленных;

* cpu_index_tuple_cost = 0.0005 для быстрых cpu, 0.005 для медленных;

* autovacuum = on

* autovacuum_vacuum_threshold = 1800

* autovacuum_analyze_threshold = 900

Обслуживание базы

При первом запуске базы, после заливки данных, необходимо сделать ANALYZE для всей базы.

VACUUM выполняется автоматически, в соответствии с настройками в файле конфигурации.

VACUUM FULL выполнять не обязательно при правильно настроенном автовакууме.

Диски и файловые системы

Если в вашем сервере есть несколько физических дисков, то вы можете разнести файлы базы данных и журнал транзакций по разным дискам:

Остановите сервер.
Перенесите каталоги pg_clog и pg_xlog, находящийся в каталоге с базами данных, на другой диск.
Создайте на старом месте символическую ссылку.
Запустите сервер.