Использование gp_toolkit

Павел Семёнов

Contents

Проверка использования диска
Выявление проблем кластера
Мониторинг блокировок в кластере
Просмотр логов базы данных
Просмотр параметров конфигурации
Мониторинг использования ресурсов
- Ресурсные группы
- Ресурсные очереди
Проверка AO-таблиц
- Сегментные файлы
- Карты видимости AO-таблиц
Просмотр пользователей и ролей

gp_toolkit — это встроенная административная схема Greengage DB. Она содержит набор представлений, функций и вспомогательных таблиц, которые отображают информацию из системных каталогов и логов кластера, а также состояние окружения. Представления gp_toolkit оборачивают SQL-запросы к внутренним системным таблицам, представляя результаты в более структурированном и удобном для чтения виде. Их использование упрощает регулярный мониторинг и обслуживание кластера.

Схема gp_toolkit доступна всем пользователям базы данных, но для просмотра некоторых ее объектов требуются права суперпользователя. В большинстве случаев вывод также ограничен объектами, к которым текущий пользователь имеет доступ.

РЕКОМЕНДАЦИЯ

Чтобы упростить использование gp_toolkit, добавьте эту схему в путь поиска схемы. Это позволит обращаться к объектам gp_toolkit без явного указания схемы:

SET search_path TO public, gp_toolkit;

В этом разделе приводятся примеры использования gp_toolkit для типичных административных задач в Greengage DB: проверка использования диска, выявление раздувания или перекоса данных, анализ потребления ресурсов. Подробная информация о конкретных аспектах обслуживания СУБД приводится в соответствующих разделах документации.

Просмотр материализованных представлений с помощью gp_toolkit

По умолчанию представления gp_toolkit показывают информацию только о таблицах. Чтобы они также включали материализованные представления, необходимо изменить внутреннее представление __gp_user_tables. Для этого необходимы права суперпользователя.

Отобразите текущее определение __gp_user_tables, используя метакоманду \d+:

\d+ gp_toolkit.__gp_user_tables

Вывод покажет определение представления, например:

<...>
View definition:
 SELECT fn.fnnspname AS autnspname,
    fn.fnrelname AS autrelname,
    pgc.relkind AS autrelkind,
    pgc.reltuples AS autreltuples,
    pgc.relpages AS autrelpages,
    pgc.relacl AS autrelacl,
    pgc.oid AS autoid,
    pgc.reltoastrelid AS auttoastoid,
    pgc.relstorage AS autrelstorage
   FROM pg_class pgc,
    gp_toolkit.__gp_fullname fn
  WHERE (pgc.relnamespace IN ( SELECT __gp_user_namespaces.aunoid
           FROM gp_toolkit.__gp_user_namespaces)) AND pgc.relkind = 'r'::"char" AND pgc.oid = fn.fnoid;

Найдите условие, которое фильтрует объекты по их виду отношения (relkind):

pgc.relkind = 'r'::"char"

Пересоздайте представление с помощью CREATE OR REPLACE VIEW AS, добавив дополнительный вид отношения — материализованные представления (pgc.relkind = 'm'):

CREATE OR REPLACE VIEW gp_toolkit.__gp_user_tables
AS
 SELECT fn.fnnspname AS autnspname,
    fn.fnrelname AS autrelname,
    pgc.relkind AS autrelkind,
    pgc.reltuples AS autreltuples,
    pgc.relpages AS autrelpages,
    pgc.relacl AS autrelacl,
    pgc.oid AS autoid,
    pgc.reltoastrelid AS auttoastoid,
    pgc.relstorage AS autrelstorage
   FROM pg_class pgc,
    gp_toolkit.__gp_fullname fn
  WHERE (pgc.relnamespace IN ( SELECT __gp_user_namespaces.aunoid
           FROM gp_toolkit.__gp_user_namespaces))
    AND (pgc.relkind = 'r' OR pgc.relkind = 'm')
    AND pgc.oid = fn.fnoid;

Обновите права доступа:

GRANT SELECT ON TABLE gp_toolkit.__gp_user_tables TO public;

Имейте в виду, что изменения в gp_toolkit теряются после восстановления базы данных из резервной копии. После восстановления необходимо повторно применить это изменение.

Для анализа размеров объектов, хранящихся в Greengage DB, используйте представления gp_toolkit с префиксом gp_size_of_*. Они предоставляют информацию об использовании диска объектами на разных уровнях: базы данных, схемы, таблицы и индексов. Доступны следующие представления:

