l
Yaroslav Schekin
По идее, нет — это же проблемы (и настройки) OS.
сделать 1 коннекшен, поставить воркмем 20мб и шаред кеши сделать по 100мб и тд почему бы и нет?
Size: a a a
2020 May 27
YS
work_mem, лимит на число коннекшенов, возможно shared кеши и еще что то
Не стоит воспринимать work_mem как что-то более "жёсткое", чем рекомендацию при планировании.
l
Yaroslav Schekin
Не стоит воспринимать work_mem как что-то более "жёсткое", чем рекомендацию при планировании.
он на диск начинает дампить, при превышении, нет?
(ну и понятно, что ворк мем не на запрос, а на одну операцию в запросе грубо говоря)
(ну и понятно, что ворк мем не на запрос, а на одну операцию в запросе грубо говоря)
b
Yaroslav Schekin
По идее, нет — это же проблемы (и настройки) OS.
Уже вроде бы у нас есть скрипт который ставит приоритет на киллы всем процессам, но изредка прилетает такой постгрес процесс который сжирает немеряно памяти и все равно киляется. Обычно этот же самый процесс к моменту килла уже наворотил огромную кучу, которую долго приходится разбирать при рековери.
Ð
он реально потребляет столько или течет?
VY
он на диск начинает дампить, при превышении, нет?
(ну и понятно, что ворк мем не на запрос, а на одну операцию в запросе грубо говоря)
(ну и понятно, что ворк мем не на запрос, а на одну операцию в запросе грубо говоря)
если вы дали больше чем есть — он будет рассчитывать (выбирать план, который работает с памятью) и, возможно, упадёт
если дали меньше, то запланирует доступ через диски
если дали меньше, то запланирует доступ через диски
VY
т.е. если дали больше, чем есть — может и пронесёт
YS
сделать 1 коннекшен, поставить воркмем 20мб и шаред кеши сделать по 100мб и тд почему бы и нет?
Насколько я помню, не так уж сложно случайно написать запросы, которые будут игнорировать настройки work_mem вообще.
Т.е. во-первых, work_mem — это рекомендация по максимальному использованию памяти одним node плана (т.е. если 60 таких node — используется 60x work_mem); во-вторых, иногда work_mem просто игнорируется, и память выделяется, и всё.
Т.е. во-первых, work_mem — это рекомендация по максимальному использованию памяти одним node плана (т.е. если 60 таких node — используется 60x work_mem); во-вторых, иногда work_mem просто игнорируется, и память выделяется, и всё.
l
если вы дали больше чем есть — он будет рассчитывать (выбирать план, который работает с памятью) и, возможно, упадёт
если дали меньше, то запланирует доступ через диски
если дали меньше, то запланирует доступ через диски
ну, это понятно. да
b
Ð
он реально потребляет столько или течет?
А вот кстати неизвестно, будем позже разбираться.
Насчет свопа я думаю это оч плохая идея, из-за походов на диски просто встанет все на месте и все равно сдохнет.
Насчет свопа я думаю это оч плохая идея, из-за походов на диски просто встанет все на месте и все равно сдохнет.
l
Yaroslav Schekin
Насколько я помню, не так уж сложно случайно написать запросы, которые будут игнорировать настройки work_mem вообще.
Т.е. во-первых, work_mem — это рекомендация по максимальному использованию памяти одним node плана (т.е. если 60 таких node — используется 60x work_mem); во-вторых, иногда work_mem просто игнорируется, и память выделяется, и всё.
Т.е. во-первых, work_mem — это рекомендация по максимальному использованию памяти одним node плана (т.е. если 60 таких node — используется 60x work_mem); во-вторых, иногда work_mem просто игнорируется, и память выделяется, и всё.
а вот про игнор work_mem я не натыкался
Ð
А вот кстати неизвестно, будем позже разбираться.
Насчет свопа я думаю это оч плохая идея, из-за походов на диски просто встанет все на месте и все равно сдохнет.
Насчет свопа я думаю это оч плохая идея, из-за походов на диски просто встанет все на месте и все равно сдохнет.
да вот просто у меня пару мес назад это было при переезде на 12
VY
А вот кстати неизвестно, будем позже разбираться.
Насчет свопа я думаю это оч плохая идея, из-за походов на диски просто встанет все на месте и все равно сдохнет.
Насчет свопа я думаю это оч плохая идея, из-за походов на диски просто встанет все на месте и все равно сдохнет.
это хорошая идея. лучше затормозиться, чем база схлопнется по OOM, и потом уйдёт в replay после крэша на сколько-то минут
b
Ð
да вот просто у меня пару мес назад это было при переезде на 12
у вас чекпоинтер не висел во время килла?
YS
Уже вроде бы у нас есть скрипт который ставит приоритет на киллы всем процессам, но изредка прилетает такой постгрес процесс который сжирает немеряно памяти и все равно киляется. Обычно этот же самый процесс к моменту килла уже наворотил огромную кучу, которую долго приходится разбирать при рековери.
Отключите overcommit в OS, рассчитайте потребление памяти, поставьте соответствующие настройки — это практически исключает "самодеятельность" OOM killer, по идее. Т.е. если что, конкретный запрос получит error "out of memory", что гораздо приятнее, чем "падение" всего сервера PostgreSQL, IMHO. :)
Ð
Ð
[Jan28 00:31] node invoked oom-killer: gfp_mask=0x14200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null), order=0, oom_score_adj=0
[ +0.000002] oom_kill_process+0x21f/0x420
[ +0.000000] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
[ +0.221529] postgres invoked oom-killer: gfp_mask=0x14200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null), order=0, oom_score_adj=0
[ +0.000002] oom_kill_process+0x21f/0x420
[ +0.000001] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
[ +0.059692] oom_reaper: reaped process 833 (postgres), now anon-rss:0kB, file-rss:0kB, shmem-rss:10168412kBвот тут обсуждали
Ð
в итоге вылечил
b
Ð
вот тут обсуждали
Вот такое в логе нашел:
kernel: [41806532.140786] Call Trace:
kernel: [41806532.140807] dump_stack+0x63/0x8b
kernel: [41806532.140815] dump_header+0x71/0x285
kernel: [41806532.140822] oom_kill_process+0x220/0x440
kernel: [41806532.140824] out_of_memory+0x2d1/0x4f0
kernel: [41806532.140828] __alloc_pages_slowpath+0xa61/0xe20
kernel: [41806532.140832] __alloc_pages_nodemask+0x263/0x280
kernel: [41806532.140841] alloc_pages_current+0x6a/0xe0
kernel: [41806532.140844] __page_cache_alloc+0x81/0xa0
kernel: [41806532.140847] filemap_fault+0x378/0x6f0
kernel: [41806532.140851] ? page_add_file_rmap+0x5b/0x180
kernel: [41806532.140853] ? filemap_map_pages+0x36c/0x390
kernel: [41806532.140862] ext4_filemap_fault+0x31/0x44
kernel: [41806532.140866] __do_fault+0x24/0xf0
kernel: [41806532.140869] handle_pte_fault+0x883/0xd30
kernel: [41806532.140871] __handle_mm_fault+0x478/0x5c0
kernel: [41806532.140874] handle_mm_fault+0xb1/0x1f0
kernel: [41806532.140884] __do_page_fault+0x250/0x4d0
kernel: [41806532.140887] do_page_fault+0x2e/0xe0
kernel: [41806532.140890] ? page_fault+0x2f/0x50
kernel: [41806532.140892] page_fault+0x45/0x50
Ð
я не силен в этих дампах, но обновление и удаление всех лишних модулей из контриба его вылечило
YS
а вот про игнор work_mem я не натыкался
Вот пример:
И пояснение (всё © RhodiumToad):
Hashaggregate currently has no way to spill to disk. Hashagg won't be planned if the estimated hashtable size exceeds work_mem,
but at runtime, it'll blow past work_mem and use as much memory as it needs.
xid is a useful built-in example of a non-sortable type for sortable types, the query will usually use a sort and therefore be subject to
work_mem limits. But xid can only be grouped by hashing, so it forces a hashagg plan regardless of work_mem. So the query will try and create a hashtable with a billion entries each of which includes an array build state.
SELECT x, COUNT(x), array_agg(x)
FROM (
SELECT ((i << 20) | (j << 10) | k)::text::xid AS x
FROM generate_series(0,1023) AS i,
generate_series(0,1023) AS j,
generate_series(0,1023) AS k
) s
GROUP BY x;
И пояснение (всё © RhodiumToad):
Hashaggregate currently has no way to spill to disk. Hashagg won't be planned if the estimated hashtable size exceeds work_mem,
but at runtime, it'll blow past work_mem and use as much memory as it needs.
xid is a useful built-in example of a non-sortable type for sortable types, the query will usually use a sort and therefore be subject to
work_mem limits. But xid can only be grouped by hashing, so it forces a hashagg plan regardless of work_mem. So the query will try and create a hashtable with a billion entries each of which includes an array build state.