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 не выбирал жертву за тебя.

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

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