Поделиться через

Диагностика и устранение неполадок, связанных с исключениями из-за превышения времени ожидания запроса к пакету SDK Azure Cosmos DB для .NET

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: NoSQL

Ошибка HTTP 408 возникает, если пакету SDK не удалось выполнить запрос до истечения времени ожидания.

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

При оценке ошибок времени ожидания задайте следующие вопросы:

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

Настройка времени ожидания для пакета SDK Azure Cosmos DB для .NET

В пакете SDK есть два разных варианта управления временем ожидания, у каждого из них разная область.

Время ожидания на уровне запроса

Конфигурация CosmosClientOptions.RequestTimeout (или ConnectionPolicy.RequestTimeout для пакета SDK версии 2) позволяет задать время ожидания для сетевого запроса после того, как запрос оставил пакет SDK и находится в сети, пока не будет получен ответ.

Конфигурация CosmosClientOptions.OpenTcpConnectionTimeout (или ConnectionPolicy.OpenTcpConnectionTimeout для пакета SDK версии 2) позволяет задать время ожидания, затраченное на открытие начального подключения. После открытия подключения последующие запросы будут использовать подключение.

Операция, запущенная пользователем, может охватывать несколько сетевых запросов, например повторные попытки. Эти две конфигурации предназначены для каждого запроса, а не сквозной для операции.

CancellationToken

Все асинхронные операции в пакете SDK имеют необязательный параметр CancellationToken. Этот параметр CancellationToken используется во всей операции во всех сетевых запросах и повторных попытках. Токен отмены может проверяться между сетевыми запросами. Если срок действия соответствующего токена истек, операция будет отменена. Токен отмены следует использовать для определения приблизительного требуемого времени ожидания в области операции.

Примечание.

Параметр CancellationToken — это механизм, с помощью которого библиотека проверяет отмену, когда она не вызывает недопустимого состояния. Отмена операции может не происходить точно по истечении времени, указанного в отмене. Наоборот, операция отменяется по истечении времени только тогда, когда это действие безопасно.

Действия по устранению неполадок

Ниже перечислены известные причины исключений, связанных со временем ожидания запроса, и решения по их устранению.

CosmosOperationCanceledException

Этот тип исключения часто возникает, когда приложение передает маркеры CancellationTokens операциям пакета SDK. Пакет SDK проверяет состояние CancellationToken между повторными попытками и, если CancellationToken он отменен, он прерывает текущую операцию с этим исключением.

Message / ToString() исключения также указывает состояние вашего CancellationToken до Cancellation Token has expired: true, а также будет включать диагностику, содержащую контекст отмены для задействованных запросов.

Эти исключения безопасны для повторных попыток и могут рассматриваться как тайм-ауты с точки зрения повтора.

Решение

Убедитесь, что настроенное время CancellationToken больше, чем requestTimeout и CosmosClientOptions.OpenTcpConnectionTimeout (если вы используете прямой режим). Если доступное время в CancellationToken меньше настроенного времени ожидания и в пакете SDK возникаю временные проблемы подключения, пакет SDK не сможет повторить попытку и выдаст исключение CosmosOperationCanceledException.

Высокая загрузка ЦП

Высокая загрузка ЦП является наиболее распространенным случаем. Для оптимальной задержки загрузка ЦП должна составлять примерно 40 %. Используйте 10 секунд в качестве интервала для наблюдения за максимальной (не средней) загрузкой ЦП. Пики загрузки ЦП часто связаны с запросами между секциями, когда для одного запроса могут выполняться несколько подключений.

Время ожидания будет содержать Diagnostics и включать:

"systemHistory": [
{
"dateUtc": "2021-11-17T23:38:28.3115496Z",
"cpu": 16.731,
"memory": 9024120.000,
"threadInfo": {
"isThreadStarving": "False",
....
}

},
{
"dateUtc": "2021-11-17T23:38:28.3115496Z",
"cpu": 16.731,
"memory": 9024120.000,
"threadInfo": {
"isThreadStarving": "False",
....
}

},
...
]
  • Если значения cpu превышают 70 %, то время ожидания, скорее всего, вызвано нехваткой ресурсов ЦП. В этом случае для решения проблемы следует изучить источник высокой загрузки ЦП и сократить ее или масштабировать компьютер, чтобы увеличить количество ресурсов.
  • Если узлы threadInfo/isThreadStarving имеют значения True, причиной является нехватка потоков. В этом случае для решения проблемы следует изучить причину нехватки потоков (потенциально заблокированные потоки) или масштабировать компьютеры, чтобы увеличить количество ресурсов.
  • Если время dateUtc между измерениями составляет отлично примерно от 10 секунд, это также указывает на состязание в пуле потоков. Загрузка ЦП измеряется как независимая задача, которая ставится в очередь в пуле потоков каждые 10 секунд. Если время между измерениями больше, это означает, что асинхронные задачи не могут быть обработаны своевременно. Чаще всего это происходит при выполнении блокирующих вызовов вместо асинхронного кода в коде приложения.

