Introduce docs about BlobStorage performance metrics #2509
Conversation
✅ Documentation buildRevision built successfully |
serbel324
force-pushed
the
YDBDOCS-615-perforamnce-metrics
branch
2 times, most recently
from
04e790c
to
2abf9a6
Compare
❌ Documentation buildRevision build failed Build logsErrors (1)❌ Link is unreachable: ../deploy/configuration/config.md#blob-storage-config in /ru/maintenance/manual/performance_metrics.md |
serbel324
force-pushed
the
YDBDOCS-615-perforamnce-metrics
branch
from
2abf9a6
to
48ce279
Compare
✅ Documentation buildRevision built successfully |
serbel324
force-pushed
the
YDBDOCS-615-perforamnce-metrics
branch
from
48ce279
to
06ac6a4
Compare
✅ Documentation buildRevision built successfully |
serbel324
force-pushed
the
YDBDOCS-615-perforamnce-metrics
branch
from
06ac6a4
to
766dfab
Compare
✅ Documentation buildRevision built successfully |
✅ Documentation buildRevision built successfully |
✅ Documentation buildRevision built successfully |
|
|
||
| ### Настройка метрик | ||
|
|
||
| Поскольку коэффициенты для формулы cost измерялись на конкретных физических устройствах, а производительность других устройств может отличаться, метрики могут потребовать масштабирования для использования их в качестве источника гарантий BlobStorage. Для этого задайте параметру `DiskTimeAvailableScale` в [конфигурации BlobStorage](../../deploy/configuration/config.md#blob-storage-config) значение, равное отношению производительности устройств кластера и эталона. Например, если ваша система использует NVME устройства и обеспечивает на 10% более высокую производительность, чем эталон, то задайте следующую конфигурацию: |
There was a problem hiding this comment.
Вот тут не хватает информации, что за устройства были. Я, конечно, не настоящий сварщик, но предположу, что для идентичных эталону дисков коэффициент должен быть 1.
Т.е. сейчас выглядит так, что подбор и исследование коэффициентов перешли на плечи пользователя и значительно осложнили его жизнь. Я бы предположила, что сценарий использования следующий: берется типовой диск определенного типа, настраивается сторадж, и дальше мы по метрикам смотрим, что он работает как нужно.
А вот если с диском что-то не так, нужно проводить дополнительные калибровки и замеры. Ведь вполне может быть, что при запуске с дисками было все хорошо, а потом их рабочие показатели ухудшились. И вот только тогда имеет смысл что-то пересчитывать и замерять.
There was a problem hiding this comment.
для идентичных эталону дисков коэффициент должен быть 1.
Да, все так, по умолчанию там 1. Добавлю это в документацию.
Я бы предположила, что сценарий использования следующий: берется типовой диск определенного типа, настраивается сторадж, и дальше мы по метрикам смотрим, что он работает как нужно.
В теории можно так сделать, но тогда нужен не один диск, а несколько, чтобы на них можно было сторадж-группы поднять.
Т.е. сейчас выглядит так, что подбор и исследование коэффициентов перешли на плечи пользователя и значительно осложнили его жизнь.
Ну мы не можем знать, какие устройства будут на кластере пользователя, мы можем лишь предположить, что примерно такие, как у нас. Коэффициенты имеет смысл подкручивать, если доступное время диска в момент начала перегрузок не сходится с оценкой стоимости, то есть из практического опыта использования.
А вот если с диском что-то не так, нужно проводить дополнительные калибровки и замеры. Ведь вполне может быть, что при запуске с дисками было все хорошо, а потом их рабочие показатели ухудшились. И вот только тогда имеет смысл что-то пересчитывать и замерять.
Такое может быть, но это как раз сигнализирует о проблеме с железом, тормозящее железо надо менять, потому что от пары медленных дисков лейтенси записи на всю группу деградирует.
❌ Documentation buildRevision build failed Build logsErrors (1)❌ Link is unreachable: ../../development/load-actors-storage.md in /ru/maintenance/manual/performance_metrics.md |
2 similar comments
❌ Documentation buildRevision build failed Build logsErrors (1)❌ Link is unreachable: ../../development/load-actors-storage.md in /ru/maintenance/manual/performance_metrics.md |
❌ Documentation buildRevision build failed Build logsErrors (1)❌ Link is unreachable: ../../development/load-actors-storage.md in /ru/maintenance/manual/performance_metrics.md |
✅ Documentation buildRevision built successfully |
✅ Documentation buildRevision built successfully |
serbel324
force-pushed
the
YDBDOCS-615-perforamnce-metrics
branch
from
72558e2
to
0df425e
Compare
❌ Documentation buildRevision build failed Build logsErrors (1)❌ No such file or has no access to /ru/maintenance/manual/performance_metrics.md |
serbel324
force-pushed
the
YDBDOCS-615-perforamnce-metrics
branch
from
73ab3a5
to
81e190b
Compare
❌ Documentation buildRevision build failed Build logsErrors (1)❌ No such file or has no access to /ru/maintenance/manual/performance_metrics.md |
❌ Documentation buildRevision build failed Build logsErrors (2)❌ Link is unreachable: ../../maintenance/manual/dynamic-config.md in /ru/reference/observability/metrics/performance.md ❌ No such file or has no access to /ru/maintenance/manual/performance_metrics.md |
serbel324
force-pushed
the
YDBDOCS-615-perforamnce-metrics
branch
from
df82567
to
1a0c384
Compare
serbel324
force-pushed
the
YDBDOCS-615-perforamnce-metrics
branch
from
1a0c384
to
41d42b8
Compare
❌ Documentation buildRevision build failed Build logsErrors (1)❌ Link is unreachable: ../../maintenance/manual/dynamic-config.md in /ru/reference/observability/metrics/performance.md |
✅ Documentation buildRevision built successfully |
✅ Documentation buildRevision built successfully |
ydb/docs/en/core/reference/observability/metrics/performance.md
Outdated
Show resolved
Hide resolved
ydb/docs/en/core/reference/observability/metrics/performance.md
Outdated
Show resolved
Hide resolved
ydb/docs/en/core/reference/observability/metrics/performance.md
Outdated
Show resolved
Hide resolved
ydb/docs/en/core/reference/observability/metrics/performance.md
Outdated
Show resolved
Hide resolved
ydb/docs/en/core/reference/observability/metrics/performance.md
Outdated
Show resolved
Hide resolved
ydb/docs/en/core/reference/observability/metrics/performance.md
Outdated
Show resolved
Hide resolved
ydb/docs/en/core/reference/observability/metrics/performance.md
Outdated
Show resolved
Hide resolved
ydb/docs/en/core/reference/observability/metrics/performance.md
Outdated
Show resolved
Hide resolved
ydb/docs/en/core/reference/observability/metrics/performance.md
Outdated
Show resolved
Hide resolved
✅ Documentation buildRevision built successfully |
✅ Documentation buildRevision built successfully |
ydb/docs/en/core/reference/observability/metrics/distributed-storage-performance.md
Outdated
Show resolved
Hide resolved
…torage-performance.md
✅ Documentation buildRevision built successfully |
…4/ydb into YDBDOCS-615-perforamnce-metrics
✅ Documentation buildRevision built successfully |
|
|
||
| ### Available disk time {#diskTimeAvailable} | ||
|
|
||
| The PDisk scheduler manages the requests execution order from its client VDisks. PDisk fairly divides the device's time among its VDisks, ensuring that each of the $n$ VDisks is guaranteed $1/n$ seconds of the physical device's working time each second. Based on the information about the number of neighboring VDisks for each VDisk, denoted as $N$, and the configurable parameter `DiskTimeAvailableScale`, the available disk time estimate, referred to as `DiskTimeAvailable`, is calculated by the formula: |
There was a problem hiding this comment.
Тема DiskTimeAvailableScale не раскрыта. Не понятно, что это такое.
|
|
||
| ### Available disk time {#diskTimeAvailable} | ||
|
|
||
| The PDisk scheduler manages the requests execution order from its client VDisks. PDisk fairly divides the device's time among its VDisks, ensuring that each of the $n$ VDisks is guaranteed $1/n$ seconds of the physical device's working time each second. Based on the information about the number of neighboring VDisks for each VDisk, denoted as $N$, and the configurable parameter `DiskTimeAvailableScale`, the available disk time estimate, referred to as `DiskTimeAvailable`, is calculated by the formula: |
There was a problem hiding this comment.
n и N -- это по сути одно и то же в рамках заданного контекста? Если да, давай использовать что-то одно, чтобы не путать читателя
| DiskTimeAvailable = \dfrac{1000000000}{N} \cdot \dfrac{DiskTimeAvailableScale}{1000} | ||
| $$ | ||
|
|
||
| ### Детектор всплесков нагрузки {#burstDetector} |
There was a problem hiding this comment.
Раздел называется "Детектор всплексков нагрузки", но в нем дается только определение всплеска, а не детектора.
| Всплеск - это резкое краткосрочное повышение нагрузки на VDisk, которое может приводить к деградации времени отклика операций. Значения сенсоров с нод кластера собираются через определенные промежутки времени, например, раз в 15 секунд, что делает невозможным надежное обнаружение краткосрочных событий с помощью одних только метрик стоимости запросов и доступного времени диска. Для решения этой задачи используется модифицированный [алгоритм Token Bucket](https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC_%D1%82%D0%B5%D0%BA%D1%83%D1%89%D0%B5%D0%B3%D0%BE_%D0%B2%D0%B5%D0%B4%D1%80%D0%B0), в нашей модификации в ведре может быть отрицательное количество токенов, и такое состояние мы будем называть underflow. К каждому VDisk'у привязан отдельный объект Token Bucket. Минимальное ожидаемое время отклика, при котором повышение нагрузки считается всплеском, определяется настраиваемым параметром `BurstThresholdNs`. Ведро будет перехдить в состояние underflow, если расчетная длительность обработки всплеска запросов в наносекундах превысит значение `BurstThresholdNs`. | ||
|
|
||
| ### Метрики производительности | ||
| Метрики производительности вычисляются на основе следующих сенсоров VDisk'а: |
There was a problem hiding this comment.
Мне как пользователю вообще не понятно, где эти метрики брать и смотреть. Где мне их искать? В логах, на странице мониторинга (ссылку можно?), и т.п.
...