[Перевод] LWLock:LockManager, fastpath блокировки в PostgreSQL 18

В статье дан качественный тест, проявляющий проблему конкуренции за блокировки типа LockManager. В статьях @drema201 (АО "Гнивц") описываются интересные проблемы, возникающе при реальной эксплуатации и было упомянуто, что проблема решена в 18 версии PostgreSQL без описания того, как решена. Эта статья закрывает пробел. Начиная с 18 версии, проблема конкуренции LWLock:LockManager при выполнении запросов к большому числу таблиц, индексов, секций ("отношений") устранена. Также даётся ответ на вопрос: если fastpath блокировки хранятся отдельно для каждого процесса, как другие процессы проверяют наличие блокировок? В статье описано, почему блокировки по быстрому пути ( fastpath) так эффективны и почему новшества в PostgreSQL, появившиеся в 18 так важны на практике. При выполнении запроса SELECT к таблице PostgreSQL блокирует не только саму таблицу, но и ВСЕ её индексы с помощью Access Share ещё на этапе планирования. Все эти блокировки помещаются в разделяемую память и защищаются блокировками LWLock. На компьютерах с большим числом ядер, обслуживающих множество простых запросов (например, поиск по первичному ключу), серверные процессы постоянно конкурируют за один и тот же раздел структуры блокировок LWLock, которая находится в разделяемой памяти. Классическое узкое место.

https://habr.com/ru/articles/1003330/

#postgresql #lwlock #postgres #производительность #новшества

LWLock:LockManager, fastpath и всё-всё-всё

Общеизвестным является тезис о том, что от избыточного индексирования страдают только DML-операции, а SELECTы только получают разнообразные бенефиты. Однако существуют определённые нюансы, которые могут разрушить данную стройную картину мира. Я попробую продемонстрировать возможную проблему на тестовом примере (кстати, почти аналогичная проблема наблюдалась в реальной ПРОМ-системе).

https://habr.com/ru/companies/gnivc/articles/993938/

#postgresql #postgres #lwlock #производительность #базы_данных #data_bases #data_base #бд

О «залипании» процесса checkpoint и archive_timeout в Postgres

Добрый день, коллеги! Недавно мы столкнулись со следующей проблемой при тестировании СУБД PostgresPro под высокой нагрузкой: процесс представлял собой массированную многопоточную заливку данных на протяжении многих часов,а данных было около 20 ТБ, потоков — 75. В процессе загрузки наблюдалось следующее явление: через некоторое время процесс checkpointer переставал делать контрольные точки в зависимости от других параметров БД либо сразу, либо через 2-3 часа.

https://habr.com/ru/companies/gnivc/articles/945742/

#postgresql #lwlock #checkpoint #troubleshooting #sql #бд #базы_данных #постгрес

Когда может быть полезно сэмплирование в pg_stat_statements?

pg_stat_statements — стандартное расширение PostgreSQL для сбора статистики выполнения SQL-запросов. Статистика позволяет анализировать поведение запросов во времени, выявлять проблемные участки и принимать обоснованные решения по оптимизации. Однако в системах с высокой конкуренцией pg_stat_statements само по себе может стать узким местом и вызывать просадки производительности. В этой статье разбираем, в каких сценариях расширение становится источником проблем, как устроено сэмплирование и в каких случаях его применение позволяет снизить накладные расходы.

https://habr.com/ru/companies/tantor/articles/919592/

#postgresql #tantor_postgres #tantor #Семплирование #pg_stat_statements #LWLock