Диагностика и устранение неполадок в Azure Cosmos DB: слишком большая частота запросов (429) исключений

ПРИМЕНИМО К: API SQL

В этой статье приведены известные причины и решения для различных ошибок кода состояния 429 для API SQL. Если вы используете API для MongoDB, см. статью Устранение распространенных проблем в API для MongoDB, чтобы узнать, как отлаживать код состояния 16500.

Исключение "Слишком большая частота запросов", также известная как код ошибки 429, указывает на то, что ваши запросы к Azure Cosmos DB ограничены по скорости.

При использовании подготовленной пропускной способности вы устанавливаете пропускную способность, измеряемую в единицах запросов в секунду (RU/s), необходимую для вашей рабочей нагрузки. Операции базы данных со службой, такие как чтение, запись и запросы, потребляют некоторое количество единиц запроса (RU). Дополнительные сведения о единицах запросов.

В заданную секунду, если операции потребляют больше, чем подготовленные единицы запроса, Azure Cosmos DB вернет исключение 429. Каждую секунду количество доступных для использования единиц запроса сбрасывается.

Прежде чем предпринимать действия по изменению единиц RU/s, важно понять основную причину ограничения скорости и устранить основную проблему.

Существуют различные сообщения об ошибках, которые соответствуют разным типам 429 исключений:

Высокая частота запросов

Этот сценарий является наиболее распространенным. Это происходит, когда количество единиц запроса, потребляемых операциями с данными, превышает предоставленное количество единиц RU/с.

Шаг 1. Проверьте показатели, чтобы определить процент запросов с ошибкой 429

Сообщения об ошибках 429 не обязательно свидетельствуют о возникновении проблемы с базой данных или контейнером.

Способ исследования

Определите, какой процент ваших запросов к базе данных или контейнеру привел к 429 секундам по сравнению с общим количеством успешных запросов. В колонке учетной записи Azure Cosmos DB перейдите в раздел Аналитика > Запросы > Общее количество запросов по коду состояния. Фильтр по конкретной базе данных и контейнеру.

По умолчанию клиентские пакеты SDK для Azure Cosmos DB и инструменты импорта данных, такие как Фабрика данных Azure и библиотека массового исполнителя, автоматически повторяют запросы на 429. Повторная попытка обычно не превышает 9 раз. В результате, несмотря на то, что в метриках может появиться число 429, эти ошибки могут быть даже не возвращены в приложение.

Таблица общего числа запросов по коду состояния, отображающая количество запросов 429 и 2xx.

В общем, для производственной рабочей нагрузки, если вы видите от 1 до 5% запросов с 429-секундными запросами и ваша сквозная задержка является приемлемой, это верный признак того, что единицы измерения в секунду используются полностью. Никаких действий не требуется. В противном случае переходите к следующим шагам по устранению неполадок.

Шаг 2: Определение наличия горячей секции

Горячая секция возникает в момент, когда один или несколько ключей логических разделов потребляют непропорционально большое количество единиц запросов в секунду из-за большего объема запроса. Это может быть вызвано тем, что ключ раздела не распределяет запросы равномерно. Это приводит к тому, что многие запросы направляются к небольшому подмножеству логических (что подразумевает физические) секции, которые становятся "горячими". Поскольку все данные для логической секции находятся в одном физическом разделе, а общее количество единиц в секунду распределяется равномерно между физическими разделами, горячая секция может привести к 429 секундам и неэффективному использованию пропускной способности.

Ниже приведены несколько примеров стратегий разделения, которые приводят к возникновению горячих секций:

  • У вас есть контейнер, который хранит данные устройства IoT для рабочей нагрузки с интенсивной записью, секционированной по date . Все данные за отдельно взятую дату будут расположены в одном логическом и физическом разделе. Поскольку все данные, записываемые каждый день, имеют одну и ту же дату, это приведет к ежедневному созданию горячей секции.
    • Вместо этого в этом сценарии ключ секции id (GUID или идентификатор устройства) или ключ искусственного раздела объединяются id и date выдают большую кратность значений и более эффективное распределение объема запросов.
  • Существует сценарий с несколькими клиентами с контейнером, секционированным по tenantId . Если один клиент значительно более активен, чем другие, это приводит к созданию горячей секции. Например, если наибольший клиент имеет 100 000 пользователей, но большинство клиентов имеют менее 10 пользователей, то у вас будет горячая секция, секционированная по tenantID .
    • В этом примере рекомендуется использовать выделенный контейнер для самого крупного клиента, секционированный по более детализированному свойству, например UserId .

