Классическая ситуация: в часы пик база данных захлебывается, CPU загружен на 100%, диски простаивают, а в топе запросов висит "мелочь". Привычный мониторинг бессилен: ни долгих транзакций, ни тяжелых выборок, ни очевидных блокировок. Истинная причина просадки остается невидимой

Иногда виновником оказываются "горячие блоки". Проблема возникает, когда множество процессов одновременно конкурируют за доступ к одному и тому же блоку. Данные находятся в кэше и читаются быстро, но механизмы защиты памяти не рассчитаны на такой ажиотаж. В итоге время тратится не на полезную работу, а на борьбу за право доступа к странице. Стандартные инструменты Postgres не позволяют локализовать проблему до конкретного объекта базы данных, ставшего узким горлышком.

В этом докладе я расскажу: 1. Как возникают "горячие блоки" и почему стандартный мониторинг слеп к этой проблеме; 2. Как я написала собственное расширение, чтобы заглянуть "под капот" базы и увидеть скрытую механику работы с памятью; 3. Как найти таблицу-виновника за пару минут и спасти производительность.