3.5. Исполнение запроса

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

Статистика исполнения представлена несколькими полями:

•calls — количество успешно исполненных запросов. По смыслу это поле близко к plans, однакообаполяявляютсянезависимыми,считаютсяотдельнодруготдругаимогутсодержать разные значения.Успешное планирование не гарантирует,что исполнение не завершится ошибкой. И наоборот, из успешного исполнения не следует, что перед ним выполнялось планирование: в случае подготовленных запросов (prepared statements) на этапе подготовки план выполнения может кешироваться;

•rows— общее количество строк, которое было возвращено (SELECT) или затронуто (INSERT, UPDATE,DELETE) в результате выполнения всех запросов данного типа;

•total_exec_time — общее время, затраченное на исполнение запросов данного типа. Это время включает в себя и время ожидания блокировок и событий;

•min_exec_time—наименьшая продолжительность исполнения;

•max_exec_time—наибольшая продолжительность исполнения;

•mean_exec_time—средняя продолжительность исполнения;

•stddev_exec_time—величина стандартного отклонения продолжительности исполнения;

•blk_read_time—общеевремя,затраченноеначтениеданныхиразмещениеихвбуферном кеше;

•blk_write_time—общее время,затраченное на запись данных.

Время планирования

Доверсииpg_stat_statements1.9поля,показывающиевремявыполнения,называлисьиначе и не содержали в своем имени слова exec. Переименование вызвано внедрением отслеживания планирования, из-за чего потребовалось добавить новые поля, а существующие переименовать.Например,поле total_time было переименовано в total_exec_time.

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

После включения и установки расширения сбор статистики осуществляется автоматически, за исключением статистики времени, затраченного на чтение и запись в буферный кеш (blk_read_time и blk_write_time). Для учета времени ввода-вывода необходимо включить параметр track_io_timing.Как и во всех остальных случаях,время выполнения считается в миллисекундах.

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

Запросыснаибольшимколичествомвызовов. Количествовызововможнополучитьвполеcalls

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

# SELECT sum(calls) AS total_calls FROM pg_stat_statements; total_calls

-------------

173438464

На выходе получилось довольно большое число.Напомню,что статистика pg_stat_statements накапливаетсявтечениеопределенногопериода,иполученноечисло—этоколичествовыпол- ненных запросов за все время накопления статистики. Значение производительности всегда определяется за какой-то период и выражается, например, в запросах в секунду или минуту. Для подсчета производительности достаточно простой арифметики,и в контексте PostgreSQL ееможновычислитьспомощью SQLифункции\watchклиентаpsql.Другойвариант—исполь- зовать функции,которые предлагает язык запросов системы мониторинга:

# sum(rate(postgres_statements_calls_total{service_id="primary"})[1m])

Функция rate считает частоту изменения величины postgres_statements_calls_total в указанном интервале (одна минута). Затем подсчитывается сумма для всех метрик (на каждый тип запроса—отдельная метрика).Результатом запроса будетграфик,показанный на рис. 3.2.

На графике изображена динамика изменения частоты выполнения запросов, в легенде внизу подсчитаныагрегатыдляинтервала.Так,например,средняячастотавыполнения—258запро- сов в секунду примерно за 12 часов.

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

Рис. 3.2.Текущая производительность

Средствами SQL аналогичный результат можно получить следующим запросом:

# SELECT

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

С помощью графиков можно увидеть эту картину в динамике,и для начала можем воспользоваться следующим запросом:

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

#topk_avg(5,

sum by (queryid,query) ( rate(postgres_statements_calls_total{service_id="primary"}[1m])

+ on(database,user,queryid) group_left(query)

0 * postgres_statements_query_info{service_id="primary"} ), "other")

На основе запроса получается следующий график (рис. 3.3):

Рис. 3.3.Наиболее вызываемые запросы

На этом графикетоже показанатекущая производительность,но уже с большейдетализацией. Здесьвиднытезапросы,которыезанимаютнаибольшуюдолюрабочейнагрузкиивыполняются чаще остальных. Остальные запросы также присутствуют на графике в виде объединенной метрики с меткой other. В случае количественного изменения рабочей нагрузки, например при изменении количества экземпляров приложений (или одновременно работающих пользователей), это изменение будет заметно: просадка на графике — это следствие выключения одного из приложений. Однако важно понимать, что большое количество выполненных запросов не означает большого потребления ресурсов, и далее мы рассмотрим примеры, как получить информацию и об использовании ресурсов, и о тех запросах, что занимают существенную долю в рабочей нагрузке.

Запросы с наибольшим количеством затронутых строк. Сортировка запросов по количеству за-

тронутых строк полезна при анализе OLTP-нагрузки. При таком виде нагрузки запросы обычно возвращают немного строк. Если запросы возвращают большое количество строк (тысячи и более), это может быть признаком ошибки в дизайне приложения: маловероятно, что клиенту,который выполнил запрос,нужны все эти тысячи строк.Возможно,в запросе не указано ключевое слово LIMIT,либо приложение обрабатывает строки своими силами,хотя это можно было сделать на стороне СУБД.Выявитьтакие запросы можно следующим образом:

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