Как определить горячую секцию

Для проверки наличия горячей секции перейдите в раздел Аналитика > Пропускная способность > Нормализованное потребление на единицу запроса (%) по PartitionKeyRangeID. Фильтр по конкретной базе данных и контейнеру.

Каждый Партитионкэйранжеид сопоставляется с одной физической секцией. В случае наличия одного PartitionKeyRangeId, у которого нормализованное потребление на единицу запроса значительно выше, чем у других (например, один постоянно на 100%, а другие на 30% или меньше), это может быть признаком горячей секции. Подробнее о Метрике нормализованного потребления единиц запросов.

Нормализованное потребление на единицу запроса по диаграмме PartitionKeyRangeId с горячей секцией.

Чтобы узнать, какие ключи логических разделов потребляют больше всего единиц в секунду, воспользуйтесь Журналами диагностики Azure. Этот пример запроса суммирует общее количество единиц запроса, потребляемых в секунду для каждого ключа логической секции.

Важно!

Включение журналов диагностики влечет за собой отдельную плату за Log Analyticsную службу, которая оплачивается в зависимости от объема принимаемых данных. Рекомендуется включать журналы диагностики на ограниченное время для отладки и выключать, когда они больше не требуются. Дополнительные сведения см. на странице цен.

AzureDiagnostics
| where TimeGenerated >= ago(24hour)
| where Category == "PartitionKeyRUConsumption"
| where collectionName_s == "CollectionName" 
| where isnotempty(partitionKey_s)
// Sum total request units consumed by logical partition key for each second
| summarize sum(todouble(requestCharge_s)) by partitionKey_s, operationType_s, bin(TimeGenerated, 1s)
| order by sum_requestCharge_s desc

Этот пример выходных данных показывает, что в конкретную минуту ключ логического раздела со значением "Contoso" потреблял около 12 000 единиц запросов в секунду, в то время как ключ логического раздела со значением "Fabrikam" потреблял менее 600 единиц запросов в секунду. Если этот шаблон был постоянным в течение периода времени, когда произошло ограничение скорости, это указывало бы на наличие горячей секции.

Ключи логических секций, потребляющие наибольшее количество запросов в секунду.

Совет

При любой рабочей нагрузке объем запросов в логических разделах будет естественным образом варьироваться. Необходимо определить, вызвана ли горячая секция фундаментальной асимметрией из-за выбора ключа раздела (который может потребовать изменения ключа) или временным всплеском из-за естественных изменений в шаблонах рабочей нагрузки.

Ознакомьтесь с руководством по выбору хорошего ключа секции.

При наличии высокого процента запросов с ограничением скорости и отсутствии горячей секции:

При наличии высокого процента запросов с ограничением скорости и наличии соответствующей горячей секции:

  • В долгосрочной перспективе для обеспечения максимальной стоимости и производительности рекомендуется изменить ключ секции. Ключ раздела нельзя обновить на месте, поэтому необходимо перенести данные в новый контейнер с другим ключом раздела. Для этой цели Azure Cosmos DB поддерживает инструмент миграции данных в реальном времени.
  • В краткосрочной перспективе вы можете временно увеличить количество единиц запросов в секунду, чтобы обеспечить большую пропускную способность для горячей секции. Это не рекомендуется в качестве долгосрочной стратегии, поскольку это приводит к избыточному выделению единиц запросов в секунду и более высокой стоимости.

Совет

Когда вы увеличиваете пропускную способность, операция масштабирования завершается мгновенно или требует до 5-6 часов, в зависимости от количества единиц запросов в секунду, до которого вы хотите масштабироваться. Если вы хотите узнать максимальное количество единиц запросов в секунду, которое вы можете установить без запуска операции асинхронного масштабирования (для которой требуется, чтобы Azure Cosmos DB подготовила больше физических разделов), умножьте количество отдельных PartitionKeyRangeIds на 10,0000 единиц запросов в секунду. Например, если у вас выделено 30 000 единиц запросов в секунду и 5 физических разделов (6000 единиц запросов в секунду выделено на физический раздел), вы можете увеличить до 50 000 единиц запросов в секунду (10 000 единиц запросов в секунду на физический раздел) в операции мгновенного масштабирования. Увеличение до >50 000 единиц запросов в секунду потребует асинхронной операции масштабирования.

Шаг 3. Определите, какие запросы возвращают 429

Порядок анализа запросов с 429

