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

Если возникли проблемы с производительностью кластера 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 — показывает количество запросов и транзакций в секунду. Если на кластер создана высокая нагрузка, график покажет, вызвана ли она большим количеством запросов. Если у кластера заканчиваются ресурсы, на графике отображается провал.

      Полный список графиков доступен в разделе Мониторинг состояния кластера PostgreSQL и хостов.

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

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

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

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

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

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

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

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

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

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

   

В результате вы нашли запросы, которые вызвали повышенное потребление 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, оптимизируйте его работу.