Добрый день. Есть ли какой-то примерный порядок поиска источника ошибки

out of memory (куда копать)?
Сегодня начала падать ошибка сначала в запросе мониторинга select size, twice_used, dirty from mamonsu.buffer_cache() затем, буквально через пару минут, начали валиться самые разные запросы и так продолжалось в половине сессий из пула вплоть до рестарта БД. Возможно, какое-то из расширений течёт, но как выяснить, какое?
Ошибки в логах примерно такие:
TopMemoryContext: 354816 total in 12 blocks; 65144 free (230 chunks); 289672 used
... (детализация памяти)
Grand total: 85437656 bytes in 13128 blocks; 23729928 free (3503 chunks); 61707728 used
2022-04-05 14:59:44 MSK [15654]: [49-1] ERROR: out of memory
2022-04-05 14:59:44 MSK [15654]: [50-1] DETAIL: Failed on request of size 5064 in memory context "ExecutorState".
2022-04-05 14:59:44 MSK [15654]: [51-1] STATEMENT: ... (запросы падают самые разные)
Версия postgresql 12.10. Настройки БД примерно такие:
shared_buffers=6GB
work_mem=64MB;
shared_preload_libraries=pg_stat_statements, pg_wait_sampling;
Используемые расширения: btree_gin, btree_gist, dblink, lo, pg_background, pg_trgm, pgcrypto, plpgsql, plpgsql_check, plpython3u, tablefunc, pg_buffercache, pg_stat_statements, pg_wait_sampling
Всего на сервере 16Гб, в момент появления массовых ошибок, судя по мониторингу, на сервере оставалось доступно 4Гб.

cat /proc/sys/vm/overcommit_memory

2

ну вот и причина. попробуй 0 :)

Не надо такое советовать на СУБД.

эм… там всё как надо, собственно. если сделать 0, то придёт OOM и сложит всю базу

Воистину так!

Скорее всего, память сильно фрагментирована, при попытке выделись целым куском, ОС показывает СУБД кукиш. Соответственно, надо поиграться с huge pages (сам не игрался, деталей по этому не подскажу).

ЗЫ. Праздного интересу для вопрос: вот этот весь список - он реально необходим, или обсуждаемый инстанс - он для разработки и прочих поиграться?

Если вы про расширения, то: btree_gin, btree_gist, pgcrypto, lo, pg_background, pg_trgm, plpgsql, plpython3u - используются напрямую в проекте в той или иной степени plpgsql_check - нужна, чтобы не развернуть кривой код (настроен триггер, который проверяет код при create function) dblink, tablefunc - вот эти, наверное, относятся к устаревшему функционалу pg_buffercache, pg_stat_statements, pg_wait_sampling - ну а это мониторинг На разработческом инстансе еще пара расширения стоит (включая pldbgapi)

Для ликвидации безграмотности подскажите пожалуйста что такое фрагментация памяти и как ее измерить?

Возможно. Хотя ведь и сейчас базе и так приходит ошибка, хотя память ещё свободная есть. Какой может быть совет в данном случаи? Поднимать уровень оверкоммита?

сейчас обламывается один запрос. когда придёт OOM — сложится вся база (перезапуск с восстановлением из транзакционного лога от последней контрольной точки) надо смотреть на кол-во памяти, настройки и сам запрос

Это похоже на какоето преуменьшение проблемы. Человек пишет что 30 минут база просто лежала, и помог только рестарт. Откуда информация про один запрос? 🤔

а что значит “просто лежала”? если основные запросы падали с ошибкой, то могло выглядеть как отказ базы для приложения. а что происходило на сервере с базой? какие там, помимо самой базы, программы работают? как долго сессии в базе живут? что происходит в сессиях — есть ли курсоры? если ли prepared statement-ы? используются ли временные таблицы?

на сервере кроме СУБД только мониторинг и системные сервисы. Когда проблема началась, в htop процесс postgres: checkpointer занимал 38% памяти. БД, вроде, работала (мне кажется, простые запросы даже проходили, но запросы посложнее - нет). С БД работают около 10 разных пулов подключений, в каждом пуле в пределе может быть от 5 до 25 подключений (25 только в двух из них). idle-сессии из пулов прибиваются, но поддерживается минимум по 2-5 подключений, так что, в теории, могут быть сессии, живущие по много дней. Явно объявленные курсоры не используются. Prepared statement-ы могут создаваться (вроде, jdbc-драйвер их создаёт только после пары запусков одинакового запроса). Да, есть несколько запросов с текстом длиннее 20кб (если это имеет значение)

Впервые слышу, что такое возможно. Ну, по идее: фрагмениацыя до отсутствия contiguous segment у 64 бит виртуальной памяти — просто невозможна. Неуспеть, да и не забить дажэ самыми маленькими сегментами. А фрагментацыю физической на 4к страницы — так их всегда можно перетасовать как угодно (дажэ вообще в своп выгрузить).

В момент — хорошо бы strace напустить на процэсс. Посмотреть, что он там не можэт — brk() иои mmap /dev/zero, или что-то ещё. Можэт, там open обламывается и дескрипторов нехватает! Плюс, лимиты процэсса посмотреть.