[Документация Yandex Cloud](../../index.md) > [Yandex MPP Analytics for PostgreSQL](../index.md) > [Пошаговые инструкции](index.md) > Пользователи и сессии > Работа с командным центром

# Работа с командным центром Yandex MPP Analytics for PostgreSQL

В командном центре Yandex MPP Analytics for PostgreSQL вы можете:

* [Посмотреть информацию о сессиях и запросах](#list).
* [Просмотреть историю потребления для завершенных запросов](#consumption-history).
* [Прервать текущую сессию](#terminate-session).
* [Прервать текущий запрос](#terminate-query).

Также ознакомьтесь с [примерами работы](#examples) в командном центре — они помогут понять, как и в каких ситуациях можно использовать командный центр.

Подробнее о статистике, которую можно получить с помощью командного центра, читайте в разделе [Командный центр Yandex MPP Analytics for PostgreSQL](../concepts/command-center.md).

{% note info %}

Командный центр Yandex MPP Analytics for PostgreSQL позволяет проводить только базовый операционный анализ сессий и запросов. Если ваша задача требует углубленного стратегического исследования и расширенных инструментов анализа, используйте [экспорт логов в Yandex Cloud Logging](mgp-to-cloud-logging.md). Сервис Cloud Logging позволяет [визуализировать логи в Grafana](../../logging/tutorials/grafana-logs-plugin.md) и выполнять их [обработку с помощью Data Streams и Query](../../logging/tutorials/cloud-logging.md).

{% endnote %}

## Посмотреть информацию о сессиях и запросах {#list}

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

Чтобы посмотреть информацию о сессиях и запросах:

{% list tabs group=instructions %}

- Консоль управления {#console}

    1. Перейдите на [страницу каталога](https://kz.console.yandex.cloud).
    1. Перейдите в сервис **Yandex MPP Analytics for PostgreSQL**.
    1. Нажмите на имя нужного кластера и перейдите на вкладку ![image](../../_assets/console-icons/pulse.svg) **Командный центр**.
    1. Выберите, что вы хотите посмотреть, и перейдите на нужную вкладку:

        * текущие сессии или запросы — вкладка **Текущее состояние**;
        * сессии или запросы за прошедший момент времени — вкладка **История состояний**.

    1. Выберите раздел **Сессии** или **Запросы**. Во вкладке **История состояний** эти разделы располагаются под графиком.
    1. Чтобы отфильтровать список сессий или запросов, нажмите кнопку ![image](../../_assets/console-icons/funnel.svg) **Фильтры** и выберите нужные параметры.
    1. Чтобы посмотреть детали:

        * сессии — нажмите на имя сессии;
        * запроса — нажмите на ключ выполняемого запроса.

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

{% endlist %}

## Просмотреть историю потребления для завершенных запросов {#consumption-history}

В истории потребления доступно несколько системных метрик. Они показывают, как кластер Yandex MPP Analytics for PostgreSQL потреблял ресурсы для обработки запросов в разные моменты времени. Также вы можете посмотреть список завершенных запросов. С помощью полученной информации вы можете определить, как управлять CPU и памятью хостов кластера для эффективной обработки запросов.

Чтобы посмотреть историю потребления для завершенных запросов:

{% list tabs group=instructions %}

- Консоль управления {#console}

    1. Перейдите на [страницу каталога](https://kz.console.yandex.cloud).
    1. Перейдите в сервис **Yandex MPP Analytics for PostgreSQL**.
    1. Нажмите на имя нужного кластера и перейдите на вкладку ![image](../../_assets/console-icons/pulse.svg) **Командный центр** → **История потребления**.
    1. Выберите нужный показатель потребления:

        * **CPU time** — время в секундах, которое понадобилось ресурсам CPU для обработки запросов.
        * **Peak memory** — максимальное количество памяти, которое потребовалось для обработки запроса за все время жизни кластера.
        * **Disk R** — память в байтах, которая понадобилась для чтения данных.
        * **Disk W** — память в байтах, которая понадобилась для записи данных в БД.
        * **Spill** — дополнительный объем дисковой памяти, который потребовался для выполнения запросов.
        * **Total time** — суммарное время, затраченное на обработку запросов.
        * **Packets sent** — количество пакетов, отправленных в рамках процесса `interconnect`.
        * **Packets recv** — количество пакетов, принятых в рамках процесса `interconnect`.
        * **Interconnect retransmits** — количество повторно переданных пакетов.
        * **Количество слайсов** — количество слайсов запроса.

        После того как вы выберете показатель потребления, отобразится график с деталями и список запросов. На графике указаны значение показателя, пользователь, который выполнил запрос, и время выполнения запроса.
        
    1. Чтобы отфильтровать результаты, нажмите кнопку ![image](../../_assets/console-icons/funnel.svg) **Фильтры** и задайте нужные параметры:
        
        * пользователь;
        * база данных;
        * ресурсная группа;
        * статус запроса;
        * идентификатор запроса;
        * текст запроса.

{% endlist %}


### Поиск по тексту запроса {#query-search}

Чтобы найти запрос, нажмите кнопку ![image](../../_assets/console-icons/funnel.svg) **Фильтры** и заполните поле **Текст запроса**. При этом поиск выполняется по подстроке без учета регистра.

> Например, чтобы найти запросы, содержащие вставку данных в таблицу `customers`, введите `INSERT INTO customers`.

Текст запроса может включать специальные символы:

* `%` — соответствует любой последовательности символов (включая пустую);
* `_` — соответствует одному символу;
* `\` — экранирует специальные символы: `%`, `_` и `\`.

> Например, чтобы найти запрос `DELETE FROM orders WHERE order_id IN (SELECT order_id FROM orders WHERE order_id = 1 LIMIT 1);`, введите `DELETE FROM orders%order_id = 1`.

Поиск по многострочным запросам и позиционным параметрам (например, `$1`) не поддерживается. Чтобы выполнить такой поиск, [выгрузите логи через Yandex Cloud Logging](../../logging/operations/export-logs.md) и найдите нужные запросы вручную.


## Прервать текущую сессию {#terminate-session}

Чтобы освободить ресурсы для сессий, вы можете прервать простаивающую сессию в статусе `Idle`:

{% list tabs group=instructions %}

- Консоль управления {#console}

    1. Перейдите на [страницу каталога](https://kz.console.yandex.cloud).
    1. Перейдите в сервис **Yandex MPP Analytics for PostgreSQL**.
    1. Нажмите на имя нужного кластера и перейдите на вкладку ![image](../../_assets/console-icons/pulse.svg) **Командный центр**.
    1. В разделе **Текущее состояние** → **Сессии** нажмите на значок ![image](../../_assets/console-icons/ellipsis.svg) в нужной строке и выберите пункт **Прервать сессию**.

        Если у вас отображается пункт **Прервать запрос**, выберите его и остановите запрос.

    1. Подтвердите остановку сессии.

{% endlist %}

## Прервать текущий запрос {#terminate-query}

Чтобы освободить ресурсы для выполнения запросов, вы можете прервать запрос в статусе `Idle` в простаивающей сессии. Для этого:

{% list tabs group=instructions %}

- Консоль управления {#console}

    1. Перейдите на [страницу каталога](https://kz.console.yandex.cloud).
    1. Перейдите в сервис **Yandex MPP Analytics for PostgreSQL**.
    1. Нажмите на имя нужного кластера и перейдите на вкладку ![image](../../_assets/console-icons/pulse.svg) **Командный центр**.
    1. В разделе **Текущее состояние** → **Запросы** нажмите на значок ![image](../../_assets/console-icons/ellipsis.svg) в нужной строке и выберите пункт **Прервать запрос**.
    1. Подтвердите остановку запроса.

{% endlist %}

## Примеры анализа текущего состояния {#current-analysis}

Командный центр Yandex MPP Analytics for PostgreSQL поддерживает следующие виды анализа текущего состояния кластера:

* Анализ метрик, например [поиск тяжелой сессии](#heavy-session) или [анализ структуры выполнения запросов](#nested-query).
* Анализ событий, например [поиск простаивающей сессии](#current-session) или [поиск блокирующей сессии](#blocker-session).

### Поиск текущей сессии, которая потребляет аномальное количество ресурсов {#heavy-session}

{% list tabs group=instructions %}

- Консоль управления {#console}

    1. Перейдите на [страницу каталога](https://kz.console.yandex.cloud).
    1. Перейдите в сервис **Yandex MPP Analytics for PostgreSQL**.
    1. Нажмите на имя нужного кластера и перейдите на вкладку ![image](../../_assets/console-icons/pulse.svg) **Командный центр** → **Текущее состояние**.
    1. Отсортируйте сессии по одному из столбцов: **CPU time**, **Peak memory**, **Spill**, **Disk W**, **Disk R**, **Net recv** или **Net sent**. 
    1. Найдите сессии, которые потребляют наибольшее количество выбранного ресурса.
    1. Для каждой выбранной сессии:
       1. Нажмите на номер сессии. Откроется страница с информацией об этой сессии.
       1. Сопоставьте показатели вычислительной нагрузки и нагрузки на ввод-вывод (**CPU time**, **Peak memory**, **Spill**, **Disk W**, **Disk R**, **Net recv**, **Net sent**) с общими графиками нагрузки на кластер или его отдельные хосты.
    1. Определите, какая из сессий внесла наибольший вклад в потребление ресурсов.
    1. Чтобы посмотреть детали о состояниях сессии в разные моменты времени и отследить изменение показателей во времени, перейдите на вкладку **История сессии**.

    {% note info %}

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

    {% endnote %}

{% endlist %}

### Анализ структуры выполнения запросов {#nested-query}

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

{% list tabs group=instructions %}

- Консоль управления {#console}

    1. Перейдите на [страницу каталога](https://kz.console.yandex.cloud).
    1. Перейдите в сервис **Yandex MPP Analytics for PostgreSQL**.
    1. Нажмите на имя нужного кластера и перейдите на вкладку ![image](../../_assets/console-icons/pulse.svg) **Командный центр** → **Текущее состояние**.
    1. Перейдите на вкладку **Сессии**.
    1. Включите отображение только активных сессий. Для этого выключите все кнопки-статусы, кроме **Active**.
    1. Отсортируйте сессии по столбцу **Время старта**.
    1. Найдите долгоживущую сессию с высокими значениями в столбцах **CPU time** и **Peak memory**. Нажмите на номер этой сессии. Откроется страница с информацией о ней.
    1. Проанализируйте значения **CPU time**, **Peak memory**, **Spill**, **Skew**, **Net sent**, **Net recv** и **Interconnect retransmits**.

       * Если вы видите высокие значения **Net sent** и **Net recv**, а также ненулевое значение **Interconnect retransmits**:
         1. Перейдите на вкладку **Запросы**.
         1. Примените фильтр **SSID:**, указав идентификатор транзакции выбранной сессии.
         1. Отсортируйте запросы по столбцу **Ключ выполняемого запроса** по убыванию.
         1. Откройте планы выполнения нескольких запросов.
         1. Если после `Sort`, `Aggregate` или `Distinct` вы видите `Gather` или `Gather Merge`, перенесите `GROUP BY`/`DISTINCT`/`ORDER BY` в подзапросы.
         1. Если вы видите широкие выборки с полным набором столбцов, ограничьте результат с помощью `LIMIT` или постраничного вывода, а также отберите только необходимые столбцы и примените фильтры на ранних этапах запроса.

       * Если вы видите ненулевое значение **Spill**:
         1. Перейдите на вкладку **Запросы**.
         1. Примените фильтр **SSID:**, указав идентификатор транзакции выбранной сессии.
         1. Отсортируйте запросы по столбцу **Ключ выполняемого запроса** по убыванию.
         1. Откройте планы выполнения нескольких запросов.
         1. Если вы видите подзапросы с зависимостью от внешней строки (`EXISTS` или `IN` с корреляцией), а в плане выполнения присутствуют узлы `SubPlan` или `InitPlan`, декоррелируйте такие подзапросы.
         1. Если вы видите сортировку или материализацию, а затем `WindowAgg` над большими выборками, примените предагрегацию или фильтрацию, а также исключите лишние столбцы до применения оконных функций.
         1. Если вы видите `Sort` или `Distinct` на разных уровнях вложенности, уменьшите количество таких операций и глубину их вложенности.

       * Если вы видите высокие значения **CPU time** или **Peak memory** при ненулевых значениях **Skew**:
         1. Перейдите на вкладку **Запросы**.
         1. Примените фильтр **SSID:**, указав идентификатор транзакции выбранной сессии.
         1. Отсортируйте запросы по столбцу **Ключ выполняемого запроса** по убыванию.
         1. Откройте планы выполнения нескольких запросов и проверьте, как выполняются соединения:
            * Если соединения выполняются по столбцам, отличным от фактического ключа распределения таблиц, перепишите запрос.
            * Если соединяются крупные наборы, а фильтры отсутствуют или применяются после `JOIN`, используйте фильтрацию в подзапросах до `JOIN`.

{% endlist %}

### Поиск простаивающей сессии {#current-session}

Допустим, пользователь закончил работу с БД, но оставил свою сессию открытой. В таком случае сессия простаивает и потребляет ресурсы кластера, что приводит к снижению его производительности. Чтобы найти и прервать такую сессию:

{% list tabs group=instructions %}

- Консоль управления {#console}

    1. Перейдите на [страницу каталога](https://kz.console.yandex.cloud).
    1. Перейдите в сервис **Yandex MPP Analytics for PostgreSQL**.
    1. Нажмите на имя нужного кластера и перейдите на вкладку ![image](../../_assets/console-icons/pulse.svg) **Командный центр** → **Текущее состояние**.
    1. Отсортируйте сессии по столбцу **Время старта**.
    1. Найдите сессию в статусе `Idle`, которая длится наибольшее количество времени. Нажмите на номер этой сессии. Откроется страница с информацией о ней.
    1. В разделе **Информация о сессии** в поле **Время начала запроса** посмотрите, когда был отправлен последний запрос.
    1. Если сессия не выполняет запросы, а удержание соединения не требуется по логике клиентского приложения, такую сессию можно прервать. Для этого в правом верхнем углу нажмите кнопку **Прервать сессию** и подтвердите остановку сессии.

{% endlist %}

### Поиск блокирующей сессии {#blocker-session}

В некоторых случаях сессия надолго захватывает строки таблицы или ее метаданные. Это может создавать очередь из заблокированных сессий, ожидающих захвата ресурса. Чтобы определить, какая сессия является блокирующей:

{% list tabs group=instructions %}

- Консоль управления {#console}

    1. Перейдите на [страницу каталога](https://kz.console.yandex.cloud).
    1. Перейдите в сервис **Yandex MPP Analytics for PostgreSQL**.
    1. Нажмите на имя нужного кластера и перейдите на вкладку ![image](../../_assets/console-icons/pulse.svg) **Командный центр** → **Текущее состояние**.
    1. Перейдите на вкладку **Сессии**.
    1. Для отображения дерева блокировок нажмите кнопку ![image](../../_assets/console-icons/branches-down.svg).
    1. Исследуйте дерево блокировок и определите основные блокирующие сессии. 
    1. По каждой блокирующей сессии проверьте:
        * Статус — как правило, `Active` или `Idle transaction`.
        * Значения параметров **Время старта** и **Статус изменён**.
        * Количество потребляемых ресурсов.
        * Количество заблокированных сессий.
        * Текст запроса.
    1. Если блокирующая сессия долго находится в состоянии `Active` и потребляет вычислительные ресурсы, причиной может быть тяжелый запрос. В этом случае может помочь оптимизация запросов и бизнес-логики.
    1. Если сессия блокирует множество других сессий и давно находится в состоянии `Idle transaction`, вы можете ее прервать после дополнительных проверок:
        1. Убедитесь, что **CPU time** не увеличивается, а поле **Причина ожидания** пустое.
        1. В правом верхнем углу нажмите кнопку **Прервать сессию**.
        1. Подтвердите остановку сессии.

    {% note tip %}

    Для предотвращения длительных блокировок:
    * оптимизируйте запросы и уменьшите разовый объем обрабатываемых данных;
    * разнесите по времени интерактивные запросы и тяжелые операции;
    * задайте таймауты выполнения запросов и ожидания блокировки.

    {% endnote %}

{% endlist %}

## Примеры анализа истории состояний и истории потребления {#historical-analysis}

Командный центр Yandex MPP Analytics for PostgreSQL поддерживает следующие виды анализа истории сессий и запросов:

* Анализ метрик, например [поиск тяжелых запросов](#past-statements) и [поиск запросов с большой нагрузкой на сеть](#net-load).
* Анализ событий, например [поиск отмененных запросов и ошибок выполнения](#cancelations).

### Поиск запросов, вызвавших высокую нагрузку CPU {#past-statements}

Допустим, в определенный период потребление вычислительной мощности CPU было выше обычного. Чтобы определить, какие запросы вызвали эту аномалию:

{% list tabs group=instructions %}

- Консоль управления {#console}

    1. Узнайте, когда было зафиксировано высокое потребление CPU:

        1. Перейдите на [страницу каталога](https://kz.console.yandex.cloud).
        1. Перейдите в сервис **Yandex MPP Analytics for PostgreSQL**.
        1. Нажмите на имя нужного кластера и перейдите в ![image](../../_assets/console-icons/pulse.svg) **Командный центр** → **История состояний**.
        1. Задайте фильтр **CPU usage**.
        1. Определите по графику, когда потребление CPU стало аномально высоким.

            Для этого наведите курсор на высокий пик. Появится всплывающее окно с информацией о состоянии кластера в выбранный момент. В этом окне указано время, когда произошел всплеск.

    1. Определите, какие запросы привели к высокому потреблению CPU:

        1. Перейдите на вкладку **История потребления**.
        1. Задайте диапазон времени на основе анализа истории состояний.
        1. Сгруппируйте запросы по пользователю, базе данных и идентификатору запроса. Так вы получите группы, которые содержат похожие друг на друга запросы.
        1. Отсортируйте полученные группы запросов по столбцу **CPU time**.
        1. Откройте группу с наибольшим значением **CPU time**.
        1. Изучите SQL-текст запросов и их планы выполнения, чтобы определить, что привело к высокому потреблению CPU.

       {% note tip %}

        Найти проблемы с потреблением CPU в конкретной сессии может только инициатор запросов, однако на необходимость в оптимизации могут указать следующие признаки:
        * сложные вычисления и выражения, выполняемые построчно;
        * сортировки и агрегации без фильтрации данных;
        * многократные проходы по большим таблицам без использования индексов или распределения данных;
        * повторные вычисления подзапросов или функций внутри выражений.

       {% endnote %}

{% endlist %}

### Поиск запросов, вызвавших большую нагрузку на сеть {#net-load}

{% list tabs group=instructions %}

- Консоль управления {#console}

    1. Определите приблизительный интервал времени, когда наблюдались сетевые проблемы и ошибки, например:

       * жалобы на сбои подключения к кластеру или долгие отклики;
       * сетевые аномалии и ошибки по данным логов и мониторинга кластера. 

    1. Определите причину появления ошибок:

        1. Перейдите на [страницу каталога](https://kz.console.yandex.cloud).
        1. Перейдите в сервис **Yandex MPP Analytics for PostgreSQL**.
        1. Нажмите на имя нужного кластера и перейдите в ![image](../../_assets/console-icons/pulse.svg) **Командный центр** → **История состояний**.
        1. Задайте диапазон времени, в который наблюдались ошибки.
        1. В выпадающем списке над графиком последовательно выберите **Connections**, а затем **Net usage**. Сравните графики.
        1. Если наблюдались необычно большие значения **Net usage**, то наиболее вероятная причина — аномальная сетевая активность. 
        1. Если наблюдались необычно большие значения **Connections**, то наиболее вероятная причина — всплеск соединений. 

    1. Если причина ошибок — аномальная сетевая активность:

        1. Перейдите на вкладку **История потребления**.
        1. Задайте диапазон времени на основе анализа истории состояний.
        1. Выберите **Группировать по:** → **пользователю**.
        1. Отсортируйте группы запросов по столбцам **Net sent** и **Net recv**.
        1. Найдите пользователя с максимальными значениями в этих столбцах. Отфильтруйте группы запросов по этому пользователю.
        1. Выберите **Группировать по:** → **ID запроса** и отключите группировку по пользователю.
        1. Найдите запросы, которые генерировали больше всего трафика. Сохраните текст этих запросов и время их старта.
        1. Перейдите на вкладку **Сессии**.
        1. Используя поиск по тексту запросов, найдите нужные запросы.
        1. Определите источник трафика с помощью столбца **Приложение**.
        1. По результатам анализа на стороне приложений с аномальной сетевой активностью:
            * ограничьте объем выгружаемых данных;
            * используйте материализованные представления или временные таблицы;
            * оптимизируйте распределение таблиц (DISTRIBUTED BY) и обновите статистику таблиц перед выполнением больших вставок;
            * пересмотрите архитектуру ETL-пайплайнов.

    1. Если причина ошибок — всплеск соединений:

        1. Под графиком перейдите на вкладку **Сессии**.
        1. Отсортируйте сессии по столбцу **Время старта**.
        1. Выберите на графике момент времени с наибольшими значениями **Connections**. Используйте блок **На момент времени:** и стрелки **<** **>** для точного задания момента времени.
        1. Используя фильтры **Пользователь** и **Имя приложения:**, сравните количество созданных сессий в секунду для каждого источника.
        1. Если один источник создает намного больше сессий, чем остальные:
            * Проверьте, что приложение переиспользует соединения.
            * Настройте параметры повторных подключений: интервал между повторами и общее количество попыток.
        1. При необходимости измените настройки [менеджера подключений](../concepts/pooling.md) по результатам анализа.

{% endlist %}

### Поиск отмененных запросов и ошибок выполнения {#cancelations}

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

Чтобы определить, какие запросы были отменены или вызвали ошибки выполнения:

{% list tabs group=instructions %}

- Консоль управления {#console}

    1. Перейдите на [страницу каталога](https://kz.console.yandex.cloud).
    1. Перейдите в сервис **Yandex MPP Analytics for&nbsp;PostgreSQL**.
    1. Нажмите на имя нужного кластера и перейдите в ![image](../../_assets/console-icons/pulse.svg) **Командный центр** → **История состояний**.
    1. Перейдите на вкладку **Запросы**.
    1. Выберите момент времени, когда наблюдались проблемы по данным мониторинга. Используйте блок **На момент времени:** и стрелки **<** **>** для точного задания момента времени.
    1. Отсортируйте запросы по столбцу **Состояние запроса**.
    1. Найдите запросы со статусом `Canceled` или `Error`.
    1. Установите источники запросов по значениям в столбцах **Пользователь** и **Приложение**. При необходимости используйте фильтры **Пользователь:** и **Имя приложения:**.
    1. Если один источник создает намного больше отмененных и ошибочных запросов, чем остальные:
  
       * Проверьте и, при необходимости, оптимизируйте бизнес-логику и структуру SQL-запросов.

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

       * Задайте интервал между повторными подключениями и общее количество попыток.

    1. При необходимости используйте [менеджер подключений](../concepts/pooling.md), чтобы ограничить количество одновременных активных подключений и сбалансировать нагрузку между клиентами.
    
       Оптимальные параметры зависят от числа сегментов и ресурсов кластера.

{% endlist %}