gp_size_of_database — размеры пользовательских баз данных в кластере (в байтах). Выводит все базы данных кластера, кроме созданных по умолчанию: postgres, template0 и template1. Например, этот запрос показывает размеры баз данных по порядку от наибольших к наименьшим:
```
SELECT * FROM gp_toolkit.gp_size_of_database
ORDER BY sodddatsize DESC;
```
Пример вывода:
```
 sodddatname | sodddatsize
-------------+-------------
 books_store |    86444564
 util        |    85855700
 marketplace |    84544020
 diskquota   |    84544020
(4 rows)
```
gp_size_of_schema_disk — размеры схем в текущей базе данных (в байтах). Представление показывает два значения: общий объем данных таблиц и общий объем индексов каждой схемы, включая public и пользовательские схемы. Пример:
```
SELECT * FROM gp_toolkit.gp_size_of_schema_disk;
```
Пример вывода:
```
 sosdnsp  | sosdschematablesize | sosdschemaidxsize
----------+---------------------+-------------------
 internal |                   0 |                 0
 public   |           120455168 |          85360640
 sales    |              163840 |                 0
(3 rows)
```
gp_size_of_table_disk — размеры таблиц в текущей базе данных. Размер таблицы делится на части: основные данные таблицы, большие атрибуты в формате TOAST, а также метаданные оптимизированных для добавления (AO) таблиц. Например, этот запрос находит пять самых больших таблиц в текущей базе:
```
SELECT * FROM gp_toolkit.gp_size_of_table_disk
ORDER BY sotdsize DESC
LIMIT 5;
```
Пример вывода:
```
 sotdoid | sotdsize  | sotdtoastsize | sotdadditionalsize | sotdschemaname | sotdtablename
---------+-----------+---------------+--------------------+----------------+---------------
   16469 | 420872192 |        163840 |                  0 | public         | orders
   24718 |    131072 |        163840 |                  0 | public         | items
   16515 |     98304 |        163840 |                  0 | sales          | customers
   16431 |     68456 |             0 |             589824 | sales          | orders
(4 rows)
```
Для AO-таблиц со сжатием также полезно представление gp_size_of_table_uncompressed — оно показывает логический размер таблицы до сжатия. Для несжатых таблиц значение совпадает с фактическим размером на диске.

gp_size_of_index — размеры индексов в текущей базе данных. Например, так можно проверить размеры всех индексов заданной таблицы:

SELECT * FROM gp_toolkit.gp_size_of_index
WHERE soitableschemaname = 'public' AND soitablename = 'orders';

Пример вывода:

 soioid | soitableoid | soisize  | soiindexschemaname |    soiindexname    | soitableschemaname | soitablename
--------+-------------+----------+--------------------+--------------------+--------------------+--------------
  16487 |       16469 | 62750720 | public             | orders_comment_idx | public             | orders
  16486 |       16469 | 22609920 | public             | orders_total_idx   | public             | orders
(3 rows)

Те же агрегированные данные можно получить из представления gp_size_of_all_table_indexes. Оно показывает суммарный размер индексов каждой таблицы.

gp_size_of_table_and_indexes_disk — общий размер каждой таблицы на диске с учетом всех индексов. Например, чтобы найти самые большие таблицы по суммарному размеру данных и индексов:

SELECT
    sotaidtablename,
    sotaidschemaname,
    sotaidtablesize,
    sotaididxsize,
    sotaidtablesize + sotaididxsize AS total_size
FROM gp_toolkit.gp_size_of_table_and_indexes_disk
ORDER BY total_size DESC
LIMIT 3;

Пример вывода:

 sotaidtablename | sotaidschemaname | sotaidtablesize | sotaididxsize | total_size
-----------------+------------------+-----------------+---------------+------------
 orders          | public           |       120455168 |      85360640 |  205815808
 customers       | sales            |          262144 |        262144 |     524288
 orders          | sales            |          163840 |             0 |     163840
(3 rows)

Внешняя таблица gp_disk_free отображает объем свободного места на каждом сегмент-хосте в килобайтах.

Следующий запрос сортирует сегменты кластера по свободному месту на их хостах, начиная с наиболее занятого:

SELECT * FROM gp_toolkit.gp_disk_free ORDER BY dfspace;

Пример вывода:

 dfsegment | dfhostname |  dfdevice  | dfspace
-----------+------------+------------+----------
         3 |    sdw2    |  /dev/vda2 | 19906016
         2 |    sdw2    |  /dev/vda2 | 19906016
         0 |    sdw1    |  /dev/vda2 | 20304960
         1 |    sdw1    |  /dev/vda2 | 20304960
