Глава 3

Выполнение запросов и функций

Вэтой главе мы рассмотрим:

•зачем нужен мониторинг запросов;

•расширение pg_stat_statements;

•метаданные запроса;

•статистику планирования и исполнения запросов;

•практические примеры использования pg_stat_statements;

•сквозную идентификацию запросов по всем источникам статистики;

•примеры отчетов на основе pg_stat_statements;

•представление pg_stat_statements_info;

•представление pg_stat_user_functions.

Впредыдущей главе мы рассмотрели клиентские процессы и сеансы, связанную с ними статистикуипримерыееиспользованиядлязадачмониторинга.Далее,вэтойглаве,мызаглянем внутрьклиентскихсеансовирассмотримспособыанализарабочейнагрузки.Запросы,отправляемыеклиентом,определяютрабочуюнагрузку;ееэффективноевыполнениесерверомСУБД определяет общую производительность системы. Статистика СУБД дает администратору возможность рассматривать нагрузку с разных точек зрения и разбирать общий поток рабочей нагрузки на отдельные запросы. Рассматривая запросы по отдельности, мы можем наметить отправные точки их оптимизации, что в итоге положительно скажется на общей производительности СУБД.

3.1. Зачем нужен мониторинг запросов

После установки соединения и настройки сеанса СУБД готова выполнять команды клиента. Посредством команд клиент может запрашивать и изменять данные (DML-команды), управлять объектами схемы (DDL-команды),выполнять служебные операции и т. п.Полный список команд можно найти в официальной документации1. Базовой единицей выполнения в рабочей нагрузке можно считать запросы (queries) — это, как правило, команды на извлечение и изменение данных: SELECT,INSERT,UPDATE,DELETE.

1 postgrespro.ru/docs/postgresql/current/sql-commands.html

Команда,оператор,запрос?

Помимо термина запрос, в документации можно встретить термин оператор (statement). Это понятие имеет более широкий смысл: «оператор» охватывает весь диапазон существующих команд, в то время как «запрос» — это подмножество команд, которые возвращают результат или изменяют данные. Далее в этой главе вместо слов «команда» и «оператор» я буду использовать более привычный термин «запрос».

Запросы, их количество и типы, а также участвующие в них объекты БД формируют индивидуальный для каждой СУБД профиль рабочей нагрузки, для выполнения которой требуются ресурсы. Оптимизируя отдельные типы запросов, можно в конечном счете оптимизировать использование ресурсов самой СУБД и добиться существенного увеличения производительности (или сокращения избыточно выделенных ресурсов, которые ранее были необходимы).

Часто на практике приходится быть свидетелем попыток решить проблемы производительности поиском магического параметра в настройках, включение которого ускорит все и сразу. К сожалению,«ускорения»,вызванныетакими параметрами,жертвуютстабильностью или надежностью системы,так что нужно заранее хорошо оценивать риски.Болеетого,таким способом нельзядобиться качественного улучшения производительности итого вау-эффекта (ускорения на порядки), которого можно достичь только с помощью оптимизации запросов. Наиболее правильный путь—это рефакторинг запроса или в простом случае добавление индекса под конкретный тип запроса. Поэтому понимание того, какие запросы выполняются в системе,является ключевым пунктом для будущей оптимизации производительности.

Для оценки профиля рабочей нагрузки и выполняемых запросов используется несколько представлений:

•pg_stat_statements — представление с кумулятивной статистикой по запросам, предоставляемое одноименным расширением;

•pg_stat_user_functions — представление со статистикой выполнения пользовательских функций.

Помимо этих стандартных средств, есть и другие инструменты, которые разрабатываются со-

обществом на основе pg_stat_statements:

•pg_stat_kcache1 — расширение собирает статистику о фактическом использовании системных ресурсов отдельными запросами клиентских процессов. Для учета статистики используется системный вызов getrusage2, и это может накладывать некоторые ограничения на платформы,отличные от Linux;

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

1 github.com/powa-team/pg_stat_kcache

2 man7.org/linux/man-pages/man2/getrusage.2.html

3 github.com/percona/pg_stat_monitor

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

3.2. Расширение pg_stat_statements

