2.5. Состояния сеансов

Результатом расследования стало исправление d0989231. Примерно в 20:00 версия приложениябылаобновлена,ипроблемаисчезла,чтотакжеподтвердилосьграфиком.Такмониторинг помог обнаружить и устранить ошибку в приложении агента.

2.5. Состояния сеансов

Клиентский процесс в своем жизненном цикле может находиться в разных состояниях, которые характеризуют происходящее в сеансе. Состояние процесса можно воспринимать как условный маркер, который помогает различать сеансы с нормальным и нежелательным поведением. Состояние отображается в pg_stat_activity.state, но при этом его можно увидеть только для клиентских соединений,а для фоновых процессов значение поля всегда отсутствует. Вероятно, это связано с тем, что «состояние» характеризует именно сеанс, а фоновые процессы не устанавливают сеансов, следовательно, и отображать нечего. Вполне возможно, в будущих версиях PostgreSQL ситуация изменится и появится какая-то информация о состоянии фоновых процессов. Давайте рассмотрим все состояния, в которых может находиться сеанс:

•idle указывает на состояние простоя. Если клиент не выполняет отправку команд, а сервер не занят выполнением запроса,то сеанс находится в холостом режиме и сервер ждет команды отклиента.В этом состоянии сеанс можетнаходиться бóльшую частьсвоего времени.

•activeуказываетнаактивноесостояние.Принявкомандуотклиента,процессначинаетее выполнениеипереходитвактивноесостояние.Здесьважноотметить,чтотакоесостояние включает в себя и состояние ожидания, когда процесс приостанавливает работу и ждет определенного события.

•idle in transaction указывает на состояние открытой транзакции, в которой ничего не происходит и процесс ждет от клиента команду на выполнение. Открыв транзакцию, приложение должно выполнить в ней набор команд и закрыть ее, однако по каким-то внутреннимпричинаммеждукомандамивозникаетпауза.Такоесостояниевзависимости от характера выполняемых команд потенциально может привести к блокировкам и раздуванию таблиц и индексов из-за отложенной автоочистки. Следует отслеживать такие транзакциииустранятьпричины,приводящиектакомусостоянию.Болееподробнообездействующих транзакциях можно узнать на с. 56.

•idle in transaction (aborted) указывает на состояние незавершенной транзакции, внутри которой произошла ошибка. Хорошим тоном считается, когда приложение полностью контролирует ход выполнения транзакции. Если выполнение любой из команд в транзакции привело к ошибке, приложение должно откатить транзакцию. При отсутствии управлениятранзакциямивтакихситуацияхвозникаетрискутечкиресурсов(ввидеслотовпула транзакций на стороне драйвера БД в приложении). Для самой СУБД пребывание сеанса

1 github.com/lesovsky/pgscv/commit/d098923caef2d1a839df76ad9f441893640faed5

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

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

•fastpath function call указывает на выполнение функции через интерфейс fast-path1. Этот способ выполнения считается устаревшим, и использовать его не рекомендуется. На практике мне не приходилось встречаться с подобным состоянием, но допускаю, что давно разработанные и оставшиеся без поддержки приложения могут использовать эту функциональность.

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

Существует еще одно важное состояние, которое при этом не отражается в поле state. Это ожидание. Это состояние неявно включено в состояние active, хотя, на мой взгляд, эти два состояния должны быть разделены и их следует рассматривать отдельно друг от друга.Активное состояние подразумевает действие и использование ресурсов, в то время как ожидание подразумевает бездействие и удерживание ресурсов от использования. Из этого следует, что активное состояние — это нормальное рабочее состояние системы, а ожидание — ненормальное,и администратор должен предпринимать действия,которые уменьшали бы ожидание.

Отслеживание состояний

Мониторинг клиентских сеансов по состояниям позволяет отслеживать выполнение рабочей нагрузки и появление в ней разных аномалий.Просмотреть все клиентские процессы и их состояния можно с помощью следующего SQL-запроса:

#SELECT state, count(*)

FROM pg_stat_activity WHERE backend_type = 'client backend' GROUP BY 1 ORDER BY 2 DESC;

Вэтомпримерессинтетическойнагрузкойвидно,чтобо́льшаячастьсоединенийпростаивает.

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

1 postgrespro.ru/docs/postgresql/current/libpq-fastpath

точное состояние сеанса. Далее мы рассмотрим природу ожиданий и блокировок и варианты более точного определения состояния сеансов.

Ожидания и блокировки

Принцип блокировок заключается в ограничении или запрете одновременного доступа к ресурсу. В конкурентной среде следствием использования блокировок является появление очередей на доступ к заблокированному ресурсу. Нахождение в такой очереди напрямую влияет на время выполнения запроса или транзакции — выполнение будет заблокировано до тех пор, пока доступ не будет получен, а произойдет это только после того, как пройдет вся очередь и блокировка будет снята. Ожидание блокировок при выполнении запросов негативно сказывается на производительности: вместо того чтобы делать полезную работу, СУБД и приложения вынуждены ждать. Администратор обязан отслеживать, когда система тратит время на ожидание вместо полезной работы.

В случае клиентских процессов ожидание означает невозможность выполнять свою работу до тех пор, пока не освободится ресурс (объект) или не появится ожидаемое событие. Объектами могут являться таблицы или отдельные строки; легкие блокировки устанавливаются на ресурсы более низкого уровня.В качестве событий может выступатьдисковый или сетевой ввод-вывод—синхронизация файлов,передача данных по сети и т. п.

Для отслеживания ожиданий используется представление pg_stat_activity. В СУБД потенциально очень много мест, где процесс может встать в ожидание. Вместо одного общего состояния важно знать, что именно стало причиной ожидания, поэтому поле state не очень подходитдля этой задачи.В качестве инструмента СУБД предлагаеттак называемые события ожидания(waitevent):ониуказываютнаконкретныесобытиеилиресурс,вожиданиикоторых находится процесс.В pg_stat_activity такие события ожидания представлены двумя полями:

•wait_event_type — общий тип ожидания, или, иными словами, обозначение группы, к которой относится ожидание;

•wait_event—конкретное событие или ресурс,в ожидании которых находится процесс.

Событие ожидания указываетна зафиксированный фактожидания процессом определенного события или ресурса, однако они появились в версии 9.6. В более ранних версиях ожидание можно было определитьпо флагу pg_stat_activity.waiting,который указывалтолько на один из частных случаев ожидания — ожидание блокировки. События ожиданий расширили охват регистрируемых событий, которые могут стать причиной ожиданий, и заменили собой этот более простой флаг. Полный список всех регистрируемых ожиданий можно найти в документации в разделе, посвященном pg_stat_activity1. В качестве небольшого примера разберем результат запроса в тестовом окружении.

1 postgrespro.ru/docs/postgresql/current/monitoring-stats#MONITORING-PG-STAT-ACTIVITY-VIEW