(4 rows)

Обратите внимание, что gp_disk_free отображает по одной строке на каждый сегмент. Если на одном хосте запущено несколько сегментов, этот хост будет показан несколько раз. Кроме того, столбец dfspace отражает общее свободное место в файловой системе, а не пространство, зарезервированное под конкретный сегмент.

РЕКОМЕНДАЦИЯ

Для стабильной работы кластера оставляйте не менее 30% свободного места на каждом хосте. При большей занятости дисков растет риск сбоев при выполнении запросов, невозможности создания spill-файлов и откатов транзакций.

Для мониторинга использования spill-файлов в кластере используйте представления gp_workfile_*.

С помощью представления gp_workfile_usage_per_query можно проверить, какие запросы порождают spill-файлы, а также количество этих файлов и объем занимаемого ими места на каждом сегменте. Пример запроса:

SELECT datname, query, segid, size, numfiles
FROM gp_toolkit.gp_workfile_usage_per_query
ORDER BY size;

Пример вывода:

   datname   |                                           query                                            | segid |   size   | numfiles
-------------+--------------------------------------------------------------------------------------------+-------+----------+----------
 marketplace | SELECT DISTINCT (item_id, price, count), value FROM items GROUP BY item_id ORDER BY value; |     2 | 18350080 |        1
 marketplace | SELECT DISTINCT (item_id, price, count), value FROM items GROUP BY item_id ORDER BY value; |     0 | 18317312 |        1
 marketplace | SELECT DISTINCT (item_id, price, count), value FROM items GROUP BY item_id ORDER BY value; |     3 | 18317312 |        1
 marketplace | SELECT DISTINCT (item_id, price, count), value FROM items GROUP BY item_id ORDER BY value; |     1 | 18219008 |        1
(4 rows)

Представление gp_workfile_entries детализирует эту информацию до уровня конкретных операторов запроса, которые вызвали создание spill-файлов — сортировок, соединений и других. gp_workfile_usage_per_segment агрегирует данные об использовании spill-файлов по сегментам, помогая выявлять неравномерную нагрузку на диски.

Более подробную информацию о проверке spill-файлов и примеры запросов см. в разделе Проверка spill-файлов.

Представление gp_pgdatabase_invalid показывает сегменты, которые в данный момент помечены как неработающие в конфигурации кластера. Каждая строка отражает один сегмент базы данных на сегмент-хосте, который вышел из строя.

SELECT * FROM gp_toolkit.gp_pgdatabase_invalid;

Пример вывода:

 pgdbidbid | pgdbiisprimary | pgdbicontent | pgdbivalid | pgdbidefinedprimary
-----------+----------------+--------------+------------+---------------------
         4 | f              |            2 | f          | t
         5 | f              |            3 | f          | t
         6 | f              |            0 | f          | f
         7 | f              |            1 | f          | f
(4 rows)

В выводе показана информация о сегментах, вышедших из строя: являются ли они основными или зеркальными (pgdbiisprimary), а также их идентификаторы сегмента данных (pgdbicontent).

Информация о восстановлении сегментов приведена в разделе Проверка и восстановление сегментов.

Два представления gp_toolkit — gp_bloat_diag и gp_bloat_expected_pages — помогают диагностировать раздувание в heap-таблицах:

gp_bloat_diag — выводит только таблицы с подозрением на раздувание. Для каждой таблицы указывается диагностическое сообщение с оценкой степени раздувания: умеренная (moderate) или значительная (significant). Эта оценка вычисляется на основе соотношения фактического и ожидаемого числа страниц, используемых таблицей. Чтобы быстро найти таблицы со значительным раздуванием, используйте запрос:
```
SELECT *
FROM gp_toolkit.gp_bloat_diag
WHERE bdidiag LIKE '%significant%';
```
gp_bloat_expected_pages — показывает фактическое и ожидаемое количество страниц для всех heap-таблиц. Используя это представление, вы можете выбрать свое пороговое значение для поиска раздувшихся таблиц:
```
SELECT *
FROM gp_toolkit.gp_bloat_expected_pages
WHERE btdrelpages / btdexppages > 5
ORDER BY btdrelpages / btdexppages;
```
Вы также можете фильтровать результаты по схемам, проверять отдельные таблицы или упорядочить все таблицы по числу избыточных страниц.

Больше примеров и информации о диагностике раздувания вы можете найти в разделе Проверка раздувания таблиц.