Решение

Клиентское приложение, использующее пакет SDK, следует масштабировать вертикально или горизонтально.

Возможна низкая доступность сокета или порта

При работе в Azure клиенты, использующие пакет SDK для .NET, могут столкнуться с нехваткой портов Azure SNAT (PAT).

Решение 1

Если вы запускаете виртуальные машины Azure, следуйте рекомендациям в разделе о нехватке портов SNAT.

Решение 2

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

Решение 3

Если вы запускаете Функции Azure, убедитесь, что выполняете рекомендации по Функциям Azure для обслуживания отдельных или статических клиентов для всех связанных служб (включая Azure Cosmos DB). Проверьте ограничения службы в зависимости от типа и размера размещения приложения-функции.

Решение 4

При использовании прокси-сервера HTTP убедитесь, что он может поддерживать число подключений, указанное в свойстве ConnectionPolicy пакета SDK. В противном случае возникнут проблемы с подключением.

Создание нескольких экземпляров клиента

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

{
    "NumberOfClientsCreated":X,
    "NumberOfActiveClients":Y,
}

NumberOfClientsCreated отслеживает количество созданных экземпляров CosmosClient в одном домене приложений и NumberOfActiveClients отслеживает активные клиенты (не удаляются). Ожидается, что если следует одноэлементный шаблон, X будет соответствовать количеству учетных записей, с которыми работает приложение, и это X равно Y.

Если X больше Y, это означает, что приложение создает и удаляет экземпляры клиента. Это может привести к возникновению состязаний по подключению и /или ЦП.

Решение

Следуйте рекомендациям по производительности и используйте один экземпляр CosmosClient для каждой учетной записи во всем процессе. Избегайте создания и удаления клиентов.

Ключ горячей секции

Azure Cosmos DB распределяет общую подготовленную пропускную способность равномерно по нескольким физическим секциям. Иногда одна или несколько физических секций с определенными ключами оказываются перегруженными, то есть потребляют все выделенные для них единицы в секунду (ЕЗ/с). В то же время в других физических секциях ЕЗ/с не используются. Важный признак такой ситуации — общий объем используемых ЕЗ/с будет меньше, чем подготовленный объем ЕЗ/с для базы данных или контейнера, но по-прежнему будет выполняться регулирование (ошибки 429) в запросах к ключу горячей логической секции. Используйте метрику потребления нормализованных единиц запросов и оцените, не возникла ли горячая секция в вашей рабочей нагрузке.

Решение

Выберите подходящий ключ секции, который равномернее распределит объем запросов и место в хранилище. Узнайте, как изменить ключ секции.

Высокая степень параллелизма

Приложение выполняется с высоким уровнем параллелизма, что может привести к состязанию в канале.

Решение

Клиентское приложение, использующее пакет SDK, следует масштабировать вертикально или горизонтально.

Запросы или ответы больших размеров

Из-за большого размера запросов или ответов может возникнуть основная блокировка канала и усугубиться состязание даже при относительно низком уровне параллелизма.

Решение

Клиентское приложение, использующее пакет SDK, следует масштабировать вертикально или горизонтально.

Частота сбоев в рамках Соглашения об уровне обслуживания Azure Cosmos DB

Приложение должно обрабатывать временные сбои и при необходимости повторять попытку. При любых исключениях с кодом 408 повторная попытка не выполняется, так как при создании путей невозможно определить, создан ли элемент службой. При повторной отправке одного и того же элемента для создания возникнет исключение из-за конфликта. Бизнес-логика приложений пользователя может быть пользовательской логикой для обработки конфликтов, которая будет нарушена из-за неоднозначности имеющегося элемента, а не конфликта при повторной попытке создания.

Частота сбоев нарушает Соглашение об уровне обслуживания Azure Cosmos DB

Обратитесь в Службу поддержки Azure.

Следующие шаги