NewBie77,
Начнём с ядра. Я смотрю на вывод:
1.
2.
cat /sys/kernel/mm/transparent_hugepage/enabled
sysctl -a|egrep '^vm.(dirty|swap|over)'
Параметры `vm.overcommit_memory = 2` и `vm.swappiness=0` можно прописать в /etc/sysctl.conf, vm.dirty% там же (советую почитать про эти параметры детальней).
“Прозрачные гигантские страницы” выключаются как-то так:
1.
2.
3.
echo >> /etc/rc.local
echo "# Stop using Transparent Huge Pages (THP)" >> /etc/rc.local
echo "echo never > /sys/kernel/mm/transparent_hugepage/enabled" >> /etc/rc.local
Теперь база. Для 20Гб я бы начал с `shared_buffers=2GB`, не больше. Тут несколько причин:
весь ввод-вывод идёт
только через шареные буфера
Postgres работает через кэш операционки, поэтому горячие данные будут в кэше (либо там, либо тут) в любом случае
Если у вас высокая пишущая нагрузка, то в кэше очень быстро накапливаются грязные станицы. Это приводит к: (1) более интенсивным контрольным точкам, (2) читающие сессии могут тормозить, ибо вынуждены сбрасывать грязные страницы из кэша
Проще заставить писателей конкурировать за "холодную" часть кэша и пистаь на диск грязные страницы.
Я предпочитаю дать базе меншье шаренных буферов, нежели отдать "как можно больше" — так меньше шансов схлопотать "затыки", когда система "внезапно" блокируется на IO. Понятно, что решение основывается на нагрузочных тестах. (Кстати, тут подход "как в ORACLE" не работает, совсем.)
Независимо от размера шареных буферов, я настраиваю bgwriter как можно более аггресивно и растягиваю чекпойнты:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
alter system set bgwriter_delay = '100ms';
alter system set bgwriter_lru_maxpages = 1000;
alter system set bgwriter_lru_multiplier = 4;
alter system set wal_level to 'hot_standby';
alter system set wal_buffers to '16MB';
alter system set wal_log_hints = on;
alter system set checkpoint_segments to 64;
alter system set checkpoint_timeout to '15min';
alter system set checkpoint_completion_target to 0.8;
Обязательно аггресивный autovacuum и логгирование:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
alter system set log_destination = 'csvlog';
alter system set logging_collector = on;
alter system set log_checkpoints = on;
alter system set log_connections = on;
alter system set log_disconnections = on;
alter system set log_lock_waits = on;
alter system set log_temp_files = 0;
alter system set log_min_duration_statement = 100;
alter system set log_min_messages = 'info';
alter system set log_min_error_statement = 'warning';
alter system set log_filename = 'postgresql-%a.log';
alter system set log_truncate_on_rotation = 'on';
alter system set autovacuum = on;
alter system set autovacuum_max_workers = 20;
alter system set autovacuum_vacuum_scale_factor = 0.005;
alter system set autovacuum_analyze_scale_factor = 0.02;
alter system set log_autovacuum_min_duration = 1000;
И ещё, про память:
`maintenance_work_mem` требуется (у меня) в основном при создании индексов, что нечасто. Ставлю в 1GB.
`autovacuum_work_mem` ставлю так, чтобы autovacuum_max_workers * autovacuum_work_mem оставляло бы достаточно памяти для нормальной работы базы, и в тоже время позволяло бы не тормозить на больших таблицах.
`effective_cache_size` не сильно влияет, потому ставлю в 80% от реально свободной памяти (free -m) для системы, проработавшей какое-то время.
`work_mem` показывает сколько памяти может съесть каждый
узел в плане. Т.е. если у вас сложный запрос с хэшами и сортировками, то этот параметр можно умножать на 5,7,... — по потребности (понятно, что это для
каждой сессии ). Соответственно, если держать его "высоко", то можно легко уйти в своп. Параметр планировщика, т.е. на этапе планирования выбирается либо более долгий алгоритм, работающий с диском (временные файлы), либо более шустрый, но жадный до памяти. При исполнении запроса переключения на что-то другое не произойдёт (не реализовано совсем).
Этот параметр самый "опасный" что-ли. И т.к. он пользовательского контекста (можно в сессии поменять), то я держу его на 6MB и выкручиваю по необходимости для индивидуальных запросов.
Обязательно настраиваю мониторинг, чтобы видеть дисковую нагрузку, нагрузку от контрольных точек и bgwriter-а. Анализирую логи и самые проблемные (индивидуально и суммарно) запросы, правлю настройки соответственно.
Тюнерами не пользуюсь. Предпочитаю делать так для новых систем:
настраиваю логи, bgwriter, checkpoint'ы и autovacuum как выше
собираю анамнез несколько типичных дней
правлю память по необходимости.
Настройка базы (особенно в случае Postgres'а) требует настройки также ОСи, поэтому надо ещё и в железе, и в ОСи разбираться. Или сисадминов привлекать...
