Sysadminium

Рассмотрим способы посмотреть текущие активности, другими словами процессы и их деятельность на сервере PostgreSQL.

Что в этой статье будет рассмотрено:

• Вы можете посмотреть на текущие активности сервера PostgreSQL с помощью представления pg_stat_activity.
• Чтобы завершить один из обслуживающих процессов нужно использовать функцию pg_terminate_backend(<pid>).
• Вы можете, с помощью функции pg_blocking_pids(<pid>), посмотреть кого ожидает процесс с этим pid.

Все эти действия можно выполнить с помощью инструментов командной строки операционной системы:

• посмотреть процессы с помощью команды ps;
• завершить процесс с помощью команды kill -9 <pid>.

Но операционная система не сможет определить чем занят процесс postgress, поэтому ps не будет столь-же информативен, как представление pg_stat_activity.

Как вы помните при работе сервера PostgreSQL работает 1 главный процесс, который запускает остальные и следит за ними. При падении одного из процессов postgres, например когда мы его завершили командой kill -9 <pid> , главный процесс postgres может решить что в базе данных случилась ошибка и перезапустит весь кластер. Поэтому завершать процессы лучше средствами PostgreSQL, с помощью функции pg_terminate_backend(<pid>).

Практика

Создадим таблицу и вставим в неё одно значение, равное 42:

postgres@s-pg13:~$ psql -d admin_monitoring
Timing is on.
psql (13.3)
Type "help" for help.

postgres@admin_monitoring=# CREATE TABLE t(n integer);
CREATE TABLE
Time: 2,281 ms

postgres@admin_monitoring=# INSERT INTO t VALUES(42);
INSERT 0 1
Time: 0,713 ms

Затем заблокируем эту таблицу выполняя в ней транзакцию:

postgres@admin_monitoring=# BEGIN;
BEGIN
Time: 0,076 ms

postgres@admin_monitoring=# UPDATE t SET n = n + 1;
UPDATE 1
Time: 0,422 ms

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

postgres@s-pg13:~$ psql -d admin_monitoring
Timing is on.
psql (13.3)
Type "help" for help.

postgres@admin_monitoring=# UPDATE t SET n = n + 2;

Второй сеанс при этом завис!

Запускаем третий сеанс, в котором будем разбираться кто кого заблокировал. Подключаемся к базе postgres и выполняем:

postgres@s-pg13:~$ psql
Timing is on.
psql (13.3)
Type "help" for help.

postgres@postgres=# SELECT pid, query, state, wait_event, wait_event_type, pg_blocking_pids(pid) FROM pg_stat_activity WHERE backend_type = 'client backend' \gx
-[ RECORD 1 ]----+------------------------------------------------------------------------------------------------------------------------------------------
pid              | 15360
query            | UPDATE t SET n = n + 1;
state            | idle in transaction
wait_event       | ClientRead
wait_event_type  | Client
pg_blocking_pids | {}
-[ RECORD 2 ]----+------------------------------------------------------------------------------------------------------------------------------------------
pid              | 15396
query            | UPDATE t SET n = n + 2;
state            | active
wait_event       | transactionid
wait_event_type  | Lock
pg_blocking_pids | {15360}
-[ RECORD 3 ]----+------------------------------------------------------------------------------------------------------------------------------------------
pid              | 15412
query            | SELECT pid, query, state, wait_event, wait_event_type, pg_blocking_pids(pid) FROM pg_stat_activity WHERE backend_type = 'client backend'
state            | active
wait_event       |
wait_event_type  |
pg_blocking_pids | {}

Time: 5,000 ms

В запросе мы получали следующую информацию:

• pid — идентификаторе процесса;
• query — текст запроса;
• state — состояние процесса;
• wait_event — чего этот процесс ожидает;
• wait_event_type — тип ожидания;
• pg_blocking_pids(pid) — с помощью этой функции, посмотрим pid процесса которого ожидает этот процесс.

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

В конфигурации сервера есть параметр:

• idle_in_transaction_session_timeout — принудительно завершает сеансы, в которых транзакция простаивает больше указанного времени.

Теперь завершим зависший процесс вручную:

postgres@postgres=# SELECT pg_terminate_backend(15360);
 pg_terminate_backend
----------------------
 t
(1 row)

Time: 0,300 ms

После этого второй терминал должен отвиснуть и запрос выполится:

postgres@admin_monitoring=# UPDATE t SET n = n + 2;
UPDATE 1
Time: 204915,650 ms (03:24,916)

Дальше посмотрим некоторую информацию по всем процессам (фоновым и обслуживающим) которые есть в этом представлении:

postgres@postgres=# SELECT pid, backend_type, backend_start, state FROM pg_stat_activity;
  pid  |         backend_type         |         backend_start         | state
-------+------------------------------+-------------------------------+--------
 29397 | logical replication launcher | 2021-06-25 15:32:38.013169+03 |
 29395 | autovacuum launcher          | 2021-06-25 15:32:38.014063+03 |
 15396 | client backend               | 2021-06-28 16:46:15.1184+03   | idle
 15412 | client backend               | 2021-06-28 16:47:10.278381+03 | active
 29393 | background writer            | 2021-06-25 15:32:38.014382+03 |
 29392 | checkpointer                 | 2021-06-25 15:32:38.014499+03 |
 29394 | walwriter                    | 2021-06-25 15:32:38.014213+03 |
(7 rows)

Time: 0,651 ms

Сравним с выводом команды операционной системы ps:

postgres@postgres=# \q

postgres@s-pg13:~$ ps -o pid,command --ppid `head -n 1 $PGDATA/postmaster.pid`
  PID COMMAND
15396 postgres: postgres admin_monitoring [local] idle
29392 postgres: checkpointer
29393 postgres: background writer
29394 postgres: walwriter
29395 postgres: autovacuum launcher
29396 postgres: stats collector
29397 postgres: logical replication launcher

Можно заметить, что в представлении pg_stat_activity нет процесса stats collector.

---