При стабильной рабочей нагрузке без сильных колебаний этот график может выглядеть более или менее ровно, при этом практически любой аномальный запрос выделяется довольно хорошо. В данном примере это можно наблюдать по простому запросу, который был запущен в цикле с помощью команды \watch 1 в psql:

# SELECT aid, abalance, filler

FROM pgbench_accounts WHERE aid < 500;

Этот запрос возвращает примерно 490 строк в секунду, в то время как его ближайшие соседи — в среднем по 35 строк,и это хорошо заметно на графике.На практике так обычно выглядят запросы с забытым ключевым словом LIMIT. В запросе, например, может использоваться сортировка, и для выполнения условий запроса и последующей сортировки СУБД просканирует большое количество строк и, более того, отправит их клиенту, что вызовет избыточный расход ресурсов не только на стороне СУБД, но и на стороне приложения. Если это какой-то регулярно выполняемый запрос,а не разовая задача,то нужно проанализироватьзапрос и его соответствие техническому заданию. Если запрос написан именно так, как и задумано, стоит проверить бизнес-требования функции, для которой используется этот запрос, — насколько оправданно обращение к такому большому количеству строк (даже для разбиения на страницы есть способы читать ровно столько,сколько нужно).

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

Напомню, что поле total_exec_time хранит время в миллисекундах, и в этом запросе оно для удобствапреобразовановпривычныйформатпредставлениявремени.Такжедляучетаможно дополнительно включить и время планирования total_plan_time, получив суммарное время выполнения запроса,включая планирование.

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

кpg_stat_statements_info.stats_reset:

#SELECT now() - stats_reset FROM pg_stat_statements_info;

?column?

-------------------------

17 days 08:11:35.489621

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

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

#topk_avg(5,

sum by (queryid,query) ( rate(postgres_statements_time_seconds_total{

service_id="primary",mode="executing"

}[1m]) + on(database,user,queryid) group_left(query)

0 * postgres_statements_query_info{service_id="primary"} ), "other")

На основе запроса можно получить график,изображенный на рис. 3.5.

График показывает изменение времени выполнения (метка mode="executing") для отдельных запросов, и по нему видно, что бóльшую часть времени СУБД занята выполнением однотипныхзапросов.Навыполнениеостальныхтребуетсясущественноменьшевремени.Такжездесь следует обратить внимание на сильное колебание времени. Для интересующего нас запроса оно находится в диапазоне от 83 до 1900 миллисекунд, и это подозрительно. В более или менее стабильной рабочей нагрузке диапазон изменений времени выполнения должен быть существенно меньшим (стандартное отклонение всей выборки должно быть близко к нулю). Дело втом,что время выполнения включаетв себя и время ожидания,а из предыдущей главы мы знаем, что в тестовой рабочей нагрузке у нас довольно часто возникают ожидания блокировок. Из-за ожидания соседних транзакций время выполнения запросов сильно колеблется, что и отражается на графике.

Рис. 3.5.Запросы с наибольшим временем выполнения

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

Запросы с наибольшим временем ввода-вывода. Время, затраченное на блочный ввод-вывод,

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

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

ис некоторыми накладными расходами.

В pg_stat_statements есть несколько полей, которые отображают время, затраченное на блочный ввод-вывод:

•blk_read_time и blk_write_time учитывают время ввода-вывода, связанного со страницами в общем и локальных кешах;

•temp_blk_read_time и temp_blk_write_time учитывают время ввода-вывода, связанного со страницами во временных файлах.

Учет статистики ведется только при включенном параметре track_io_timing. По опыту, всегда рекомендуется его включать (однако накладные расходы могут быть на уровне 1%). За счет этой статистики появляется возможность выявить те запросы, которым регулярно требуется доступ к диску,и запланировать оптимизацию или увеличение ресурсов.

Можно вычислять как отдельные статистики по чтению и записи, так и одну общую. Обычно на практике используется второй вариант:

# SELECT to_char(

interval '1 millisecond' * sum(

blk_read_time + blk_write_time + temp_blk_read_time + temp_blk_write_time ), 'HH24:MI:SS.MS'

) AS io_time,

left(query, 64) AS query_trunc FROM pg_stat_statements

WHERE blk_read_time + blk_write_time + temp_blk_read_time + temp_blk_write_time > 0 GROUP BY query

ORDER BY sum(blk_read_time + blk_write_time + temp_blk_read_time + temp_blk_write_time) DESC

Бóльшую часть времени ввод-вывод выполняется на одном типе запросов.Это другой запрос, нетот,что встретился в предыдущей части и на выполнение котороготратилось больше всего времени. Рассматривая подобные запросы, нужно учитывать частоту их выполнения. Например, обращение к диску может быть приемлемо для запросов, которые выполняются редко