Представление gp_stats_missing в gp_toolkit выводит таблицы, для которых в системном каталоге отсутствует статистика.

SELECT * FROM gp_toolkit.gp_stats_missing;

Пример вывода:

 smischema | smitable | smisize | smicols | smirecs
-----------+----------+---------+---------+---------
 public    | test     | f       |       1 |       0
 sales     | orders   | f       |       5 |       0
(2 rows)

Этим таблицам требуется сбор статистики (ANALYZE), чтобы оптимизатор мог строить эффективные планы выполнения запросов. Подробнее о статистике базы данных рассказывается в статье Сбор статистики с помощью ANALYZE.

Представления gp_toolkit.gp_skew_* предоставляют информацию о перекосе данных в кластере. С их помощью можно выявить неравномерное распределение данных по сегментам, которое может вызывать снижение производительности:

gp_skew_coefficients — измеряет перекос с помощью коэффициента вариации (CV) для данных таблицы на каждом сегменте. Более высокие значения CV указывают на больший перекос. Например, следующий запрос сортирует таблицы в порядке убывания коэффициента вариации:
```
SELECT skcnamespace, skcrelname, skccoeff
FROM gp_toolkit.gp_skew_coefficients
ORDER BY skccoeff DESC;
```
Пример вывода:
```
 skcnamespace | skcrelname |         skccoeff
--------------+------------+-------------------------
 sales        | customers  | 2.979247332241260000000
 public       | orders     | 0.187996312020564400000
 sales        | orders     |                       0
(3 rows)
```
gp_skew_idle_fractions — измеряет перекос использования вычислительных ресурсов (computational skew), то есть долю системных ресурсов, которые остаются неиспользованными во время сканирования таблицы. Если значение превышает 0.1 (10%), таблица может быть распределена неравномерно:
```
SELECT sifnamespace, sifrelname, siffraction
FROM gp_toolkit.gp_skew_idle_fractions;
```
Пример вывода:
```
 sifnamespace | sifrelname |      siffraction
--------------+------------+------------------------
 sales        | orders     |                      0
 public       | orders     | 0.00262906977208079502
 sales        | customers  | 0.50000000000000000000
(3 rows)
```

Подробнее о проверке и устранении перекоса рассказывается в разделе Проверка распределения данных.

Представления gp_toolkit.gp_locks_* выводят информацию о блокировках в базе данных. Они полезны для диагностики проблем с блокировками или медленных SQL-запросов в кластере Greengage DB:

gp_locks_on_relation — показывает блокировки, которые в данный момент удерживаются на отношениях (relation) базы данных. Для каждой блокировки отображаются имя отношения, тип блокировки, SQL-запрос, который удерживает или ожидает блокировку, и другая информация. Пример:

SELECT lorlocktype, lordatabase, lorrelname, lorpid, lormode, lorgranted
FROM gp_toolkit.gp_locks_on_relation
WHERE lorcurrentquery LIKE '%gp_toolkit.gp_locks_on_relation%';

Результат показывает, что этот SQL-запрос сам накладывает блокировки на системные таблицы, такие как pg_class или pg_locks:

 lorlocktype | lordatabase |            lorrelname             | lorpid |     lormode     | lorgranted
-------------+-------------+-----------------------------------+--------+-----------------+------------
 relation    |       12812 | gp_locks_on_relation              |   3388 | AccessShareLock | t
 relation    |           0 | pg_authid                         |   3388 | AccessShareLock | t
 relation    |           0 | pg_authid_oid_index               |   3388 | AccessShareLock | t
 relation    |           0 | pg_authid_rolname_index           |   3388 | AccessShareLock | t
 relation    |           0 | pg_authid_rolresgroup_index       |   3388 | AccessShareLock | t
 relation    |           0 | pg_authid_rolresqueue_index       |   3388 | AccessShareLock | t
 relation    |       12812 | pg_class                          |   3388 | AccessShareLock | t
 relation    |       12812 | pg_class_oid_index                |   3388 | AccessShareLock | t
 relation    |       12812 | pg_class_relname_nsp_index        |   3388 | AccessShareLock | t
 relation    |       12812 | pg_class_tblspc_relfilenode_index |   3388 | AccessShareLock | t
 relation    |           0 | pg_database                       |   3388 | AccessShareLock | t
 relation    |           0 | pg_database_datname_index         |   3388 | AccessShareLock | t
 relation    |           0 | pg_database_oid_index             |   3388 | AccessShareLock | t
 relation    |       12812 | pg_locks                          |   3388 | AccessShareLock | t
 relation    |       12812 | pg_stat_activity                  |   3388 | AccessShareLock | t
