Add information about fine-tuning

ydb/docs/ru/core/maintenance/manual/performance_metrics.md

@@ -26,10 +26,6 @@ $$
 
 Планировщик PDisk управляет порядком выполнения PDisk'ом запросов от его клиентов-VDisk'ов. PDisk честно делит время устройства между своими VDisk'ами, то есть каждому из $n$ VDisk'ов гарантируется $1/n$ секунд работы физического устройства каждую секунду. На основе информации о количестве VDisk'ов-соседей для каждого VDisk'а рассчитывается доступное время диска или `DiskTimeAvailable`.
 
-### Масштабирование метрик
-
-Поскольку коэффициенты производительности 
-
 ### Детектор берстов
 
 Берст - это резкое краткосрочное повышение нагрузки на VDisk, которое может приводить к деградации latency операций. Значения сенсоров с нод кластера собираются через определенные промежутки времени, например, раз в 15 секунд, что делает невозможным надежное обнаружение краткосрочных событий с помощью одних только метрик Cost и TimeAvailable. Для решения этой задачи используется модифицированный [алгоритм Token Bucket](https://en.wikipedia.org/wiki/Token_bucket), в нашей модификации в ведре может быть отрицательное количество токенов, и такое состояние мы будем называть underflow. К каждому VDisk'у привязан отдельный объект Token Bucket.
@@ -51,6 +47,26 @@ $$
 1. `DiskTimeAvailable >= UserDiskCost + InternalDiskCost + CompactionDiskCost + DefragDiskCost + ScrubDiskCost` - средний поток нагрузки не превышает предельно допустимый.
 2. `BurstDetector_redMs = 0` - отсутствуют краткосрочные пики нагрузки, приводящие к образованию очередей запросов.
 
+### Масштабирование метрик
+
+Поскольку коэффициенты для формулы cost измерялись на конкретных физических устройствах, а производительность других устройств может отличаться, метрики могут потребовать мамсштабирования для использования их в качестве источника гарантий BlobStorage. Для этого задайте параметру `DiskTimeAvailableScale` в [конфигурации BlobStorage](../deploy/configuration/config.md#blob-storage-config) значение, равное отношению производительности устройств кластера и эталона. Например, если ваша система использует NVME устройства и обеспечивает вдвое более высокую производительность, чем эталон, то задайте следующую конфигурацию:
+```
+blob_storage_config:
+  vdisk_types:
+  - pdisk_type: NVME
+    disk_time_available_scale: 2
+```
+
+### Как сравнить свое устройство с эталоном
+
+Чтобы сравнить производительность BlobStorage на вашей системе с эталонной, необходимо загрузить распределенное хранилище запросами до того момента, как VDisk'и не смогут обрабатывать поток входящих запросов, запросы начнут выстраиваться в очередь на VDisk'ах и latency ответов VDisk'ов начнет резко расти. Посчитайте величину $D$ в момент перегрузки:
+$$
+D = \frac{UserDiskCost + InternalDiskCost + CompactionDiskCost + DefragDiskCost + ScrubDiskCost}{DiskTimeAvailable}
+$$
+Задайте параметр `disk_time_available_scale` конфигурации равным рассчитанному значению $D$.
+
+Создать такую нагрузку можно любым инструментом, который обеспечивает плавно возрастающую частоту запросов, например, с помощью [Storage LoadActor](../../development/load-actors-storage.md).
+
 ### Дашборд в Monitoring
 Для удобного просмотра метрик и диагностики существует [дашборд](https://m.yandex-team.ru/projects/kikimr/dashboards/mongi8n4phijn4n3o4il) во внутреннем инструменте Monitoring.
 

ydb/docs/ru/core/maintenance/manual/toc_i.yaml

@@ -35,3 +35,5 @@ items:
   href: balancing_load.md
 - name: Освобождение места на физических устройствах
   href: disk_end_space.md
+- name: Работа с метриками производительности BlobStorage
+  href: performance_metrics.md