Связаться с намиПопробовать бесплатно

Работа с командным центром Greenplum®

Статья создана
Улучшена
Обновлена 26 декабря 2025 г.

В командном центре Greenplum® вы можете:

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

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

Примечание

Командный центр Greenplum® позволяет проводить только базовый операционный анализ сессий и запросов. Если ваша задача требует углубленного стратегического исследования и расширенных инструментов анализа, используйте экспорт логов в Yandex Cloud Logging. Сервис Yandex Cloud Logging позволяет визуализировать логи в Grafana и выполнять их обработку с помощью Data Streams и Query.

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

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

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

  1. Перейдите на страницу каталога и выберите сервис Yandex MPP Analytics for PostgreSQL.

  2. Нажмите на имя нужного кластера и перейдите на вкладку  Командный центр.

  3. Выберите, что вы хотите посмотреть, и перейдите на нужную вкладку:

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

  4. Выберите раздел Сессии или Запросы. Во вкладке История состояний эти разделы располагаются под графиком.

  5. Чтобы отфильтровать список сессий или запросов, нажмите кнопку  Фильтры и выберите нужные параметры.

  6. Чтобы посмотреть детали:

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

    Параметры сессий и запросов описаны в разделе Параметры командного центра Greenplum®.

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

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

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

  1. Перейдите на страницу каталога и выберите сервис Yandex MPP Analytics for PostgreSQL.

  2. Нажмите на имя нужного кластера и перейдите на вкладку  Командный центр → История потребления.

  3. Выберите нужный показатель потребления:

    • CPU time — время в секундах, которое понадобилось ресурсам CPU для обработки запросов.
    • Peak memory — максимальное количество памяти, которое потребовалось для обработки запроса за все время жизни кластера.
    • Disk R — память в байтах, которая понадобилась для чтения данных.
    • Disk W — память в байтах, которая понадобилась для записи данных в БД.
    • Spill — дополнительный объем дисковой памяти, который потребовался для выполнения запросов.
    • Total time — суммарное время, затраченное на обработку запросов.

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

  4. Чтобы отфильтровать результаты, нажмите кнопку  Фильтры и выберите нужные параметры.

Прервать текущую сессию

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

  1. Перейдите на страницу каталога и выберите сервис Yandex MPP Analytics for PostgreSQL.

  2. Нажмите на имя нужного кластера и перейдите на вкладку  Командный центр.

  3. В разделе Текущее состояние → Сессии нажмите на значок в нужной строке и выберите пункт Прервать сессию.

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

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

Прервать текущий запрос

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

  1. Перейдите на страницу каталога и выберите сервис Yandex MPP Analytics for PostgreSQL.
  2. Нажмите на имя нужного кластера и перейдите на вкладку  Командный центр.
  3. В разделе Текущее состояние → Запросы нажмите на значок в нужной строке и выберите пункт Прервать запрос.
  4. Подтвердите остановку запроса.

Примеры анализа текущего состояния

Командный центр Greenplum® поддерживает следующие виды анализа текущего состояния кластера:

Поиск текущей сессии, которая потребляет аномальное количество ресурсов

  1. Перейдите на страницу каталога и выберите сервис Yandex MPP Analytics for PostgreSQL.
  2. Нажмите на имя нужного кластера и перейдите на вкладку  Командный центр → Текущее состояние.
  3. Отсортируйте сессии по одному из столбцов: CPU time, Peak memory, Spill, Disk W, Disk R, Net recv или Net sent.
  4. Найдите сессии, которые потребляют наибольшее количество выбранного ресурса.
  5. Для каждой выбранной сессии:
    1. Нажмите на номер сессии. Откроется страница с информацией об этой сессии.
    2. Сопоставьте показатели вычислительной нагрузки и нагрузки на ввод-вывод (CPU time, Peak memory, Spill, Disk W, Disk R, Net recv, Net sent) с общими графиками нагрузки на кластер или его отдельные хосты.
  6. Определите, какая из сессий внесла наибольший вклад в потребление ресурсов.
  7. Чтобы посмотреть детали о состояниях сессии в разные моменты времени и отследить изменение показателей во времени, перейдите на вкладку История сессии.

Примечание

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

Анализ структуры выполнения запросов

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

  1. Перейдите на страницу каталога и выберите сервис Yandex MPP Analytics for PostgreSQL.

  2. Нажмите на имя нужного кластера и перейдите на вкладку  Командный центр → Текущее состояние.

  3. Перейдите на вкладку Сессии.

  4. Включите отображение только активных сессий. Для этого выключите все кнопки-статусы, кроме Active.

  5. Отсортируйте сессии по столбцу Время старта.

  6. Найдите долгоживущую сессию с высокими значениями в столбцах CPU time и Peak memory. Нажмите на номер этой сессии. Откроется страница с информацией о ней.

  7. Проанализируйте значения CPU time, Peak memory, Spill, Skew, Net sent, Net recv и Interconnect retransmits.

    • Если вы видите высокие значения Net sent и Net recv, а также ненулевое значение Interconnect retransmits:

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

    • Если вы видите ненулевое значение Spill:

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

    • Если вы видите высокие значения CPU time или Peak memory при ненулевых значениях Skew:

      1. Перейдите на вкладку Запросы.
      2. Примените фильтр SSID:, указав идентификатор транзакции выбранной сессии.
      3. Отсортируйте запросы по столбцу Ключ выполняемого запроса по убыванию.
      4. Откройте планы выполнения нескольких запросов и проверьте, как выполняются соединения:
        • Если соединения выполняются по столбцам, отличным от фактического ключа распределения таблиц, перепишите запрос.
        • Если соединяются крупные наборы, а фильтры отсутствуют или применяются после JOIN, используйте фильтрацию в подзапросах до JOIN.

