--- metadata: - name: generator content: Diplodoc Platform v5.62.0 alternate: - https://ydb.tech/docs/ru/dev/optimization/metrics.md - href: https://ydb.tech/docs/ru/dev/optimization/metrics.md type: text/markdown title: Markdown version - href: https://ydb.tech/docs/ru/llms.txt rel: describedby sourcePath: ru/core/dev/optimization/metrics.md --- > **Documentation Index:** Fetch the complete configuration index at https://ydb.tech/docs/ru/llms.txt # Визуализация метрик запроса YDB — распределённая СУБД для больших объёмов данных. [Кластер](https://ydb.tech/docs/ru/concepts/glossary.md#cluster) может включать много [узлов](https://ydb.tech/docs/ru/concepts/glossary.md#node); структура запроса тогда состоит из сотен и тысяч [задач](https://ydb.tech/docs/ru/concepts/glossary.md#task), каждая со своими метриками. Показать все значения по отдельности и по ним же делать выводы нереалистично, поэтому метрики [задач](https://ydb.tech/docs/ru/concepts/glossary.md#task) **агрегируются по [стадии](https://ydb.tech/docs/ru/concepts/glossary.md#processing-stage)**, попадают в ответ сервиса и на диаграмму уже в агрегированном виде. На SVG-плане они показаны в колонках `Tasks`, `Statistics` и `Timeline` — см. [Расположение информации в плане запроса](https://ydb.tech/docs/ru/dev/optimization/layout.md). Ниже — как устроены агрегирование и визуализация и как по ним быстро оценить план и узкие места. ## Общий вид визуализации {#overview} Графический план объединяет [структуру запроса](https://ydb.tech/docs/ru/dev/optimization/structure.md) слева и агрегированные метрики справа: ![План выполнения запроса](../../_assets/rts-count-lineitem.svg){inline=false} Колонки диаграммы описаны в [Расположении информации в плане запроса](https://ydb.tech/docs/ru/dev/optimization/layout.md). ## Параллельность {#parallelism} Число параллельно выполняющихся [задач](https://ydb.tech/docs/ru/concepts/glossary.md#task) показано в колонке `Tasks`. Для [стадий](https://ydb.tech/docs/ru/concepts/glossary.md#processing-stage) чтения из хранилища оно совпадает с числом [шардов](https://ydb.tech/docs/ru/concepts/glossary.md#data-shard). Слева в той же колонке полосатый фон («зебра») отражает долю уже завершившихся [задач](https://ydb.tech/docs/ru/concepts/glossary.md#task). На финальном графике завершённого запроса полоса занимает всю высоту строки стадии; для снимка «в процессе» картина иная. Точные числа — во всплывающей подсказке при наведении на область. ![Параллельность](../../_assets/rts-structure-1.svg){inline=false} {% note info %} Цвет фона колонки `Tasks` зависит от интенсивности использования CPU и от простоев [задач](https://ydb.tech/docs/ru/concepts/glossary.md#task) в стадии; см. [следующий раздел](#aggregates). {% endnote %} ## Агрегаты {#aggregates} Для метрик в статистике вычисляются и передаются в ответ те же агрегаты, что и в SQL: - `MIN` — минимум; - `MAX` — максимум; - `COUNT` — число значений; - `SUM` — сумма; - `AVG` — среднее (из `COUNT` и `SUM`). Если `COUNT` меньше числа [задач](https://ydb.tech/docs/ru/concepts/glossary.md#task) стадии (часть [задач](https://ydb.tech/docs/ru/concepts/glossary.md#task) не отдала метрику), это помечается как аномалия: рядом с метрикой появляется красный круг с числом `COUNT`. Подробности — во всплывающей подсказке. Если `COUNT` совпадает с числом [задач](https://ydb.tech/docs/ru/concepts/glossary.md#task) (типичный случай), отдельный индикатор не рисуется. По умолчанию показывается `SUM`; при наведении — развёрнуто: `SUM, MIN | AVG | MAX`. Если метрику сообщила одна [задача](https://ydb.tech/docs/ru/concepts/glossary.md#task), `MIN`, `AVG` и `MAX` скрыты, остаётся `SUM` (она совпадает с единственным значением). Дополнительные правила отображения: - для целочисленных счётчиков (число строк) используются суффиксы `K`, `M` — множители 10³, 10⁶ и т.д.; - для объёма (данные, память) — `KB`, `MB` и т.д. по степеням двойки: 2¹⁰, 2²⁰ …; - длительности — в удобочитаемом виде часы / минуты / секунды. ## Масштаб метрик {#scale} В колонке `Statistics` для каждой стадии сверху вниз выводятся метрики: - `Egress` (тёмно-синий) — вывод данных через границу подсистемы (из хранилища в вычисление и обратно); - `Output` (синий) — передача в следующую вычислительную стадию или в результат; - `Memory` (тёмно-песочно-красный) — память; - `CPU` (песочно-красный) — процессорное время; - `Input` (зелёный) — ввод из другой вычислительной стадии; - `Ingress` (тёмно-зелёный) — ввод через границу подсистемы. Не у каждой стадии есть все шесть строк. У вычислительных стадий обязательны `Memory` и `CPU`. Из пары `Egress` / `Ingress` указывается одна соответствующая. Несколько входов `Input` перечисляются отдельно. Если выходов `Output` несколько, на основной строке стадии показывается один из них, остальные — у связанных «клонов», см. [Множественные выходы](https://ydb.tech/docs/ru/dev/optimization/structure.md#multiout). Помимо числа, каждая метрика сопровождается цветной полосой. Для одного и того же типа метрики значения по стадиям **нормируются между собой**: у стадии с максимальным `SUM` полоса на всю ширину колонки `Statistics`, у остальных — пропорционально этому максимуму. Так проще сравнить, на какой стадии больше всего трафика, CPU, памяти и т.п. {% note info %} Масштабы **разных** типов метрик не сопоставимы: ширина полосы `Output` не означает то же самое, что ширина полосы `Input` — каждый тип масштабируется отдельно. Часто максимумы на выходе одной стадии и на входе другой близки, поэтому полосы выглядят согласованно. Однако это не всегда так. {% endnote %} ## Перекос данных {#dataskew} При параллельной обработке важно, чтобы [задачи](https://ydb.tech/docs/ru/concepts/glossary.md#task) одной стадии стартовали и завершались почти синхронно. Длительность стадии задаётся **самой медленной** [задачей](https://ydb.tech/docs/ru/concepts/glossary.md#task): пока она не закончилась, стадия не считается завершённой. Помимо `SUM` (она задаёт длину цветной полосы), по остальным агрегатам строится ломаная линия; участок полосы **выше** линии рисуется более светлым: - `MAX` задаёт общий масштаб; ломаная начинается в левом верхнем углу полосы; - `MIN` задаёт высоту ломаной на правом краю: отношение к `MAX` такое же, как `MIN/MAX` (например, при `MIN` вдвое меньше `MAX` конец ломаной — середина правой границы); - `AVG` задаёт промежуточную точку между `MIN` и `MAX` по горизонтали и вертикали. ![Перекос данных](../../_assets/rts-metrics-0.svg){inline=false} ```text Hmax = H Hmin = MIN * H / MAX Havg = AVG * H / MAX Wavg = (AVG – MIN) * W / (MAX – MIN) ``` Четыре типичных случая: 1. `MIN == AVG == MAX`: ломаная совпадает с верхним краем полосы, светлой зоны нет. Нагрузка по [задачам](https://ydb.tech/docs/ru/concepts/glossary.md#task) равномерна (данные, время или память — в зависимости от метрики). ![Идеальное распределение](../../_assets/rts-metrics-1.svg){inline=false} ```text MAX = 100 AVG = 100 MIN = 100 ``` 2. `MIN < MAX`, но разброс небольшой: светлая область — узкий сегмент у правого верхнего угла. Роль `AVG` для визуальной оценки вторична. ![Небольшой разброс](../../_assets/rts-metrics-2.svg){inline=false} ```text MAX = 100 AVG = 90 MIN = 80 ``` 3. `MIN` существенно меньше `MAX`: важно положение `AVG`. Если оно близко к `MAX`, большинство [задач](https://ydb.tech/docs/ru/concepts/glossary.md#task) загружены примерно одинаково, «лёгкие» [задачи](https://ydb.tech/docs/ru/concepts/glossary.md#task) мало влияют на время стадии — перекос обычно некритичен. ![Некритичный разброс](../../_assets/rts-metrics-3.svg){inline=false} ```text MAX = 100 AVG = 90 MIN = 20 ``` 4. `MIN` сильно меньше `MAX`, а `AVG` близко к `MIN`: мало сильно перегруженных [задач](https://ydb.tech/docs/ru/concepts/glossary.md#task) при большом числе простаивающих. Снижение перекоса (перераспределение работы) может заметно укоротить стадию. ![Критичный разброс](../../_assets/rts-metrics-4.svg){inline=false} ```text MAX = 100 AVG = 30 MIN = 20 ``` Практическое правило: **чем больше площадь светлой части полосы, тем сильнее неравномерность и тем внимательнее стоит смотреть на эту метрику.** Сильный [перекос данных](#dataskew) дополнительно помечается красным кругом с буквой `S` (data skew). {% note info %} Число `SUM` рисуется поверх полосы и частично её перекрывает. Так сделано намеренно: либо полоса мала и стадия всё равно «тяжёлая», либо закрывается правый участок, менее важный для быстрой оценки; слева остаётся область с ломаной и светлым сегментом. {% endnote %} ## Перекос времени {#timeskew} Неравномерность бывает и **по времени**: одинаковый объём данных и схожее CPU/память, но разная длительность [задач](https://ydb.tech/docs/ru/concepts/glossary.md#task) ([узел](https://ydb.tech/docs/ru/concepts/glossary.md#node) перегружен, вытеснение планировщиком и т.д.). Такой сценарий на метриках из [предыдущего раздела](#dataskew) не всегда виден. Оценка по времени — по правой колонке с временной шкалой: когда стадия стартовала и завершилась, как шли [задачи](https://ydb.tech/docs/ru/concepts/glossary.md#task). Чистый перекос по времени без перекоса по данным редок; чаще проявляются оба эффекта, поэтому логично начинать с данных. Временная шкала читается проще, чем геометрия перекоса по данным. Для каждого [канала](https://ydb.tech/docs/ru/concepts/glossary.md#channels) [задачи](https://ydb.tech/docs/ru/concepts/glossary.md#task) отдают `FirstMessage` (`F`) и `LastMessage` (`L`) — моменты обработки первого и последнего сообщения. `Fmin` — начало активности всех [задач](https://ydb.tech/docs/ru/concepts/glossary.md#task) стадии, `Lmax` — конец. Дополнительно рисуются две жёлтые «зебры»: от `Fmin` до `Fmax` вдоль верхнего края прямоугольника и от `Lmin` до `Lmax` вдоль нижнего. В точках `Favg` и `Lavg` — вертикальные штрихи до середины по высоте. ![Перекос во времени](../../_assets/rts-metrics-5.svg){inline=false} Особый случай: обе «зебры» на всю ширину, вертикальные штрихи совпадают (не обязательно ровно по центру). Это соответствует ситуации, когда у каждой [задачи](https://ydb.tech/docs/ru/concepts/glossary.md#task) `FirstMessage == LastMessage` — одно сообщение на передачу всего объёма между [задачами](https://ydb.tech/docs/ru/concepts/glossary.md#task) (мало данных на канал). ![Специальный случай](../../_assets/rts-metrics-6.svg){inline=false} {% note tip %} Так бывает, когда для каждой [задачи](https://ydb.tech/docs/ru/concepts/glossary.md#task) в стадии `FirstMessage == LastMessage`: отправлено или принято ровно одно сообщение. Типично при небольшом объёме данных на канал. {% endnote %} ## Потребление CPU {#cpu} Рассмотрим CPU на примере стадии `0` из раздела [Структура фактического плана запроса](https://ydb.tech/docs/ru/dev/optimization/structure.md). Здесь «потребление» — использование процессорного времени на полезную работу. Простой стадии не даёт вклада в CPU; при работе вклады [задач](https://ydb.tech/docs/ru/concepts/glossary.md#task) суммируются обычным агрегированием. ![Потребление CPU](../../_assets/rts-structure-0.svg){inline=false} «Загруженность» [стадии](https://ydb.tech/docs/ru/concepts/glossary.md#processing-stage) и всей структуры выполнения запроса зависит от многих факторов, в том числе от других запросов на [кластере](https://ydb.tech/docs/ru/concepts/glossary.md#cluster). Для интерпретации CPU используется несколько представлений. Помимо строк в `Statistics`, в правой колонке — график CPU по времени: интервалы с большей и меньшей утилизацией (песочно-красный) и ожидание данных (зелёный). При back pressure возможны и синие области; в этом разделе акцент на самом потреблении. В примере суммарное процессорное время [задач](https://ydb.tech/docs/ru/concepts/glossary.md#task) стадии `0` — 1,79 с, стадии `1` — 0,81 с, при более короткой календарной длительности. Чтобы сравнивать стадии, считается пропускная способность (throughput): число входных строк в секунду (сумма входов, если их несколько). От неё зависит насыщенность фона в `Tasks`. На диаграмме видно расхождение: у стадии `1` порядка 329 млн строк/с, у стадии `0` — около 90 млн (точные значения — во всплывающей подсказке по ячейке в `Tasks`). Так сопоставляются разные величины — суммарный CPU и обработка строк, нормированная по длительности, — и становится проще искать узкое место в структуре выполнения. Графики CPU по стадиям имеют **разный вертикальный масштаб**: шкала подбирается так, чтобы пики заполняли доступную высоту. У каждого типа метрики свой масштаб полос для сравнения стадий по одному показателю — иначе при разбросе на порядки менее нагруженные стадии были бы нечитаемы. На рисунке выше видно, что временной график CPU стадии `0` в колонке `Timeline` занимает меньшую долю высоты, чем у стадии `1`, хотя суммарное время процессора у `0` больше: шкала подобрана отдельно для каждой стадии. ## Потребление памяти {#memory} Память проще интерпретировать, чем CPU: ресурс менее «эластичен», и [задачи](https://ydb.tech/docs/ru/concepts/glossary.md#task) чаще всего освобождают память к концу работы. Как и для CPU, временной график памяти по стадиям масштабируется независимо. Как использовать итоги диагностики: - Сравните полосы `Statistics` и `Timeline` — найдите [стадии](https://ydb.tech/docs/ru/concepts/glossary.md#processing-stage) с наибольшим CPU, памятью или трафиком. - Проверьте `Tasks` и [перекос данных](#dataskew): неравномерная нагрузка удлиняет [стадию](https://ydb.tech/docs/ru/concepts/glossary.md#processing-stage). - Сопоставьте метрики со [стадиями](https://ydb.tech/docs/ru/concepts/glossary.md#processing-stage) и [каналами связи](https://ydb.tech/docs/ru/concepts/glossary.md#channels) в [структуре плана](https://ydb.tech/docs/ru/dev/optimization/structure.md) — узкое место часто совпадает с тяжёлой стадией или каналом. - Сравните оценки [`EXPLAIN`](https://ydb.tech/docs/ru/dev/optimization/plans.md#explain-cli) с фактическими метриками [`ANALYZE`](https://ydb.tech/docs/ru/dev/optimization/plans.md#analyze-cli).