В чем причина того что PostgreSQL сильно нагружает процессор?

Question

[redduckrobot]

Есть сайт на Джанго, бд соответственно, в день чуть меньше 100 посетителей, хостинг vps у digitalocean (515). Не могу понять по какой причине PostgreSQL так сильно нагружает процессор, причем это происходит как по накоплению чего-то, вот сейчас ребутнул сервер и при заходе на сайт htop показывает нагрузку 1-3%, до ребута было 40+% за одно обращение. Поскольку сайт раньше падал из-за этого (PostgreSQL не хватало памяти и она отключалась), я внес настройки рекомендованные pgtune, сайт не падает, но дико виснет.
В логах PostgreSQL видно что не хватает памяти, но куда она девается я не могу понять и из-за чего.

2015-12-09 12:28:40 EST LOG:  could not fork autovacuum worker process: Cannot allocate memory

По логам nginx-access не вижу никаких особых нагрузок.

Вероятней всего это из-за моей не опытности, но я даже не могу понять как найти дырку, подскажите, пожалуйста, на что обратить внимание и как найти причину из-за которой возникает такая нагрузка?

htop в тихом состоянии:


htop siege -b -c 1 -r 1000 (аналогичный результат и для других проектов):

Transactions:                   1000 hits
Availability:                 100.00 %
Elapsed time:                  88.91 secs
Data transferred:               5.10 MB
Response time:                  0.09 secs
Transaction rate:              11.25 trans/sec
Throughput:                     0.06 MB/sec
Concurrency:                    1.00
Successful transactions:        1000
Failed transactions:               0
Longest transaction:            0.60
Shortest transaction:           0.06

Конфиг pg дефолтный, за исключением:

max_connections = 100
shared_buffers = 128GB
effective_cache_size = 384GB
work_mem = 1342177kB
maintenance_work_mem = 2GB
checkpoint_segments = 32
checkpoint_completion_target = 0.7
wal_buffers = 16MB
default_statistics_target = 100

Сейчас все работает нормально, когда оно еще раз выстелет я не знаю.

Answer 1

[romy4]

ну тут пальцем в небо потыкать можно будет долго
1. нагрузка на винт? проверить. свапинг
2. наличие ключей на полях
3. найти кто "ест" память

Answer 2

[Кирилл]

настройки постгреса выложите, что у вас там по памяти/диску/cpu ?
дайте pg_stat_bgwriter и pg_stat_database

Answer 3

[FeNUMe]

Проблема явно в коде или преждевременной бездумной оптимизации настроек бд. У меня есть аналогичный(Django+Postres9.1) проект на DO и ни разу похожих проблем не было за несколько лет.
Еще вариант что вас взломали и запустили какого-то зловреда нагружающего систему. В любом случае без логов, топа, конфигов определить что там у вас не так сложно.

Comments

[redduckrobot]

Добавил данные топа и конфиг pg.

[FeNUMe]

redduckrobot: вы правда не видите в конфиге постгреса проблемы? у вас в виртуалке 512 мегабайт оперативки, а вы постгресу выделяете память гигабайтами естественно все будет падать.
effective_cache_size = 384GB
work_mem = 1342177kB
maintenance_work_mem = 2GB
wal_buffers = 16MB
Закоментируйте эти строки вообще, чтобы подхватились значения по умолчанию. А в
shared_buffers начните с 32MB.

Ну а конкретно в htopе ведь видно что база проц не грузит, вся нагрузка идет от вашего приложения запущенного через uwsgi.

Answer 4

[Пума Тайланд]

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

Answer 5

[Артем Афонин]

Можно посмотреть в сторону large_page в sysctl, конфиг postgres.conf с его оптимизацией и разумеется VACUUM.

Answer 6

[neuronic]

1. Замените GB на MB в параметрах и измените work_mem, чтобы стало так:

shared_buffers = 128MB
effective_cache_size = 384MB
work_mem = 4MB
maintenance_work_mem = 32MB

Конкретно по ошибке из лога: VACUUM использует maintenance_work_mem параметр, а он у вас 2GB.
2. Также, по выводу htop видно, что в системе нет свопа. Cоздать своп.