За годы практики я и некоторые мои коллеги пришли к тому, что среди всех типов событий ожидания есть особая группа,которую можно выделить среди остальных и рассматривать как отдельное состояние, равноценное значениям из pg_stat_activity.state. Речь о группе событий с типом Lock: ожидания этой группы указывают на то, что выполнение команды остановлено и ожидает получения тяжелой блокировки. Группа включает в себя несколько ожиданий, которые болееточно определяютпричину ожидания.Одним из примеров можетслужитьожидание transactionid,указывающее на ожидание завершения соседней конкурентнойтранзакции. События группы Lock прямо указывают, что как процесс, так и клиентское приложение вместовыполненияполезнойработынаходятсявожидании,иэтосамопосебенегативновлияет на производительность приложения и СУБД.

Отслеживание состояний с учетом ожиданий

Для учета состояния ожиданий блокировок есть два способа. Первый и предпочтительный заключается в использовании событий ожидания. С помощью условия wait_event_type = 'Lock' процессы можно идентифицировать как находящиеся в ожидании блокировок:

# SELECT

CASE WHEN wait_event_type = 'Lock' THEN 'waiting' ELSE state

END AS state, count(*)

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

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

#SELECT

CASE WHEN NOT l.granted

THEN 'waiting' ELSE a.state END AS state,

count(*)

FROM pg_stat_activity a

LEFT JOIN pg_locks l ON a.pid = l.pid AND NOT l.granted WHERE a.backend_type = 'client backend'

GROUP BY 1 ORDER BY 2 DESC;

На графике есть процессы почти во всех возможных состояниях, в том числе и в ожидании блокировок. Объединяя возможности полей state и wait_event_type, можно собрать воедино информацию о состоянии клиентских сеансов.

Взаимоблокировки

Взаимоблокировка (deadlock) — это ситуация из нескольких блокировок, которая не может разрешиться сама собой, поскольку ее участники дошли до тупикового состояния, в котором все они заблокированы друг другом, перешли в ожидание и не могут продолжать работу. Для разрешения ситуации необходимо освободить часть блокировок путем принудительного завершения одного из участников взаимоблокировки.

В случае обычных блокировок ожидание можетдлиться непредсказуемо долго.Со взаимоблокировками все намного проще: их обнаружение и разрешение выполняется автоматически, без необходимости вмешательства со стороны администратора. Если блокировку не удалось взять за время deadlock_timeout (по умолчанию одна секунда), сеанс проверяет, не является ли он участником взаимоблокировки. В ходе проверки определяются участники конфликта. Если среди участников есть процесс очистки, то ему будет отправлен сигнал о завершении. Исключение составляют процессы очистки с целью предотвращения зацикливания счетчика транзакций (to prevent wraparound).Если процессов очистки нет,то сеанс,начавший проверку, принудительно отменяет выполнение своего собственного запроса, ради которого и потребовалось взять блокировки. Если запрос выполнялся в транзакции, вся транзакция становится ошибочной и ее следует завершить откатом. Остальные участники взаимоблокировки могут дальше продолжить работу, однако нет гарантий, что взаимоблокировка не возникнет снова.

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

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

Для отслеживания взаимоблокировок используют счетчик pg_stat_database.deadlocks, свой для каждой БД. В случае возникновения взаимоблокировки информация о ней записывается в журнал активности:

[UPDATE] ERROR: deadlock detected [UPDATE] DETAIL:

Process 3498160 waits for ShareLock on transaction 809; blocked by process 3498137. Process 3498137 waits for ShareLock on transaction 808; blocked by process 3498160. Process 3498160: update t1 set a = 1 where a = 2;

Process 3498137: update t1 set a = 2 where a = 1; [UPDATE] HINT: See server log for query details.

[UPDATE] CONTEXT: while updating tuple (0,3) in relation "t1" [UPDATE] STATEMENT: update t1 set a = 1 where a = 2;

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

