С момента первой же хабрапубликации о возможностях нашего сервиса визуализации планов запросов PostgreSQL explain.tensor.ru (а было это уже больше 2 лет назад) пользователи задавали резонный вопрос: "Все у вас круто, но у нас в запросах и планах есть коммерческая инфа, которую отправлять куда-то наружу низзя... Можно как-то ваш сервис развернуть на своей площадке?"

Ну, а почему бы и нет, подумали мы - тем более, некоторые пользователи уже интересовались возможностью интеграции нашего сервиса в свои системы.

"Я джва года ждал"
"Я джва года ждал"

Зеркало на Amazon

И начать этот путь мы решили с подготовки сборки для AWS и разворота там зеркала сервиса (explain-postgresql.com), чем помогли некоторым пользователям оперативно обойти обратные блокировки (когда с рабочего места в "забугорье" закрыт доступ к части RU-ресурсов) после начала известных событий.

Self-hosted версия

Ну а теперь мы сделали и выложили полноценные сборки для установки на RHEL/Debian, Docker Linux/Win/MacOS, k8s и AWS - можно свободно попробовать для тестов, отладки и личного использования, а вот корпоративные инсталляции, поддержка и расширенные возможности - на отдельных условиях.

Визуальные улучшения

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

Навигатор

Мгновенно визуально оцениваем с помощью полоски-навигатора, сколько времени занял каждый узел. Клик - и мы стоим на нужном узле:

Навигатор по плану
Навигатор по плану

Если доминируют красные сегменты - вы тратите много времени на чтение данных (Seq Scan, Index Scan, Bitmap Heap Scan, ...), если желтые - на их обработку (Aggregate, Unique, ...), а зеленых Join должно быть не слишком много.

Average IO

Если в вашем плане присутствуют показатели времени, затраченного на операции ввода-вывода (атрибут I/O Timings при включенном параметре track_io_timing), то теперь в строке итогов можно мгновенно оценить усредненные показатели скорости доступа к диску при последовательном и случайном чтении или записи.

Average IO
Average IO

Если вы видите тут цифры в единицы MB/s, хотя база находится на SSD, то где-то в работе дисковой подсистемы явно есть проблема.

Дерево rows/RRbF

На tilemap-диаграмме плана появился новый режим rows - в нем вы можете мгновенно оценить, в каком сегменте плана генерируется или фильтруется чересчур много записей.

В этом режиме подсвечиваются те узлы, на которых было отброшено из-за несоответствия условию (Rows Removed by ...) наибольшее количество записей, а "ширина" связи пропорциональна количеству записей, которые были переданы вверх по дереву.

Чем ярче узел и толще его "ветви", тем более пристально стоит к нему присмотреться:

Дерево rows
Дерево rows

Тултип узла

Наводя курсор на узел в навигаторе или любой другой диаграмме, вы сразу видите все иконки рекомендаций, которые советует наш сервис:

Если это подсказка об индексе, то простого клика по ней достаточно, чтобы перейти к предлагаемым вариантам подходящих индексов.

Также для всех больших чисел в тексте узла добавлены разделители разрядов, чтобы сходу воспринимать порядок величин.

Комментарии (9)


  1. edo1h
    20.07.2022 16:11

    теперь в строке итогов можно мгновенно оценить усредненные показатели скорости доступа к диску при последовательном и случайном чтении или записи.
    Если вы видите тут цифры в единицы MB/s, хотя база находится на SSD, то где-то в работе дисковой подсистемы явно есть проблема.

    не удобнее ли было бы для случайного чтения указывать iops?


    1. Kilor Автор
      20.07.2022 16:13
      +1

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


      1. edo1h
        21.07.2022 12:18

        То есть мы не знаем, сколько операций требуется конкретному хранилищу для вычитки одной страницы

        не понял
        вы про то, что данные могут быть «размазаны» с помощью какого-нибудь raid 5 и чтение одной страницы может идти с нескольких физических накопителей? ну так iops обычно считаются на уровне верхнего блочного устройства, так что это нам неинтересно


        несколько физически последовательных страниц за одну операцию получить

        опять же не страшно. если мы запустим fio с rw=read вместо rw=randread мы тоже получим много iops, никто же этим не возмущается.
        то, что последовательное чтение оптимизируется, никак не отменяет того факта, что дисковая подсистема выдала нам столько-то страниц в секунду.


        1. Kilor Автор
          21.07.2022 13:36

          Так речь про страниц/сек или операций/сек? Первую величину можно посчитать, но она "нечеловеческая", на нее никак не опереться.

          Если я скажу, что Seq Scan шел со скоростью 1MB/s - сразу понятно, что это жуть как плохо, а если 128 страниц/сек - то непонятно.


          1. edo1h
            21.07.2022 13:54

            seqscan понятно, что в мегабайтах в секунду считать удобнее. а вот random мне бы было удобнее видеть в страницах в секунду, это можно в первом приближении принять за iops


            1. Kilor Автор
              21.07.2022 13:56

              А к чему эту величину привязывать, как оценивать?


              1. edo1h
                21.07.2022 14:24

                типичное время доступа у ssd — 60-100 мкс, то есть 10-15к iops при qd=1.
                на вашем скриншоте 8 мегабайт в секунду, это примерно 1000 iops, то есть или дисковая не очень хорошая, или узкое место не в обращении к диску


                1. Kilor Автор
                  21.07.2022 14:46

                  8 мегабайт в секунду, это примерно 1000 iops

                  Обычно первого значения уже достаточно, чтобы понять хорошо/плохо, даже не обладая, знанием о спеках СХД. А переводить его в iops - зачем?


                  1. edo1h
                    21.07.2022 22:39

                    честно говоря, не представляю, как можно не переводя в iops понять 8 мегабайт в секунду — это много или мало для случайного доступа.