Уже который раз сталкиваюсь со следующей проблемой, если postgres давать большие запросы (скажем >1мб), то при большом work_mem он начинает выжирать огромное количество памяти до окончания выполнения запроса(скажем при 128мб - 7гб, здесь и далее речь идет о колонке DATA+STACK, в принципе ее можно понять если внутри 100 join'ов например и \ или план неправильный). Более того даже после окончания выполнения запроса, 1гб в connection'е остается - видимо кэши планов, так как temp_buffers меньше 128 мб (кстати может кто знает что это еще может быть, и где смотреть?). Но вопрос не в этом.

Если звезды выстраиваются в линию и таких соединений становится много (пул соединений, для одновременно работающих пользователей \ процессов в нашем случае не вариант из-за временных таблиц например, отдельно обсуждалось), они могут потребить оперативной памяти больше чем есть, и здравствуй "активный" swap, а на медленном винчестере, это считай падение сервера. Раньше для зажравшихся соединений использовали OOM Killer, но ситуация тогда была еще хуже, так как во-первых, OOM Killer похоже убивал процессы kill -9, а это приводило к corruption'у shared buffer'ов, а во-вторых не использовался "пассивный" swap (плюс хоть и маленький, но шанс что "активный" swap будет не долгим есть).

Соответственно, вопросы:

а) Можно настроить OOM Killer, так чтобы он убивал процессы не kill -9, а сначала пробовал обычный kill, плюс (так как kill может потребовать времени ожидания) делал это не когда память закончилась, а когда она почти закончилась (то есть продолжал allocate'ить, но уже вызвав kill)
б) Можно ли как-то из приложения дать указания OOM Killer'у что такие-то connection'ы не трогать. Я в курсе что есть oom_adj_score, но это надо тогда например из java как-то обращаться к ОС, то есть делать системные вызовы, со всеми вытекающими. В смысле есть какое-то более менее элегантное решение для этого.
в) Ну и то что было в начале DATA+STACK 1гб у процесса-соединения что может занимать?

Maxim BogukNitro_Junkie,

А какой у вас размер shared_buffers стоит? Так как те страницы из shared buffers которые были зацеплены процессом Backend тоже считаются его DATA.
У меня есть сервера где 500 коннектов и каждый из них типа занимает 200GB памяти (так как они живут черт знает сколько и успели все страницы из shared buffers зацепить).


--
Maxim Boguk
www.postgresql-consulting.ru


shared_buffers большой - гигов 12, но он по идее в SHR попадает, во всяком случае у большинства connection'ов DATA метров 40, и SHR под несколько гигов, только вот у таких "зажравшихся" (кому достались мегабайтные запросы) connection'ов DATA под гиг.

tadminNitro_Junkie в нашем случае не вариант из-за временных таблиц
Вы так и не собрались за три месяца сделать общую таблицу с кешом для хранения временных данных клиентов?
А могли бы спокойно переехать за pgBouncer..

Там огромное количество таблиц, плюс что-то мне подсказывает что хранение временных данных в общей таблице дает очень неслабый оверхед, чисто на отборах по пользователю...

qwwqиндексы, начинающиеся с пользователя

Ну пробег и поддержку индексов я и имел ввиду под оверхедом.

но ваша задача решается наверное как превентивный (до ООМ киллера) мониторинг сессий с говорением их пидам мягкого pg_terminate_backend . [не выгорит -- если пользуете обильно автономии dbi_link и прочее, где идет неявное ожидание возврата из "детских "--процессов]

Собственно так и предполагается сейчас делать. Но тут проблема в том что непонятно по какому критерию score'ить сессии, чтобы выделять "зажравшиеся". По хорошему это и лучше делать по DATA, RES-SHR, TIME+, но тогда опять таки надо обращаться к ОС, у самого постгреса непонятно где брать информацию о потребленной памяти :(

Maxim Boguk3)просто кроном стрелять раз в N минут M самых старых сессий по времени старта backend (M/N подобрать экспериментально)
или просто стрелять сессии старше 5 или 10 минут.

Ну это из сервера приложений надо делать, а то не очень весело закладывать в архитектуру возможность закрытия соединения в любой момент.

PS: какая версия базы у вас напомните? может просто обновится? там за последний год куча утечек памяти в разных местах устранена.


9.4 - одна из самых последних.


PPS: а приведите пример запроса и план этого мегабайтного запроса (просто для интереса)?


Он не в один форматтер (типа sqlformat.org) не влазит :( полотно будет жуткое.

qwwqNitro_Junkie а то не очень весело закладывать в архитектуру возможность закрытия соединения в любой момент.
а бывает иначе ?
правда--правда ?


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

А у вас приложение гарантирует, что при kill ЛЮБОГО процесса в ЛЮБОЙ момент, ВСЕГДА корректно продолжит работу? Хотя конечно если у вас там 3 какие-нибудь примитивные операции, у нас приложения на порядок сложнее...