Поделиться через

Устранение проблем, связанных с высоким уровнем использования процессора в Базе данных Azure для PostgreSQL (гибкий сервер)

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для PostgreSQL — гибкий сервер

В этой статье показано, как быстро определить первопричину высокой загрузки ЦП и возможные действия по исправлению использования ЦП при использовании гибкого сервера База данных Azure для PostgreSQL.

Из этой статьи вы узнаете следующее.

  • Сведения об устранении неполадок для выявления и получения рекомендаций по устранению основных причин.
  • какие средства помогают выявить высокую загрузку ЦП — метрики Azure, хранилище запросов и pg_stat_statements;
  • как определять первопричины проблем, например длительные запросы и большое количество подключений;
  • как устранить высокую загрузку ЦП с помощью таблиц анализа, пула подключений и очистки.

Руководства по устранению неполадок

С помощью руководств по устранению неполадок функций, доступных на портале гибкого сервера База данных Azure для PostgreSQL, можно найти вероятные первопричины и рекомендации по устранению высокого уровня ЦП. Как настроить руководства по устранению неполадок, чтобы использовать их, следуйте инструкциям по устранению неполадок установки.

Средства для выявления высокого уровня использования ЦП

Для выявления высокого уровня использования ЦП можно применить следующие средства.

Метрики Azure

Метрики Azure всегда будут хорошей отправной точкой для анализа использования ЦП за определенную дату и период. Метрики предоставляют сведения о длительности периода с высокой загрузкой ЦП. Сравните графики нагрузки на ЦП с графиками операций ввода-вывода в секунду для записи и чтения, пропускной способности для записи и чтения. Это поможет выявить периоды, в которые рабочая нагрузка приводит к высокой загрузке ЦП. Для упреждающего мониторинга настройте оповещения для метрик. Пошаговые инструкции см. в статье Метрики Azure.

Хранилище запросов

Хранилище запросов автоматически ведет журнал запросов и статистики выполнения и сохраняет их для просмотра. В журнале выполняется сортировка данных по времени, чтобы можно было видеть шаблоны использования во времени. Данные для всех пользователей, баз данных и запросов хранятся в базе данных с именем azure_sys в гибком экземпляре сервера База данных Azure для PostgreSQL. Пошаговые инструкции см. в разделе Хранилище запросов.

pg_stat_statements

Расширение pg_stat_statements помогает определить, какие запросы потребляют время работы сервера.

Среднее время выполнения

Для Postgres версии 13 и более поздних используйте следующую процедуру, чтобы просмотреть пять инструкций SQL, имеющих наибольшее среднее время выполнения:

SELECT userid::regrole, dbid, query, mean_exec_time
FROM pg_stat_statements
ORDER BY mean_exec_time
DESC LIMIT 5;

Общее время выполнения

Выполните следующие инструкции, чтобы просмотреть пять инструкций SQL, имеющих наибольшее общее время выполнения.

Для Postgres версии 13 и более поздних используйте следующую процедуру, чтобы просмотреть пять инструкций SQL, имеющих наибольшее общее время выполнения:

SELECT userid::regrole, dbid, query
FROM pg_stat_statements
ORDER BY total_exec_time
DESC LIMIT 5;

Определение первопричин

Если уровни потребления ЦП не связаны с конкретным источником, возможны следующие первопричины:

Продолжительные транзакции

Длительные транзакции могут использовать много ресурсов ЦП, что приводит к высокой загрузке ЦП.

Следующий запрос помогает определить подключения, выполнение которых занимает много времени:

SELECT pid, usename, datname, query, now() - xact_start as duration
FROM pg_stat_activity
WHERE pid <> pg_backend_pid() and state IN ('idle in transaction', 'active')
ORDER BY duration DESC;

Общее количество подключений и число подключений по состояниям

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

Следующий запрос предоставляет сведения о количестве подключений с разбивкой по состояниям:

SELECT state, count(*)
FROM  pg_stat_activity
WHERE pid <> pg_backend_pid()
GROUP BY 1 ORDER BY 1;

Устранение высокой загрузки ЦП

Используйте средства Explain Analyze, PG Bouncer, пулы подключений и принудительно завершайте длительные транзакции, чтобы устранить проблему с высокой нагрузкой на ЦП.

Использование анализа объясняемых данных

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

PGBouncer и пул подключений

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

Дополнительные сведения о PgBouncer:

Организация пулов подключений.

Рекомендации

База данных Azure для PostgreSQL гибкий сервер предлагает PgBouncer в качестве встроенного решения для пула подключений. Дополнительные сведения см. в разделе PgBouncer.

Завершение длительных транзакций

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

Чтобы завершить идентификатор piD сеанса, необходимо обнаружить piD с помощью следующего запроса:

SELECT pid, usename, datname, query, now() - xact_start as duration
FROM pg_stat_activity
WHERE pid <> pg_backend_pid() and state IN ('idle in transaction', 'active')
ORDER BY duration DESC;

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

После получения пин-код сеанса можно завершить с помощью следующего запроса:

SELECT pg_terminate_backend(pid);

Мониторинг статистики вакуума и таблицы

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

Следующий запрос помогает определить таблицы, требующие очистки:

select schemaname,relname,n_dead_tup,n_live_tup,last_vacuum,last_analyze,last_autovacuum,last_autoanalyze
from pg_stat_all_tables where n_live_tup > 0;

столбцы last_autovacuum и last_autoanalyze содержат дату и время последней автоматической очистки или анализа таблицы. Если таблицы регулярно не вакуумируются, выполните действия по настройке автовакуума. Дополнительные сведения о настройке автоматической очистки и устранении неполадок с ней см. в статье Устранение неполадок с автоматической очисткой.

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

vacuum analyze <table_name>;

Связанный контент