Конфликты при закреплении блоков (BufferPin) в PostgreSQL
Ожидания получения BufferPin включают в себя: 1) Конфликты BufferPin на репликах (recovery conflict). Процесс на реплике startup должен получить блокировку на буфер, чтобы проиграть (replay, apply, накатить журнальную запись) hotcleanup, для этого startup должен дождаться pincount=0. Быстрая очистка происходит часто и процесс startup, если столкнется с блокировкой, полностью приостановит накат. Накатом занимается только он и в один поток. Из-за частых ожиданий BufferPin отставание реплики растёт и кажется, что startup не справляется и кажется, что проблема в том, что он однопоточный. Мониторинг таких ситуаций затруднён, так как в представлении pg_stat_database_conflicts отражаются только конфликты, которые привели к прерыванию запросов на реплике, то есть, когда startup приостанавливал работу более, чем на max_standby_streaming_delay (по умолчению, 30 секунд): Из-за таких конфликтов, используют реплику, которая не обслуживает запросы, чтобы она не отставала из-за конфликтов и на реплику можно было быстро переключиться. 2) конфликты с автовакуумом при заморозке страниц. Такие конфликты есть и на мастере и на реплике и начинаются через 100 миллионов транзакций (по умолчанию, до 18 версии PostgreSQL). При недолгих тестированиях приложений не отлавливаются, проблемы начинаются при эксплуатации. Это одна из причин, по которой нагрузочные тесты длятся долго. Зная, как работает PostgreSQL, можно использовать недолгие тесты и оптимизировать приложение и параметры экземпляра, используя результаты недолгих тестов для обратной связи при настройке.
https://habr.com/ru/articles/1025254/
#postgres #postgresql #постгрес #блокировки #автовакуумирование #вакуум
