PostgreSQL memory usage issue

Ситуация следующая:

имеется проблема с регулярном ростом свопа на серверах Unix

Параметры PostgreSQL следующие :

select version ();
version
-------------------------------------------------------------------------------------------------------
PostgreSQL 9.2.8 on x86_64-unknown-linux-gnu, compiled by gcc-4.4.real (Debian 4.4.5-8) 4.4.5, 64-bit

select name,setting,unit,short_desc from pg_settings where name IN ('shared_buffers', 'work_mem', 'maintenance_work_mem' , 'effective_cache_size' );

name | setting | unit | short_desc
----------------------+---------+------+-----------------------------------------------------------------
effective_cache_size | 786432 | 8kB | Sets the planner's assumption about the size of the disk cache.
maintenance_work_mem | 16384 | kB | Sets the maximum memory to be used for maintenance operations.
shared_buffers | 262144 | 8kB | Sets the number of shared memory buffers used by the server.
work_mem | 16384 | kB | Sets the maximum memory to be used for query workspaces.

select count( pid ) from pg_stat_activity;
count
-------
246

Подозреваю , что проблема не в БД а на стороне приложения.

Но как это обосновать и что проверить со стороны PostgreSQL , просьба подсказать.

Спасибо.

rinace,

а сколько всего памяти и какой прописан max_connections? pgbouncer не используется?

Всего памяти 16GB
max_connecttions = 600
pgbouncer не используется

вообще , пытаюсь найти способы , как посмотреть сколько вообще памяти использует PostgreSQL
но пока кроме
http://www.depesz.com/2012/06/09/how-much-ram-is-postgresql-using/
ничего внятного для себя , не нашел

rinace,

max_connections = 600
work_mem = 16MB

означают, что 9.6GB могут быть использованы под “рабочую память” сессиями. Это минимум, т.к. `work_mem` ограничивает память не для всего запроса, а для операции. Т.е. если в плане будет HashAgg с последующей Sort — то будет использовано до 32MB одним запросом.

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

Рекомендации:
- понизить `work_mem` в postgresql.conf
- явным образом увеличивать его для больших запросов (параметр можно изменить для текущей сессии)
- начать использовать pgbouncer (или любой другой пулер) + понизить max_connections

vyegorov,

Спасибо за информацию.
Копаю в этом направлении.

По поводу :
- понизить `work_mem` в postgresql.conf

Вопрос в том, как определить насколько уменьшить ?

Мне пока видится только последовательно уменьшать work_mem и изменить log_temp_files=новый размер и контролировать влияние на performance и смотреть лог файл.

Явное увеличение work_mem в сессии и использование pgbouncer это в чуть более отдаленной перспективе. Не уверен , что клиент на это пойдет.

rinace
По поводу : - понизить `work_mem` в postgresql.conf Вопрос в том, как определить насколько уменьшить ?

Тут я не могу помочь удаленно. Есть статистика по:
- кол-ву открытых сессий в момент когда система уходит в своп?
- потреблению памяти другими службами (мало ли, апач или жава работает на том же сервере)?

Я бы от общего объема отнял бы:
- 1GB на системные нужды
- `shared_buffers` (очевидно)
- потребляемую сторонним совтом память.

И остаток поделил бы на кол-во активных +25 сессий. Думаю должно получиться что-то в районе 8MB.

Логи обычно настраиваю (без подкрутки) так:

 log_autovacuum_min_duration  | 5s
 log_checkpoints              | on
 log_connections              | on
 log_destination              | csvlog
 log_disconnections           | on
 log_file_mode                | 0640
 log_filename                 | postgresql-%Y-%m-%d_%H%M%S.log
 log_line_prefix              | %u:%d:%a:%h:%c:%x:%t>
 log_lock_waits               | on
 log_min_duration_statement   | 500ms
 log_rotation_age             | 1d
 log_rotation_size            | 0
 log_temp_files               | 0

По ходу работы подкручиваю.

rinace
vyegorov, Вопрос в том, как определить насколько уменьшить ? Мне пока видится только последовательно уменьшать work_mem и изменить log_temp_files=новый размер и контролировать влияние на performance и смотреть лог файл. Явное увеличение work_mem в сессии и использование pgbouncer это в чуть более отдаленной перспективе. Не уверен , что клиент на это пойдет.

вполне хороший подход (log_temp_files можно только поменьше чем work_mem поставить или просто в 0).
ну и можно посмотреть какие запросы/процессы больше съедают/держат подключений и оптимизировать их, раз баунсер сложно поставить.

rinace

Ситуация следующая: имеется проблема с регулярном ростом свопа на серверах Unix Параметры PostgreSQL следующие : select version (); version ------------------------------------------------------------------------------------------------------- PostgreSQL 9.2.8 on x86_64-unknown-linux-gnu, compiled by gcc-4.4.real (Debian 4.4.5-8) 4.4.5, 64-bit select name,setting,unit,short_desc from pg_settings where name IN ('shared_buffers', 'work_mem', 'maintenance_work_mem' , 'effective_cache_size' ); name | setting | unit | short_desc ----------------------+---------+------+----------------------------------------------------------------- effective_cache_size | 786432 | 8kB | Sets the planner's assumption about the size of the disk cache. maintenance_work_mem | 16384 | kB | Sets the maximum memory to be used for maintenance operations. shared_buffers | 262144 | 8kB | Sets the number of shared memory buffers used by the server. work_mem | 16384 | kB | Sets the maximum memory to be used for query workspaces. select count( pid ) from pg_stat_activity; count ------- 246 Подозреваю , что проблема не в БД а на стороне приложения. Но как это обосновать и что проверить со стороны PostgreSQL , просьба подсказать. Спасибо.

линукс на больших обьемах памяти любит сваппится не по делу...
для начала vm.swappiness=0 поставьте а потом уже смотрите

--Maxim Boguk
www.postgresql-consulting.ru

Maxim Boguk
линукс на больших обьемах памяти любит сваппится не по делу... для начала vm.swappiness=0 поставьте а потом уже смотрите

Спасибо за подтверждение
Тоже приходим к аналогичному выводу

Alexius,

Видимо как один из путей подойдет. Спасибо за подтверждение.
Смотрел самые долгие запросы.
Памяти для сортировки используется наамного меньше чем указано в в work_mem
Видимо имеет смысл постепенно уменьшать этот параметр

Спасибо