[Документация Yandex Cloud](../../index.md) > [Yandex MPP Analytics for PostgreSQL](../index.md) > [Концепции](overview.md) > Командный центр

# Командный центр Yandex MPP Analytics for PostgreSQL

_Командный центр_ в Yandex MPP Analytics for PostgreSQL — это инструмент, с помощью которого можно:

* отслеживать метрики выполняемых запросов и их планов выполнения;
* прерывать отдельные запросы и сессии;
* просматривать истории выполнения завершенных запросов;
* анализировать запросы к БД;
* проводить тюнинг БД.

{% note info %}

Командный центр доступен в кластерах с БД:

* Greenplum® — начиная c версии 6.25;
* Apache Cloudberry™ — начиная с версии 2.0.

{% endnote %}

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

* [текущее состояние](#current-state);
* [история состояний](#states-history);
* [история потребления ресурсов](#consumption-history).

Параметры сессий и запросов описаны в разделе [Параметры командного центра Yandex MPP Analytics for PostgreSQL](command-center-parameters.md).

Также в командном центре запросам присваиваются [ключи](#statement-key) и [идентификаторы](#statement-id) для распознавания и группировки запросов.

Подробнее о том, как работать в командном центре, читайте в разделе [Работа с командным центром Yandex MPP Analytics for PostgreSQL](../operations/command-center.md).

## Текущее состояние {#current-state}

_Текущее состояние_ — состояние сессий или запросов в кластере в реальном времени. На вкладке **Текущее состояние** можно узнать, какие пользователи подключились к БД, какие запросы выполняются, сколько ресурсов сейчас потребляется.

> Допустим, пользователи проводят ресурсоемкие вычисления в рамках нескольких сессий. Эти вычисления не закончились к моменту начала регулярных процессов.
>
> Чтобы определить, в рамках каких сессий создается наибольшая нагрузка на CPU, на вкладке **Текущее состояние** отсортируйте сессии по **CPU time**. Так можно найти и [прервать](../operations/command-center.md#terminate-session) сессии с наиболее ресурсоемкими вычислениями, и в результате освободить ресурсы для других операций. О том, как продиагностировать подобные случаи, читайте в разделе [Поиск простаивающей сессии](../operations/command-center.md#current-session).

## История состояний {#states-history}

_История состояний_ — снимки состояний сессий и запросов в определенный момент в прошлом. История состояний позволяет определить, какие сессии или запросы вызвали аномалии в работе кластера.

> Например, утром вы обнаружили, что ночные [процессы ETL](https://ru.wikipedia.org/wiki/ETL) выполнялись дольше обычного. История состояний поможет понять, что происходило с сессиями ночных процессов: какие запросы выполнялись и как долго, кто блокировал работу, когда начал выполняться определенный запрос.

## История потребления {#consumption-history}

_История потребления_ — информация о CPU time, Peak memory и других показателях потребления ресурсов в определенный момент в прошлом для завершенных запросов.

> Допустим, по [истории состояний](#states-history) видно, что в определенный период нагрузка CPU была выше обычного. Тогда по истории потребления можно понять, какие запросы вызвали высокую нагрузку. О примере такого анализа читайте в разделе [Поиск запросов, вызвавших высокую нагрузку CPU](../operations/command-center.md#past-statements).

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

Группа запросов представляет собой их список, в котором можно посмотреть информацию по каждому запросу. Отображаемая информация зависит от длительности выполнения запроса:

* Больше часа — по запросу сохранена вся информация. Например, когда запрос выполнялся, кто его выполнял, сколько ресурсов потреблялось на каждом из сегментов БД.
* Меньше часа — информация сохранена в агрегированном виде по аналогии с представлением PostgreSQL [pg_stat_statements](https://www.postgresql.org/docs/current/pgstatstatements.html). Можно узнать только суммарное потребление ресурсов в выбранный момент времени.

Запросы можно сгруппировать по одному или нескольким признакам:

* пользователь, отправивший запрос;
* БД, с которой работали;
* [идентификатор запроса](#statement-id);
* [ресурсная группа](resource-groups.md).

Кроме того, группы запросов можно отсортировать по разным показателям, например CPU time. Так можно быстрее найти нужную группу.

## Ключи запросов {#statement-key}

_Ключ_ — уникальный атрибут, который присваивается запросу во время его выполнения. При каждой отправке запроса ему присваивается новый ключ, в результате по ключам можно различить выполнения одного и того же запроса в разное время.

Ключ формируется по шаблону:

```text
<идентификатор_сессии>/<timestamp>/<номер_запроса>
```

Где:

* `идентификатор_сессии` — сессия, во время которой был выполнен запрос.
* `timestamp` — время старта сегмента БД.
* `номер_запроса` — порядковый номер запроса в сессии.

> Пример ключа: `7247590/1701763297/5`.

## Идентификаторы запросов {#statement-id}

_Идентификатор_ — неуникальный хеш, полученный из текста запроса. Порядок расчета идентификатора зависит от длительности выполнения запроса. Если запрос выполнялся больше часа:

1. В запросе удаляются числовые и строковые литералы.
1. От оставшейся части запроса рассчитывается хеш. Этот хеш является идентификатором.

Если запрос выполнялся меньше часа:

1. Выбираются запросы, которые можно объединить в одну группу вместе с данным запросом.

   Иногда один и тот же SQL-запрос выполняется периодически. В таком случае в командном центре собирается информация о нескольких запросах, отличие между которыми заключается только во времени выполнения.

1. В запросе удаляются числовые и строковые литералы.
1. В оставшейся части запроса определяются и убираются незначительные отличия между запросами одной группы.
1. От оставшейся части запроса рассчитывается хеш. Этот хеш является идентификатором.

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

> Пример идентификатора: `1f9c40bf`.

_Greenplum® и Greenplum Database® являются зарегистрированными товарными знаками или товарными знаками Broadcom Inc в США и/или других странах._

_Apache® и Apache Cloudberry™ являются зарегистрированными товарными знаками или товарными знаками Apache Software Foundation в США и/или других странах._