Классическая ситуация: в часы пик база данных захлебывается, CPU загружен на 100%, диски простаивают, а в топе запросов висит «мелочь». Привычный мониторинг бессилен: ни долгих транзакций, ни тяжелых выборок, ни очевидных блокировок. Истинная причина просадки остается невидимой Иногда виновником оказываются «горячие блоки». Проблема возникает, когда множество процессов одновременно конкурируют за доступ к одному и тому же блоку. Данные находятся в кэше и читаются быстро, но механизмы защиты памяти не рассчитаны на такой ажиотаж. В итоге время тратится не на полезную работу, а на борьбу за право доступа к странице. Стандартные инструменты Postgres не позволяют локализовать проблему до конкретного объекта базы данных, ставшего узким горлышком. В этом докладе я расскажу: 1. Как возникают «горячие блоки» и почему стандартный мониторинг слеп к этой проблеме; 2. Как я написала собственное расширение, чтобы заглянуть «под капот» базы и увидеть скрытую механику работы с памятью; 3. Как найти таблицу-виновника за пару минут и спасти производительность.