Представление pg_stat_statements является одним из основных источников статистики по всем запросам, которые выполняются в СУБД. Представление служит интерфейсом к одноименному расширению, которое отслеживает стадии выполнения запросов и хранит накопленную статистику. Расширение сохраняет статистику по всем успешно выполненным запросам. В случаях, когда запрос завершился ошибкой (или был прерван администратором), статистика о нем не будет сохранена, что, пожалуй, можно считать некоторым недостатком при учете ресурсов.

По умолчанию расширение pg_stat_statements выключено, однако рекомендуется всегда его включать.Сделать это можно следующим образом:

1.Указать расширение в параметре shared_preload_libraries,после чего перезапустить сервер. Это необходимо для резервирования места в общей памяти, инициализация которой выполняется только при старте; получить место в уже выделенной общей памяти на лету во время работы СУБД невозможно.

2.После перезапуска СУБД расширение нужно установить в конкретной базе. Для этого подходит любая база: можно использовать базу данных postgres, которая всегда создается по умолчанию. Несмотря на то что расширение устанавливается в конкретную базу, сбор статистики осуществляется глобально для всех запросов независимо от того, в каких базах они работают. Установка выполняется с помощью команды CREATE EXTENSION pg_stat_statements;.

Втестовом окружении расширение pg_stat_statements уже установлено и настроено, поэтому дополнительного ничего делать не нужно. После установки расширения сбор статистики начинается автоматически. Убедиться в этом можно простым запросом к pg_stat_statements с подсчетом количества строк в представлении:

# SELECT count(*) FROM pg_stat_statements; count

-------

113

Наданный моментуже накоплена статистика по 113 типам запросов.Запросы,даже оченьпохожиедругнадруга,могутотличаться значениями параметров.Хранитьв статистике запросы со всеми значениями параметров избыточно—запросы могутсодержатьсотни итысячи параметров и уникальных значений. Поэтому в процессе сбора для каждого запроса выполняется

74Глава 3. Выполнение запросов и функций

нормализация—конкретныепараметрызаменяютсяпронумерованнымизаполнителямивида $1,$2,$3ит.д.Нормализация позволяетотнести запрос к некоторомутипу и учитыватьобъем использованных ресурсов для этого типа.

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

Помимо обязательного указания в shared_preload_libraries, расширение имеет несколько параметров конфигурации, которые позволяют подстраивать работу расширения под различные условия эксплуатации СУБД:

•pg_stat_statements.max — максимальное количество типов запросов, отслеживаемых расширением, что соответствует количеству строк в представлении. При регистрации большогоколичествазапросоврежеобновляемаячастьстатистикиможетбытьудалена.Факты удаления можно отследить с помощью pg_stat_statements_info.dealloc. Значение параметра устанавливается только при старте сервера. На практике значения по умолчанию (5000) обычно достаточно, но на производственных серверах с большим разнообразием запросов его имеет смысл сразу увеличивать как минимум вдвое,чтобы избежать перезапуска СУБД в будущем.

•pg_stat_statements.track —уровень отслеживаемых запросов.Возможные значения:

—top—отслеживатьвызовыверхнегоуровня,тоестьзапрошенныеклиентом.Включено по умолчанию;

—all—отслеживать все вызовы,включая вложенные в функции и процедуры;

—none—отключить сбор и хранение статистики.

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

•pg_stat_statements.track_utility — отслеживать ли статистику для служебных команд, отличных от DML-запросов вроде SELECT, INSERT, UPDATE и DELETE. Если на основе представленияpg_stat_statementsстроятсяотчетыпроизводительности,включениеэтогопараметра позволитполучитьболееполнуюиточнуюкартинуорабочейнагрузке.Новажнопомнить, что отслеживаемые служебные команды также будут занимать место в памяти и может возникнуть риск удаления статистики из-за достижения pg_stat_statements.max.

•pg_stat_statements.track_planning — собирать ли статистику о планировании запросов. Поумолчаниюсборвыключен,таккакможетприводитькснижениюпроизводительности, особенновслучае,когдазапросысодинаковойструктуройвыполняютсямножествомклиентов (что характерно для OLTP-нагрузки), поскольку это вызывает конкуренцию за обновление одних и тех же элементов статистики.

•pg_stat_statements.save — сохранять ли статистику при перезапусках или выключении сервера.По умолчанию включено,и обычно эту настройку можно оставить без изменений.