Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
ОБЛАСТЬ ПРИМЕНЕНИЯ:
База данных Azure для PostgreSQL — гибкий сервер
Хранилище запросов — это функция гибкого сервера Базы данных Azure для PostgreSQL, которая позволяет отслеживать производительность запросов с течением времени. Хранилище запросов упрощает устранение проблем с производительностью, помогая быстро находить самые длительные и наиболее ресурсоемкие запросы. Хранилище запросов автоматически записывает журнал запросов и статистику среды выполнения и сохраняет их для проверки. Он срезает данные по времени, чтобы увидеть временные шаблоны использования. Данные для всех пользователей, баз данных и запросов хранятся в базе данных с именем azure_sys в База данных Azure для PostgreSQL гибком экземпляре сервера.
Включение хранилища запросов
Хранилище запросов доступно для использования без дополнительных расходов. Это функция согласия, поэтому она не включена по умолчанию на сервере. Хранилище запросов можно включить или отключить глобально для всех баз данных на определенном сервере и не может быть включен или отключен для каждой базы данных.
Это важно
Не включайте хранилище запросов на ценовую категорию Burstable, что может привести к снижению производительности.
Включение хранилища запросов на портале Azure
- Войдите на портал Azure и выберите гибкий экземпляр сервера Базы данных Azure для PostgreSQL.
- Выберите параметры сервера в разделе "Параметры " меню.
- Найдите параметр
pg_qs.query_capture_mode. - Задайте значение
topилиallв зависимости от того, хотите ли вы отслеживать запросы верхнего уровня или также вложенные запросы (те, которые выполняются внутри функции или процедуры), и нажмите кнопку "Сохранить". Подождите до 20 минут, чтобы первый пакет данных сохранился вazure_sysбазе данных.
Включить выборку ожиданий в хранилище запросов
- Найдите параметр
pgms_wait_sampling.query_capture_mode. - Задайте значение
allи сохраните его.
Сведения в хранилище запросов
Хранилище запросов состоит из двух хранилищ:
- Хранилище статистики среды выполнения для сохранения сведений о статистике выполнения запросов.
- Хранилище статистики ожидания для сохранения сведений статистики ожидания.
Ниже приведены распространенные сценарии использования хранилища запросов:
- Определение количества выполнения запроса в заданном окне времени.
- Сравнение среднего времени выполнения запроса в течение нескольких периодов времени, чтобы увидеть большие вариации.
- Определение самых длительных запросов за последние несколько часов.
- Определение основных 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 отдельных запросов на окно. Атрибуты, которые отличают уникальность каждого запроса, user_id (идентификатор пользователя, выполняющего запрос), db_id (идентификатор базы данных, в контексте которой выполняется запрос) и query_id (целочисленное значение, уникально определяющее выполняемый запрос). Если число уникальных запросов достигает 500 в течение настроенного интервала, 5% из записанных будут удалены, чтобы освободить место для большего количества. Первыми освобождаются те, которые были выполнены наименьшее количество раз.
Для настройки параметров хранилища запросов доступны следующие параметры:
| Параметр | Описание | По умолчанию | Диапазон |
|---|---|---|---|
pg_qs.interval_length_minutes (*) |
Интервал фиксации данных в минутах для хранилища запросов. Определяет частоту сохраняемости данных. | 15 |
1 - 30 |
pg_qs.is_enabled_fs |
Только для внутреннего использования: этот параметр используется в качестве переопределения функции. Если оно отображается как отключенное, хранилище запросов отключено, несмотря на значение, заданное для pg_qs.query_capture_mode. |
on |
on, off |
pg_qs.max_plan_size |
Максимальное количество байтов, сохраненных из текста плана запроса хранилищем запросов; более длинные планы сокращены. | 7500 |
100 - 10000 |
pg_qs.max_query_text_length |
Максимальная длина запроса, которую можно сохранить; более длинные запросы усечены. | 6000 |
100 - 10000 |
pg_qs.parameters_capture_mode |
Указывает, следует ли и когда записывать позиционные параметры запроса. | capture_parameterless_only |
capture_parameterless_only, capture_first_sample |
pg_qs.query_capture_mode |
Утверждения для отслеживания. | none |
none, top, all |
pg_qs.retention_period_in_days |
Период хранения в днях для хранилища запросов. Старые данные автоматически удаляются. | 7 |
1 - 30 |
pg_qs.store_query_plans |
Следует ли сохранять планы запросов в хранилище запросов. | off |
on, off |
pg_qs.track_utility |
Следует ли Query Store отслеживать команды служебных утилит. | on |
on, off |
(*) Параметр статического сервера, для изменения значения которого требуется перезапуск сервера для вступления в силу.
Замечание
Если изменить значение параметра pg_qs.max_query_text_length , текст всех запросов, которые были записаны перед изменением, продолжают использовать те же query_id и sql_query_text. Это может дать впечатление, что новое значение не вступает в силу, но для запросов, которые не были записаны в хранилище запросов раньше, вы заметите, что текст запроса использует вновь настроенную максимальную длину. Это сделано намеренно и объясняется в разделе представления и функции. Если вы выполняете query_store.qs_reset, удаляет все данные, записанные хранилищем запросов до сих пор, включая текст, записанный для каждого идентификатора запроса, и если любой из этих запросов выполняется снова, то только что настроенная максимальная длина применяется к захватываемому тексту.
Следующие параметры применяются специально к статистике ожидания:
| Параметр | Описание | По умолчанию | Диапазон |
|---|---|---|---|
pgms_wait_sampling.history_period |
Частота ( в миллисекундах), при которой выборка событий ожидания выполняется. | 100 |
1 - 600000 |
pgms_wait_sampling.is_enabled_fs |
Только для внутреннего использования: этот параметр используется в качестве переопределения функции. Если он отображается как off, выборка ожидания отключена, несмотря на значение, заданное для pgms_wait_sampling.query_capture_mode. |
on |
on, off |
pgms_wait_sampling.query_capture_mode |
Какие утверждения должно отслеживать расширение pgms_wait_sampling. |
none |
none, all |
Замечание
pg_qs.query_capture_mode
pgms_wait_sampling.query_capture_modeзаменяет. В противном pg_qs.query_capture_modenonepgms_wait_sampling.query_capture_mode случае параметр не действует.
Используйте портал Azure , чтобы получить или задать другое значение параметра.
Представления и функции
Вы можете запросить информацию, записанную в хранилище запросов, или удалить ее с помощью некоторых представлений и функций, доступных в схеме query_storeazure_sys базы данных. Любой пользователь в общедоступной роли PostgreSQL может использовать эти представления для просмотра данных в хранилище запросов. Эти представления доступны только в базе данных azure_sys .
Запросы нормализуются за счёт анализа их структуры и игнорирования компонентов, не имеющих семантического значения, таких как литералы, константы, псевдонимы и различия в регистре.
Если два запроса семантически идентичны, то, даже если они используют разные псевдонимы для одинаковых ссылочных столбцов и таблиц, они идентифицируются с тем же идентификатором запроса. Если два запроса отличаются только в литеральных значениях, используемых в них, они также имеют одинаковый 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;.
Ниже приведены некоторые запросы, которые не соответствуют идентификаторам запросов в предыдущем пакете, и причина их несоответствия.
Запрос:
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).
| Имя | Тип | Ссылки | Описание |
|---|---|---|---|
runtime_stats_entry_id |
Бигинт | Идентификатор из таблицы runtime_stats_entries. | |
user_id |
oid | pg_authid.oid | Идентификатор пользователя, выполнившего инструкцию. |
db_id |
oid | pg_database.oid | OID базы данных, в которой была выполнена инструкция. |
query_id |
Бигинт | Внутренний хэш-код, вычисляемый из дерева синтаксического анализа инструкции. | |
query_sql_text |
varchar(10000) | Текст репрезентативного заявления. Различные запросы с одной структурой кластеризованы вместе; этот текст — это текст для первого запроса в кластере. Значение по умолчанию для максимальной длины текста запроса равно 6000 и может быть изменено с помощью параметра pg_qs.max_query_text_lengthхранилища запросов. Если текст запроса превышает это максимальное значение, оно усечено до первых pg_qs.max_query_text_length байтов. |
|
plan_id |
Бигинт | Идентификатор плана, соответствующего этому запросу. | |
start_time |
отметка времени | Запросы агрегируются по временным периодам. Параметр pg_qs.interval_length_minutes сервера определяет интервал времени этих окон (по умолчанию — 15 минут). Этот столбец соответствует времени начала окна, в котором была записана запись. |
|
end_time |
отметка времени | Время окончания, соответствующее временному интервалу для этой записи. | |
calls |
Бигинт | Количество раз, когда запрос выполняется в этом окне времени. Обратите внимание, что для параллельных запросов число вызовов для каждого выполнения соответствует 1 для внутреннего процесса, который управляет выполнением запроса, а также множество других единиц для каждого внутреннего рабочего процесса, который запускает совместную работу, выполняя параллельные ветви дерева выполнения. | |
total_time |
двойная точность | Общее время выполнения запроса в миллисекундах. | |
min_time |
двойная точность | Минимальное время выполнения запроса в миллисекундах. | |
max_time |
двойная точность | Максимальное время выполнения запроса в миллисекундах. | |
mean_time |
двойная точность | Среднее время выполнения запроса в миллисекундах. | |
stddev_time |
двойная точность | Стандартное отклонение времени выполнения запроса в миллисекундах. | |
rows |
Бигинт | Общее количество строк, полученных или затронутых инструкцией. Обратите внимание, что для параллельных запросов количество строк для каждого выполнения соответствует количеству строк, возвращаемых клиенту серверным процессом, который управляет выполнением запроса, плюс сумме всех строк, которые каждый серверный процесс, запущенный для совместного выполнения параллельных ветвей дерева выполнения, возвращает этому серверному процессу, управляющему выполнением запроса. | |
shared_blks_hit |
Бигинт | Общее количество попаданий в общий кэш блоков инструкцией. | |
shared_blks_read |
Бигинт | Общее количество блоков, совместно используемых и прочитанных инструкцией. | |
shared_blks_dirtied |
Бигинт | Общее количество разделяемых блоков, изменённых запросом. | |
shared_blks_written |
Бигинт | Общее количество общих блоков, написанных инструкцией. | |
local_blks_hit |
Бигинт | Общее количество попаданий в кэш локальных блоков запросом. | |
local_blks_read |
Бигинт | Общее количество локальных блоков, считываемых инструкцией. | |
local_blks_dirtied |
Бигинт | Общее количество локальных блоков, изменённых запросом. | |
local_blks_written |
Бигинт | Общее количество локальных блоков, написанных инструкцией. | |
temp_blks_read |
Бигинт | Общее количество блоков temp, считываемых инструкцией. | |
temp_blks_written |
Бигинт | Общее количество блоков temp, написанных инструкцией. | |
blk_read_time |
двойная точность | Общее время, затраченное заявлением на чтение блоков, в миллисекундах (если включен track_io_timing, иначе ноль). | |
blk_write_time |
двойная точность | Общее время, которое заявление потратило на запись блоков, в миллисекундах (если track_io_timing включен, в противном случае ноль). | |
is_system_query |
булевый | Определяет, выполняла ли роль с user_id = 10 (azuresu) запрос. Этот пользователь имеет права суперпользователя и используется для выполнения операций контрольной плоскости. Так как эта служба является управляемой службой PaaS, только корпорация Майкрософт является частью этой роли суперпользователя. | |
query_type |
текст | Тип операции, представленной запросом. Возможные значения: unknown, select, update, insert, delete, merge, utility, nothing, . undefined |
|
search_path |
текст | Значение search_path задано во время записи запроса. | |
query_parameters |
текст | Текстовое представление объекта JSON со значениями, передаваемыми в позиционные параметры параметризованного запроса. Этот столбец заполняет значение только в двух случаях: 1) для непараметризованных запросов. 2) Для параметризованных запросов, если pg_qs.parameters_capture_mode задано capture_first_sample, и хранилище запросов может получить значения параметров запроса во время выполнения. |
|
parameters_capture_status |
текст | Тип операции, представленной запросом. Возможные значения succeeded (запрос не был параметризован или был параметризованным, и значения были успешно записаны), disabled (запрос был параметризован, но параметры не были записаны, потому что pg_qs.parameters_capture_mode установлено в capture_parameterless_only), too_long_to_capture (запрос был параметризован, но параметры не были записаны, так как длина результирующего JSON, который будет отображаться в столбце query_parameters этого представления, считалась чрезмерно длинной для сохранения в хранилище запросов), too_many_to_capture (запрос был параметризован, но параметры не были записаны, так как общее количество параметров считалось чрезмерным для сохранения в хранилище запросов), serialization_failed (запрос был параметризован, но по крайней мере одно из значений, переданных как параметр, не может быть сериализовано в текст). |
query_store.query_texts_view
Это представление возвращает текстовые данные запроса в хранилище запросов. Для каждого уникального query_sql_text имеется одна строка.
| Имя | Тип | Описание |
|---|---|---|
query_text_id |
Бигинт | Идентификатор таблицы query_texts |
query_sql_text |
varchar(10000) | Текст репрезентативного заявления. Различные запросы с одной структурой кластеризованы вместе; этот текст — это текст для первого запроса в кластере. |
query_type |
smallint | Тип операции, представленной запросом. В версии PostgreSQL <= 14 возможные значения : 0 (неизвестно), 12 (select), (обновление), 3 (вставка), (удаление), 45 (служебная программа), 6 (ничего). В версии PostgreSQL >= 15 возможные значения: 0 (неизвестно), 1 (select), 2 (update), 3 (insert), 4 (delete), 5 (merge), 6 (utility), 7 (nothing). |
query_store.pgms_wait_выборка_view
Это представление возвращает данные о событиях ожидания в хранилище запросов. Это представление возвращает другую строку для каждой отдельной базы данных (db_id), пользователя (user_id), запроса (query_id) и события (события).
| Имя | Тип | Ссылки | Описание |
|---|---|---|---|
start_time |
отметка времени | Запросы агрегируются по временным периодам. Параметр pg_qs.interval_length_minutes сервера определяет интервал времени этих окон (по умолчанию — 15 минут). Этот столбец соответствует времени начала окна, в котором была записана запись. |
|
end_time |
отметка времени | Время окончания, соответствующее временному интервалу для этой записи. | |
user_id |
oid | pg_authid.oid | Идентификатор объекта пользователя, выполнившего инструкцию. |
db_id |
oid | pg_database.oid | Идентификатор объекта базы данных, в которой была выполнена инструкция. |
query_id |
Бигинт | Внутренний хэш-код, вычисляемый из дерева синтаксического анализа инструкции. | |
event_type |
текст | Тип события, которого ожидает сервер. | |
event |
текст | Имя события ожидания, если серверная часть в настоящее время ожидает. | |
calls |
целое число | Количество раз, когда было записано одно и то же событие. |
Замечание
Для списка возможных значений в столбцах event_type и event представления query_store.pgms_wait_sampling_view, обратитесь к официальной документации pg_stat_activity и найдите информацию, связанную со столбцами с такими же названиями.
хранилище_запросов.просмотр_планов_запросов
Это представление возвращает план запроса, который использовался для выполнения запроса. Для каждой отдельной базы данных и идентификатора запроса существует одна строка. Хранилище запросов записывает только планы запросов для неутилитарных запросов.
| Имя | Тип | Ссылки | Описание |
|---|---|---|---|
plan_id |
Бигинт | Хэш-значение из нормализованного плана запроса, созданного с помощью команды EXPLAIN. Он находится в нормализованной форме, так как он исключает предполагаемые затраты на узлы плана и использование буферов. | |
db_id |
oid | pg_database.oid | OID базы данных, в которой была выполнена инструкция. |
query_id |
Бигинт | Внутренний хэш-код, вычисляемый из дерева синтаксического анализа инструкции. | |
plan_text |
varchar(10000) | План выполнения инструкции с заданными затратами=false, buffers=false и format=text. Идентичные выходные данные, аналогичные выходным данным, созданным с помощью EXPLAIN. |
Функции
query_store.qs_reset
Эта функция сбрасывает все статистические данные, собранные до сих пор хранилищем запросов. Она удаляет статистику для уже закрытых периодов времени, которые уже сохраняются в таблицах на диске. Она также отменяет статистику для текущего периода времени, которое существует только в памяти. Только члены роли администратора сервера (azure_pg_admin) могут выполнять эту функцию.
query_store.staging_data_reset
Эта функция удаляет все статистические данные, собранные в памяти хранилищем запросов (т. е. данные в памяти, которые еще не перенесены в таблицы на диске, обеспечивающие сохранность собранных данных для хранилища запросов). Только члены роли администратора сервера (azure_pg_admin) могут выполнять эту функцию.
Режим только для чтения
Если гибкий сервер Базы данных Azure для PostgreSQL находится в режиме только для чтения, например, если default_transaction_read_only параметр установлен onили автоматически включен режим только для чтения из-за достижения емкости хранилища, хранилище запросов не записывает данные.
Включение хранилища запросов на сервере с репликами чтения не приводит к автоматическому включению хранилища запросов на любую из реплик чтения. Даже если включить эту функцию на любой из реплик чтения, хранилище запросов не записывает запросы, выполняемые на этих репликах, так как они работают в режиме только для чтения, пока их не повысите до первичного уровня.