(15 rows)

gp_locks_on_resqueue — отображает блокировки в ресурсных очередях, если очереди используются для управления ресурсами кластера. Это представление помогает администраторам проверить, в каких ресурсных очередях SQL-запросы ожидают выполнения из-за достижения лимитов очереди.
```
SELECT lorrsqname, lorlocktype, lorobjid, lormode, lorwaiting
FROM gp_toolkit.gp_locks_on_resqueue
WHERE lorwaiting = true;
```
Пример вывода:
```
 lorrsqname |  lorlocktype   | lorobjid |    lormode    | lorwaiting
------------+----------------+----------+---------------+------------
 reporting  | resource queue |    16449 | ExclusiveLock | t
(1 row)
```

gp_toolkit содержит представления для доступа к логам Greengage DB из SQL-консоли. Эти представления основаны на внешних таблицах, которые обращаются напрямую к лог-файлам кластера. Данные представления доступны только суперпользователям.

gp_log_command_timings — показывает отметки времени и длительность выполнения SQL-команд, выполненных в кластере. Например, чтобы узнать, какие пользователи запускали SQL-запросы длительностью более 5 секунд в течение последнего часа:
```
SELECT
    logsession,
    loguser,
    logdatabase,
    logcmdcount,
    logtimemin AS start_time,
    logduration
FROM gp_toolkit.gp_log_command_timings
WHERE logduration > INTERVAL '5 seconds'
  AND logtimemin > now() - INTERVAL '1 hour'
ORDER BY logtimemin DESC;
```
Пример вывода:
```
 logsession | loguser | logdatabase | logcmdcount |          start_time           |   logduration
------------+---------+-------------+-------------+-------------------------------+-----------------
 con8       | alice   | postgres    | cmd1        | 2025-08-28 03:49:50.140174+00 | 00:00:25.940927
(1 row)
```
Чтобы увидеть сами запросы, используйте представления, описанные ниже, например, gp_log_database.

gp_log_database — показывает события текущей базы данных. Можно фильтровать записи по уровню критичности (severity), например, выводить только ошибки:

SELECT
    logtime,
    loguser,
    logdatabase,
    logseverity,
    logmessage
FROM gp_toolkit.gp_log_database
WHERE logseverity IN ('ERROR','FATAL','PANIC')
ORDER BY logtime DESC
LIMIT 5;

Пример результата:

            logtime            | loguser | logdatabase | logseverity |               logmessage
-------------------------------+---------+-------------+-------------+-----------------------------------------
 2025-08-28 03:50:16.081062+00 | alice   | postgres    | ERROR       | canceling statement due to user request
 2025-08-28 03:50:16.079898+00 | alice   | postgres    | ERROR       | canceling MPP operation
 2025-08-28 03:50:16.079793+00 | alice   | postgres    | ERROR       | canceling MPP operation
 2025-08-28 03:50:16.079789+00 | alice   | postgres    | ERROR       | canceling MPP operation
 2025-08-28 03:50:16.079692+00 | alice   | postgres    | ERROR       | canceling MPP operation
(5 rows)

gp_log_master_concise — представляет лог мастер-экземпляра в сокращенной форме. Полезно для быстрого просмотра событий:

SELECT
    logtime,
    logseverity,
    logmessage
FROM gp_toolkit.gp_log_master_concise
ORDER BY logtime DESC
LIMIT 10;

Фрагмент вывода:

            logtime            | logseverity |                                            logmessage
-------------------------------+-------------+--------------------------------------------------------------------------------------------------
 2025-08-28 03:58:10.772125+00 | LOG         | statement: SELECT                                                                               +
                               |             |     logtime,                                                                                    +
                               |             |     logseverity,                                                                                +
                               |             |     logmessage                                                                                  +
                               |             | FROM gp_toolkit.gp_log_master_concise                                                           +
                               |             | ORDER BY logtime DESC                                                                           +
                               |             | LIMIT 5;
 2025-08-28 03:58:07.293417+00 | LOG         | An exception was encountered during the execution of statement: select pg_sleep(10) from orders;
 2025-08-28 03:58:07.293379+00 | ERROR       | canceling statement due to user request
 2025-08-28 03:58:02.799049+00 | LOG         | statement: SELECT                                                                               +
                               |             |     logtime,                                                                                    +
                               |             |     logseverity,                                                                                +
                               |             |     logmessage                                                                                  +
                               |             | FROM gp_toolkit.gp_log_master_concise                                                           +
                               |             | ORDER BY logtime DESC                                                                           +
                               |             | LIMIT 5;
 2025-08-28 03:57:48.153789+00 | LOG         | statement: select pg_sleep(10) from orders;

