postgres убивает oom killer на 8гб, как прикинуть shared_buffers

Добрый день. Не DBA, но доки читал, поэтому не совсем с нуля. Ситуация: на сервере (8 гб) крутится postgres + n8n + пара мелких сервисов. Под нагрузкой postgres падает, в dmesg классическое:

Out of memory: Killed process (postgres)
oom-kill: ... total-vm:... anon-rss:...

Я, кажется, сам виноват: выкрутил shared_buffers в 4гб «чтоб быстрее», начитавшись, что это кэш. Но сервер не пустой, там ещё n8n живёт. Как правильно прикинуть shared_buffers и work_mem, когда база не одна на сервере? И правда ли, что shared_buffers больше четверти памяти на маленьком сервере смысла не имеет?

mike_pg 4 гб shared_buffers на 8 гб сервере, где ещё n8n — вот тебе и oom, ты просто отдал половину ram под кэш postgres и не оставил на всё остальное + на work_mem, который умножается на каждое соединение. прикидка:

• shared_buffers ~25% ram, но на общем сервере я бы взял меньше: 1-1.5 гб
  
• work_mem — это НА каждое соединение и на сортировку, 64мб × 50 конектов = 3.2 гб внезапно. держи 16-32мб, не больше
  
• effective_cache_size — не выделяет память, это подсказка планировщику, ставь ~50% ram
  

и оставь ram на n8n и систему. на 8 гб с соседями postgres надо ужимать, а не разгонять. точные числа nesterov лучше скажет, он на этом собаку съел.

mike_pg если postgres и n8n в докере — поставь им ещё и mem_limit в compose, чтобы один не съедал всё и не подставлял соседа под oom. а то ты shared_buffers починишь, а какой-нибудь workflow в n8n тебе память сожрёт и убьёт опять postgres. лимиты — это не «на всякий», это чтобы oom killer не выбирал жертву за тебя.

Апдейт по треду, вдруг кто с тем же придёт: после ужатия shared_buffers и work_mem держится сутки под той же нагрузкой, oom не приходил. Ключевым оказался work_mem × соединения, я реально не понимал, что он на каждый конект. n8n держал десятки конектов, вот и множилось.

mike_pg gleb_tomsk числа дал верные, добавлю по сути. на сервере, где база не одна, postgres надо не «разгонять», а вписывать в остаток. 1 гб shared_buffers, work_mem 16 мб, и смотри реально по нагрузке, а не по статьям «как ускорить postgres», их писали под выделенный сервер.
и раз уж вы про базу: shared_buffers вы подкрутите, а pg_dump по расписанию есть? oom killer сегодня убил процесс, завтра диск, послезавтра вы сами не туда. дамп в другое место и раз в месяц развернуть его на пустую директорию — это то, что спасает, а не тюнинг буферов. базу без проверенного дампа тюнить рано.

mike_pg хорошо. и раз конектов от n8n много — поставь пул (pgbouncer или пул в самом n8n), чтобы не плодить прямые соединения к postgres. меньше конектов — меньше суммарный work_mem и стабильнее. это следующий шаг, когда захочешь не «терпит», а «с запасом».

gleb_tomsk спасибо, про work_mem × соединения я не подумал вообще, у меня как раз конектов много от n8n — вот оно. Ужал shared_buffers до 1 гб, work_mem 24мб, effective_cache_size поднял — под той же нагрузкой oom пока не приходил. kate_ekb mem_limit в compose добавил, логично. nesterov pg_dump по cron настроил ещё вчера, а вот «развернуть на пустую и проверить» не делал — сделаю в выходные, справедливо.

mike_pg и mem_limit контейнерам всё же поставь, если ещё не. пул убрал причину, но лимит — это чтоб один сервис не утащил соседей, когда что-то пойдёт не так. пояс и подтяжки, как pavel_63 любит.

nesterov pgbouncer поставил, конекты к базе упали в разы, память успокоилась совсем. Теперь понятно, почему «маленькая база, а память ест» — дело было в куче прямых соединений, а не в объёме данных. Спасибо, дописал себе в заметки: сначала пул, потом уже думать про тюнинг буферов.