Одной из задач администратора БД является отслеживание, выяснение причин и предотвращение таких ситуаций.Далее в этой главе мы рассмотрим эти ситуации более подробно.

2.3. Источники информации об активности

Мы начнем с представлений pg_stat_activity, pg_locks и pg_stat_database. С исторической точки зрения возможности отображения активности развивались постепенно и со временем пришликтомувиду,вкоторомониестьнаданныймомент.Враннихверсияхэтитрипредставления содержали информацию, которая тематически не была связана между собой. Представ-

ления pg_stat_activity и pg_locks могли дополнятьдругдруга,а pg_stat_database не содержа-

ла той статистики, что будет рассматриваться далее. Сейчас все три представления содержат различную информацию, которую объединяет одна тема — определение активности. Все три представления помогают составить общую картину происходящего в СУБД:

•pg_stat_activity—статистика о процессах,подключенных клиентах и фоновых службах;

•pg_locks — статистика о блокировках, удерживаемых или ожидаемых активными процессами;

•pg_stat_database—кумулятивнаястатистикаоклиентскихсеансахвконтекстеотдельных баз данных.

Соглашение об именовании

Здесь и далее в тексте при указании представлений и их полей будет использоваться нотация представление.поле.Например,pg_stat_activity.pid указывает на поле pid в представ-

лении pg_stat_activity.

Представление pg_stat_activity

Весьмойпрактическийопытпоискаиустраненияпроблемговоритотом,чтопривозникновении самых разных подозрений на проблемы в работе СУБД pg_stat_activity—главный источник первичной информации. Если с точки зрения операционной системы администратор можетувидетьтолько процессы,то pg_stat_activityпомогаетадминистратору заглянутьвнутрь СУБД и посмотреть на работу этих же процессов, но с точки зрения самой PostgreSQL. В представлении содержится информация обо всех процессах СУБД, будь то клиентские процессы или фоновые службы, и каждая строка описывает отдельный серверный процесс. В ранних версияхPostgreSQLpg_stat_activityсодержалоинформациюпреимущественнооклиентских процессах. В следующих версиях была добавлена информация о фоновых службах. При этом клиентские процессы и фоновые службы отличаются характером работы с СУБД и часть информации,котораяприсущаклиентскимпроцессам,дляфоновыхслужбпопростуотсутствует.

Информация о клиенте. Основные реквизиты соединения:

•client_addr — сетевой адрес, с которого выполнено подключение. Если соединение установлено через UNIX-сокет,значение будет отсутствовать (NULL);

•client_port—номер порта в удаленной системе,с которого установлено соединение;

•usename—имя пользователя,используемое при подключении;

•datname—имя базы данных,к которой выполнено подключение.

Для лучшей идентификации клиент при подключении может обозначить себя через отдельный идентификатор application_name. Это удобный способ отличать приложения в случаях, когда они подключены с одинаковыми реквизитами и с одного адреса.Поле backend_type позволяет отличать клиентские процессы от фоновых служб. В ранних версиях СУБД этого поля не было, и для определения клиентских подключений приходилось прибегать к различным уловкам—например,указывать в SQL-запросе дополнительное условие datname IS NOT NULL.

#SELECT

row_number() OVER (ORDER BY pid) AS n,

pid, backend_type, client_addr, application_name, usename, datname

Этот пример наглядно показывает различия между фоновыми службами (строки с 1-й по 7-ю) и клиентскими процессами (строки с 8-й по 15-ю). Во-первых, отличить их можно по значению поля backend_type. Во-вторых, для фоновых служб могут отсутствовать значения других полей,например client_addr,application_name,usename и datname,поскольку фоновые процес-

сы могут запускаться локально или не устанавливать соединений к БД.

Продолжительностьсеанса,транзакции,запроса. В представлении естьинформация,относяща-

яся ко времени начала сеанса и той активности,что происходит в сеансе:

• backend_start—время начала сеанса,то есть момент подключения клиента к СУБД;

34Глава 2. Статистика активности

•xact_start—время начала текущей транзакции;

•query_start — время начала текущего запроса — на случай, если это не единственный запрос в транзакции.

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

Состояние сеанса. Сеанс в течение своего жизненного цикла может находиться в разных состояниях. По состоянию можно определить, все ли в порядке с сеансом, и принять меры, если с ним что-то не так. На состояние сеанса указывает поле state. Также в поле state_change доступно время перехода в текущее состояние, по которому можно определить его продолжительность. Далее по этим полям мы будем отслеживать потенциально опасную активность в БД и ее продолжительность.

Ожидания и блокировки. ВнутренняямеханикаСУБДпредполагаетиспользованиеразныхмеханизмов синхронизации; хорошим примером являются блокировки, которые используются длясериализациидоступакобъектам.Следствиемиспользованиятакихмеханизмовявляется риск возникновения ожиданий на разных участках выполнения кода. Для отслеживания ожиданий СУБД предоставляет поля wait_event и wait_event_type, которые детально идентифицируют место, где возникло ожидание. С помощью полей state, wait_event_type и wait_event можно определять узкие места в работе СУБД, где происходит ожидание вместо выполнения полезной работы.

Идентификаторитекстзапроса. ВполеqueryуказанытекстывыполняющихсявСУБДзапросов. Поле ограничено размером буфера,который регулируется параметром track_activity_query_size (поумолчанию1КБ).Текствыявленногомедленногозапросадаетадминистраторуотправную точку для оптимизации производительности. Запрос можно воспроизвести, получить план выполнения,проанализировать производительность и в результате наметитьдействия по оптимизации. Дополнительно для каждого запроса формируется уникальный идентификатор queryid, который в сочетании с полями usesysid и datid можно использовать для соединения с представлением pg_stat_statements, в результате чего будут получены дополнительные сведения о том,сколько ресурсов было использовано этим запросом и ему подобными.

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

СУБД умеет распределять выполнение частей запроса между несколькими процессами, ускоряя выполнение запросов и увеличивая эффективность использования многоядерных систем. При наблюдении важно отделять группу процессов, занятых выполнением параллельного запроса от всех остальных процессов или групп. Для этой цели служит поле leader_pid, которое у всех дочерних процессов указывает на pid родительского процесса.