Ввыводе есть ключевое сообщение о том, что зафиксировано появление взаимоблокировки — deadlock detected. Далее следуют информация о том, какой процесс находился в ожидании, каким процессом была вызвана блокировка, и тексты запросов, которые выполнялись в обоих сеансах в момент обнаружения взаимоблокировки. Здесь стоит учитывать, что это текущие запросы, а в реальности конфликтующая блокировка могла быть захвачена другим запросом той же транзакции, выполнение которого предшествовало текущему. Для полного анализа необходимо включать протоколирование всех запросов (log_statement = all или log_min_duration_statement = 0), полностью записывать ход выполнения запросов в транзакции и проверять порядок их выполнения.

Бездействующие транзакции

В идеальном случае последовательность команд, составляющих транзакцию, должна выполняться непрерывно, без пауз или задержек — клиент, получив результат, должен немедленно отправитьследующую команду.Однако на практике получается,что между отправкой команд приложение выполняет какую-то работу, в то время как СУБД ожидает от него продолжения (маркер ожидания Client.ClientRead).Транзакция в состоянии ожидания команды отклиента называется бездействующей (idle) транзакцией. Состояние простоя idle in transaction в абсолютном большинстве случаев возникает из-за клиента и лишь в редких случаях из-за окружения,в котором работаетприложение (операционная система или сетевое окружение).Сточки зрения приложения паузы между отправкой команд могут быть вызваны такими причинами, как:

•вычисления на основе результатов предыдущих команд;

•обращение к удаленному сервису (кеш,очередь,БД,API и т. п.);

•недостаток системных ресурсов и их выделение операционной системой (память);

•приостановка приложения при исчерпании установленного ограничения на использова-

ние ресурсов (Kubernetes requests/limits);

•возникновение ошибок и обработка исключений.

Это неполный список, и причины, по которым могут появляться простои в транзакциях, могут быть самыми разными и не всегда очевидными. В большинстве случаев ответственность за образование бездействующих транзакций возлагается на приложение. Хороший пример — обработка ошибок. В случае ошибки правильным действием со стороны приложения является завершение транзакции откатом. В худшем случае может возникать утечка транзакций — ситуация,когда приложение теряет контроль над транзакцией и она остается незавершенной в течение неопределенно долгого времени. Возможны и другие сценарии. Например, пользо- вательподключаетсякБДивыполняеткакие-токоманды.Пользователюможетпотребоваться начатьтранзакцию, выполнить в ней команду и затем сделать откат. Или IDE, в которой работает пользователь, при выполнении команд может неявно открывать транзакцию. Пользователь отвлекается на другую задачу,и ранее открытая транзакция остается незавершенной.

Пребывание клиентских сеансов в состоянии idle in transaction имеет свои негативные эффекты, и некоторые из них в зависимости от условий эксплуатации СУБД могут привести

каварии:

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

•Устаревшие версии строк, эффект раздувания и падение производительности. При высокой интенсивности на запись размер таблиц и индексов растет из-за появления нескольких версий одних и тех же строк. Устаревшие версии строк не только занимают место на диске, но и негативно влияют на производительность. При чтении и поиске данных процессу приходится обрабатывать больше страниц в поисках нужной версии строки,что приводит к замедлению запроса и избыточному использованию ресурсов CPU, памяти и ввода-вывода.Для регулярного удаления устаревших версий строк и освобождения места используется автоочистка. Рабочие процессы автоочистки сканируют таблицы и индексы, находят версии строк, которые не нужны ни одной из транзакций, и удаляют их. Ностарыеверсиистрокмогутпонадобитьсядолгимтранзакциям(втомчислебездействующим), поэтому автоочистка пропускает удаление таких версий. В случае же успешного удаления освобожденное место продолжает принадлежать таблице (или индексу). Получается,что размер таблиц и индексов увеличивается,но после очистки не уменьшается— это и называется эффектом раздувания. В особо запущенных случаях объем освобожденного пространства внутри таблиц и индексов может превышать общий объем полезных данных.

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