How to use pg_stat_activity?
I’d like to see which queries are being executed on a live Django application, and how much memory they are taking up. I have read that pg_stat_activity can be useful to monitor a Postgres database. I have looked at the Postgres documentation, but I have a very simple question that doesn’t seem to be answered there. How do I actually get started with pg_stat_activity ? What do I type to use it, and where do I type it?
312k 78 78 gold badges 699 699 silver badges 785 785 bronze badges
asked Jul 15, 2013 at 12:15
63.8k 129 129 gold badges 340 340 silver badges 551 551 bronze badges
You probably need the pgstatstatements module instead.
Jul 15, 2013 at 13:42
2 Answers 2
pg_stat_activity is a view in the pg_catalog schema.
You can query it by SELECT ing from it like any other table, e.g. SELECT * FROM pg_stat_activity . The manual page you linked to explains its columns.
You’ll sometimes find yourself wanting to join on other tables like pg_class (tables), pg_namespace (schemas), etc.
Limitations
pg_stat_activity does not expose information about back-end memory use. You need to use operating-system level facilities for that. However it does tell you the process ID, active user, currently running query, activity status, time the last query started, etc. It’s good for identifying long-running idle in transaction sessions, very long running queries, etc.
Frankly, PostgreSQL’s built-in monitoring is rather rudimentary. It’s one of the areas that’s not that exciting to work on, and commercial clients aren’t often willing to fund it. Most people couple tools like check_postgres with Icinga and Munin, or use Zabbix or other external monitoring agents.
In your case it sounds like you really want pg_stat_statements , and/or PgBadger log analysis with suitable logging settings and possibly the auto_explain module.
PostgreSQL управление сессиями, блокировками
Для работы с блокировками используется представление pg_locks.
- Просмотр блокировок определенной таблицы:
SELECT * FROM pg_locks WHERE relation = ‘eps_blobs.document_info’::regclass; - Просмотр кто кого заблокирвал:
select coalesce(bgl.relation::regclass::text, bgl.locktype) as locked_item,
now() — bda.query_start as waiting_duration,
bda.pid as blocked_pid, bda.query as blocked_query,
bdl.mode as blocked_mode, bga.pid as blocking_pid,
bga.query as blocking_query, bgl.mode as blocking_mode
from pg_catalog.pg_locks bdl
join pg_stat_activity bda on bda.pid = bdl.pid
join pg_catalog.pg_locks bgl on bgl.pid != bdl.pid
and (bgl.transactionid = bdl.transactionid
or bgl.relation = bdl.relation and bgl.locktype = bdl.locktype)
join pg_stat_activity bga on bga.pid = bgl.pid and bga.datid = bda.datid
where not bdl.granted and bga.datname = current_database(); - Просмотр блокированных объектов с указанием периода блокировки:
SELECT a.datname, l.relation::regclass, l.transactionid, l.mode, l.GRANTED,
a.usename, a.query, a.query_start, age(now(), a.query_start) AS «age»,
a.pid
FROM pg_stat_activity a JOIN pg_locks l ON l.pid = a.pid ORDER BY a.query_start;
Полезные ссылки:
- https://zelark.github.io/exploring-query-locks-in-postgres/
- https://wiki.postgresql.org/wiki/Lock_Monitoring
- https://postgrespro.ru/docs/postgrespro/12/functions-admin
- https://postgrespro.ru/docs/postgrespro/12/view-pg-locks
- https://postgrespro.ru/docs/postgrespro/12/monitoring-stats#PG-STAT-ACTIVITY-VIEW
Мониторим базу PostgreSQL — кто виноват, и что делать
Я уже рассказывал, как мы «ловим» проблемы PostgreSQL с помощью массового мониторинга логов на сотнях серверов одновременно. Но ведь кроме логов, эта СУБД предоставляет нам еще и множество инструментов для анализа ее состояния — грех ими не воспользоваться.
Правда, если просто смотреть на них с консоли, можно очень быстро окосеть без какой-либо пользы, потому что количество доступных нам данных превышает все разумные пределы.
Поэтому, чтобы ситуация все же оставалась контролируемой, мы разработали надстройку над Zabbix, которая поставляет метрики, формирует экраны и задает единые правила мониторинга для всех серверов и баз на них.
Сегодняшняя статья — о том, какие выводы можно сделать, наблюдая в динамике различные метрики баз PostgreSQL-сервера, и где может скрываться проблема.
Состояние соединений
Самое первое, с чего начинаются все разборки на тему «что у нас с базой сейчас/было плохо» — это наблюдение за сводным состоянием pg_stat_activity:
На левом графике мы видим все соединения, которые чего-то ждут, на правом — которые что-то делают. В зависимости от версии PG состояние соединения определяется по pg_stat_activity.state/wait_event и/или тексту самого запроса.
На что обращать внимание:
- Слишком мало idle — вашему приложению может в какой-то момент не хватить уже открытых к базе соединений, и при попытке открыть еще одно вы попадете на длительное ожидание инициализации процесса для обслуживания нового коннекта.
- Слишком много idle с динамикой роста может означать «утечку» соединений на стороне приложения, что рано или поздно приведет к достижению лимита max_connections .
- Много idle in transaction — скорее всего, у нас перегружена бизнес-логика или pgbouncer. То есть с точки зрения БД вы транзакцию открыли и ушли перекурить.
query ~* E'^(\\s*(--[^\\n]*\\n|/\\*.*\\*/|\\n))*(autovacuum|VACUUM|ANALYZE|REINDEX|CLUSTER|CREATE|ALTER|TRUNCATE|DROP)'В большинстве случаев там будет фигурировать количество одновременно работающих autovacuum/autoanalyze, вред которых заключается разве что в употреблении ресурсов сервера на «посторонние» дела. Если для вас это критично — покрутите autovacuum_max_workers и autovacuum_naptime , но совсем отключать — не стоит.
Состояние соединений и блокировок
WITH event_types(wait_event_type) AS( VALUES ('lwlock') , ('lock') , ('bufferpin') , ('client') , ('extension') , ('ipc') , ('timeout') , ('io') ) , events(wait_event) AS( VALUES ('walwritelock') , ('wal_insert') , ('buffer_content') , ('buffer_io') , ('lock_manager') , ('relation') , ('extend') , ('page') , ('tuple') , ('transactionid') , ('virtualxid') , ('speculative token') , ('object') , ('userlock') , ('advisory') , ('clientread') , ('datafileextend') , ('datafileread') , ('datafilewrite') , ('slruread') , ('slruwrite') ) , states(state) AS( VALUES ('running') , ('maintenance') , ('waiting') , ('transaction') , ('idle') ) , stats AS( SELECT pid , datname , state , lower(wait_event_type) wait_event_type , lower(wait_event) wait_event , query FROM pg_stat_activity WHERE pid <> pg_backend_pid() ) , dbs AS( SELECT datname FROM pg_database db WHERE NOT db.datistemplate ) SELECT date_part('epoch', now())::integer ts , coalesce(s.qty, 0) val , dbs.datname dbname , states.state , true total FROM dbs CROSS JOIN states NATURAL LEFT JOIN ( SELECT datname , CASE WHEN query ~* E'^(\\s*(--[^\\n]*\\n|/\\*.*\\*/|\\n))*(autovacuum|VACUUM|ANALYZE|REINDEX|CLUSTER|CREATE|ALTER|TRUNCATE|DROP)' THEN 'maintenance' WHEN wait_event IS NOT NULL AND wait_event <> 'clientread' AND state = 'active' THEN 'waiting' WHEN state = 'active' THEN 'running' WHEN state = 'idle' THEN 'idle' WHEN state IN ('idle in transaction', 'idle in transaction (aborted)') THEN 'transaction' WHEN state = 'fastpath function call' THEN 'fastpath' ELSE 'disabled' END state , count(*) qty FROM stats GROUP BY 1, 2 ) s UNION SELECT date_part('epoch', now())::integer ts , coalesce(t.qty, 0) val , dbs.datname dbname , event_types.wait_event_type , false total FROM dbs CROSS JOIN event_types NATURAL LEFT JOIN ( SELECT datname , wait_event_type , count(*) qty FROM stats WHERE wait_event_type IS NOT NULL GROUP BY 1, 2 ) t UNION SELECT date_part('epoch', now())::integer ts , coalesce(e.qty, 0) val , dbs.datname dbname , events.wait_event , false total FROM dbs CROSS JOIN events NATURAL LEFT JOIN ( SELECT datname , wait_event , count(*) qty FROM stats WHERE wait_event IS NOT NULL GROUP BY 1, 2 ) e; Блокировки
Раз уж мы затронули в предыдущем пункте мониторинг блокировок, то стоит заметить, что PostgreSQL любит их накладывать направо и налево:
Нас из них больше всего интересуют два вида:
- Exclusive — типично возникают при блокировке на конкретной записи.
- AccessExclusive — при проведении maintenance-операции над таблицей.
И рекомендательные, и обычные блокировки сохраняются в области общей памяти, размер которой определяется параметрами конфигурации max_locks_per_transaction и max_connections . Важно, чтобы этой памяти было достаточно, так как в противном случае сервер не сможет выдать никакую блокировку. Таким образом, число рекомендуемых блокировок, которые может выдать сервер, ограничивается обычно десятками или сотнями тысяч в зависимости от конфигурации сервера.
Обычно такая ситуация возникает, если у вас в приложении «текут» и не освобождаются ресурсы: соединения с базой, контексты транзакций или advisory-блокировки. Поэтому обращайте внимание на общую динамику.
Transactions per second (TPS)
Для получения информации об изменениях в контексте текущей базы можно воспользоваться системным представлением pg_stat_database. Но если баз на сервере много, удобно делать это сразу для них всех, подключившись к postgres .
TPS & tuples
SELECT extract(epoch from now())::integer ts , datname dbname , pg_stat_get_db_tuples_returned(oid) tup_returned , pg_stat_get_db_tuples_fetched(oid) tup_fetched , pg_stat_get_db_tuples_inserted(oid) tup_inserted , pg_stat_get_db_tuples_updated(oid) tup_updated , pg_stat_get_db_tuples_deleted(oid) tup_deleted , pg_stat_get_db_xact_commit(oid) xact_commit , pg_stat_get_db_xact_rollback(oid) xact_rollback FROM pg_database WHERE NOT datistemplate; Отдельно хочу акцентировать внимание — не пренебрегайте выводом max-значений метрик!
На этом графике мы как раз хорошо видим ситуацию внезапного пикового увеличения количества проведенных ( commit ) транзакций. Это не один-в-один соответствует нагрузке на сервер и транзакции могут быть разной сложности, но рост в 4 раза явно показывает, что серверу стоит иметь определенный резерв производительности, чтобы и такой пик переживать беспроблемно.
Ну а откат ( rollback ) транзакции — это повод проверить, осознанно ли ваше приложение выполняет ROLLBACK , или это автоматически делает сервер в результате возникшей ошибки.
Количество операций над записями
Сначала обратим внимание на записи, которые у нас вычитываются из индексов/таблиц:
- tuples.returned — это количество записей, которые были «прочитаны» со страниц данных.
- tuples.fetched — те из них, которые не были отфильтрованы «прямо тут» на этапе Rows Removed by Filter , а ушли «выше» по плану выполнения.
- tuples.ratio — соответственно, отношение одного к другому, которое должно стремиться к 1, чем больше — тем хуже. Это базовый показатель, который демонстрирует, во сколько раз больше данных вы вычитываете, чем реально необходимо вашим запросам.
Впрочем, даже если ratio идеально равно 1, но пик пришелся на returned/fetched — тоже хорошего не жди. Обычно это может означать наличие в плане какой-то неприятности вроде:
Hash Join - Hash - Seq Scan on BIG_TABLE - Index Scan . Merge Join - Index Scan on BIG_INDEX - Index Scan . Раз уж мы начали проверять, «что» у нас там читается — давайте посмотрим и «как» это происходит. То есть какой объем записей у нас читается по индексам, а какой — в результате Seq Scan :
Понятно, что тут любой внеплановый рост показателей должен вызвать подозрение. Например, если вы по каким-то нуждам каждую ночь вычитываете целиком табличку на 10M записей, то возникновение такого пика днем — повод к разборкам.
Равно как и любые массово-аномальные вставки/обновления/удаления:
Использование кэша данных
Чтобы понять, насколько реально ухудшает жизнь сервера массовая вычитка записей, посмотрим на работу сервера со страницами данных и соотношение block.read/hit . В идеальном мире сервер не должен «читать» с диска ( shared read на узле плана) ровно ничего, все уже должно быть в памяти ( shared hit ), поскольку обращение к диску — всегда медленно.
В реальности все не совсем так, и является поводом к доскональному анализу запросов около времени пика:
Самый длительный запрос/транзакция
Для MVCC долго активные запросы и транзакции в нагруженных системах — беда для производительности. Подробно и в картинках про это можно прочитать тут, а тут — как можно все-таки выжить в таких условиях.
Поймать таких злодеев нам помогают pg_stat_activity.query_start/xact_start .
Как показывает наш опыт, визуального представления этих метрик уже достаточно, чтобы примерно представлять, куда дальше «копать»:
- искать утечки ресурсов в приложении
- оптимизировать неудачные запросы
- ставить более производительное «железо»
- … или следить, чтобы нагрузка была правильно разнесена во времени
- Блог компании Тензор
- PostgreSQL
- Анализ и проектирование систем
- Администрирование баз данных
- Визуализация данных
Pg stat activity как использовать
Сборщик статистики в Postgres Pro представляет собой подсистему, которая собирает и отображает информацию о работе сервера. В настоящее время сборщик может подсчитывать количество обращений к таблицам и индексам — в виде количества прочитанных блоков или строк с диска. Кроме того, он отслеживает общее число строк в каждой таблице, информацию о выполнении очистки и сбора статистики для каждой таблицы. Он также может подсчитывать вызовы пользовательских функций и общее время, затраченное на выполнение каждой из них.
Кроме того, Postgres Pro может предоставить динамическую информацию о том, что происходит в системе прямо сейчас, в частности, сообщить, какие именно команды выполняются другими серверными процессами и какие другие соединения существуют в системе. Эта возможность не зависит от процесса сборщика.
27.2.1. Конфигурация системы сбора статистики
Поскольку сбор статистики несколько увеличивает накладные расходы при выполнении запроса, есть возможность настроить СУБД так, чтобы выполнять или не выполнять сбор статистической информации. Это контролируется конфигурационными параметрами, которые обычно устанавливаются в файле postgresql.conf . (Подробно установка конфигурационных параметров описывается в Главе 18.)
Параметр track_activities включает мониторинг текущих команд, выполняемой любым серверным процессом.
Параметр track_counts определяет необходимость сбора статистики по обращениям к таблицам и индексам.
Параметр track_functions включает отслеживание использования пользовательских функций.
Параметр track_io_timing включает мониторинг времени чтения и записи блоков.
Обычно эти параметры устанавливаются в postgresql.conf , поэтому они применяются ко всем серверным процессам, однако, используя команду SET , их можно включать и выключать в отдельных сессиях. (Для того чтобы обычные пользователи не скрывали свою работу от администратора СУБД, изменять эти параметры с помощью команды SET могут только суперпользователи.)
Сборщик статистики использует временные файлы для передачи собранной информации другим процессам Postgres Pro . Имя каталога, в котором хранятся эти файлы, задаётся параметром stats_temp_directory, по умолчанию он называется pg_stat_tmp . Для повышения производительности stats_temp_directory может указывать на каталог, расположенный в оперативной памяти, что сокращает время физического ввода/вывода. При остановке сервера постоянная копия статистической информации сохраняется в подкаталоге pg_stat , поэтому статистику можно хранить на протяжении нескольких перезапусков сервера. Когда восстановление выполняется при запуске сервера (например, после непосредственного завершения работы, катастрофического отказа сервера, и восстановлении на заданную точку во времени), все статистические данные счётчиков сбрасываются.
27.2.2. Просмотр статистики
Для просмотра текущего состояния системы предназначены несколько предопределённых представлений, которые перечислены в Таблице 27.1. В дополнение к ним есть несколько других представлений, перечисленных в Таблице 27.2, позволяющих просмотреть результаты сбора статистики. Кроме того, на базе нижележащих статистических функций можно создать собственные представления, как описано в Подразделе 27.2.3.
Наблюдая собранные данные в сборщике статистики, важно понимать, что эта информация обновляется не сразу. Каждый серверный процесс передаёт новые статистические данные сборщику статистики непосредственно перед переходом в режим ожидания; то есть запрос или транзакция в процессе выполнения не влияют на отображаемые данные статистики. К тому же, сам сборщик статистики формирует новый отчёт не чаще, чем раз в PGSTAT_STAT_INTERVAL миллисекунд (500 мс, если этот параметр не изменялся при компиляции сервера). Так что отображаемая информация отстаёт от того, что происходит в настоящий момент. Однако информация о текущем запросе, собираемая с параметром track_activities , всегда актуальна.
Ещё одним важным моментом является то, что когда в серверном процессе запрашивают какую-либо статистику, сначала он получает наиболее свежий моментальный снимок от сборщика статистики и затем до окончания текущей транзакции использует этот снимок для всех статистических представлений и функций. Так что на протяжении одной транзакции статистическая информация меняться не будет. Подобным же образом информация о текущих запросах во всех сессиях собирается в тот момент, когда она впервые запрашивается в рамках транзакции, и эта же самая информация будет отображаться на протяжении всей транзакции. Это не ошибка, а полезное свойство СУБД, поскольку оно позволяет выполнять запросы к статистическим данным и сравнивать результаты, не беспокоясь о том, что статистические данные изменяются. Но если для каждого запроса вам нужны новые результаты, то их следует выполнять вне любых транзакционных блоков. Или же можно вызывать функцию pg_stat_clear_snapshot (), которая сбросит ранее полученный снимок статистики в текущей транзакции (если он был). При следующем обращении к статистической информации будет сформирован новый моментальный снимок.
Через представления pg_stat_xact_all_tables , pg_stat_xact_sys_tables , pg_stat_xact_user_tables , и pg_stat_xact_user_functions транзакции также доступна её собственная статистика (ещё не переданная сборщику статистики). Данные в этих представлениях ведут себя не так, как описано выше; наоборот, в течение транзакции они постоянно обновляются.
Таблица 27.1. Динамические статистические представления
| Имя представления | Описание |
|---|---|
| pg_stat_activity | Одна строка для каждого серверного процесса c информацией по текущей активности процесса, такой как состояние и текущий запрос. За подробностями обратитесь к pg_stat_activity. |
| pg_stat_replication | По одной строке для каждого процесса-передатчика WAL со статистикой по репликации на ведомом сервере, к которому подключён этот процесс. За подробностями обратитесь к pg_stat_replication. |
| pg_stat_ssl | Одна строка для каждого подключения (обычного и реплицирующего), в которой показывается информация об использовании SSL для данного подключения. За подробностями обратитесь к pg_stat_ssl. |
Таблица 27.2. Представления собранной статистики
| Имя представления | Описание |
|---|---|
| pg_stat_archiver | Только одна строка со статистикой о работе активности процесса архивации WAL. Более подробно смотрите pg_stat_archiver. |
| pg_stat_bgwriter | Только одна строка со статистикой о работе фонового процесса записи. Более подробно смотрите pg_stat_bgwriter. |
| pg_stat_database | Одна строка для каждой базы данных со статистикой на уровне базы. Более подробно смотрите pg_stat_database. |
| pg_stat_database_conflicts | По одной строке на каждую базу данных со статистикой по отменам запросов, выполненным вследствие конфликта с процессами восстановления на ведомых серверах. Более подробно смотрите pg_stat_database_conflicts. |
| pg_stat_all_tables | По одной строке на каждую таблицу в текущей базе данных со статистикой по обращениям к этой таблице. Более подробно смотрите pg_stat_all_tables. |
| pg_stat_sys_tables | Аналогично pg_stat_all_tables , за исключением того, что отображаются только системные таблицы. |
| pg_stat_user_tables | Аналогично pg_stat_all_tables , за исключением того, что отображаются только пользовательские таблицы. |
| pg_stat_xact_all_tables | Подобно pg_stat_all_tables , но подсчитывает действия, выполненные в текущей транзакции к настоящему моменту (которые ещё не вошли в pg_stat_all_tables и связанные представления). Столбцы для числа живых и мёртвых строк, а также количества операций очистки и сбора статистики, в этом представлении отсутствуют. |
| pg_stat_xact_sys_tables | Аналогично pg_stat_xact_all_tables , за исключением того, что отображаются только системные таблицы. |
| pg_stat_xact_user_tables | Аналогично pg_stat_xact_all_tables , за исключением того, что отображаются только пользовательские таблицы. |
| pg_stat_all_indexes | По одной строке для каждого индекса в текущей базе данных со статистикой по обращениям к этому индексу. Более подробно смотрите pg_stat_all_indexes. |
| pg_stat_sys_indexes | Аналогично pg_stat_all_indexes , за исключением того, что показываются только индексы по системным таблицам. |
| pg_stat_user_indexes | Аналогично pg_stat_all_indexes , за исключением того, что показываются только индексы по пользовательским таблицам. |
| pg_statio_all_tables | По одной строке для каждой таблицы в текущей базе данных со статистикой по операциям ввода/вывода для этой таблицы. Более подробно смотрите pg_statio_all_tables. |
| pg_statio_sys_tables | Аналогично pg_statio_all_tables , за исключением того, что показываются только системные таблицы. |
| pg_statio_user_tables | Аналогично pg_statio_all_tables , за исключением того, что показываются только пользовательские таблицы. |
| pg_statio_all_indexes | По одной строке для каждого индекса в текущей базе данных со статистикой по операциям ввода/вывода для этого индекса. Более подробно смотрите pg_statio_all_indexes. |
| pg_statio_sys_indexes | Аналогично pg_statio_all_indexes , за исключением того, что показываются только индексы по системным таблицам. |
| pg_statio_user_indexes | Аналогично pg_statio_all_indexes , за исключением того, что показываются только индексы по пользовательским таблицам. |
| pg_statio_all_sequences | По одной строке для каждой последовательности в текущей базе данных со статистикой по операциям ввода/вывода для этой последовательности. Более подробно смотрите pg_statio_all_sequences. |
| pg_statio_sys_sequences | Аналогично pg_statio_all_sequences , за исключением того, что показываются только системные последовательности. (В настоящее время системных последовательностей нет, поэтому это представление всегда пусто.) |
| pg_statio_user_sequences | Аналогично pg_statio_all_sequences , за исключением того, что показываются только пользовательские последовательности. |
| pg_stat_user_functions | По одной строке для каждой отслеживаемой функции со статистикой по выполнениям этой функции. Более подробно смотрите pg_stat_user_functions. |
| pg_stat_xact_user_functions | Аналогично pg_stat_user_functions , однако подсчитываются только вызовы функций, выполненные в текущей транзакции (которые ещё не были включены в pg_stat_user_functions ). |
Статистика по отдельным индексам особенно полезна для определения того, какие индексы используются и насколько они эффективны.
Представления pg_statio_ полезны, прежде всего, для определения эффективности буферного кеша. Если количество фактических дисковых чтений существенно меньше количества чтений из буферного кеша, то это означает, что кеш справляется с большинством запросов на чтение без обращения к ядру. Однако эта статистика не даёт полной картины: Postgres Pro обрабатывает дисковый ввод/вывод так, что данные, не находящиеся в буферном кеше Postgres Pro , могут все ещё располагаться в кеше ввода/вывода ядра, и, следовательно, для их получения физическое чтение может не использоваться. Для получения более детальной информации о процессе ввода/вывода в Postgres Pro рекомендуется использовать сборщик статистики Postgres Pro в сочетании с утилитами операционной системы, которые дают более полное представление о том, как ядро осуществляет ввод/вывод.
Таблица 27.3. Представление pg_stat_activity
| Столбец | Тип | Описание |
|---|---|---|
| datid | oid | OID базы данных, к которой подключён этот серверный процесс |
| datname | name | Имя базы данных, к которой подключён этот серверный процесс |
| pid | integer | Идентификатор процесса этого серверного процесса |
| usesysid | oid | OID пользователя, подключённого к этому серверному процессу |
| usename | name | Имя пользователя, подключённого к этому серверному процессу |
| application_name | text | Название приложения, подключённого к этому серверному процессу |
| client_addr | inet | IP-адрес клиента, подключённого к этому серверному процессу. Значение null в этом поле означает, что клиент подключён через сокет Unix на стороне сервера или что это внутренний процесс, например, автоочистка. |
| client_hostname | text | Имя компьютера для подключённого клиента, получаемое в результате обратного поиска в DNS по client_addr . Это поле будет отлично от null только в случае соединений по IP и только при включённом режиме log_hostname. |
| client_port | integer | Номер TCP-порта, который используется клиентом для соединения с этим серверным процессом, или -1 , если используется сокет Unix |
| backend_start | timestamp with time zone | Время запуска процесса, т. е. время, когда клиент подсоединился к серверу |
| xact_start | timestamp with time zone | Время начала текущей транзакции в этом процессе или null при отсутствии активной транзакции. Если текущий запрос был первым в своей транзакции, то значение в этом столбце совпадает со значением столбца query_start . |
| query_start | timestamp with time zone | Время начала выполнения активного в данный момент запроса, или, если state не active , то время начала выполнения последнего запроса |
| state_change | timestamp with time zone | Время последнего изменения состояния (поля state ) |
| waiting | boolean | True, если этот серверный процесс ожидает освобождения блокировки |
| state | text | Общее текущее состояние этого серверного процесса. Возможные значения: |
active : серверный процесс выполняет запрос.
idle : серверный процесс ожидает новой команды от клиента.
idle in transaction : серверный процесс находится внутри транзакции, но в настоящее время не выполняет никакой запрос.
idle in transaction (aborted) : Это состояние подобно idle in transaction , за исключением того, что один из операторов в транзакции вызывал ошибку.
fastpath function call : серверный процесс выполняет fast-path функцию.
В представлении pg_stat_activity для каждого серверного процесса будет присутствовать по одной строке с информацией, относящейся к текущей деятельности этого процесса.
Примечание
Значения в столбцах waiting и state не зависят друг от друга. Серверный процесс, находящийся в состоянии active может быть waiting , а может и не быть. Если статусы процессов имеют значение true в active , и waiting , то это означает, что запрос выполняется, но его работе препятствует какая-то блокировка в системе.
Таблица 27.4. Представление pg_stat_replication
| Столбец | Тип | Описание |
|---|---|---|
| pid | integer | Идентификатор процесса-передатчика WAL |
| usesysid | oid | OID пользователя, подключённого к этому процессу-передатчику WAL |
| usename | name | Имя пользователя, подключённого к этому процессу-передатчику WAL |
| application_name | text | Имя приложения, которое подключено к этому процессу-передатчику WAL |
| client_addr | inet | IP-адрес клиента, подключённого к этому процессу-передатчику WAL. Значение null в этом поле говорит о том, что клиент подсоединён через сокет Unix на сервере. |
| client_hostname | text | Имя компьютера для подключённого клиента, получаемое в результате обратного поиска в DNS по client_addr . Это поле будет отлично от null только в случае соединений по IP и только при включённом режиме log_hostname. |
| client_port | integer | Номер TCP-порта, который используется клиентом для взаимодействия с процессом-передатчиком WAL, или -1 , если используется сокет Unix |
| backend_start | timestamp with time zone | Время запуска процесса, т. е. время подключения клиента к этому процессу-передатчику WAL |
| backend_xmin | xid | Значение xmin , полученное от ведомого сервера при включённом hot_standby_feedback. |
| state | text | Текущее состояние процесса-передатчика WAL |
| sent_location | pg_lsn | Позиция последней транзакции в журнале транзакций, отправленной по этому соединению |
| write_location | pg_lsn | Позиция последней транзакции в журнале транзакций, записанной на диск ведомым сервером |
| flush_location | pg_lsn | Позиция последней транзакции в журнале транзакций, сброшенной на диск ведомым сервером |
| replay_location | pg_lsn | Позиция последней транзакции в журнале транзакций, выполненной в этой базе данных на ведомом сервере |
| sync_priority | integer | Приоритет этого ведомого сервера для выбора в качестве синхронного ведомого |
| sync_state | text | Состояние синхронизации для этого ведомого сервера |
Представление pg_stat_replication для каждого процесса-передатчика WAL будет содержать по одной строке со статистикой о репликации на ведомый сервер, к которому подключён этот процесс. В представлении перечисляются только ведомые серверы, подключённые напрямую; информация о ведомых серверах, подключённых опосредованно, не представлена.
Таблица 27.5. Представление pg_stat_ssl
| Столбец | Тип | Описание |
|---|---|---|
| pid | integer | Идентификатор обслуживающего процесса или процесса, передающего WAL |
| ssl | boolean | True, если для этого подключения используется SSL |
| version | text | Версия SSL либо NULL, если SSL для этого подключения не используется |
| cipher | text | Имя применяемого шифра SSL либо NULL, если SSL для этого подключения не используется |
| bits | integer | Число бит в применяемом алгоритме шифрования либо NULL, если SSL для этого подключения не используется |
| compression | boolean | True, если применяется сжатие SSL, false в противном случае, либо NULL, если SSL для этого подключения не используется |
| clientdn | text | Поле DN (Distinguished Name, Уникальное имя) из используемого клиентского сертификата либо NULL, если клиент не передал сертификат или SSL для этого подключения не используется. Это значение усекается, если поле DN оказывается длиннее NAMEDATALEN символов (64 символа в стандартной сборке) |
Представление pg_stat_ssl содержит по одной строке для каждого обслуживающего процесса и процесса, передающего WAL, и показывает статистику использования SSL для подключений. Его можно соединить с pg_stat_activity или pg_stat_replication по столбцу pid и получить дополнительные сведения о подключении.
Таблица 27.6. Представление pg_stat_archiver
| Столбец | Тип | Описание |
|---|---|---|
| archived_count | bigint | Число файлов WAL, которые были успешно архивированы |
| last_archived_wal | text | Имя последнего файла WAL успешно архивированного |
| last_archived_time | timestamp with time zone | Время последней успешной архивации |
| failed_count | bigint | Число неудачных попыток архивации файлов WAL |
| last_failed_wal | text | Имя файла WAL последней неудавшейся архивации |
| last_failed_time | timestamp with time zone | Время последней неудавшейся архивации |
| stats_reset | timestamp with time zone | Последнее время сброса этих статистических данных |
Представление pg_stat_archiver всегда будет иметь одну строку, содержащую данные о текущем состоянии процесса архивации кластера.
Таблица 27.7. Представление pg_stat_bgwriter
| Столбец | Тип | Описание |
|---|---|---|
| checkpoints_timed | bigint | Количество запланированных контрольных точек, которые уже были выполнены |
| checkpoints_req | bigint | Количество запрошенных контрольных точек, которые уже были выполнены |
| checkpoint_write_time | double precision | Общее время, которое было затрачено на этап обработки контрольной точки, в котором файлы записываются на диск, в миллисекундах |
| checkpoint_sync_time | double precision | Общее время, которое было затрачено на этап обработки контрольной точки, в котором файлы синхронизируются с диском, в миллисекундах |
| buffers_checkpoint | bigint | Количество буферов, записанных при выполнении контрольных точек |
| buffers_clean | bigint | Количество буферов, записанных фоновым процессом записи |
| maxwritten_clean | bigint | Сколько раз фоновый процесс записи останавливал сброс грязных страниц на диск из-за того, что записал слишком много буферов |
| buffers_backend | bigint | Количество буферов, записанных самим серверным процессом |
| buffers_backend_fsync | bigint | Сколько раз серверному процессу пришлось выполнить fsync самостоятельно (обычно фоновый процесс записи сам обрабатывает эти вызовы, даже когда серверный процесс выполняет запись самостоятельно) |
| buffers_alloc | bigint | Количество выделенных буферов |
| stats_reset | timestamp with time zone | Последнее время сброса этих статистических данных |
В представлении pg_stat_bgwriter всегда будет только одна строка, в которой будут представлены общие данные по всему кластеру.
Таблица 27.8. Представление pg_stat_database
| Столбец | Тип | Описание |
|---|---|---|
| datid | oid | OID базы данных |
| datname | name | Имя базы данных |
| numbackends | integer | Количество серверных процессов, в настоящее время подключённых к этой базе данных. Это единственный столбец в этом представлении, значение в котором отражает текущее состояние; все другие столбцы возвращают суммарные значения со времени последнего сброса статистики. |
| xact_commit | bigint | Количество зафиксированных транзакций в этой базе данных |
| xact_rollback | bigint | Количество транзакций в этой базе данных, для которых был выполнен откат транзакции |
| blks_read | bigint | Количество прочитанных дисковых блоков в этой базе данных |
| blks_hit | bigint | Сколько раз дисковые блоки обнаруживались в буферном кеше, так что чтение с диска не потребовалось (в значение входят только случаи обнаружения в буферном кеше Postgres Pro, а не в кеше файловой системы ОС) |
| tup_returned | bigint | Количество строк, возвращённое запросами в этой базе данных |
| tup_fetched | bigint | Количество строк, извлечённое запросами в этой базе данных |
| tup_inserted | bigint | Количество строк, вставленное запросами в этой базе данных |
| tup_updated | bigint | Количество строк, изменённое запросами в этой базе данных |
| tup_deleted | bigint | Количество строк, удалённое запросами в этой базе данных |
| conflicts | bigint | Количество запросов, отменённых из-за конфликта с восстановлением в этой базе данных. (Конфликты происходят только на ведомых серверах; более подробно смотрите pg_stat_database_conflicts.) |
| temp_files | bigint | Количество временных файлов, созданных запросами в этой базе данных. Подсчитываются все временные файлы независимо от причины их создания (например, для сортировки или для хеширования) и независимо от установленного значения log_temp_files |
| temp_bytes | bigint | Общий объём данных, записанных во временные файлы запросами в этой базе данных. Учитываются все временные файлы, вне зависимости от того, по какой причине они созданы и вне зависимости от значения log_temp_files. |
| deadlocks | bigint | Количество взаимных блокировок, зафиксированное в этой базе данных |
| blk_read_time | double precision | Время, затраченное серверными процессами в этой базе данных, на чтение блоков из файлов данных, в миллисекундах |
| blk_write_time | double precision | Время, затраченное серверными процессами в этой базе данных, на запись блоков в файлы данных, в миллисекундах |
| stats_reset | timestamp with time zone | Последнее время сброса этих статистических данных |
Представление pg_stat_database содержит одну строку со статистикой на каждую базу данных кластера.
Таблица 27.9. Представление pg_stat_database_conflicts
| Столбец | Тип | Описание |
|---|---|---|
| datid | oid | OID базы данных |
| datname | name | Имя базы данных |
| confl_tablespace | bigint | Количество запросов в этой базе данных, отменённых из-за того, что табличные пространства были удалены |
| confl_lock | bigint | Количество запросов в этой базе данных, отменённых по истечении времени ожидания блокировки |
| confl_snapshot | bigint | Количество запросов в этой базе данных, отменённых из-за устаревших снимков данных |
| confl_bufferpin | bigint | Количество запросов в этой базе данных, отменённых из-за прикреплённых страниц буфера |
| confl_deadlock | bigint | Количество запросов в этой базе данных, отменённых из-за взаимных блокировок |
Представление pg_stat_database_conflicts для каждой базы данных будет содержать по одной строке со статистикой на уровне базы по отменам запросов, произошедшим вследствие конфликтов с процессами восстановления на ведомых серверах. В этом представлении будет содержаться только информация по ведомым серверам, поскольку на главных серверах конфликты не возникают.
Таблица 27.10. Представление pg_stat_all_tables
| Столбец | Тип | Описание |
|---|---|---|
| relid | oid | OID таблицы |
| schemaname | name | Имя схемы, в которой расположена эта таблица |
| relname | name | Имя таблицы |
| seq_scan | bigint | Количество последовательных чтений, запущенных по этой таблице |
| seq_tup_read | bigint | Количество «живых» строк, прочитанных при последовательных чтениях |
| idx_scan | bigint | Количество сканирований по индексу, запущенных по этой таблице |
| idx_tup_fetch | bigint | Количество «живых» строк, отобранных при сканированиях по индексу |
| n_tup_ins | bigint | Количество вставленных строк |
| n_tup_upd | bigint | Количество изменённых строк (включая изменения по схеме HOT) |
| n_tup_del | bigint | Количество удалённых строк |
| n_tup_hot_upd | bigint | Количество строк, обновлённых в режиме HOT (т. е. без отдельного изменения индекса) |
| n_live_tup | bigint | Оценочное количество «живых» строк |
| n_dead_tup | bigint | Оценочное количество «мёртвых» строк |
| n_mod_since_analyze | bigint | Оценочное число строк, изменённых в этой таблице, с момента последнего сбора статистики |
| last_vacuum | timestamp with time zone | Время последней очистки этой таблицы вручную ( VACUUM FULL не учитывается) |
| last_autovacuum | timestamp with time zone | Время последней очистки таблицы фоновым процессом автоочистки |
| last_analyze | timestamp with time zone | Время последнего выполнения сбора статистики для этой таблицы вручную |
| last_autoanalyze | timestamp with time zone | Время последнего выполнения сбора статистики для этой таблицы фоновым процессом автоочистки |
| vacuum_count | bigint | Сколько раз очистка этой таблицы была выполнена вручную ( VACUUM FULL не учитывается) |
| autovacuum_count | bigint | Сколько раз очистка этой таблицы была выполнена фоновым процессом автоочистки |
| analyze_count | bigint | Сколько раз сбор статистики для этой таблицы был выполнен вручную |
| autoanalyze_count | bigint | Сколько раз сбор статистики для этой таблицы был выполнен фоновым процессом автоочистки |
Представление pg_stat_all_tables будет содержать по одной строке на каждую таблицу в текущей базе данных (включая таблицы TOAST) со статистикой по обращениям к этой таблице. Представления pg_stat_user_tables и pg_stat_sys_tables содержат ту же самую информацию, но отфильтрованную так, чтобы показывать только пользовательские и системные таблицы соответственно.
Таблица 27.11. Представление pg_stat_all_indexes
| Столбец | Тип | Описание |
|---|---|---|
| relid | oid | OID таблицы для индекса |
| indexrelid | oid | OID индекса |
| schemaname | name | Имя схемы, в которой расположен индекс |
| relname | name | Имя таблицы для индекса |
| indexrelname | name | Имя индекса |
| idx_scan | bigint | Количество запущенных сканирований по этому индексу |
| idx_tup_read | bigint | Количество элементов индекса, возвращённых при сканированиях по этому индексу |
| idx_tup_fetch | bigint | Количество живых строк таблицы, отобранных при простых сканированиях по этому индексу |
Представление pg_stat_all_indexes для каждого индекса в текущей базе данных будет содержать по одной строке со статистикой по обращениям к этому индексу. Представления pg_stat_user_indexes и pg_stat_sys_indexes содержат ту же самую информацию, но отфильтрованную так, чтобы показывать только пользовательские и системные индексы соответственно.
Индексы могут использоваться при простом сканировании по индексу, при сканировании « битовой карты » индекса и в работе оптимизатора. Результаты сканирования битовых карт разных индексов могут объединяться логическим умножением или сложением, поэтому когда применяются битовые карты, сложно связать выборки отдельных строк с определёнными индексами. Поэтому при сканировании битовых карт увеличиваются счётчики pg_stat_all_indexes . idx_tup_read для задействованных индексов и счётчик pg_stat_all_tables . idx_tup_fetch для каждой таблицы, а pg_stat_all_indexes . idx_tup_fetch не меняется. Оптимизатор тоже обращается к индексам для проверки переданных констант, значения которых оказываются вне диапазона, записанного в статистике оптимизатора, так как эта статистика может быть неактуальной.
Примечание
Значения счётчиков idx_tup_read и idx_tup_fetch могут различаться, даже если сканирование с использованием битовой карты не используется, поскольку idx_tup_read подсчитывает полученные из индекса элементы, а idx_tup_fetch — количество «живых» строк, выбранных из таблицы. Различие будет меньше, если «мёртвые» или ещё незафиксированные строки будут извлекаться с использованием индекса или если для получения строк таблицы будет использоваться сканирование только по индексу.
Таблица 27.12. Представление pg_statio_all_tables
| Столбец | Тип | Описание |
|---|---|---|
| relid | oid | OID таблицы |
| schemaname | name | Имя схемы, в которой расположена эта таблица |
| relname | name | Имя таблицы |
| heap_blks_read | bigint | Количество дисковых блоков, прочитанных из этой таблицы |
| heap_blks_hit | bigint | Число попаданий в буфер для этой таблицы |
| idx_blks_read | bigint | Количество дисковых блоков, прочитанных из всех индексов этой таблицы |
| idx_blks_hit | bigint | Число попаданий в буфер для всех индексов по этой таблице |
| toast_blks_read | bigint | Количество прочитанных дисковых блоков TOAST (если есть) для этой таблицы |
| toast_blks_hit | bigint | Число попаданий в буфер в таблице TOAST для этой таблицы (если такие есть) |
| tidx_blks_read | bigint | Количество прочитанных дисковых блоков из индекса по TOAST (если есть) для этой таблицы |
| tidx_blks_hit | bigint | Число попаданий в буфер для индекса по TOAST (если есть) для этой таблицы |
Представление pg_statio_all_tables для каждой таблицы (включая таблицы TOAST) в текущей базе данных будет содержать по одной строке со статистикой по операциям ввода/вывода для этой таблицы. Представления pg_statio_user_tables и pg_statio_sys_tables содержат ту же самую информацию, но отфильтрованную так, чтобы показывать только пользовательские или системные таблицы соответственно.
Таблица 27.13. Представление pg_statio_all_indexes
| Столбец | Тип | Описание |
|---|---|---|
| relid | oid | OID таблицы для индекса |
| indexrelid | oid | OID индекса |
| schemaname | name | Имя схемы, в которой расположен индекс |
| relname | name | Имя таблицы для индекса |
| indexrelname | name | Имя индекса |
| idx_blks_read | bigint | Количество дисковых блоков, прочитанных из этого индекса |
| idx_blks_hit | bigint | Число попаданий в буфер для этого индекса |
Представление pg_statio_all_indexes для каждого индекса в текущей базе данных будет содержать по одной строке со статистикой по операциям ввода/вывода для этого индекса. Представления pg_statio_user_indexes и pg_statio_sys_indexes содержат ту же самую информацию, но отфильтрованную так, чтобы показывать только пользовательские или системные индексы соответственно.
Таблица 27.14. Представление pg_statio_all_sequences
| Столбец | Тип | Описание |
|---|---|---|
| relid | oid | OID последовательности |
| schemaname | name | Имя схемы, в которой расположена эта последовательность |
| relname | name | Имя последовательности |
| blks_read | bigint | Количество дисковых блоков, прочитанных из этой последовательности |
| blks_hit | bigint | Число попаданий в буфер в этой последовательности |
Представление pg_statio_all_sequences для каждой последовательности в текущей базе данных будет содержать по одной строке со статистикой по операциям ввода/вывода для этой последовательности.
Таблица 27.15. Представление pg_stat_user_functions
| Столбец | Тип | Описание |
|---|---|---|
| funcid | oid | OID функции |
| schemaname | name | Имя схемы, в которой расположена функция |
| funcname | name | Имя функции |
| calls | bigint | Сколько раз вызывалась функция |
| total_time | double precision | Общее время, потраченное на выполнение этой функции и всех других функций, вызванных ею, в миллисекундах |
| self_time | double precision | Общее время, потраченное на выполнение самой функции, без учёта других функций, которые были ею вызваны, в миллисекундах |
Представление pg_stat_user_functions для каждой отслеживаемой функции будет содержать по одной строке со статистикой по выполнениям этой функции. Отслеживаемые функции определяются параметром track_functions.
27.2.3. Статистические функции
Статистическую информацию можно просматривать и другими способами. Для этого можно написать запросы, использующие те же функции доступа к статистике, что лежат в основе описанных выше стандартных представлений. За более подробной информацией, например, об именах этих функций, обратитесь к определениям этих стандартных представлений. (Например, в psql можно выполнить \d+ pg_stat_activity .) В качестве аргумента функции, предоставляющие доступ к статистике на уровне базы, принимают OID базы данных, по которой должна быть выдана информация. Функции, которые работают на уровне таблиц и индексов, принимают в качестве аргумента OID таблицы или индекса. Аргументом для функции, предоставляющей статистику на уровне функций, является OID функции. Обратите внимание, что с помощью этих функций можно получить информацию по таблицам, индексам и функциям исключительно в текущей базе данных.
Дополнительные функции, связанные со сбором статистики, перечислены в Таблице 27.16.
Таблица 27.16. Дополнительные статистические функции
| Функция | Тип результата | Описание |
|---|---|---|
| pg_backend_pid() | integer | Идентификатор серверного процесса, выполняющего текущую сессию |
| pg_stat_get_activity ( integer ) | setof record | Возвращает запись с информацией о серверном процессе с заданным PID или по одной строке для каждого активного серверного процесса в системе, если был указан NULL . Возвращаемые поля являются подмножеством столбцов представления pg_stat_activity . |
| pg_stat_get_snapshot_timestamp() | timestamp with time zone | Возвращает время снимка текущей статистики |
| pg_stat_clear_snapshot() | void | Сбросить текущий снимок статистики |
| pg_stat_reset() | void | Сбросить все статистические счётчики в текущей базе данных в ноль (требуются привилегии суперпользователя) |
| pg_stat_reset_shared (text) | void | Сбросить в ноль некоторые статистические счётчики на уровне кластера, в зависимости от заданного аргумента (требуются привилегии суперпользователя). Вызов pg_stat_reset_shared(‘bgwriter’) сбросит в ноль все счётчики, которые показываются в представлении pg_stat_bgwriter . Вызов pg_stat_reset_shared(‘archiver’) сбросит в ноль все счётчики, которые показываются в представлении pg_stat_archiver . |
| pg_stat_reset_single_table_counters (oid) | void | Сбросить в ноль статистику по отдельной таблице или индексу в текущей базе данных (требуются привилегии суперпользователя) |
| pg_stat_reset_single_function_counters (oid) | void | Сбросить в ноль статистику по отдельной функции в текущей базе данных (требуются привилегии суперпользователя) |
Функция pg_stat_get_activity , на которой основано представление pg_stat_activity , возвращает набор строк, содержащих всю доступную информацию о каждом серверном процессе. Иногда более удобным оказывается получение только части этой информации. В таких случаях можно использовать набор более старых функций, дающих доступ к статистике на уровне серверных процессов; эти функции описаны в Таблице 27.17. Эти функции используют идентификатор серверного процесса, значение которого варьируется от единицы до числа активных в настоящий момент серверных процессов. Функция pg_stat_get_backend_idset генерирует по одной строке для каждого активного серверного процесса, что необходимо для вызова этих функций. Например, для того, чтобы отобразить значения PID и текущие запросы всех серверных процессов:
SELECT pg_stat_get_backend_pid(s.backendid) AS pid, pg_stat_get_backend_activity(s.backendid) AS query FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS s;
Таблица 27.17. Статистические функции на уровне серверных процессов
| Функция | Тип результата | Описание |
|---|---|---|
| pg_stat_get_backend_idset() | setof integer | Набор значений идентификаторов активных в настоящий момент серверных процессов (от 1 до числа активных серверных процессов) |
| pg_stat_get_backend_activity(integer) | text | Текст последнего запроса этого серверного процесса |
| pg_stat_get_backend_activity_start(integer) | timestamp with time zone | Время запуска последнего запроса |
| pg_stat_get_backend_client_addr(integer) | inet | IP-адрес клиента, подключённого к этому серверному процессу |
| pg_stat_get_backend_client_port(integer) | integer | Номер TCP-порта, который клиент использует для взаимодействия |
| pg_stat_get_backend_dbid(integer) | oid | OID базы данных, к которой подключён этот серверный процесс |
| pg_stat_get_backend_pid(integer) | integer | Идентификатор процесса этого серверного процесса |
| pg_stat_get_backend_start(integer) | timestamp with time zone | Время запуска этого процесса |
| pg_stat_get_backend_userid(integer) | oid | OID пользователя, подключённого к этому серверному процессу |
| pg_stat_get_backend_waiting(integer) | boolean | True, если этот серверный процесс ожидает освобождения блокировки |
| pg_stat_get_backend_xact_start(integer) | timestamp with time zone | Время начала текущей транзакции |
| Пред. | Наверх | След. |
| 27.1. Стандартные инструменты Unix | Начало | 27.3. Просмотр информации о блокировках |