|
26 | 26 |
|
27 | 27 | Планировщик PDisk управляет порядком выполнения PDisk'ом запросов от его клиентов-VDisk'ов. PDisk честно делит время устройства между своими VDisk'ами, то есть каждому из $n$ VDisk'ов гарантируется $1/n$ секунд работы физического устройства каждую секунду. На основе информации о количестве VDisk'ов-соседей для каждого VDisk'а рассчитывается доступное время диска или `DiskTimeAvailable`.
|
28 | 28 |
|
29 |
| -### Масштабирование метрик |
30 |
| - |
31 |
| -Поскольку коэффициенты производительности |
32 |
| - |
33 | 29 | ### Детектор берстов
|
34 | 30 |
|
35 | 31 | Берст - это резкое краткосрочное повышение нагрузки на VDisk, которое может приводить к деградации latency операций. Значения сенсоров с нод кластера собираются через определенные промежутки времени, например, раз в 15 секунд, что делает невозможным надежное обнаружение краткосрочных событий с помощью одних только метрик Cost и TimeAvailable. Для решения этой задачи используется модифицированный [алгоритм Token Bucket](https://en.wikipedia.org/wiki/Token_bucket), в нашей модификации в ведре может быть отрицательное количество токенов, и такое состояние мы будем называть underflow. К каждому VDisk'у привязан отдельный объект Token Bucket.
|
|
51 | 47 | 1. `DiskTimeAvailable >= UserDiskCost + InternalDiskCost + CompactionDiskCost + DefragDiskCost + ScrubDiskCost` - средний поток нагрузки не превышает предельно допустимый.
|
52 | 48 | 2. `BurstDetector_redMs = 0` - отсутствуют краткосрочные пики нагрузки, приводящие к образованию очередей запросов.
|
53 | 49 |
|
| 50 | +### Масштабирование метрик |
| 51 | + |
| 52 | +Поскольку коэффициенты для формулы cost измерялись на конкретных физических устройствах, а производительность других устройств может отличаться, метрики могут потребовать масштабирования для использования их в качестве источника гарантий BlobStorage. Для этого задайте параметру `DiskTimeAvailableScale` в [конфигурации BlobStorage](../../deploy/configuration/config.md#blob-storage-config) значение, равное отношению производительности устройств кластера и эталона. Например, если ваша система использует NVME устройства и обеспечивает вдвое более высокую производительность, чем эталон, то задайте следующую конфигурацию: |
| 53 | +``` |
| 54 | +blob_storage_config: |
| 55 | + vdisk_types: |
| 56 | + - pdisk_type: NVME |
| 57 | + disk_time_available_scale: 2 |
| 58 | +``` |
| 59 | + |
| 60 | +### Как сравнить свое устройство с эталоном |
| 61 | + |
| 62 | +Чтобы сравнить производительность BlobStorage на вашей системе с эталонной, необходимо загрузить распределенное хранилище запросами до такого состояния, когда VDisk'и не могут обрабатывать поток входящих запросов, сответственно запросы начинают выстраиваться в очередь, и время отклика VDisk'ов резко возрастает. Посчитайте величину $D$ в момент перегрузки: |
| 63 | +$$ |
| 64 | +D = \frac{UserDiskCost + InternalDiskCost + CompactionDiskCost + DefragDiskCost + ScrubDiskCost}{DiskTimeAvailable} |
| 65 | +$$ |
| 66 | +Задайте параметр `disk_time_available_scale` конфигурации равным рассчитанному значению $D$. |
| 67 | + |
| 68 | +Создать подобную нагрузку можно любым инструментом, который обеспечивает плавно возрастающую частоту запросов, например, с помощью [Storage LoadActor](../../development/load-actors-storage.md). |
| 69 | + |
54 | 70 | ### Дашборд в Monitoring
|
55 | 71 | Для удобного просмотра метрик и диагностики существует [дашборд](https://m.yandex-team.ru/projects/kikimr/dashboards/mongi8n4phijn4n3o4il) во внутреннем инструменте Monitoring.
|
56 | 72 |
|
|
0 commit comments