Добрый день коллеги. Кто может подсказать по организации работы с

памятью в postgres.
Когда освобождается буфер work_mem и память возвращается в систему? По окончании запроса или по окончании сессии? И если есть ссылки на документацию или статью. Я к сожалению не нашел. В базе много idle соединений и интересует вопрос они держат work_mem или нет. Если нет то есть смысл считать исходя из количества активных сессий.

Да никогда. СУБД не должна возвращать свою память кому-то

Ну, это в идеале

По моему это касается shared_buffers?

Тут не понятно что значит никогда. Сессия закрылась а буфер висит в памяти OS? По факту это утечка памяти.

Это должно касаться всей памяти, используемой СУБД. Я не знаю как конкретно в PG, но в идеале любая СУБД должна брать на старте всю отведенную ей память и никогда не отдавать обратно. Во первых, некому, во вторых, её потом придётся брать обратно, а это время...

Висит, для следующей сессии...

Ещё раз, я не знаю точно как конкретно в PG с этой конкретной памятью, но в идеале должно быть так.

Обычно такая память , используемая клиентами, состоит из двух или больше частей, одна часть составляет структуры обслуживания самого соединения, она остаётся, остальная память обычно пере используется всеми клиентами СУБД, и не принадлежит конкретной сессии.

Есть 2 "типа памяти" shared_buffers (аналог в ORACLE SGA) она резервируется на всё время работы процесса СУБД. Есть динамическая work_mem (аналог в ORACLE - PGA) - она выделяется динамически на каждую сессию. Причем work_mem может использоваться многократно в зависимости от операций (соединения, сортировки). Если бы она не возвращалась - логичнее было бы так же как и shared_buffers резервировать при старте и на все время работы. Хотелось бы услышать комментарий кто точно знает как это работает или может прочитать в исходниках.

Каждое соединение это форк от основного процесса. При закрытии сессии процесс завершается. Что происходит с памятью? Если она передается другому процессу то в каком объеме? = work_mem или n*work_mem если он использоваться многократно например при нескольких операциях соединения.

Спроси в PG чате, там грамотно скажут.

Попробую и там. Спасибо. Если здесь есть кто знает - буду благодарен за ответ.

Но я бы хотел услышать зачем это тебе, принципиально

Да всегда. С чего это она не должна?! > Я не знаю как конкретно в PG, Возвращается. > но в идеале любая СУБД должна брать на старте всю отведенную ей память и никогда не отдавать обратно Почему это "идеал"? Вот, например, что делает другая СУБД (цитирую https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/server-memory-server-configuration-options?view=sql-server-ver15 ): "When SQL Server is using memory dynamically, it queries the system periodically to determine the amount of free memory. Maintaining this free memory prevents the operating system (OS) from paging. If less memory is free, SQL Server releases memory to the OS. " Т.е. тоже возвращает. > Во первых, некому Как это "некому" (всегда есть OS (и другие программы))?!

> Хотелось бы услышать комментарий кто точно знает как это работает Возвращается, естественно. Используется система memory contexts (это вид region based memory management, если что). > или может прочитать в исходниках Описание: https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/utils/mmgr/README Реализация: https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/utils/mmgr/aset.c

Спасибо. Попробую разобраться

@lex_sey , вот Ярослав у нас большой спец по PG !

Потому что ОС и СУБД - антагонисты, должна работать либо ОС, либо СУБД, в идеале, в худшем случае СУБД под ОС (это к сожалению самый распространённой случай). Но ни в коем случае никаких больше "приложений"...

> Потому что ОС и СУБД - антагонисты, должна работать либо ОС, либо СУБД Ну уж нет. Вы видели, что считают разработчики по крайней мере двух "крупных" СУБД по поводу выделения памяти? Как Вы объясните этот факт? > в идеале, в худшем случае СУБД под ОС (это к сожалению самый распространённой случай). Сейчас этой дурью уже почти никто не мается, нет? ;) > Но ни в коем случае никаких больше "приложений"... А на практике чаще всего бывает иначе (к сожалению, да). ;)

Да мне то что до того что они там думают?

А им что до того, что думают те, кто СУБД не разрабатывает, извините? ;) Сейчас уже никто не делает СУБД, которые работают "прямо на железе", нет? Т.е. аргументы какие-то есть в пользу этого утверждения?

Да, почти не делают...

Неужели кто-то до сих про делает RDBMS прямо на "железе" (просто любопытно)?!

Ну ИБМ же. Но оно уж разваливается...

У нас основная часть в облаке но самая нагруженная база на baremetal.

Разве IBM не использует Z/OS (или как оно там называется) повсеместно на своих mainframes (т.е. железа там и близко от СУБД нет, всегда есть слои трансляции)?

Не-не, речь совсем не об этом, а о том, что какая-то СУБД работает вообще без операционной системы.

IBM, разумеется. iSeries (как оно сейчас там называется, потомок AS/400) -- до сих пор делают.

Z/OS -- действительно не реляцыонная система, но iSeries -- это и не мэйнфреймы.

Кстати, под мэйнфрэймы z/os -- вроде тожэ не единственный вариант, там помнится как минимум их DTM мог на голом жэлезе вроде работать (а мог и на партицыи, понятно), была ещё куча каких-то старых наследников разного уровня мониторов -- но там вроде реляцыонных на жэлезе действительно не припомню.

А это именно RDBMS? Ну и ссылка есть (а то в этих так любимых IBM разных продуктах с почти одинаковыми названиями пойди разберись)?

Ну "раньше" много чего было, вопрос о современных.

SLIC IBM i during initial program load of the SLIC The SLIC consists of the code which implements the TIMI on top of the IBM Power architecture. In addition to containing most of the functionality typically associated with an operating system kernel, it is responsible for translating TIMI instructions into machine code, and it also implements some high level functionality which is exposed through the TIMI, such as IBM i's integrated relational database.[1] from https://en.wikipedia.org/wiki/IBM_i Ну да, есть нюанс, что в общем существует некоторый low-level уровень ("объекты" в памяти, "файлы"), который в общем доступен через SQL -- но с ограничениями. Например, файлы могут не журналироваться, а при доступе через SQL -- изменения в них обязательно пишутся в журнал, для транзакцыонности. Но система реально выстроена вокруг базы данных, и сейчас это ужэ большэ реляцыонная база данных, чем нет.

Да... продукты IBM — это какая-то альтернативная реальность, честное слово. ;) > Но система реально выстроена вокруг базы данных По документации больше похоже на то, что это такой "сплав" OS и СУБД. Спасибо!

я там порыскал про Терадата, но инфо почти нет, тоже.

Ну так вот до сих про есть, оказывается: https://t.me/dba_ru/146501