зеркало из
https://github.com/iharh/notes.git
synced 2025-10-29 20:56:06 +02:00
176 строки
15 KiB
Plaintext
176 строки
15 KiB
Plaintext
|
||
*****************************************
|
||
В 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.
|
||
|
||
*****************************************
|
||
|
||
16-я версия PostgreSQL принесла нам много нововведений и улучшений как в плане технической части, так и в плане мониторинга. Одним из таких нововведений в мониторинге стало представление pg_stat_io.
|
||
|
||
До появления этого представления нагрузку на дисковую подсистему, которую генерирует PostgreSQL можно было посмотреть с помощью средств и утилит операционной системы, профайлеров и т.д. Короче приходилось как-то извращаться 😪 Теперь же, в 16-й версии PostgreSQL все стало просто и понятно. Еще один повод обновиться 😉
|
||
|
||
Простейший запрос к этому представлению может выглядеть вот так:
|
||
|
||
SELECT * FROM pg_stat_io WHERE reads <> 0 OR writes <> 0;
|
||
|
||
Теперь давайте разбираться с полями в выводе запроса.
|
||
|
||
backend_type
|
||
|
||
Это поле показывает тип процесса PostgreSQL. Я думаю вы помните, что PostgreSQL использует так называемую процессную модель. Т.е. когда выделяется отдельный процесс в системе на каждое действие, в том числе и на подключение клиента. Вот имена этих процессов это поле и показывает.
|
||
|
||
object
|
||
|
||
В этом поле может быть одно из двух значений: relation и temp relation. Т.е. здесь мы увидим вид объекта базы данных: постоянная таблица, индекс или другой вид объекта или временная таблица.
|
||
|
||
context
|
||
|
||
В этом поле уже может быть четыре вида значений: normal, vacuum, bulkread или bulkwrite. Это поле показывает тип (контекст) нагрузки на файловую систему.
|
||
normal - имеются в виду операции с общим буферным кэшем, тогда данные читаются или пишутся в него. Такие операции считаются "нормальными".
|
||
vacuum - как думаю понятно из названия, это операции, связанные с процессом VACUUM.
|
||
bulkread или bulkwrite - это операции, связанные с чтением и записью большого кол-ва данных за пределами буферного кэша. Т.е. это может быть, например, последовательное сканирование большой таблицы или загрузка большого объема данных с помощью операции COPY.
|
||
|
||
reads и writes
|
||
|
||
Кол-во операций чтения и записи. Здесь показывается именно кол-во, а не размер в байтах.
|
||
|
||
read_time и write_time
|
||
|
||
Время, затраченное процессом на чтение и запись. Эта колонка может быть помощником в выявлении проблем с производительностью. Чтобы значение в этой колонке заполнялось нужно включить параметр track_io_timing в конфигурационном файле postgresql.conf.
|
||
|
||
hits
|
||
|
||
Это кол-во попаданий в общий буферный кэш. Т.е. значение показывает сколько раз раз процесс обращался к данным из кэша, а не считывал их с диска.
|
||
|
||
Это наиболее интересные, на наш взгляд поля представления. Со всеми остальными полями можете ознакомиться в документации по ссылке:
|
||
|
||
➡️ https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-IO-VIEW
|
||
|
||
Вот еще парочка полезных запросов к этому представлению:
|
||
|
||
✅ Смотрим дисковую активность процесса AUTOVACUUM.
|
||
|
||
SELECT * FROM pg_stat_io WHERE backend_type = 'autovacuum worker';
|
||
|
||
✅ Смотрим большие операции чтения и записи.
|
||
|
||
SELECT * FROM pg_stat_io WHERE io_context IN ('bulkread', 'bulkwrite') AND (reads <> 0 OR writes <> 0);
|
||
|
||
В общем, вариантов запросов к представлению много, все зависит от вашей задачи. Расследование проблем с операциями ввода/вывода всегда было важной задачей для администратора PostgreSQL. С новым представлением pg_stat_io теперь очень легко и быстро можно получить как общую картину по операциям чтения и записи, так отдельно по определенному процессу или контексту.
|
||
|
||
*****************************************
|