5.4. Диагностика распределённых запросов
Shardman расширяет возможности команды EXPLAIN, предоставляя дополнительную информацию по запросу, если он распределённый. Работа с распределёнными таблицами построена на узлах плана с типом ForeignScan. Запрос к каждой удалённой секции определяется одним узлом плана такого типа. При этом Shardman предоставляет дополнительную информацию в блоки EXPLAIN, описывающие эти узлы.
При выполнении распределённого запроса часть плана (поддерево), которая касается конкретной удалённой секции, сериализуется в SQL-выражение (происходит deparsing). После этого такое выражение отправляется на удалённый сервер. Результат выполнения этого запроса виден в выводе для узла ForeignScan. Он участвует в сборке окончательного результата выполнения распределённого запроса.
Когда задано значение on для параметра VERBOSE команды EXPLAIN, в блоке узла ForeignScan в поле Remote SQL будет показано выражение, отправляемое на удалённый сервер. При этом в поле Server будет указано имя сервера в том же виде, в каком оно задано при конфигурировании кластера и как оно отображается в каталоге pg_foreign_server, а также вид транспорта, применяющегося для отправки этого выражения. Поле transport может принимать два значения: silk для использования оптимизированного транспортного механизма Shardman или libpq для отправки через стандартный протокол PostgreSQL.
5.4.1. Показ планов с удалённого сервера
Чтобы увидеть под блоком EXPLAIN узла ForeignScan, какой план выполнения будет реализован на удалённом сервере, используется параметр конфигурации postgres_fdw.foreign_explain. Возможные значения: none не включает вывод EXPLAIN с удалённых серверов, full включает вывод EXPLAIN с удалённых серверов для всех узлов ForeignScan, collapsed включает вывод EXPLAIN только для первого узла ForeignScan под узлами Append/MergeAppend.
В производственной системе рекомендуется выключать этот параметр (задать значение none) или оставлять его со значением collapsed, так как получение любого фрагмента EXPLAIN является дополнительным неявным запросом к серверу. Кроме того, этот запрос выполняется в синхронном режиме, то есть общий вывод EXPLAIN будет построен после последовательного опроса всех серверов. Для таблиц с большим количеством секций это может быть затратной операцией.
Необходимо учитывать, что внутренний запрос на получение блоков EXPLAIN для удалённого плана осуществляется с принудительным отключением некоторых параметров (вне зависимости от того, какие параметры указал пользователь при запросе EXPLAIN от координатора): ANALYZE OFF, TIMING OFF, SUMMARY OFF, SETTINGS OFF, NETWORK OFF. Соответствующие метрики в блоках EXPLAIN удалённого плана будут отсутствовать. Остальные параметры EXPLAIN (FORMAT, VERBOSE, COSTS, BUFFERS, WAL) наследуются с координатора.
Если в результате сериализация подплана выполнения в SQL формируется выражение, включающее в себя параметры (аргументы, представленные в выражении при помощи символов $1, $2), такое выражение в целом нельзя отправить на удалённый сервер для получения результата EXPLAIN. Поэтому для SQL-выражений с параметрами построение блоков ForeignExplain не осуществляется.
5.4.2. Сетевые метрики и время ожидания
При включённом параметре NETWORK команды EXPLAIN как для отдельных узлов плана ForeignScan, так и для общих узлов Append или MergeAppend отображаются метрики сетевых операций.
Для каждого узла плана отображаются параметры FDW bytes, sent и received для исходящего и входящего трафика, потраченного при выполнении этого узла (вне зависимости от вида транспорта). Необходимо учитывать, что эти метрики выводятся, только если задано значение on параметра ANALYZE команды EXPLAIN.
При включённом параметре конфигурации track_fdw_wait_timing дополнительно выводится метрика wait_time. Она обобщает все этапы выполнения данного узла плана, начиная от отправки запроса на удалённый сервер, включая время, потраченное собственно на выполнение запроса, а также время до получения полного объёма результатов для этого узла плана.
Необходимо учитывать, что узел ForeignScan может выполняться как в синхронном, так и в асинхронном режиме. В случае асинхронного выполнения функция выполнения узла отправляет запрос на удалённый сервер и завершает выполнение, не дожидаясь получения результата, который будет учтён и обработан позже, по факту получения. В этом случае метрика wait_time может не отражать реальное время выполнения.
5.4.3. Трассировка прохождения запроса для транспорта Silk
Для транспорта Silk существует возможность вывести расширенную отладочную информацию по трассировке прохождения запроса от координатора на удалённый сервер, включающую получение результатов с удалённого сервера. Эта информация отображается, если задано значение on для параметра ANALYZE команды EXPLAIN и включён параметр конфигурации shardman.silk_tracepoints.
При включении этого режима каждое сообщение, передаваемое через транспорт Silk (отправка SQL-запроса, доставка его адресату, выполнение там этого запроса и передача результата выполнения обратно), сопровождается массивом отметок времени, измеренного в некоторых точках конвейера. После выполнения такого запроса эта информация будет показана в блоке EXPLAIN в виде строк, начинающихся со слова Trace. Каждая такая метрика является разницей между отметками времени в разных точках и выводится в миллисекундах:
Таблица 5.1. Метрики трассировки прохождения запроса для транспорта Silk
| Интервал | Описание |
|---|---|
| bk shm->mp1 (qry) | Время передачи SQL-запроса от координатора к его мультиплексору через общую память. |
| mp1 shm->net (qry) | Время между приёмом запроса внутри мультиплексора из общей памяти и передачей по сети. |
| net (qry) | Время прохождения SQL-запроса по сети между мультиплексорами. |
| mp2 recv->shm (qry) | Время между приёмом SQL-запроса из сети и передачей в очередь в общей памяти на удалённом мультиплексоре. |
| wk exec (1st tup) | Время выполнения запроса на Silkworm до получения первой строки результата. |
| wk exec (all tups) | Время выполнения запроса на Silkworm до получения полного результата. |
| wk->shm (1st tup) | Время передачи в очередь Silkworm первой строки результата. |
| wk->shm (last tup) | Время передачи в очередь Silkworm последней строки результата. |
| mp2 shm->net (1st tup) | Время между чтением из очереди удалённым мультиплексором первой строки результата и передачей её в сеть. |
| net (1st tup) | Время передачи по сети первой строки результата между мультиплексорами. |
| mp1 recv->shm (1st tup) | Время между приемом из сети и передачей в очередь первой строки результата локальным мультиплексором. |
| mp1 shm->bk (1st tup) | Время получения координатором из очереди первой строки результата. |
| mp2 shm->net (last tup) | Время между чтением из очереди удалённым мультиплексором последней строки результата и передачей её в сеть. |
| net (last tup) | Время передачи по сети между мультиплексорами последней строки результата. |
| mp1 recv->shm (last tup) | Время между приёмом из сети и передачей в очередь последней строки результата локальным мультиплексором. |
| mp1 shm->bk (last tup) | Время получения координатором из очереди последней строки результата. |
| END-TO-END | Общее время от отправки запроса до получения последней строки результата. Примерно совпадает с wait_time. |
Для метрик net (qry), net (1st tup) и net (last tup) значение интервала считается как разница отметок времени, измеренных на разных серверах. Поэтому в этих строках допускается появление отрицательных значений. Величина такого интервала по сути представляет собой сумму времени передачи сообщения по сети и величины (положительной или отрицательной) сдвига часов между серверами. Поэтому даже при незначительном сдвиге, если его абсолютное значение превышает длительность передачи по сети, будут встречаться отрицательные значения. Несмотря на то, что это не является сбоем, при достаточно больших значениях необходимо удостовериться в правильной синхронизации времени в кластере. Более подробно информация описана в Раздел 5.3.