мониторинг производительности с помощью хранилища запросов;
Область применения:
гибкий сервер Базы данных Azure для PostgreSQL
Функция хранилище запросов гибкого сервера База данных Azure для PostgreSQL позволяет отслеживать производительность запросов с течением времени. Хранилище запросов упрощает устранение неполадок, позволяя быстро выявлять самые медленные и ресурсоемкие запросы. Хранилище запросов автоматически ведет журнал запросов и статистики выполнения и сохраняет их для просмотра. В журнале выполняется сортировка данных по времени, чтобы можно было видеть шаблоны использования во времени. Данные для всех пользователей, баз данных и запросов хранятся в базе данных с именем azure_sys в экземпляре гибкого сервера База данных Azure для PostgreSQL.
Внимание
Не изменяйте базу данных azure_sys или ее схему. Это приведет к нарушению работы хранилища запросов и связанных функций оценки производительности.
Включите хранилище запросов.
хранилище запросов доступна во всех регионах без дополнительных расходов. Это функция согласия, поэтому она не включена по умолчанию на сервере. Хранилище запросов можно включить или отключить глобально для всех баз данных на определенном сервере и не может быть включен или отключен для каждой базы данных.
Внимание
Не включите хранилище запросов на ценовую категорию с возможностью ускорения, так как это приведет к снижению производительности.
Включение хранилище запросов в портал 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 отдельных запросов на окно.
Для настройки параметров хранилище запросов доступны следующие параметры:
| Параметр | Description | По умолч. | Диапазон |
|---|---|---|---|
| pg_qs.query_capture_mode | Задает, какие инструкции отслеживаются. | ничего | none, top, all |
| pg_qs.interval_length_minutes (*) | Задает интервал записи query_store в минутах для pg_qs — это частота сохраняемости данных. | 15 | 1–30 |
| pg_qs.store_query_plans | Включает или отключает планы запросов для pg_qs. | off | on, off |
| pg_qs.max_plan_size | Задает максимальное число байтов для сохраняемого текста плана запроса для pg_qs; более длинные планы будут усечены. | 7500 | 100–10 000 |
| pg_qs.max_query_text_length | Задает максимальную длину запроса, которую можно сохранить; Более длинные запросы будут усечены. | 6000 | 100–10 000 |
| pg_qs.retention_period_in_days | Задает период хранения в днях для pg_qs — после этого данные будут удалены. | 7 | 1–30 |
| pg_qs.index_generation_interval (*) | Задает интервал автоматического создания индекса query_store в минутах для pg_qs. | 720 | 15 - 10080 |
| pg_qs.index_recommendations | Включает или отключает рекомендации по индексу. pg_qs.query_capture_mode также должно быть "TOP" или "ALL". | off | off, рекомендуется |
| pg_qs.track_utility | Задает, отслеживаются ли команды служебной программы pg_qs. | on | on, off |
(*) Параметр статического сервера, для которого требуется перезапуск сервера, чтобы изменить его значение, вступают в силу.
Следующие параметры применяются специально к статистике ожидания:
| Параметр | Description | По умолч. | Диапазон |
|---|---|---|---|
| pgms_wait_sampling.query_capture_mode | Выбирает, какие инструкции отслеживаются расширением pgms_wait_sampling. | ничего | none, all |
| Pgms_wait_sampling.history_period | Задает частоту (в миллисекундах), в которой выборка событий ожидания выполняется. | 100 | 1–600 000 |
Примечание.
pg_qs.query_capture_mode заменяет pgms_wait_sampling.query_capture_mode. Если параметр pg_qs.query_capture_mode имеет значение NONE, pgms_wait_sampling.query_capture_mode не оказывает влияния.
Используйте портал Azure, чтобы получить значение параметра или задать другое значение.
Представления и функции
Просмотр и управление хранилищем запросов осуществляеются с помощью следующих представлений и функций. Любой пользователь с общедоступной ролью 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).
| Имя | Тип | Ссылки | Description |
|---|---|---|---|
| runtime_stats_entry_id | bigint | Идентификатор из таблицы runtime_stats_entries. | |
| user_id. | oid | pg_authid.oid | Идентификатор пользователя, выполнившего инструкцию. |
| db_id | oid | pg_database.oid | OID базы данных, в которой была выполнена инструкция. |
| query_id | bigint | Внутренний хэш-код, вычисляемый из дерева синтаксического анализа инструкции. | |
| query_sql_text | varchar(10000) | Текст репрезентативной инструкции. Разные запросы с одной структурой объединяются в кластеры: этот текст — текст для первого запроса в кластере. Значение по умолчанию для максимальной длины текста запроса равно 6000 и может быть изменено с помощью параметра pg_qs.max_query_text_lengthхранилища запросов. Если текст запроса превышает это максимальное значение, он усечен до первых pg_qs.max_query_text_length символов. |
|
| plan_id | bigint | Идентификатор плана, соответствующего этому запросу. | |
| start_time | TIMESTAMP | Запросы агрегируются по периодам времени, интервал времени которого определяется параметром pg_qs.interval_length_minutes сервера (по умолчанию — 15 минут). Это время начала, соответствующее периоду времени для этой записи. |
|
| end_time | TIMESTAMP | Время окончания, соответствующее периоду времени для этой записи. | |
| вызывает | bigint | Количество раз, когда запрос выполняется в этом окне времени. Обратите внимание, что для параллельных запросов число вызовов для каждого выполнения соответствует 1 для внутреннего процесса, который управляет выполнением запроса, а также множество других единиц для каждого внутреннего рабочего процесса, запущенного для совместной работы при выполнении параллельных ветвей дерева выполнения. | |
| total_time | double precision | Общее время выполнения запроса в миллисекундах. | |
| min_time | double precision | Минимальное время выполнения запроса в миллисекундах. | |
| min_time | double precision | Максимальное время выполнения запроса в миллисекундах. | |
| mean_time | double precision | Среднее время выполнения запроса в миллисекундах. | |
| stddev_time | double precision | Стандартное отклонение времени выполнения запроса в миллисекундах. | |
| строк | bigint | Общее количество строк, полученных или затронутых инструкцией. Обратите внимание, что для параллельных запросов число строк для каждого выполнения соответствует количеству строк, возвращаемых клиенту серверным процессом, в результате выполнения запроса, а также суммы всех строк, запущенных для совместной работы для выполнения параллельных ветвей дерева выполнения, возвращается во внутренний серверный процесс. | |
| shared_blks_hit | bigint | Общее количество попаданий в общий кэш блоков инструкцией. | |
| shared_blks_read | bigint | Общее количество общих блоков, прочитанных инструкцией. | |
| shared_blks_dirtied | bigint | Общее количество общих блоков, грязных инструкцией. | |
| shared_blks_written | bigint | Общее количество общих блоков, написанных инструкцией. | |
| local_blks_hit | bigint | Общее количество попаданий в кэш локальных блоков инструкцией. | |
| local_blks_read | bigint | Общее количество локальных блоков, считываемых инструкцией. | |
| local_blks_dirtied | bigint | Общее количество локальных блоков, грязных инструкцией. | |
| local_blks_written | bigint | Общее количество локальных блоков, написанных инструкцией. | |
| temp_blks_read | bigint | Общее количество блоков temp, считываемых инструкцией. | |
| temp_blks_written | bigint | Общее количество блоков temp, написанных инструкцией. | |
| blk_read_time | double precision | Общее время, затраченное оператором на чтение блоков, в миллисекундах (если track_io_timing включен, в противном случае — ноль). | |
| blk_write_time | double precision | Общее время, затраченное оператором на запись блоков, в миллисекундах (если track_io_timing включен, в противном случае — ноль). | |
| is_system_query | boolean | Определяет, был ли запрос выполнен ролью с user_id = 10 (azuresu), который имеет права суперпользователя и используется для выполнения операций панели управления. Так как эта служба является управляемой службой PaaS, только корпорация Майкрософт является частью этой роли суперпользователя. | |
| query_type | text | Тип операции, представленной запросом. Возможные значения: unknown, select, insertdeletemergeupdate, utility, . undefinednothing |
query_store.query_texts_view
Это представление возвращает текстовые данные запроса в хранилище запросов. Для каждой отдельной query_sql_text существует одна строка.
| Имя | Тип | Description |
|---|---|---|
| query_text_id | bigint | Идентификатор для таблицы query_texts |
| query_sql_text | varchar(10000) | Текст репрезентативной инструкции. Разные запросы с одной структурой объединяются в кластеры: этот текст — текст для первого запроса в кластере. |
| query_type | smallint | Тип операции, представленной запросом. В версии PostgreSQL <= 14 возможные значения : 0 (неизвестно), 21 (select), (обновление), 3 (вставка), (удаление), 45 (служебная программа), 6 (ничего). В версии PostgreSQL >= 15 возможные значения : 0 (неизвестно), 21 (select), (update), 3 (insert), 4 (delete), (merge), 56 (utility), 7 (nothing). |
query_store.pgms_wait_sampling_view
Это представление возвращает данные событий ожидания в хранилище запросов. Это представление возвращает другую строку для каждой отдельной базы данных (db_id), пользователя (user_id), запроса (query_id) и события (события).
| Имя | Тип | Ссылки | Description |
|---|---|---|---|
| start_time | TIMESTAMP | Запросы агрегируются по периодам времени, интервал времени которого определяется параметром pg_qs.interval_length_minutes сервера (по умолчанию — 15 минут). Это время начала, соответствующее периоду времени для этой записи. |
|
| end_time | TIMESTAMP | Время окончания, соответствующее периоду времени для этой записи. | |
| user_id. | oid | pg_authid.oid | Идентификатор пользователя, выполнившего инструкцию. |
| db_id | oid | pg_database.oid | OID базы данных, в которой была выполнена инструкция. |
| query_id | bigint | Внутренний хэш-код, вычисляемый из дерева синтаксического анализа инструкции. | |
| event_type | text | Тип события, для которого ожидается серверная часть. | |
| события | text | Имя события ожидания, если серверная часть в настоящее время ожидает. | |
| вызывает | integer | Количество раз, когда было записано одно и то же событие. |
Примечание.
Список возможных значений в столбцах event_type и событий представления query_store.pgms_wait_выборки_представления см. в официальной документации по pg_stat_activity и поиск сведений, ссылающихся на столбцы с одинаковыми именами.
query_store.query_plans_view
Это представление возвращает план запроса, который использовался для выполнения запроса. Для каждой отдельной базы данных и идентификатора запроса существует одна строка. При этом будут храниться только планы запросов без использования.
| plan_id | db_id | query_id | plan_text |
|---|---|---|---|
| plan_id | bigint | Хэш-значение из нормализованного плана запроса, созданного ОБЪЯСНИМ. Считается нормализованным, поскольку он исключает предполагаемые затраты на узлы плана и использование буферов. | |
| db_id | oid | pg_database.oid | OID базы данных, в которой была выполнена инструкция. |
| query_id | bigint | Внутренний хэш-код, вычисляемый из дерева синтаксического анализа инструкции. | |
| plan_text | varchar(10000) | План выполнения инструкции с заданными затратами=false, buffers=false и format=text. Это те же выходные данные, которые даны в ОБЪЯСНН. |
Функции
query_store.qs_reset
Эта функция не карта все статистические данные, собранные до сих пор хранилище запросов. Он не карта и статистику для уже закрытых периодов времени, которые были сохранены в таблицах дисков, и те для текущего периода времени, которые по-прежнему хранятся в памяти. Эта функция может выполняться только ролью администратора сервера (azure_pg_admin).
query_store.staging_data_reset
Эта функция не карта все статистические данные, собранные в памяти хранилище запросов (т. е. данные в памяти, которые еще не были удалены на диски, поддерживающие сохраняемость собранных данных для хранилище запросов). Эта функция может выполняться только ролью администратора сервера (azure_pg_admin).
Режим только для чтения
Если База данных Azure для PostgreSQL — гибкий экземпляр сервера находится в режиме только для чтения, например если default_transaction_read_only для параметра задано onзначение , или если режим только для чтения включен из-за достижения емкости хранилища, хранилище запросов не записывает данные.