🩺 Диагностика — как понять, на что ушла оперативка (часть 2, work_mem наносит ответный удар)

👈 Часть инструментов рассмотрели в прошлом посте, а в этом рассмотрим ещё парочку:

🧰 Что лежит в кэше прямо сейчас
Расширение pg_buffercache (мы его уже видели в посте про shared_buffers) показывает поимённо, какие страницы заняли кэш Postgres в данный момент. Удобно, когда надо понять, чем именно забиты те самые 128 MB, выданные под shared_buffers

👥 Кто сейчас активен (дикпик 3)
Кроме shared_buffers можно проверить и work_mem, чтобы узнать, сколько соединений работает и что они выполняют. Это показывает представление pg_stat_activity: оно построчно показывает каждое соединение, и там видно текущий запрос от клиента (app) и его состояние. Дальше пользуемся арифметикой work_mem × число операций × число активных соединений, чтобы получить объём памяти, занятый данными для операций

Чтобы при этом явно понять, какой клиент выполняет запрос, важно передавать его читаемое название через строку подключения или в запросе, тогда его название отобразится в app 🧠

⚠️ Ловушка при подсчёте памяти процессов
Если помнишь, каждое соединение в Postgres обслуживает отдельный процесс. Казалось бы, сложи память всех процессов и получишь общий расход. Но есть подвох: shared_buffers общий, и операционная система засчитывает его в память каждого процесса. Этот объём называют RSS (resident set size — объём оперативки, занятый процессом). Если просто сложить RSS всех бэкендов, общий shared_buffers посчитается много раз, и итог окажется сильно завышенным. Для суммирования правильнее брать PSS (proportional set size): он делит общую память поровну между процессами, которые ею пользуются

🧯 Если work_mem чересчур раздут
Если арифметика подтвердит, что в основном память выделена под обработку запросов, рецепт простой: уменьшить work_mem, сократить число соединений, или поставить перед базой пулер соединений. Пулер (например, PgBouncer) — это прослойка, которая держит небольшой набор постоянных соединений к Postgres и раздаёт их клиентам, что позволяет избежать выделение процесса на подключение каждого клиента. А отдельному тяжёлому запросу можно задать work_mem прямо в нём командой SET LOCAL (она меняет параметр в пределах текущей транзакции).

🅰️ Что унести с собой
🟢 Состав кэша показывает pg_buffercache. Кто сейчас активен, видно в pg_stat_activity
🟢 Складывать RSS процессов не стоит: общий shared_buffers задвоится. Для суммы есть PSS

🧑‍💻dp🥁
#бд #postgresql #инженерныештучки #heavywednesday