Почему минимальный autoscale max RU/s может вырасти из-за истории пика, объёма хранения и числа контейнеров в shared database, и какие метрики собрать до изменения throughput.
Отделите текущий расход от границы Tmax
В autoscale вы задаёте максимальный предел Tmax, а сервис масштабирует текущий throughput внутри разрешённого диапазона. Низкая текущая нагрузка не означает, что портал обязан разрешить любое меньшее значение Tmax. Microsoft отдельно описывает текущий provisioned throughput, normalized RU consumption и минимально допустимый autoscale max RU/s. Поэтому сначала запишите, какое именно число выросло: текущий показатель, установленный максимум или минимальное значение, доступное при редактировании.
Соберите четыре входа формулы
Для контейнера официальный минимум Tmax — максимум из 1000 RU/s, десятой части наибольшего когда-либо установленного максимума и текущего хранения в гигабайтах, умноженного на 10, с округлением. Для shared throughput database добавляется член, зависящий от числа контейнеров сверх 25. Соберите current storage, highest max RU/s ever, container count и уровень, на котором назначен throughput. Не подставляйте общий размер аккаунта вместо размера конкретной базы или контейнера.
Проверьте уровень provisioned throughput
Microsoft различает throughput на контейнере и на базе данных. В shared database ресурсы делят общий throughput, а отдельный контейнер может иметь dedicated throughput. Откройте свойства именно того объекта, который показывает высокий минимум, и составьте список контейнеров: какие используют shared, а какие выделенный режим. Это важнее текущего графика запросов. Не пытайтесь исправить базовый минимум настройкой SDK-клиента или повторными запросами — формула относится к ресурсу сервиса.
Сверьте метрики без поспешного снижения
Для оценки использования Microsoft рекомендует Normalized RU Consumption, а Provisioned Throughput отражает оплачиваемый throughput с агрегацией и задержкой. Сопоставьте минимум формулы, хранение, число контейнеров, нормализованное потребление и 429 по подходящему окну времени. Высокая нижняя граница и низкое потребление могут существовать одновременно. Не снижайте максимум только по одному часовому графику: сначала проверьте горячие разделы, пики и требования к задержке.
Подготовьте решение и эскалацию
Если вычисленная граница совпадает с порталом, это документированное ограничение, а не самопроизвольный скачок. Дальнейшие варианты — пересмотреть уровень shared versus dedicated, количество контейнеров и размещение данных в рамках отдельного проектного изменения; некоторые переходы требуют переноса данных. Если числа не совпадают, передайте поддержке resource ID в защищённом канале, регион, API, storage, container count, history max RU/s и временной диапазон метрик. Не публикуйте ключи, строки подключения или содержимое документов.
Материал подготовлен самостоятельно с автоматизацией и редакционно проверен 29 июля 2026 года по обезличенному сигналу Microsoft Q&A и актуальной официальной документации Azure; клиентские ресурсы и метрики не использовались.
Источники и проверка
- Microsoft Learn — Azure Cosmos DB autoscale FAQ проверено 2026-07-29
- Microsoft Learn — Provision throughput for containers and databases проверено 2026-07-29
- Microsoft Learn — Cosmos DB service quotas and limits проверено 2026-07-29
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.