Воспользуйтесь Журналами диагностики Azure, чтобы определить, какие запросы возвращают 429 и сколько единиц запросов они потребили. Этот пример запроса выполняет агрегирование на минутном уровне.

Важно!

За включение журналов диагностики взимается отдельная плата за службу Log Analytics, которая оплачивается в зависимости от объема полученных данных. Рекомендуется включать журналы диагностики на ограниченное время для отладки и выключать, когда они больше не требуются. Дополнительные сведения см. на странице цен.

AzureDiagnostics
| where TimeGenerated >= ago(24h)
| where Category == "DataPlaneRequests"
| summarize throttledOperations = dcountif(activityId_g, statusCode_s == 429), totalOperations = dcount(activityId_g), totalConsumedRUPerMinute = sum(todouble(requestCharge_s)) by databaseName_s, collectionName_s, OperationName, requestResourceType_s, bin(TimeGenerated, 1min)
| extend averageRUPerOperation = 1.0 * totalConsumedRUPerMinute / totalOperations 
| extend fractionOf429s = 1.0 * throttledOperations / totalOperations
| order by fractionOf429s desc

Так, этот пример выходных данных показывает, что каждую минуту 30% запросов на создание документов были ограничены по скорости, при этом каждый запрос потреблял в среднем 17 единиц запросов. Запросы с 429 в журналах диагностики.

Ошибки 429 при запросах на создание, замену или выполнение операции upsert для документа
  • По умолчанию в SQL API все свойства индексируются по умолчанию. Настройте политику индексирования, чтобы индексировать только необходимые свойства. Это снизит количество запросов, требуемых для каждой операции создания документа, что снизит вероятность появления 429 или позволит вам достичь более высоких операций в секунду для того же количества подготовленных единиц запросов в секунду.
429 по запросам документов
429 при выполнении хранимых процедур
  • Хранимые процедуры предназначены для операций, требующих транзакций записи по значению ключа раздела. Не рекомендуется использовать хранимые процедуры для большого количества операций чтения или запросов. Для обеспечения максимальной производительности эти операции чтения или запроса должны выполняться на стороне клиента с использованием пакетов SDK Cosmos.

Ограничение скорости запросов метаданных

Ограничение скорости метаданных может возникнуть, когда вы выполняете большой объем операций с метаданными в базах данных и/или контейнерах. Операции с метаданными включают:

  • Создание, чтение, обновление или удаление контейнера или базы данных
  • Перечисление баз данных или контейнеров в учетной записи Cosmos
  • Запрос предложений для просмотра текущей подготовленной пропускной способности

Для этих операций существует зарезервированный системой предельное количество единиц запросов в секунду, поэтому увеличение выделенных единиц запросов в секунду базы данных или контейнера не будет оказывать никакого влияния и не является рекомендуемым. См. ограничения на операции с метаданными.

Способ исследования

Перейдите в раздел Аналитика > Система > Запросы метаданных по коду состояния. При необходимости выполните фильтрацию по конкретной базе данных и контейнеру.

Запросы метаданных по диаграмме кода состояния в аналитике.

  • Если вашему приложению необходимо выполнять операции с метаданными, рассмотрите возможность реализации политики отсрочки передачи, чтобы отправлять эти запросы с более низкой скоростью.

  • Используйте статические экземпляры клиентов Cosmos DB. при инициализации DocumentClient или космосклиент пакет SDK Cosmos DB извлекает метаданные учетной записи, включая сведения об уровне согласованности, базах данных, контейнерах, секциях и предложениях. При инициализации может использоваться большое число ЕЗ. Поэтому ее не следует выполнять часто. Используйте один экземпляр DocumentClient на протяжении времени существования приложения.

  • Кэшируйте имена баз данных и контейнеров. Извлеките имена ваших баз данных и контейнеров из конфигурации или кэшируйте их при запуске. Такие вызовы, как ReadDatabaseAsync/ReadDocumentCollectionAsync или CreateDatabaseQuery/CreateDocumentCollectionQuery, приведут к вызовам метаданных к службе, которые потребляют из зарезервированного системой ограничения единиц запросов. Не стоит выполнять эти операции слишком часто.

Ограничение скорости из-за временной ошибки службы

Ошибка 429 повторяется, когда запрос обнаруживает временную ошибку службы. Увеличение количества запросов в секунду в базе данных или контейнере не будет оказывать никакого влияния и не является рекомендуемым.

Повторите запрос. Если ошибка повторяется в течение нескольких минут, отправьте заявку в службу поддержки на портале Azure.

Дальнейшие действия