Yandex Cloud
Поиск
Связаться с намиПодключиться
  • Документация
  • Блог
  • Все сервисы
  • Статус работы сервисов
    • Популярные
    • Инфраструктура и сеть
    • Платформа данных
    • Контейнеры
    • Инструменты разработчика
    • Бессерверные вычисления
    • Безопасность
    • Мониторинг и управление ресурсами
    • Машинное обучение
    • Бизнес-инструменты
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Безопасность
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Облако для интеграторов
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Контент-программа
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Истории успеха
    • Тарифы Yandex Cloud
    • Промоакции и free tier
    • Правила тарификации
  • Документация
  • Блог
Проект Яндекса
© 2025 ООО «Яндекс.Облако»
Практические руководства
    • Все руководства
    • Развертывание веб-интерфейса Apache Kafka®
    • Миграция БД из стороннего кластера Apache Kafka® в Managed Service for Apache Kafka®
    • Перенос данных между кластерами Managed Service for Apache Kafka® с помощью Data Transfer
    • Поставка данных из Managed Service for MySQL® в Managed Service for Apache Kafka® с помощью Data Transfer
    • Поставка данных из Managed Service for MySQL® в Managed Service for Apache Kafka® с помощью Debezium
    • Поставка данных из Managed Service for PostgreSQL в Managed Service for Apache Kafka® с помощью Data Transfer
    • Поставка данных из Managed Service for PostgreSQL в Managed Service for Apache Kafka® с помощью Debezium
    • Поставка данных из Managed Service for YDB в Managed Service for Apache Kafka® с помощью Data Transfer
    • Поставка данных из Managed Service for Apache Kafka® в Managed Service for ClickHouse® с помощью Data Transfer
    • Поставка данных из Managed Service for Apache Kafka® в Managed Service for Greenplum® с помощью Data Transfer
    • Поставка данных из Managed Service for Apache Kafka® в Managed Service for MongoDB с помощью Data Transfer
    • Поставка данных из Managed Service for Apache Kafka® в Managed Service for MySQL® с помощью Data Transfer
    • Поставка данных из Managed Service for Apache Kafka® в Managed Service for OpenSearch с помощью Data Transfer
    • Поставка данных из Managed Service for Apache Kafka® в Managed Service for PostgreSQL с помощью Data Transfer
    • Поставка данных из Managed Service for Apache Kafka® в Managed Service for YDB с помощью Data Transfer
    • Поставка данных из Managed Service for Apache Kafka® в Data Streams с помощью Data Transfer
    • Поставка данных из Data Streams в Managed Service for YDB с помощью Data Transfer
    • Поставка данных из Data Streams в Managed Service for Apache Kafka® с помощью Data Transfer
    • Захват изменений YDB и поставка в YDS
    • Настройка Kafka Connect для работы с кластером Managed Service for Apache Kafka®
    • Автоматизация задач Query с помощью Managed Service for Apache Airflow™
    • Отправка запросов к API Yandex Cloud через Yandex Cloud Python SDK
    • Настройка SMTP-сервера для отправки уведомлений по электронной почте
    • Добавление данных в БД ClickHouse®
    • Миграция данных в Managed Service for ClickHouse® средствами ClickHouse®
    • Миграция данных в Managed Service for ClickHouse® при помощи Data Transfer
    • Поставка данных из Managed Service for MySQL® в Managed Service for ClickHouse® с помощью Data Transfer
    • Асинхронная репликация данных из PostgreSQL в ClickHouse®
    • Обмен данными между Managed Service for ClickHouse® и Yandex Data Processing
    • Настройка Managed Service for ClickHouse® для Graphite
    • Получение данных из Managed Service for Apache Kafka® в Managed Service for ClickHouse®
    • Получение данных из Managed Service for Apache Kafka® в ksqlDB
    • Получение данных из RabbitMQ в Managed Service for ClickHouse®
    • Сохранение потока данных Data Streams в Managed Service for ClickHouse®
    • Асинхронная репликация данных из Яндекс Метрика в ClickHouse® с помощью Data Transfer
    • Использование гибридного хранилища в Managed Service for ClickHouse®
    • Шардирование таблиц Managed Service for ClickHouse®
    • Перешардирование данных в кластере Managed Service for ClickHouse®
    • Загрузка данных из Яндекс Директ в витрину Managed Service for ClickHouse® с использованием Cloud Functions, Object Storage и Data Transfer
    • Загрузка данных из Object Storage в Managed Service for ClickHouse® с помощью Data Transfer
    • Миграция данных со сменой хранилища из Managed Service for OpenSearch в Managed Service for ClickHouse® с помощью Data Transfer
    • Загрузка данных из Managed Service for YDB в Managed Service for ClickHouse® с помощью Data Transfer
    • Интеграция Yandex Managed Service for ClickHouse® с Microsoft SQL Server через ClickHouse® JDBC Bridge
    • Миграция базы данных из Google BigQuery в Managed Service for ClickHouse®
    • Интеграция Yandex Managed Service for ClickHouse® с Oracle через ClickHouse® JDBC Bridge
    • Настройка Cloud DNS для доступа к кластеру Managed Service for ClickHouse® из других облачных сетей
    • Миграция кластера Yandex Data Processing с HDFS в другую зону доступности
    • Импорт данных из Managed Service for MySQL® в Yandex Data Processing с помощью Sqoop
    • Импорт данных из Managed Service for PostgreSQL в Yandex Data Processing с помощью Sqoop
    • Монтирование бакетов Object Storage к файловой системе хостов Yandex Data Processing
    • Работа с топиками Apache Kafka® с помощью Yandex Data Processing
    • Автоматизация работы с Yandex Data Processing с помощью Managed Service for Apache Airflow™
    • Совместная работа с таблицами Yandex Data Processing с использованием Metastore
    • Перенос метаданных между кластерами Yandex Data Processing с помощью Metastore
    • Импорт данных из Object Storage, обработка и экспорт в Managed Service for ClickHouse®
    • Миграция в Managed Service for Elasticsearch с помощью снапшотов
    • Миграция коллекций из стороннего кластера MongoDB в Managed Service for MongoDB
    • Миграция данных в Managed Service for MongoDB
    • Миграция кластера Managed Service for MongoDB с версии 4.4 на 6.0
    • Шардирование коллекций MongoDB
    • Анализ производительности и оптимизация MongoDB
    • Миграция БД из стороннего кластера MySQL® в кластер Managed Service for MySQL®
    • Анализ производительности и оптимизация Managed Service for MySQL®
    • Синхронизация данных из стороннего кластера MySQL® в Managed Service for MySQL® с помощью Data Transfer
    • Миграция БД из Managed Service for MySQL® в сторонний кластер MySQL®
    • Миграция БД из Managed Service for MySQL® в Object Storage с помощью Data Transfer
    • Перенос данных из Object Storage в Managed Service for MySQL® с использованием Data Transfer
    • Поставка данных из Managed Service for MySQL® в Managed Service for Apache Kafka® с помощью Data Transfer
    • Поставка данных из Managed Service for MySQL® в Managed Service for Apache Kafka® с помощью Debezium
    • Миграция БД из Managed Service for MySQL® в Managed Service for YDB с помощью Data Transfer
    • Захват изменений MySQL® и поставка в YDS
    • Миграция данных из Managed Service for MySQL® в Managed Service for PostgreSQL с помощью Data Transfer
    • Миграция данных из AWS RDS for PostgreSQL в Managed Service for PostgreSQL с помощью Data Transfer
    • Миграция данных из Managed Service for MySQL® в Managed Service for Greenplum® с помощью Data Transfer
    • Настройка политики индексов в Managed Service for OpenSearch
    • Миграция данных из Elasticsearch в Managed Service for OpenSearch
    • Миграция данных в Managed Service for OpenSearch из стороннего кластера OpenSearch с помощью Data Transfer
    • Загрузка данных из Managed Service for OpenSearch в Object Storage с помощью Data Transfer
    • Миграция данных из Managed Service for OpenSearch в Managed Service for YDB с помощью Data Transfer
    • Копирование данных из Managed Service for OpenSearch в Managed Service for Greenplum® с помощью Yandex Data Transfer
    • Миграция данных из Managed Service for PostgreSQL в Managed Service for OpenSearch с помощью Data Transfer
    • Аутентификация в OpenSearch Dashboards кластера Managed Service for OpenSearch с помощью Keycloak
    • Использование плагина yandex-lemmer в Managed Service for OpenSearch
    • Создание кластера PostgreSQL для «1С:Предприятия»
    • Поиск проблем с производительностью кластера Managed Service for PostgreSQL
    • Анализ производительности и оптимизация Managed Service for PostgreSQL
    • Логическая репликация PostgreSQL
    • Миграция БД из стороннего кластера PostgreSQL в Managed Service for PostgreSQL
    • Миграция БД из Managed Service for PostgreSQL
    • Поставка данных из Managed Service for PostgreSQL в Managed Service for Apache Kafka® с помощью Data Transfer
    • Поставка данных из Managed Service for PostgreSQL в Managed Service for Apache Kafka® с помощью Debezium
    • Поставка данных из Managed Service for PostgreSQL в Managed Service for YDB с помощью Data Transfer
    • Миграция БД из Managed Service for PostgreSQL в Object Storage
    • Перенос данных из Object Storage в Managed Service for PostgreSQL с использованием Data Transfer
    • Захват изменений PostgreSQL и поставка в YDS
    • Миграция данных из Managed Service for PostgreSQL в Managed Service for MySQL® с помощью Data Transfer
    • Миграция данных из Managed Service for PostgreSQL в Managed Service for OpenSearch с помощью Data Transfer
    • Решение проблем с сортировкой строк в PostgreSQL после обновления glibc
    • Миграция БД из Greenplum® в ClickHouse®
    • Миграция БД из Greenplum® в PostgreSQL
    • Выгрузка данных Greenplum® в холодное хранилище Object Storage
    • Загрузка данных из Object Storage в Managed Service for Greenplum® с помощью Data Transfer
    • Копирование данных из Managed Service for OpenSearch в Managed Service for Greenplum® с помощью Yandex Data Transfer
    • Создание внешней таблицы на базе таблицы из бакета Object Storage с помощью конфигурационного файла
    • Миграция БД из стороннего кластера Valkey™ в Yandex Managed Service for Valkey™
    • Использование кластера Yandex Managed Service for Valkey™ в качестве хранилища сессий PHP
    • Загрузка данных из Object Storage в Managed Service for YDB с помощью Data Transfer
    • Загрузка данных из Managed Service for YDB в Object Storage с помощью Data Transfer
    • Обработка аудитных логов Audit Trails
    • Обработка логов Cloud Logging
    • Обработка потока изменений Debezium
    • Анализ данных с помощью Jupyter
    • Обработка файлов детализации в сервисе Yandex Cloud Billing
    • Ввод данных в системы хранения
    • Умная обработка логов
    • Передача данных в микросервисных архитектурах
    • Миграция данных в Object Storage с помощью Data Transfer
    • Миграция данных из стороннего кластера Greenplum® или PostgreSQL в Managed Service for Greenplum® с помощью Data Transfer
    • Миграция кластера Managed Service for MongoDB
    • Миграция кластера MySQL®
    • Миграция на сторонний кластер MySQL®
    • Миграция кластера PostgreSQL
    • Создание реестра схем для поставки данных в формате Debezium CDC из Apache Kafka®
    • Автоматизация работы с помощью Yandex Managed Service for Apache Airflow™