gp_log_system — показывает подробные логи всех экземпляров кластера: мастера, сегментов и их зеркал. Это наиболее детализированное представление, полезное при диагностике проблем, затрагивающих более одного сегмента:

SELECT
    logtime,
    logseverity,
    logmessage,
    loghost,
    logpid AS pid,
    logfile
FROM gp_toolkit.gp_log_system
WHERE logseverity IN ('ERROR','FATAL','PANIC')
ORDER BY logtime DESC
LIMIT 5;

Пример вывода:

            logtime            | logseverity |               logmessage                |   loghost    |  pid  |     logfile
-------------------------------+-------------+-----------------------------------------+--------------+-------+------------------
 2025-08-28 04:02:51.496107+00 | ERROR       | column "procpid" does not exist         | [local]      | p2418 | parse_relation.c
 2025-08-28 04:02:08.205361+00 | ERROR       | column "hostname" does not exist        | [local]      | p2418 | parse_relation.c
 2025-08-28 04:01:19.729128+00 | ERROR       | permission denied for relation orders   | [local]      | p2523 | aclchk.c
 2025-08-28 03:58:07.293379+00 | ERROR       | canceling statement due to user request | [local]      | p2523 | postgres.c
 2025-08-28 03:58:07.290905+00 | ERROR       | canceling MPP operation                 | 10.92.40.164 | p1531 | postgres.c
(5 rows)

Подробнее о логах Greengage DB см. в статье Логирование.

Функция gp_param_setting('parameter_name') в gp_toolkit выводит значения указанного параметра конфигурации на всех сегментах, включая мастер (сегмент с идентификатором -1) :

SELECT * FROM gp_toolkit.gp_param_setting('max_connections');

Результат может выглядеть так:

 paramsegment |    paramname    | paramvalue
--------------+-----------------+------------
           -1 | max_connections | 250
            0 | max_connections | 750
            1 | max_connections | 750
            2 | max_connections | 750
            3 | max_connections | 750
(5 rows)

Представление gp_param_settings_seg_value_diffs показывает параметры, значения которых отличаются на разных сегментах. Это может указывать на несогласованность конфигурации. Эта проверка применяется только к локальным параметрам, которые задаются независимо на каждом сегменте. Параметры, значения которых ожидаемо различаются (например, порт), исключены. Пример:

SELECT * FROM gp_toolkit.gp_param_settings_seg_value_diffs;

Результат может выглядеть так:

       psdname        | psdvalue | psdcount
----------------------+----------+----------
 tcp_keepalives_count | 9        |        3
 tcp_keepalives_count | 5        |        1
(2 rows)

Подробнее о конфигурации кластера см. в разделе Настройка СУБД с помощью GUC.

Если в кластере используются ресурсные группы, можно использовать представления gp_toolkit.gp_resgroup_* для отслеживания их конфигурации и использования:

gp_resgroup_config — выводит лимиты ресурсных групп. Пример:

SELECT
    groupname,
    concurrency,
    cpu_rate_limit,
    memory_limit
FROM gp_toolkit.gp_resgroup_config
ORDER BY groupname;

Пример результата:

 groupid |   groupname    | concurrency | cpu_rate_limit | memory_limit
---------+----------------+-------------+----------------+--------------
    6437 | default_group  | 20          | 30             | 0
    6438 | admin_group    | 10          | 10             | 10
   16411 | rg_plcontainer | 0           | -1             | 20
   16403 | rg_analysts    | 10          | 20             | 20
(4 rows)

gp_resgroup_status — показывает текущее использование ресурсов на сегментах, включая количество выполняющихся и ожидающих в очереди транзакций. Например, этот запрос выделяет группы, в которых есть запросы в очереди:
```
SELECT rsgname,
       num_running,
       num_queued
FROM gp_toolkit.gp_resgroup_status
WHERE num_queued > 0
ORDER BY num_queued DESC;
```
Пример результата:
```
    rsgname     | num_running | num_queued
----------------+-------------+------------
 admin_group    |          10 |          2
 rg_analysts    |           5 |          1
(2 rows)
```
gp_resgroup_status_per_host и gp_resgroup_status_per_segment — агрегируют текущее использование ресурсных групп по хостам и сегментам. Они полезны для выявления узких мест, когда отдельный хост или сегмент перегружен по сравнению с остальным кластером.

