notes/pages/pg.txt

*****************************************
В PostgreSQL анализ статистики для мониторинга может быть выполнен с использованием различных инструментов и запросов к системным представлениям. Вот несколько шагов и примеров:

1. pg_stat_statements:

Включите расширение pg_stat_statements в вашей базе данных. Это расширение отслеживает выполнение SQL-запросов и предоставляет информацию о времени выполнения, количестве вызовов и т.д.:

Включение расширения (выполнить один раз)

CREATE EXTENSION pg_stat_statements;

Запрос для анализа

SELECT * FROM pg_stat_statements ORDER BY total_time DESC;

Этот запрос вернет список SQL-запросов, отсортированный по общему времени выполнения в порядке убывания.

📌 Посмотреть статистику времени выполнения запросов для конкретной базы данных:

SELECT * FROM pg_stat_statements WHERE dbid = (SELECT oid FROM pg_database WHERE datname = 'your_database_name');

Замените 'your_database_name' на имя вашей базы данных.

📌 Посмотреть статистику времени выполнения запросов для конкретного пользователя:

SELECT * FROM pg_stat_statements WHERE userid = (SELECT usesysid FROM pg_user WHERE usename = 'your_username');

Замените 'your_username' на имя пользователя.

📌 Посмотреть статистику времени выполнения запросов для конкретной сессии:

SELECT * FROM pg_stat_statements WHERE pg_backend_pid() = procpid;

Этот запрос вернет статистику выполнения запросов для текущей сессии. Обратите внимание, что pg_backend_pid() - это функция, возвращающая идентификатор процесса текущей сессии.

✅ Эти запросы предоставляют информацию о времени выполнения, количестве вызовов и других параметрах запросов. Вы можете адаптировать эти запросы в соответствии с вашими конкретными требованиями анализа и мониторинга.

2. pg_stat_bgwriter:

Данное представление предоставляет статистику по работе фонового процесса записи:

SELECT * FROM pg_stat_bgwriter;

3. pg_stat_database:

Это представление предоставляет статистику по использованию баз данных:

SELECT * FROM pg_stat_database;

4. pg_stat_user_tables:

Позволяет получить статистику по таблицам:

SELECT * FROM pg_stat_user_tables;

5. pg_stat_user_indexes:

Статистика по индексам:

SELECT * FROM pg_stat_user_indexes;

6. pg_locks:

Позволяет отслеживать текущие блокировки в базе данных:

SELECT * FROM pg_locks;

7. pg_stat_activity:

Дает информацию о текущих активных сессиях:

SELECT * FROM pg_stat_activity;

8. pg_stat_replication:

Если вы используете репликацию, этот запрос предоставит статистику по репликации:

SELECT * FROM pg_stat_replication;

✅ Эти запросы могут помочь вам мониторить производительность, выявлять узкие места и выявлять проблемы в вашей базе данных PostgreSQL. Помните, что регулярный мониторинг и анализ данных являются важной частью управления базой данных для обеспечения ее эффективной работы.

*****************************************
Смотрим контекст памяти в PostgreSQL.

Сначала давайте разберемся что вообще это такое - Контекст памяти. Как мы все прекрасно знаем, PostgreSQL написан на языке программирования C, а управление памятью в C непростая задача. Программа должна явно освободить всю динамически выделенную ей память, если она этого не сделает, то может случится утечка памяти. Это, в свою очередь, может привести к постоянно растущему потреблению памяти, что в конечном итоге окажется фатальным для вашего сервера PostgreSQL. Память просто закончится 😥

Чтобы снизить опасность утечек памяти, PostgreSQL внедрила собственную систему управления памятью: контексты памяти. Контексты памяти - это участки памяти, которые могут увеличиваться по требованию программы. PostgreSQL ни когда не будет использовать память напрямую, она будет ее запрашивать из этих самых контекстов. Если памяти будет недостаточно, PostgreSQL просто расширит контекст памяти.

Большим преимуществом контекстов памяти является то, что вы можете удалять их, что освобождает всю память сразу. Контекст памяти имеет иерархическую структуру, где сверху идет контекст основного процесса, а ниже контексты конкретных задач, под которые выделяется память. 

Т.е., например, для процесса выполнителя запросов будет выделен контекст памяти под названием ExecutorState. Как только запрос выполнится, этот контекст будет удален из памяти, что позволит освободить ее и избежать утечки.

Как правило, DBA и разработчикам, работающим с PostgreSQL вообще не нужно заботиться об этих контекстах памяти, но когда на сервере случиться утечка памяти расследовать ее все же придется 😣

Если хочется очень глубоко погрузиться в механизм контекстов памяти PostgreSQL, то можно почитать документацию в его исходниках по ссылке:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob_plain;f=src/backend/utils/mmgr/README;hb=HEAD

Там же, ближе к концу вы увидите перечисление контекстов памяти PostgreSQL и их описание. Так можно разобраться какой контекст за что отвечает при расследовании утечек памяти.

До 14-й версии PostgreSQL для расследования утечек памяти нужно было использовать какой-то дебагер или профайлер или средства ОС. В 14-ю версию PostgreSQL добавили специальное представление pg_backend_memory_contexts, которое нам позволит заглянуть в контексты памяти PostgreSQL и выяснить кто всю ее съел 😡

Для начала давайте посмотрим сколько памяти употребила наша сессия:

SELECT pg_size_pretty(sum(used_bytes)) AS “TotalMem by session” FROM pg_backend_memory_contexts;

В ответ получим кол-во израсходованной памяти в байтах.

Следующим запросом мы увидим топ 10 контекстов-потребителей оперативки:

SELECT * FROM pg_backend_memory_contexts ORDER BY used_bytes DESC LIMIT 10;

А таким запросом мы увидим все контексты памяти и размер ее потребления каждым:

SELECT name,pg_size_pretty(sum(used_bytes)) FROM pg_backend_memory_contexts;

Пользоваться представлением может только роль с правами суперпользователя или с правом pg_read_all_stats.

*****************************************