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

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

  • Статья

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

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

В этой статье раскрываются приведенные ниже темы.

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

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

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

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

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

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

Метрики 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 state
ORDER BY state ASC;

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

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

Использование EXPLAIN ANALYZE

После того как вы знаете запросы, которые используют больше ЦП, используйте EXPLAIN ANALYZE для дальнейшего изучения и настройки.

Дополнительные сведения о команде EXPLAIN ANALYZE см. в документации.

PgBouncer, встроенный пул соединений

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

Дополнительные сведения о PgBouncer см. в статье "Пул подключений" и рекомендации по обработке подключений с помощью PostgreSQL

База данных 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>;

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