Добрый день. Postgres меееедленно но верно отжирает память. PostgreSQL 15.4 (Ubuntu 15.4-2.pgdg22.04+1) Количество

коннектов не меняется, автовакуум не запускается.

Потребление памяти растет вот так (рис)

ps показывает что один и тоот же процесс постгресса со временем все больше и больше потребляет.

Потребляет именно постгрес.

Потом отжирается вся память ОС и приходится перезапускать постгрес.

Что это может быть?

Добрый день А что показывает select * from pg_stat_activity ?

показывает одни и те же 25 коннектов, в состоянии idle 99.99% времени.

А что за процесс? И как отожранная память и размер shared_buffers соотносятся?

Для начала — начните фиксировать потребление памяти в числах и по процэссам (как там — все жрут, один жрёт, некоторые жрут...). И по известным методикам (ну там, какая-то сумма из /proc или какой-то отчёт cgroups или что). Будет, как минимум, пища для размышлений.

Процессы postgres Память и shared_buffers соотносятся так, что при текущих настройках shared_buffers = 10% ОЗУ постгрес никак всю память отожрать не может в теории, но на практике съедает все.

Ну и как результат? Что за память отожрана? Сколько там в байтах? Это один процэсс или на каждого сколько-то приходится?

Результат так себе. Вот, процессы постгресса в формате: PID потребляемая_память название_процесса 1030 218996 postgres 19779 218996 postgres 1033 219132 postgres 1032 219380 postgres 19781 220556 postgres 19780 220572 postgres 33642 221076 postgres 33643 221076 postgres 33652 221076 postgres 33654 221076 postgres 33658 221076 postgres 33661 221076 postgres 33687 221076 postgres 33691 221076 postgres 19796 221144 postgres 19942 221144 postgres 20039 221144 postgres 19789 221216 postgres 1044 222136 postgres 33638 222364 postgres 33619 222480 postgres 1168 223508 postgres 20037 802356 postgres 19795 836428 postgres 19941 850968 postgres И то же самое через пол часа: 1030 218996 postgres 19779 218996 postgres 1033 219132 postgres 1032 219380 postgres 19781 220556 postgres 19780 220572 postgres 35703 220976 postgres 35397 221076 postgres 35398 221076 postgres 35402 221076 postgres 35403 221076 postgres 35429 221076 postgres 35433 221076 postgres 35458 221076 postgres 35471 221076 postgres 19796 221144 postgres 19942 221144 postgres 20039 221144 postgres 19789 221216 postgres 35396 222120 postgres 1044 222136 postgres 1168 223508 postgres 35360 228536 postgres 20037 830260 postgres 19795 873532 postgres 19941 877100 postgres это результат команды ps -e -o pid,vsz,comm= | sort -n -k 2 c grep postgres видно что три нижних процесса потребляют больше и больше памяти, у остальных потребление не меняется.

А что это за процессы? Обычные backends?

да, от приложения. работают с JSON. 99% времени idle

Боюсь не смогу подсказать. JSON велик и удивителен

т.е. он может отожрать памяти на 1 pid в 10 раз больше shared_buffers + work_mem ? ... по факту так (

Был тут такой фокус https://www.cybertec-postgresql.com/en/memory-context-for-postgresql-memory-management/ не знаю насколько будет информативен в вашем случае

читаю, спасибо. но пока проблема актуальна (

Так это и не решение - это понять в каком месте проблема

а клиент использует libpq? и какой клиент?

И shared_buffers 10% RAM? То есть у вас там два гига? Да, тогда бэкэнды по 800 метров — это сложно. Что жэ, начинайте смотреть, почему/после какого запроса он ест 800 метров. Это вполне можэт быть большое значение одно в запросе, которое требуется пепеложыть пару раз из тапла в тапл.

Да его и перекладывать не надо) так просто запросить пару

ОЗУ там 4 Гб. Меня пугает что отжирание не прекращается до падения сервера :(

Так это нормально

с чего это интересно нормально при work_mem = 4Mb и 25 коннектах?

1 work_mem на узел 2 результат запроса в памяти

Нет ограничения на память процесса подключенного в pg

В общем, заметил такую особенность. Делаю SELECT pg_log_backend_memory_contexts(pid); Для прожерливого процесса. И там куча записей: CachedPlan CachedPlanSource CachedPlanQuery Когда делаю для другого pid, который не жрет память - этих записей нет. Скажите, можно как-то отключить кэширование планов или ограничить хотябы? SELECT-ы там одинаковые, двух типов.

что же желать? ведь постгрес жрет в 1000 раз больше чем work_mem ((

А какая-нибудь разница в подключенных клиентах есть?

Запрос покажите из этих процессов

У нормального указан апликэйшн найм PostgreSQL JDBC Driver У прожерливого пусто.

А на самом деле кто там с клиентской стороны?

там только начало видно. SELECT id, value, MAX(CASE key WHEN 'fuel' THEN value2 END) AS name,..

Да все там должно быть

Ну, то 5сть эти бэкэнды выполняют одни запросы (процэдуры), а не эти — другие... Запретить кэш планов процэдур вроде можно, но, скорее всего, вопрос у вас совсем не в этом...

Да не могут кэш столько есть)))) там сами запросы должны быть интересными

А посмотрите ещ1 в эту сторону. Не знаю как там в современных джавах, но в 2016 похожие проблемы и на Оракле ловились https://habr.com/ru/articles/499794/

там 152 записи о кэшировании, каждая по 70Кб памяти примерно, итого больше 10Мб, при work_mem=Mb

10мб * 25 о чем вы волнуетесь?

А проблема у тебя в 500 МБ....

Записи о кэше только у прожерливых pid А там же не процедура, там запрос указан. Или этот запрос кусок процедуры?

Недавно перезапустил постгрес, пока 500Мб не отожрало, но отжирает потихоньку.

Вполне вероятно. Кэш планов идёт только для PREPARED запросов и для кода PL/pgSQL.

Сейчас 10Мб, через час 100Мб, через два упадет сервер.

Вы так запрос и не показали

что в логе было то и показал, больше там нет ничего - обрезается.

Потихоньку? Так заставь каждый час бэкэнды передёргивать... Не, твк-то ечть правильный метод – debug symbols, gdb, какой-нибудь malloc debugger... Но ты уверен, что хочешь этим занимать ся?

дело в том, что на версии 9.6 работало без проблем. а на днях обновились до 15-й и начались проблем с памятью.

А кэш можно сбросить только через pg_terminate_backend() сессии или как-то более гуманно можно, без обрыва коннекта?

vsz это не память, это размер адресного пространства процесса, а на него потом отображаются физическая память, выполняемые файлы и библотеки, можно и просто файлы через mmap подключить, они будут занимать vzs но не физическую память если вы хотите посмотреть сколько физической памяти подключено к адресному пространству процесса то надо смотреть rss, но rss не учитывает shared память (в частности shared_buffers) то есть её страницы будут дублироваться в счётчике rss у каждого процесса

rss - а как её посмотреть? в принципе pg_log_backend_memory_contexts показывает память процесса, и она больше в разы чем work_mem (

Она так и должна быть! Что вы к work_mem то привязались?

не, не должна вроде

в норме вывод ps в поле rss у idle процессов активно обслуживающих пользовательские сессии должен показывать ~ рамер shared_buffers + ещё N мегабайт на локальные кеши каталога и т.п.

а, получается вычесть из большего меньший, спасибо )

ну это норм, он же постепенно всё что в pg_catalog — грузит в память в кеши, по мере обращения

Work_mem память выделяемая для выполнения условно одного узла в плане запроса, можно написать запрос и на любое количество work_men почти