В этой статье:

  • Проверьте состояние кластера с помощью Yandex Monitoring
  • Диагностируйте производительность кластера
  • Посмотрите логи кластера
  1. Построение Data Platform
  2. Поиск проблем с производительностью кластера Managed Service for PostgreSQL

Поиск проблем с производительностью кластера Managed Service for PostgreSQL

Статья создана
Yandex Cloud
Обновлена 20 марта 2025 г.
  • Проверьте состояние кластера с помощью Yandex Monitoring
  • Диагностируйте производительность кластера
  • Посмотрите логи кластера

Если возникли проблемы с производительностью кластера Managed Service for PostgreSQL, проведите его диагностику. Так вы узнаете, что вызвало проблемы, и сможете их предотвратить в будущем.

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

В качестве примера предположим, что в кластере Managed Service for PostgreSQL было повышенное потребление CPU. Чтобы понять, почему возникла проблема:

  1. Проверьте состояние кластера с помощью Yandex Monitoring.
  2. Диагностируйте производительность кластера.
  3. Посмотрите логи кластера.

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

Проверьте состояние кластера с помощью Yandex MonitoringПроверьте состояние кластера с помощью Yandex Monitoring

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

  2. Нажмите на имя нужного кластера и выберите вкладку Мониторинг.

  3. Чтобы перейти к работе с метриками, дашбордами или алертами в сервисе Yandex Monitoring, нажмите кнопку Открыть в Monitoring на панели сверху.

  4. На графике Average CPU usage найдите участок, где график постоянно рос, а потом вышел на плато.

    График показывает среднюю загрузку процессорных ядер. Плато на графике означает, что потребление CPU было выше нормы. Чтобы найти плато, отрегулируйте период, за который строятся графики.

  5. Посмотрите другие графики. Найдите на них всплески или плато за тот же период, в котором было повышенное потребление CPU.

    Проверьте следующие графики:

    • Session CPU usage cores — показывает потребление CPU по видам сессий. В результате можно узнать, во время сессии какого пользователя и на какой БД CPU потреблялось выше нормы.

      Обычно пользователи вызывают высокое потребление CPU, когда выполняют длительные запросы (например, аналитические запросы без индексов для таблиц). Такие запросы можно отследить на графике Age of oldest transaction/statement.

    • Age of oldest transaction/statement — показывает длительность транзакций и запросов. Если на графике есть всплеск, значит, определенные запросы выполнялись дольше обычного.

      Допустим, всплеск на графике Age of oldest transaction/statement отображается за то же время, что и всплески или плато на графиках Session CPU usage cores и Average CPU usage. Это означает, что повышенное потребление CPU вызвали длительные запросы.

    1. (Опционально) Проверьте другие графики:

      • Average transaction/statement time — показывает среднее время, затраченное на выполнение транзакций и запросов. Если график возрастает, возможно, некоторые запросы стали выполняться дольше.

      • Log errors — показывает поток ошибок в кластере. Если на графике есть всплеск, проверьте логи кластера.

      • OOM Count — показывает наличие процессов Out-Of-Memory Killer. Они останавливают приложения, которые расходуют всю память на машине, и предотвращают аварийную остановку ОС. Если на графике OOM Count отображаются процессы Out-Of-Memory Killer, проверьте расход памяти в кластере на графике Maximum memory usage и освободите память для приложений.

      • PostgreSQL Alive, [boolean] — показывает доступность PostgreSQL на хостах кластера. Если вы не можете подключиться к какому-либо хосту кластера, проверьте его доступность на этом графике.

      • Sessions per wait event — количество ожидающих сессий по типам событий. К таким типам относятся, например, блокировки или ожидание, когда CPU или память освободятся. Если на графике есть всплеск, значит, в кластере заканчиваются ресурсы.

      • Sessions read bytes и Sessions write bytes — показывают объем прочитанных и записанных данных в разбивке по сессиям. Если объем упирается в лимит, работа кластера может замедлиться.

      • Transactions/statements per second — показывает количество запросов и транзакций в секунду. Если на кластер создана высокая нагрузка, график покажет, вызвана ли она большим количеством запросов. Если у кластера заканчиваются ресурсы, на графике отображается провал.

      Полный список графиков доступен в разделе {#T}.

Диагностируйте производительность кластераДиагностируйте производительность кластера

После того как вы выяснили, в какое время потребление CPU было повышенным, найдите запросы, которые привели к проблеме. Для этого воспользуйтесь диагностикой производительности в кластере Managed Service for PostgreSQL:

  1. Включите опцию Сбор статистики, если она еще не включена.

  2. На странице кластера выберите Диагностика производительности на панели слева.

  3. На открывшейся вкладке найдите участок, где график постоянно рос, а потом вышел на плато. Он должен совпадать по времени с теми же участками графиков, которые вы нашли в Yandex Monitoring.

    Чтобы найти плато, отрегулируйте период, за который строятся графики.

  4. На вкладке Сессии, в поле Срез выберите значение WAIT_EVENT.

  5. Найдите события ожидания (wait events), из-за которых потребление CPU повысилось. Для этого наведите курсор на плато. Во всплывающем окне отобразятся все возможные события ожидания. На проблему преимущественно влияют события с наибольшими значениями.

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

    Допустим, график показал много событий ожидания типа CPU. Тогда проблемные запросы также содержат большое количество таких событий. Это видно на диаграммах, расположенных в строках запросов в списке:

    image

В результате вы нашли запросы, которые вызвали повышенное потребление CPU.

Посмотрите логи кластераПосмотрите логи кластера

Допустим, в Yandex Monitoring, на графике Log errors отображаются всплески. Чтобы узнать, что произошло, проверьте логи кластера. Их рекомендуется проверять ежедневно, не только в случае инцидентов. Так вы будете знать об актуальном состоянии кластера.

Чтобы посмотреть логи:

  1. На странице кластера Managed Service for PostgreSQL выберите Логи на панели слева.

  2. Задайте период, за который было замечено повышенное потребление CPU.

  3. В поле Уровень логирования выберите ERROR, PANIC и FATAL.

  4. Посмотрите полученный список ошибок. Они показывают, что происходило во время повышенного потребления CPU.

    Ошибка может отображаться в логах несколько раз. Например, если пользователь отправлял слишком длительные запросы, в логах может повторяться ошибка canceling statement due to user request. Это означает, что БД не смогла обработать запросы в ожидаемый промежуток времени, и поэтому они были отменены.

  5. Смените уровень логирования на LOG и WARNING.

  6. Посмотрите полученный список событий, которые происходили за заданный период.

    В логах отображаются запросы, которые были выполнены. Если в кластере преднастроен параметр СУБД log_min_duration_statement, логи также показывают время выполнения запросов. В результате можно найти длительные запросы.

    Важно

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

    Логи типа LOG и WARNING содержат не только выполненные запросы. Например, в логах может быть запись temporary file: path "<путь_к_файлу>" size <размер_файла>. Многократный повтор такой записи показывает, что запросы составлены неоптимально. Их сортировка или агрегация потребляют слишком много памяти work_mem, выделенной под выполнение операций в БД. В результате не хватает памяти в буфере кластера.

В результате вы определили, когда и почему возникло повышенное потребление CPU, какие пользователи и запросы вызвали его и какие события были связаны с этой проблемой. Чтобы в дальнейшем предотвратить повтор проблемы в кластере Managed Service for PostgreSQL, оптимизируйте его работу.

Была ли статья полезна?

Предыдущая
Создание кластера PostgreSQL для «1С:Предприятия»
Следующая
Анализ производительности и оптимизация Managed Service for PostgreSQL
Проект Яндекса
© 2025 ООО «Яндекс.Облако»