изатрагивают холодные (архивные) данные. К регулярно выполняющимся запросам, наподобие запроса, обнаруженного в тестовом окружении, такое постоянное обращение к диску может считаться накладным и увеличивать время выполнения запросов. Устранив обращения к диску или хотя бы уменьшив время обращения, можно ускорить выполнение запросов. В зависимости от характера обращений есть различные варианты: увеличить буферный кеш, так,чтобывсенеобходимыегорячиеданныеполностьюпомещалисьвнего;модернизировать системные ресурсы (увеличить память, использовать более производительный накопитель, виртуальную машину и т. п.). Самый лучший вариант, конечно же, провести анализ запроса

иоптимизацию.

В мониторинге запросы с наибольшим временем блочного ввода-вывода можно получитьследующим запросом:

#topk_avg(5,

sum by (queryid,query) ( rate(postgres_statements_time_seconds_total{

service_id="primary",mode=~"ioread|iowrite" }[1m]) + on(database,user,queryid) group_left(query)

0 * postgres_statements_query_info{service_id="primary"} ), "other")

Обратитевнимание,чтовзапроседляметкиmodeиспользуетсяперечислениезначенийioread и iowrite; при необходимости можно получить время только чтения или только записи.

Используя этот запрос,можно увидеть ввод-вывод в динамике (рис. 3.6):

Рис. 3.6.Запросы с наибольшим временем ввода-вывода

Картина на графике сходится с результатом SQL-запроса. Только одному запросу постоянно требуется время на ввод-вывод,и в среднем это 6,83 миллисекунды за одну секунду реального времени. Может показаться, что это не так уж и много, однако стоит помнить, что дешевые обращения к страничному кешу ОС также расцениваются как блочный ввод-вывод. Можно провести эксперимент: сбросить страничный кеш и посмотреть, как изменится время вводавывода,когда СУБД будет вынуждена действительно обращаться к диску.В ОС Linux сбросить кеш можно следующей командой, выполненной от пользователя root (не делайте этого в производственных окружениях,это негативно скажется на производительности):

# echo 3 > /proc/sys/vm/drop_caches

Через пару минут, когда данные попадут в мониторинг, можно увидеть, как выросло время ввода-вывода до 1,16 секунды в пике (рис. 3.7). По мере продолжения рабочей нагрузки и наполнения буферного и страничного кешей время ввода-вывода будет постепенно уменьшать- сяивкакой-томоментокончательнопридеткзначению,котороебылодосбросастраничного кеша.

Запросы с наибольшим временем выполнения без учета ввода-вывода. Учитывая возможность получить время, потраченное на блочный ввод-вывод, можно с помощью простой арифметики получить и время, условно потраченное процессором на выполнение запроса. Условно, потому что полученная статистика хоть и будет указывать на время выполнения, но все-таки она не будет являться точным отражением того, сколько времени процессор провел в активном состоянии,выполняя этоттип запроса.Другой важный момент: это время будетвключать в себя и время ожидания. Точную статистику по использованию процессора можно получить

Рис. 3.7.Время ввода-вывода после сброса страничного кеша

с помощью модуля pg_stat_kcache, использующего системный вызов getrusage. Однако это расширение не является официальным и устанавливается как отдельный пакет.

Итак, для получения статистики следует из общего времени total_exec_time вычесть время, потраченное на блочный ввод-вывод:

# SELECT to_char(

interval '1 millisecond' * sum(total_exec_time - (

blk_read_time + blk_write_time + temp_blk_read_time + temp_blk_write_time)), 'HH24:MI:SS') AS cpu_time,

left(query, 64) AS query_trunc FROM pg_stat_statements

GROUP BY query

ORDER BY sum(total_exec_time - (

blk_read_time + blk_write_time + temp_blk_read_time + temp_blk_write_time)

Здесь процессорное время практически совпадает с общим. Это значит, что СУБД тратит на блочный ввод-вывод относительно немного времени,всего около 1%:

При использовании SQL для оценки времени выполнения запроса всегда полезно выводить обе статистики вместе,чтобы видеть,на что именно тратится время.

# SELECT to_char(

interval '1 millisecond' * sum(total_exec_time), 'HH24:MI:SS'

) AS exec_time, (100 * sum(

blk_read_time + blk_write_time + temp_blk_read_time + temp_blk_write_time

) / sum(total_exec_time))::numeric(5,2)::text || ' / ' || (100 * sum(total_exec_time - (

blk_read_time + blk_write_time + temp_blk_read_time + temp_blk_write_time)

) / sum(total_exec_time))::numeric(5,2) AS "io / cpu, %", left(query, 48) AS query_trunc

FROM pg_stat_statements

GROUP BY query ORDER BY sum(total_exec_time) DESC LIMIT 10;

Здесь сразу видно отношение времени,затраченного на ввод-вывод и CPU относительно друг друга, и запрос, в котором на ввод-вывод тратится примерно треть от общего времени выполнения, довольно хорошо бросается в глаза. Если этому типу запроса дать возможность находить нужные данные в буферном кеше, то из четырех часов суммарного выполнения высвободится примерно 80 минут. Это время можно потратить на выполнение других запросов и увеличить производительность.