Мониторинг производительности с помощью хранилища запросов

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

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

Включение хранилища запросов

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

Включение хранилища запросов в портал Azure

1. Войдите в портал Azure и выберите экземпляр гибкого сервера База данных Azure для PostgreSQL.
2. Выберите параметры сервера в разделе "Параметры" меню.
3. Найдите параметр pg_qs.query_capture_mode.
4. Задайте значение top или allв зависимости от того, хотите ли вы отслеживать запросы верхнего уровня или также вложенные запросы (те, которые выполняются внутри функции или процедуры), и нажмите кнопку "Сохранить". Разрешить до 20 минут для первого пакета данных сохраняться в azure_sys базе данных.

Включение выборки ожидания хранилища запросов

1. Найдите параметр pgms_wait_sampling.query_capture_mode.
2. Установите значение all и нажмите Сохранить.

Сведения в хранилище запросов

Хранилище запросов состоит из двух хранилищ:

1. хранилище статистики времени выполнения для хранения статистических сведений о выполнении запросов;
2. хранилище статистики ожидания для хранения статистических сведений об ожидании.

Ниже приведены распространенные сценарии использования хранилища запросов:

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

С целью экономии места к статистическим данным о выполнении запросов в хранилище статистики времени выполнения применяется агрегирование за фиксированный настраиваемый период. Данные в этих хранилищах можно запрашивать с использованием представлений.

Доступ к сведениям о хранилище запросов

Данные хранилища запросов хранятся в azure_sys базе данных на База данных Azure для PostgreSQL гибком экземпляре сервера. Следующий запрос возвращает сведения о запросах, записанных в хранилище запросов:

SELECT * FROM  query_store.qs_view;

И этот запрос возвращает сведения о статистике ожидания:

SELECT * FROM  query_store.pgms_wait_sampling_view;

Поиск запросов ожидания

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

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

Варианты конфигурации

Если хранилище запросов включено, он сохраняет данные в окнах агрегирования длины, определенных параметром сервера pg_qs.interval_length_minutes (по умолчанию — 15 минут ). Для каждого окна оно хранит до 500 отдельных запросов на окно. Атрибуты, которые отличают уникальность каждого запроса, являются userid (идентификатор пользователя, выполняющего запрос), dbid (идентификатор базы данных, в контексте которого выполняется запрос) и queryid (целочисленное значение, уникально определяющее выполняемый запрос). Если количество отдельных запросов достигает 500 в течение настроенного интервала, 5% записываемых запросов будут освобождены, чтобы освободить место для получения дополнительных возможностей. Те, которые были освобождены, сначала являются теми, которые были выполнены наименьшее количество раз.

Для настройки параметров хранилище запросов доступны следующие параметры:

(*) Параметр статического сервера, для которого требуется перезапуск сервера, чтобы изменить его значение, вступают в силу.

Следующие параметры применяются специально к статистике ожидания:

Используйте портал Azure, чтобы получить значение параметра или задать другое значение.

Представления и функции

Вы можете запросить информацию, записанную в хранилище запросов, или удалить ее с помощью некоторых представлений и функций, доступных в схеме query_store azure_sys базы данных. Любой пользователь в общедоступной роли PostgreSQL может использовать эти представления для просмотра данных в хранилище запросов. Эти представления доступны только в базе данных azure_sys.

Запросы нормализуются, просматривая их структуру и игнорируя ничего не семантического значения, таких как литералы, константы, псевдонимы или различия в регистре.

Если два запроса семантически идентичны, даже если они используют разные псевдонимы для одинаковых ссылочных столбцов и таблиц, они идентифицируются с одинаковыми query_id. Если два запроса отличаются только в литеральных значениях, используемых в них, они также идентифицируются с одинаковыми query_id. Для запросов, определенных с тем же query_id, их sql_query_text заключается в том, что запрос, который выполнялся сначала с момента начала записи хранилища запросов, или с момента последнего отмены сохраненных данных, так как функция query_store.qs_reset была выполнена.

Как работает нормализация запросов

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

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

create table tableOne (columnOne int, columnTwo int);

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

select * from tableOne;
select columnOne, columnTwo from tableOne;
select columnOne as c1, columnTwo as c2 from tableOne as t1;
select columnOne as "column one", columnTwo as "column two" from tableOne as "table one";

Все предыдущие запросы используют одинаковые query_id. И текст, который хранилище запросов сохраняется, заключается в том, что первый запрос, выполняемый после включения сбора данных. Таким образом, это было бы select * from tableOne;.