Подробнее см. в разделе Проверка ресурсных групп.

Если в кластере используются ресурсные очереди, их можно отслеживать через представления gp_resqueue_*:

gp_resqueue_status — показывает лимиты и текущее использование ресурсных очередей, например:

SELECT
    rsqname,
    rsqcountlimit,
    rsqcountvalue,
    rsqmemorylimit,
    rsqmemoryvalue
FROM gp_toolkit.gp_resqueue_status;

Пример результата:

 queueid |  rsqname   | rsqcountlimit | rsqcountvalue | rsqmemorylimit | rsqmemoryvalue
---------+------------+---------------+---------------+----------------+----------------
    6055 | pg_default |            21 |             0 |             -1 |              0
   16449 | reporting  |            22 |             2 |             -1 |    2.62144e+08
   16456 | adhoc      |            15 |             0 |    2.68435e+08 |              0
(3 rows)

gp_resq_activity — показывает информацию о запросах, которые выполняются или ожидают в ресурсных очередях:

SELECT * FROM gp_toolkit.gp_resq_activity;

Пример результата:

 resqprocpid | resqrole | resqoid | resqname  |           resqstart           | resqstatus
-------------+----------+---------+-----------+-------------------------------+------------
        3460 | charlie  |   16449 | reporting | 2025-08-04 10:25:48.318273+00 | running
        3351 | alice    |   16449 | reporting | 2025-08-04 10:25:53.574034+00 | running
(2 rows)

gp_resq_activity_by_queue — агрегирует текущую активность по каждой очереди без детализации на уровне запросов. Полезно для быстрой оценки состояния очередей.
gp_resq_priority_statement — показывает приоритеты запросов в ресурсных очередях.

gp_resq_role — показывает, какие ресурсные очереди назначены ролям в кластере

SELECT * FROM gp_toolkit.gp_resq_role
WHERE rrrsqname = 'reporting';

Пример результата:

 rrrolname | rrrsqname
-----------+------------
 alice     | reporting
 charlie   | reporting
(4 rows)

Подробнее см. в разделе Проверка ресурсных очередей.

Для изучения деталей хранения оптимизированных для добавления (AO) таблиц gp_toolkit предоставляет функции __gp_ao*. Существуют две основные группы функций: __gp_aoseg*/__gp_aocsseg* и __gp_aovisimap*.

ВАЖНО

При выполнении на мастере функции gp_toolkit для AO-таблиц не получают информацию с сегментов. Чтобы собрать данные о видимости и хранении строк по всему кластеру, необходимо либо вызывать функции на конкретных сегментах, либо использовать gp_dist_random() для выполнения на всех сегментах:

SELECT gp_segment_id, (gp_toolkit.__gp_aovisimap_entry('orders')).*
FROM gp_dist_random('gp_id');

Функции __gp_aoseg*/__gp_aocsseg* возвращают метаданные о сегментных файлах AO-таблиц:

__gp_aoseg(regclass) — выводит метаданные сегментных файлов для строковой AO-таблицы.

Пример:

SELECT gp_segment_id, (gp_toolkit.__gp_aoseg('orders')).*
FROM gp_dist_random('gp_id');

Пример вывода:

 gp_segment_id | segno |  eof  | tupcount | varblockcount | eof_uncompressed | modcount | formatversion | state
---------------+-------+-------+----------+---------------+------------------+----------+---------------+-------
             0 |     1 | 16592 |      485 |             3 |            16592 |        3 |             3 |     1
             1 |     1 | 17584 |      514 |             3 |            17584 |        3 |             3 |     1
             2 |     1 | 16360 |      478 |             3 |            16360 |        3 |             3 |     1
             3 |     1 | 17920 |      524 |             3 |            17920 |        3 |             3 |     1
(4 rows)

Среди полей: количество кортежей в сегментном файле (tupcount), число обновлений файла (modcount) и его статус (1 — активный сегмент, 2 — помеченный для удаления во время AO-уплотнения).

При вызове на мастере обычным образом функция показывает общую информацию, доступную на нем:

SELECT * FROM gp_toolkit.__gp_aoseg('orders');

Результат:

 segno | eof | tupcount | varblockcount | eof_uncompressed | modcount | formatversion | state
-------+-----+----------+---------------+------------------+----------+---------------+-------
     1 |   0 |     2001 |             0 |                0 |        4 |             3 |     1
