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

Мы с тобой разобрались с shared_buffers, кэш ОС и work_mem. Теперь можем понять, если на сервере память забита под завязку (как на дикпике из графаны), проблема это или норма, и куда смотреть в первую очередь 👀

📊 Доля попаданий в кэш (дикпик 1)
Первый вопрос — насколько хорошо данные ложатся в память. По каждой базе Postgres в pg_stat_database (системное представление, содержащее накопленную статистику по каждой базе данных в кластере) содержит два счётчика: blks_hit (сколько страниц нашлись прямо в shared_buffers) и blks_read (сколько пришлось дочитывать мимо него). Их отношение hit / (hit + read) называют долей попаданий в кэш (по-английски cache hit ratio) 🔖

На прогретой базе эта доля стремится к 99% и выше. У меня после прогрева вышло около 97.84%, а сразу после рестарта она была заметно ниже, потому что кэш ещё пустой.

Если доля стабильно низкая, это сигнал: рабочий набор (та часть данных, к которой реально обращаются запросы) не помещается в память, либо запросы идут мимо индексов и вычитывают всё подряд 📖

🔎 Разрез по таблицам и индексам (дикпик 2)
Одно общее число по базе мало о чём говорит. Чтобы понять, что конкретно не попадает в кэш, есть два представления: pg_statio_user_tables (счётчики чтений и попаданий по каждой таблице) и pg_statio_user_indexes (то же самое по каждому индексу). В нём сразу видно, какая таблица или какой индекс постоянно бегает на диск 💽

🅰️ Что унести с собой
🟢 Доля попаданий из pg_stat_database показывает, помещаются ли данные в память. Если она стабильно низкая, это повод разбираться
🟢 Представление о таблицах и индексах в кэше дают... представления pg_statio_user_tables и pg_statio_user_indexes

Ещё пару инструментов рассмотрим в следующем посте 👉

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

🩺 Диагностика — как понять, на что ушла оперативка (часть 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