Поиск простаивающей сессии

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

  1. Перейдите на страницу каталога и выберите сервис Yandex MPP Analytics for PostgreSQL.
  2. Нажмите на имя нужного кластера и перейдите на вкладку  Командный центр → Текущее состояние.
  3. Отсортируйте сессии по столбцу Время старта.
  4. Найдите сессию в статусе Idle, которая длится наибольшее количество времени. Нажмите на номер этой сессии. Откроется страница с информацией о ней.
  5. В разделе Информация о сессии в поле Время начала запроса посмотрите, когда был отправлен последний запрос.
  6. Если сессия не выполняет запросы, а удержание соединения не требуется по логике клиентского приложения, такую сессию можно прервать. Для этого в правом верхнем углу нажмите кнопку Прервать сессию и подтвердите остановку сессии.

Поиск блокирующей сессии

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

  1. Перейдите на страницу каталога и выберите сервис Yandex MPP Analytics for PostgreSQL.
  2. Нажмите на имя нужного кластера и перейдите на вкладку  Командный центр → Текущее состояние.
  3. Перейдите на вкладку Сессии.
  4. Для отображения дерева блокировок нажмите кнопку .
  5. Исследуйте дерево блокировок и определите основные блокирующие сессии.
  6. По каждой блокирующей сессии проверьте:
    • Статус — как правило, Active или Idle transaction.
    • Значения параметров Время старта и Статус изменён.
    • Количество потребляемых ресурсов.
    • Количество заблокированных сессий.
    • Текст запроса.
  7. Если блокирующая сессия долго находится в состоянии Active и потребляет вычислительные ресурсы, причиной может быть тяжелый запрос. В этом случае может помочь оптимизация запросов и бизнес-логики.
  8. Если сессия блокирует множество других сессий и давно находится в состоянии Idle transaction, вы можете ее прервать после дополнительных проверок:
    1. Убедитесь, что CPU time не увеличивается, а поле Причина ожидания пустое.
    2. В правом верхнем углу нажмите кнопку Прервать сессию.
    3. Подтвердите остановку сессии.

Совет

Для предотвращения длительных блокировок:

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

Примеры анализа истории состояний и истории потребления

Командный центр Greenplum® поддерживает следующие виды анализа истории сессий и запросов:

Поиск запросов, вызвавших высокую нагрузку CPU

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

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

    1. Перейдите на страницу каталога и выберите сервис Yandex MPP Analytics for PostgreSQL.

    2. Нажмите на имя нужного кластера и перейдите в  Командный центр → История состояний.

    3. Задайте фильтр CPU usage.

    4. Определите по графику, когда потребление CPU стало аномально высоким.

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

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

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

    Совет

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

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

Поиск запросов, вызвавших большую нагрузку на сеть

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

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

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

    1. Перейдите на страницу каталога и выберите сервис Yandex MPP Analytics for PostgreSQL.
    2. Нажмите на имя нужного кластера и перейдите в  Командный центр → История состояний.
    3. Задайте диапазон времени, в который наблюдались ошибки.
    4. В выпадающем списке над графиком последовательно выберите Connections, а затем Net usage. Сравните графики.
    5. Если наблюдались необычно большие значения Net usage, то наиболее вероятная причина — аномальная сетевая активность.
    6. Если наблюдались необычно большие значения Connections, то наиболее вероятная причина — всплеск соединений.

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

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

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

    1. Под графиком перейдите на вкладку Сессии.
    2. Отсортируйте сессии по столбцу Время старта.
    3. Выберите на графике момент времени с наибольшими значениями Connections. Используйте блок На момент времени: и стрелки < > для точного задания момента времени.
    4. Используя фильтры Пользователь и Имя приложения:, сравните количество созданных сессий в секунду для каждого источника.
    5. Если один источник создает намного больше сессий, чем остальные:
      • Проверьте, что приложение переиспользует соединения.
      • Настройте параметры повторных подключений: интервал между повторами и общее количество попыток.
    6. При необходимости измените настройки менеджера подключений по результатам анализа.

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

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

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

  1. Перейдите на страницу каталога и выберите сервис Yandex MPP Analytics for PostgreSQL.

  2. Нажмите на имя нужного кластера и перейдите в  Командный центр → История состояний.

  3. Перейдите на вкладку Запросы.

  4. Выберите момент времени, когда наблюдались проблемы по данным мониторинга. Используйте блок На момент времени: и стрелки < > для точного задания момента времени.

  5. Отсортируйте запросы по столбцу Состояние запроса.

  6. Найдите запросы со статусом Canceled или Error.

  7. Установите источники запросов по значениям в столбцах Пользователь и Приложение. При необходимости используйте фильтры Пользователь: и Имя приложения:.

  8. Если один источник создает намного больше отмененных и ошибочных запросов, чем остальные:

    • Проверьте и, при необходимости, оптимизируйте бизнес-логику и структуру SQL-запросов.

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

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

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

    Оптимальные параметры зависят от числа сегментов и ресурсов кластера.

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

Предыдущая
Правила аутентификации пользователей
Следующая
Управление клиентскими процессами и сессиями пользователей