PostgreSQL — формула оптимизации

Написал admin . Опубликовано в Databases просмотров 2 591

Так себеПойдетХорошоПонравилосьОтличный пост (1 votes, average: 5,00 out of 5)
Загрузка...

Среднестатистическая настройка для максимальной производительности.

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 включить
analyze treshhold = 900
vacuum treshhold = 1800

Если на сервере крутится еще что-то большое кроме PostgreSQL, то нужно
изменить effective_cache_size (например 1С рекомендует устанавливать
этот параметр в RAM/2).

Выключить fsync можно только при использовании аппаратного рейда с BBU — здорово прибавляет в производительности, но Вы должны полностью доверять железке.

Также в рекомендациях от 1С встречается «установить enable_nestloop = off»

Не стоит так делать. Как, впрочем, и использовать другие костыли, для
того, чтобы обмануть планировщик запросов PostgreSQL. Планировщик у
PostgreSQL значительно умнее среднестатистического администратора БД, и
в 99.9% случаев срабатывает корректно.

Если же он работает некорректно, то нужно настраивать в первую очередь
effective_cache_size, random_page_cost и cpu*_cost. Чем меньше значения
этих параметров, тем больше будут использоваться агрессивные планы с
использованием индексов.

Похожие статьи:

Метки: , , , , , ,

Trackback from your site.

Comments (1)

Leave a comment