(1 row)

__gp_aoseg_history(regclass) — возвращает подробную историю изменений файлов сегментов, полезную для диагностики и анализа.
__gp_aocsseg((regclass)) и __gp_aoseg_history(regclass) — эквиваленты __gp_aoseg(regclass) и __gp_aoseg_history(regclass) для колоночных AO-таблиц.

Функции __gp_aovisimap* возвращают информацию о карте видимости таблицы, определяющей, какие строки доступны для чтения:

__gp_aovisimap(regclass) — перечисляет скрытые строки AO-таблицы с указанием идентификаторов, номеров сегментов и позиций строк:

SELECT gp_segment_id, (gp_toolkit.__gp_aovisimap('orders')).*
FROM gp_dist_random('gp_id');

Фрагмент вывода:

  gp_segment_id |      tid       | segno | row_num
----------------+----------------+-------+---------
              1 | (33554432,502) |     1 |     501
              1 | (33554432,503) |     1 |     502
              1 | (33554432,504) |     1 |     503
              1 | (33554432,505) |     1 |     504
<...>

__gp_aovisimap_hidden_info(regclass) — выводит количество скрытых строк по сегментным файлам AO-таблицы:

SELECT gp_segment_id, (gp_toolkit.__gp_aovisimap_hidden_info('orders')).*
FROM gp_dist_random('gp_id');

Пример вывода:

 gp_segment_id | segno | hidden_tupcount | total_tupcount
---------------+-------+-----------------+----------------
             1 |     1 |              19 |            485
             0 |     1 |              30 |            514
             3 |     1 |              25 |            478
             2 |     1 |              27 |            524
(4 rows)

__gp_aovisimap_compaction_info(regclass) — агрегирует статистику по скрытым строкам и показывает, требуется ли AO-уплотнение таблицы. Пример:

SELECT * FROM gp_toolkit.__gp_aovisimap_compaction_info('orders'::regclass);

Пример вывода:

NOTICE:  gp_appendonly_compaction_threshold = 10
 content | datafile | compaction_possible | hidden_tupcount | total_tupcount | percent_hidden
---------+----------+---------------------+-----------------+----------------+----------------
       2 |        1 | f                   |              30 |            514 |           5.84
       1 |        1 | f                   |              19 |            485 |           3.92
       0 |        1 | f                   |              27 |            524 |           5.15
       3 |        1 | f                   |              25 |            478 |           5.23
(4 rows)

Подробнее см. в разделе Вакуумирование AO-таблиц.

__gp_aovisimap_entry(regclass) — показывает записи карты видимости таблицы полностью в виде последовательностей битов (bitmap). Каждая запись отображается строкой из символов 0 и 1, где 1 обозначает скрытую строку, а 0 — видимую. Сегменты без скрытых строк не отображаются. Для улучшения читаемости в вывод попадает только начальная часть последовательности до последней скрытой строки (символа 1). Оставшиеся нули не выводятся. Пример:
```
SELECT gp_segment_id, (gp_toolkit.__gp_aovisimap_entry('orders')).*
FROM gp_dist_random('gp_id');
```
Пример вывода:
```
 gp_segment_id | segno | first_row_num | hidden_tupcount | bitmap
---------------+-------+---------------+-----------------+--------
             1 |     1 |             0 |               1 | 01
             2 |     1 |             0 |               2 | 0101
(1 row)
```

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

Пример:

SELECT * FROM gp_toolkit.gp_roles_assigned;

Результат может выглядеть так:

 raroleid |  rarolename  | ramemberid | ramembername
----------+--------------+------------+--------------
    16511 | sales_team   |      16444 | alice
    16511 | sales_team   |      16455 | bob
       10 | gpadmin      |            |
    16444 | alice        |            |
    16455 | bob          |            |
    16476 | charlie      |            |
(6 rows)

Подробнее о пользователях и ролях см. в статье Роли и привилегии.

Использование ресурсных очередей

Сбор статистики с помощью ANALYZE

Использование gp_toolkit

Проверка использования диска

Размеры объектов базы данных

Свободное место на диске

Spill-файлы

Выявление проблем кластера

Вышедшие из строя сегменты

Раздувание

Отсутствие статистики

Перекос данных

Мониторинг блокировок в кластере

Просмотр логов базы данных

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

Мониторинг использования ресурсов

Ресурсные группы

Ресурсные очереди

Проверка AO-таблиц

Сегментные файлы

Карты видимости AO-таблиц

Просмотр пользователей и ролей