В теории память отжираемаемая постгресом складывается из shared_buffers и количество_коннектов * work_mem.

Поправьте если ошибаюсь..



Так вот при ворк мем = 8Мб, шаред буферс = 256Мб и колличестве коннектов около 200, каким образом постгес умудряется отожрать 12 Гб оперативки? о_О

в теории ведь около двух Гб отъести должен только.

Maxim Bogukппамять,

И в 255 раз отвечаем на этот вопрос. Вы неверно смотрите на потребляемую память.
Большинство тулзов покажет shared как кусок КАЖДОГО из процессов postgres так что в теории вы можете увидеть таким образом до 200*256MB + 200 * 8Mb = до 51Gb. А занята будет пара гигабайт.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru



Ну смотрите, даже в Task Manager процессы постгрес в Memory (Private Working Set) (да и в других тоже) показывает разное количество памяти, почти от 0 до 12 Мб, все разные.

А в Peak Working Set (Memory) даже до 1 Гб.


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

Maxim Bogukппамять,

И в 255 раз отвечаем на этот вопрос. Вы неверно смотрите на потребляемую память.
Большинство тулзов покажет shared как кусок КАЖДОГО из процессов postgres так что в теории вы можете увидеть таким образом до 200*256MB + 200 * 8Mb = до 51Gb. А занята будет пара гигабайт.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru



А, т.е. в памяти может показать от 8Мб до 256+8Мб.

Но показывает ведь меньше.

может быть есть статья какая-нибудь про память на винде? Я ничего толкового не нашел - все по линуксу.

vyegorovппамять,

`work_mem` он не для соединения, а для узла в плане запроса . Если у вас развесистые запросы, то каждый из них может кушать по несколько `work_mem`. Также имеется другая часть приватной памяти, в которой сидит кэш системного каталога, разобранные запросы и т.д.


Т.е. один коннект может употребить два и более work_mem из оперативной памяти? (не с диска)


Про другую часть приватной памяти -это шаред буфер вы имеете ввиду?

Maxim Boguk, vyegorov буду очень благодарен, если скажите где написано что work_mem может потреблять больше операитвной памяти (не с диска) если ему не хватает. Я всегда думал что при нехватке просто темповые файлы создаются чтобы обеспечить выполнение запроса.

Просто тут с памятью серьезные траблы и непонятки

Maxim BogukппамятьMaxim Boguk, vyegorov буду очень благодарен, если скажите где написано что work_mem может потреблять больше операитвной памяти (не с диска) если ему не хватает. Я всегда думал что при нехватке просто темповые файлы создаются чтобы обеспечить выполнение запроса.

Просто тут с памятью серьезные траблы и непонятки




Я очень давно не видел проблем на нормальном оборудование с памятью для PG в нормальных условиях (нормальные - выделенный сервер исключительно под базу с 64+Gb и не тысячи коннектов и разумная настройка).

Идем прямо в доку https://www.postgresql.org/docs/9.4/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-MEMORY и читаем:
work_mem (integer)

Specifies the amount of memory to be used by internal sort operations and hash tables before writing to temporary disk files. The value defaults to four megabytes (4MB). Note that for a complex query, several sort or hash operations might be running in parallel; each operation will be allowed to use as much memory as this value specifies before it starts to write data into temporary files.

(но это "использование более чем work_mem памяти" если не OLAP типа задачи - случай весьма редкий).

PS: не используйте винду в связке с PG на Production это до добра не доводит.

Так во временные файлы ведь пишется, а не оперативную память.



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

daevyппамятьMaxim Boguk, vyegorov буду очень благодарен, если скажите где написано что work_mem может потреблять больше операитвной памяти (не с диска) если ему не хватает. Я всегда думал что при нехватке просто темповые файлы создаются чтобы обеспечить выполнение запроса.

Просто тут с памятью серьезные траблы и непонятки




work_mem не потребляется больше чем определено в конфигах, -- а может выделяться на каждый узел плана если это потребуется. Условно запросу потребовалось сделать 5 сортировок , будет выделено 5 отдельных сегментов памяти равных work_mem. Но если данные для пятой сортировки не влезли в сегмент, то будет создан темповый файл на диске.
То есть нельзя создавать сегмент памяти больше чем work_mem, но можно создать несколько сегментов равных work_mem)))

But work_mem RAM can be allocated for each node of a query on each connection, all at the same time. -- отсюда https://wiki.postgresql.org/wiki/Number_Of_Database_Connections

Ого, круто!


Получается создасться еще один или несколько коннектов, которые в pg_stat_activity отдельными строками будут?

vyegorovппамятьЯ всегда думал что при нехватке просто темповые файлы создаются чтобы обеспечить выполнение запроса.
work_mem — это параметр планировщика . т.е. вы говорите: когда запрос будет работать, смело можно потреблять X мегабайт по необходимости. и если выбранный узел “влезает” в этот лимит, то будет использован алгоритм работы с памятью, если не влезает — планировщик выберет что-то другое, с временными файлами или менее прожорливое до памяти.
это всё ещё до передачи запроса executor-у.

если сделать `work_mem` большим, то база будет “брать” свои законные мегабайты.
неаккуратная настройка может увести систему в своп.

проще всего подобные проблемы смотреть в мониторинге — за CPU, RAM, SWAP и IO надо следить.


Получается что планы могут "поехать" при изменении work_mem, даже если не менять effective_cache_size ?

vyegorovппамятьПолучается создасться еще один или несколько коннектов, которые в pg_stat_activity отдельными строками будут?

Почему? если сложный запрос, в нём будет много узлов, каждый из которых может выделить себе до `work_mem` памяти (верхний предел). новые подключения не открываются.


Понял, спасибо.

А максимальное распарралеливание ведь настравивается где-то?

Maxim Bogukппамятьпропущено...



Понял, спасибо.

А максимальное распарралеливание ведь настравивается где-то?

Вы бы объяснили в чем у вас проблема то??? Скорее всего выяснится что она не там где вы думаете.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru


Проблема в том, что доступная память на сервере меееедленно выедается.

И потом приходится перезапускать постгре, иначе сервер совсем не шевелится

ппамять

вот так выглядит картина