Следующий набор запросов после нормализации не соответствует предыдущему набору запросов, так как предложение WHERE делает их семантической по-разному:

select columnOne as c1, columnTwo as c2 from tableOne as t1 where columnOne = 1 and columnTwo = 1;
select * from tableOne where columnOne = -3 and columnTwo = -3;
select columnOne, columnTwo from tableOne where columnOne = '5' and columnTwo = '5';
select columnOne as "column one", columnTwo as "column two" from tableOne as "table one" where columnOne = 7 and columnTwo = 7;

Однако все запросы в этом последнем наборе используют одинаковые query_id, а текст, используемый для их идентификации, состоит в том, что первый запрос в пакете select columnOne as c1, columnTwo as c2 from tableOne as t1 where columnOne = 1 and columnTwo = 1;.

Наконец, найдите ниже некоторые запросы, не соответствующие query_id из них в предыдущем пакете, и причина, по которой они не:

Запрос:

select columnTwo as c2, columnOne as c1 from tableOne as t1 where columnOne = 1 and columnTwo = 1;

Причина несоответствия: список столбцов относится к тем же двум столбцам (columnOne и ColumnTwo), но порядок, в котором они называются, обратно, от columnOne, ColumnTwo предыдущего пакета до ColumnTwo, columnOne этого запроса.

Запрос:

select * from tableOne where columnTwo = 25 and columnOne = 25;

Причина несоответствия: порядок, в котором выражения, вычисляемые в предложении WHERE, ссылаются обратно из columnOne = ? and ColumnTwo = ? предыдущего пакета ColumnTwo = ? and columnOne = ? в этот запрос.

Запрос:

select abs(columnOne), columnTwo from tableOne where columnOne = 12 and columnTwo = 21;

Причина несоответствия: первое выражение в списке столбцов больше не columnOne совпадает, но функция abs , вычисляемая поверх columnOne (abs(columnOne)), которая не является семантической эквивалентной.

Запрос:

select columnOne as "column one", columnTwo as "column two" from tableOne as "table one" where columnOne = ceiling(16) and columnTwo = 16;

Причина несоответствия: первое выражение в предложении WHERE больше не оценивает равенство columnOne с литеральным, но с результатом функции ceiling , вычисляемой по литералу, которая не является семантически эквивалентной.

Представления

query_store.qs_view

Это представление возвращает все данные, сохраненные в вспомогательных таблицах хранилища запросов. Данные, которые по-прежнему записывайте в памяти для текущего активного периода времени, не отображаются до тех пор, пока время не завершится, и его в памяти переменные данные собираются и сохраняются в таблицах, хранящихся на диске. Это представление возвращает другую строку для каждой отдельной базы данных (db_id), пользователя (user_id) и запроса (query_id).

query_store.query_texts_view

Это представление возвращает текстовые данные запроса в хранилище запросов. Для каждой отдельной query_sql_text существует одна строка.

query_store.pgms_wait_sampling_view

Это представление возвращает данные событий ожидания в хранилище запросов. Это представление возвращает другую строку для каждой отдельной базы данных (db_id), пользователя (user_id), запроса (query_id) и события (события).

query_store.query_plans_view

Это представление возвращает план запроса, который использовался для выполнения запроса. Для каждой отдельной базы данных и идентификатора запроса существует одна строка. Хранилище запросов записывает только планы запросов для неуловимых запросов.

Функции

query_store.qs_reset

Эта функция отменяет все статистические данные, собранные до сих пор по хранилищу запросов. Она удаляет статистику для уже закрытых периодов времени, которые уже сохраняются в таблицах на диске. Она также отменяет статистику для текущего периода времени, которое существует только в памяти. Только члены роли администратора сервера (azure_pg_admin) могут выполнять эту функцию.

query_store.staging_data_reset

Эта функция удаляет все статистические данные, собранные в памяти по хранилищу запросов (т. е. данные в памяти, которые еще не удалены на таблицы дисков, поддерживающие сохраняемость собранных данных для хранилища запросов). Только члены роли администратора сервера (azure_pg_admin) могут выполнять эту функцию.

Режим только для чтения

Если экземпляр гибкого сервера База данных Azure для PostgreSQL находится в режиме только для чтения, например если default_transaction_read_only параметр установлен onили если режим только для чтения включен из-за достижения емкости хранилища, хранилище запросов не записывает данные.

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

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

• Сценарии, в которых хранилище запросов может быть особенно полезным
• Рекомендации по использованию хранилища запросов
• визуализация данных из хранилища запросов с помощью аналитики производительности запросов