Всем привет, на этой неделе вышел бета-релиз PostgreSQL 14. В этом небольшом посте я сделаю краткий обзор того что есть нового и полезного в плане мониторинга и наблюдения.
По идее пост должен быть интересен тем кому небезразлична тема мониторинга и поиска проблем в PostgreSQL — системные администраторы, DBA, SRE, DBRE.
Вот и всё.
В завершение хочу сделать анонс мероприятия — 8 и 9 июля в онлайне состоится PG Day’21 Russia. Это будет двух-дневная тусовка фанатов PostgreSQL, 12 выступлений от отечественных и зарубежных докладчиков. Участие бесплатное. Прием докладов также открыт до 7 июня
На этом все, спасибо за внимание!
По идее пост должен быть интересен тем кому небезразлична тема мониторинга и поиска проблем в PostgreSQL — системные администраторы, DBA, SRE, DBRE.
- В pg_stat_activity добавлено новое поле query_id. Поле содержит идентификатор запроса аналогичный тому что есть в pg_stat_statements. Таким образом с помощью трио полей datid/userid/query_id можно присоединить pg_stat_statements и посмотреть накопленную статистику по конкретному типу запросов. Забавный нюанс — имена полей для объединения между pg_stat_activity и pg_stat_statements отличаются.
Осторожно, текстselect a.*, s.* from pg_stat_activity a inner join pg_stat_statements s on (a.datid = s.dbid AND a.usesysid = s.userid AND a.query_id = s.queryid) where a.pid = 1001291; -[ RECORD 1 ]-------+----------------------------------------------------------- datid | 16413 datname | pgbench pid | 1001291 leader_pid | usesysid | 10 usename | postgres application_name | pgbench client_addr | client_hostname | client_port | -1 backend_start | 2021-05-22 10:15:57.299468+05 xact_start | 2021-05-22 10:16:25.566151+05 query_start | 2021-05-22 10:16:25.566623+05 state_change | 2021-05-22 10:16:25.566763+05 wait_event_type | wait_event | state | idle in transaction backend_xid | 237577 backend_xmin | query_id | 2517686606037258902 query | SELECT abalance FROM pgbench_accounts WHERE aid = 1715456; backend_type | client backend userid | 10 dbid | 16413 toplevel | t queryid | 2517686606037258902 query | SELECT abalance FROM pgbench_accounts WHERE aid = $1 plans | 0 total_plan_time | 0 min_plan_time | 0 max_plan_time | 0 mean_plan_time | 0 stddev_plan_time | 0 calls | 209439 total_exec_time | 4251.98569499987 min_exec_time | 0.005414 max_exec_time | 0.435581 mean_exec_time | 0.020301785698938563 stddev_exec_time | 0.005889254053319066 rows | 209439 shared_blks_hit | 884097 shared_blks_read | 0 shared_blks_dirtied | 0 shared_blks_written | 0 local_blks_hit | 0 local_blks_read | 0 local_blks_dirtied | 0 local_blks_written | 0 temp_blks_read | 0 temp_blks_written | 0 blk_read_time | 0 blk_write_time | 0 wal_records | 149 wal_fpi | 2 wal_bytes | 9870
- В pg_stat_activity в списке процессов теперь также отображается WAL archiver. Пока информации не так много, так что не особо информативно и есть куда развиваться далее.
- В pg_stat_activity для wal sender процессов (участвуют в репликации), в поле query отображается команда протокола репликации. Это небольшое улучшение позволяет отслеживать команды репликации между мастером и репликами, раньше это возможно было только через логи с включенным параметром log_replication_commands.
- В pg_locks добавлено поле waitstart — время с которого началось ожидание. Поле позволяет получить время ожидания и при этом не присоединять pg_stat_activity. С одной стороны вроде и удобно, но чтобы взять текст запроса, все равно понадобится присоединить pg_stat_activity. А вот для использования в качестве метрики, вполне подходит т.к. в таком случае текст запроса может быть неинтересен.
Выглядит так# select pid,mode,now()-waitstart as wait_time from pg_locks where not granted; -[ RECORD 1 ]-------------- pid | 1068094 mode | ShareLock wait_time | 00:00:12.669753 -[ RECORD 2 ]-------------- pid | 1068093 mode | ShareLock wait_time | 00:00:14.789208
- Пара групп полей в pg_stat_database. Первая группа это session_time, active_time, idle_in_transaction_time — коротко, в этих полях посчитано сколько времени проведено сессиями. Есть нюанс — счетчики обновляются в момент смены состояния (поле state), поэтому если сессия долгое время находится в одном состоянии, то это время засчитается только тогда когда оно (состояние) сменится на другое или сессия завершится. Вторая группа полей — sessions, sessions_abandoned, sessions_fatal, sessions_killed определяет статистику по сессиям и причинам их завершения. Обе группы счетчиков так и просятся в графики на мониторинг.
- Новое представление pg_stat_progress_copy. По названию очевидно что представление показывает ход выполнения команд COPY. Полезно за наблюдением того как 1) выполняется выгрузка и загрузка дампов (pg_dump), 2) непосредственное выполнение команд COPY, 3) выполнение начальной загрузки таблиц при использовании логической репликации через публикации/подписки.
Пример копирования из файла в таблицу-[ RECORD 1 ]----+---------- pid | 1068106 datid | 16413 datname | pgbench relid | 17612 command | COPY FROM type | FILE bytes_processed | 30998528 bytes_total | 195764221 tuples_processed | 313263 tuples_excluded | 0
- Новое представление pg_stat_wal — с помощью него можно получить подробное представление об объемах генерируемого WAL. До версии 13 ничего подобного не было. Затем в 13-й версии подобная статистика была добавлена в pg_stat_statements и если ее просуммировать можно получить нечто похожее. Теперь эта статистика расширена и есть в более обобщенном виде (не привязана к запросам).
Пример-[ RECORD 1 ]----+------------------------------ wal_records | 40811237 wal_fpi | 1551923 wal_bytes | 13744020096 wal_buffers_full | 509935 wal_write | 1177449 wal_sync | 666045 wal_write_time | 26449.751 wal_sync_time | 10956905.427 stats_reset | 2021-05-21 10:33:39.009804+05
- Новое представление для наблюдения за логическими слотами репликации — pg_stat_replication_slots. Если используется логическая репликация (PUBLICATIONS/SUBSCRIPTIONS, или например Debezium), то это будет полезно в добавок к уже имеющейся pg_replication_slots.
- Новое поле toplevel в pg_stat_statements. Известно что pg_stat_statements можно настроить так, чтобы хранить статистику о запросах вложенных в процедуры и функции. Однако если считать агрегаты, то можно получить неверные результаты — статистика по вложенным запросам посчитается дважды. Все из-за того, что непонятно как отличить вложенный запрос от нормального. Новое поле позволяет отличать запросы и исключать их.
- Новое представление pg_stat_statements_info. Пока там всего два значения — время сброса статистики и количество выброшенных значений из pg_stat_statements. Второе значение представляет пользу, поскольку pg_stat_statements имеет лимит на количество записей и если лимит достигнут, то старые записи будут удалены и этого никто не узнает. Теперь же это можно отследить и при необходимости пересмотреть значение pg_stat_statements.max.
- Новое представление pg_backend_memory_contexts — одно из нововедений которое вызвало у меня противоречивые эмоции. Показывает распределение используемой памяти текущим процессом. Представление как мне кажется предназначено для разработчиков и для отладки на предмет утечек памяти при долгой работе сессий.
- Здесь как бы продолжение предыдущего пункта, в котором будет понятен тезис про эмоции.
Новая функция pg_log_backend_memory_contexts() — это развитие предыдущего улучшения, функция принимает в качестве аргумента идентификатор процесса и сохраняет в журнал, статистику утилизации подобно той что в представлении pg_backend_memory_contexts.
И вот тут как мне кажется, разработчики перемудрили — достаточно было бы сделать только одну эту функцию (без вьюхи) которая бы принимала идентификатор процесса, но при этом вместо логирования, выводила бы статистику в виде строк. В таком случае можно взять статистику и по текущей сессии и по любой соседней. При этом возможность залогировать вывод тоже никуда не девается (хоть и не в журнал, но тем не менее возможность есть). А в текущем виде есть представление и функция с логированием и еще в журнал надо сходить, чтобы достать сброшенную статистику. Короче, мне реализация показалось слегка странной.
- Новые поля в pg_prepared_statements — generic_plans, custom_plans — для подсчета количества планов для каждого запроса. Честно, я практически этим представлением никогда не пользовался и у меня нет практических примеров его применения.
- Новая функция pg_get_wal_replay_pause_state(). Чуть более улучшенная версия функции pg_is_wal_replay_paused(). Показывает состояние постановки репликации на паузу. Доступно три варианта — not paused, pause requested, paused.
- Новый параметр log_recovery_conflict_waits — включает журналирование случаев когда воспроизведение WAL журнала на реплике вступает в конфликт и ждет разрешения конфликта. Штука полезная, я бы рекомендовал включать по-умолчанию.
- Новые операторы для pg_lsn типа. Тип pg_lsn используется для работы с позицией в WAL журнале — например с помощью этого типа удобно считать лаг репликации в байтах. С помощью двух новых операторов арифметика стала проще и значения pg_lsn можно складывать или вычитать с целыми числами.
Пока не придумал где использовать, но выглядит клевоpgbench=# select '1/8000000'::pg_lsn + 16777216; -[ RECORD 1 ]------- ?column? | 1/9000000 pgbench=# select '1/8000000'::pg_lsn - 16777216; -[ RECORD 1 ]------- ?column? | 1/7000000
- Добавлена информация о таймингах ввода-вывода при журналировании операций autovacuum и autoanalyze. Должен быть включен log_autovacuum_min_duration.
А ну-ка попробуйте отыскать2021-05-22 10:50:48.000 +05 1005664 @ from [vxid:4/309623 txid:0] [] LOG: automatic vacuum of table "pgbench.public.pgbench_accounts": index scans: 1 pages: 0 removed, 65600 remain, 0 skipped due to pins, 0 skipped frozen tuples: 1936414 removed, 2000605 remain, 566 are dead but not yet removable, oldest xmin: 253998 buffer usage: 92201 hits, 108672 misses, 129131 dirtied index scan needed: 58623 pages from table (89.36% of total) had 1961508 dead item identifiers removed index "pgbench_accounts_pkey": pages: 10970 in total, 0 newly deleted, 0 currently deleted, 0 reusable avg read rate: 3.522 MB/s, avg write rate: 4.185 MB/s I/O Timings: read=392.361 write=1964.360 system usage: CPU: user: 2.92 s, system: 1.79 s, elapsed: 241.07 s WAL usage: 195815 records, 72916 full page images, 308792606 bytes
Вот и всё.
В завершение хочу сделать анонс мероприятия — 8 и 9 июля в онлайне состоится PG Day’21 Russia. Это будет двух-дневная тусовка фанатов PostgreSQL, 12 выступлений от отечественных и зарубежных докладчиков. Участие бесплатное. Прием докладов также открыт до 7 июня
На этом все, спасибо за внимание!
