Как стать автором
Обновить

Что нового в плане мониторинга в PostgreSQL 14

Время на прочтение 6 мин
Количество просмотров 5.1K
Всем привет, на этой неделе вышел бета-релиз PostgreSQL 14. В этом небольшом посте я сделаю краткий обзор того что есть нового и полезного в плане мониторинга и наблюдения.

По идее пост должен быть интересен тем кому небезразлична тема мониторинга и поиска проблем в PostgreSQL — системные администраторы, DBA, SRE, DBRE.

  1. В 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
    


  2. В pg_stat_activity в списке процессов теперь также отображается WAL archiver. Пока информации не так много, так что не особо информативно и есть куда развиваться далее.
  3. В pg_stat_activity для wal sender процессов (участвуют в репликации), в поле query отображается команда протокола репликации. Это небольшое улучшение позволяет отслеживать команды репликации между мастером и репликами, раньше это возможно было только через логи с включенным параметром log_replication_commands.
  4. В 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
    	


  5. Пара групп полей в pg_stat_database. Первая группа это session_time, active_time, idle_in_transaction_time — коротко, в этих полях посчитано сколько времени проведено сессиями. Есть нюанс — счетчики обновляются в момент смены состояния (поле state), поэтому если сессия долгое время находится в одном состоянии, то это время засчитается только тогда когда оно (состояние) сменится на другое или сессия завершится. Вторая группа полей — sessions, sessions_abandoned, sessions_fatal, sessions_killed определяет статистику по сессиям и причинам их завершения. Обе группы счетчиков так и просятся в графики на мониторинг.
  6. Новое представление 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
    


  7. Новое представление 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
    


  8. Новое представление для наблюдения за логическими слотами репликации — pg_stat_replication_slots. Если используется логическая репликация (PUBLICATIONS/SUBSCRIPTIONS, или например Debezium), то это будет полезно в добавок к уже имеющейся pg_replication_slots.
  9. Новое поле toplevel в pg_stat_statements. Известно что pg_stat_statements можно настроить так, чтобы хранить статистику о запросах вложенных в процедуры и функции. Однако если считать агрегаты, то можно получить неверные результаты — статистика по вложенным запросам посчитается дважды. Все из-за того, что непонятно как отличить вложенный запрос от нормального. Новое поле позволяет отличать запросы и исключать их.
  10. Новое представление pg_stat_statements_info. Пока там всего два значения — время сброса статистики и количество выброшенных значений из pg_stat_statements. Второе значение представляет пользу, поскольку pg_stat_statements имеет лимит на количество записей и если лимит достигнут, то старые записи будут удалены и этого никто не узнает. Теперь же это можно отследить и при необходимости пересмотреть значение pg_stat_statements.max.
  11. Новое представление pg_backend_memory_contexts — одно из нововедений которое вызвало у меня противоречивые эмоции. Показывает распределение используемой памяти текущим процессом. Представление как мне кажется предназначено для разработчиков и для отладки на предмет утечек памяти при долгой работе сессий.
  12. Здесь как бы продолжение предыдущего пункта, в котором будет понятен тезис про эмоции.

    Новая функция pg_log_backend_memory_contexts() — это развитие предыдущего улучшения, функция принимает в качестве аргумента идентификатор процесса и сохраняет в журнал, статистику утилизации подобно той что в представлении pg_backend_memory_contexts.

    И вот тут как мне кажется, разработчики перемудрили — достаточно было бы сделать только одну эту функцию (без вьюхи) которая бы принимала идентификатор процесса, но при этом вместо логирования, выводила бы статистику в виде строк. В таком случае можно взять статистику и по текущей сессии и по любой соседней. При этом возможность залогировать вывод тоже никуда не девается (хоть и не в журнал, но тем не менее возможность есть). А в текущем виде есть представление и функция с логированием и еще в журнал надо сходить, чтобы достать сброшенную статистику. Короче, мне реализация показалось слегка странной.
  13. Новые поля в pg_prepared_statementsgeneric_plans, custom_plans — для подсчета количества планов для каждого запроса. Честно, я практически этим представлением никогда не пользовался и у меня нет практических примеров его применения.
  14. Новая функция pg_get_wal_replay_pause_state(). Чуть более улучшенная версия функции pg_is_wal_replay_paused(). Показывает состояние постановки репликации на паузу. Доступно три варианта — not paused, pause requested, paused.
  15. Новый параметр log_recovery_conflict_waits — включает журналирование случаев когда воспроизведение WAL журнала на реплике вступает в конфликт и ждет разрешения конфликта. Штука полезная, я бы рекомендовал включать по-умолчанию.
  16. Новые операторы для 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
    


  17. Добавлена информация о таймингах ввода-вывода при журналировании операций 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 июня

На этом все, спасибо за внимание!
Теги:
Хабы:
+20
Комментарии 0
Комментарии Комментировать

Публикации

Истории

Работа

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн