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

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

  • Статья

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

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

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

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

Политика сквозного времени ожидания

Существуют сценарии, в которых 408 ошибок времени ожидания сети возникают, даже если все решения, упомянутые ниже, были реализованы. Общая рекомендация по сокращению задержки хвоста, а также улучшению доступности в этих сценариях заключается в реализации сквозной политики времени ожидания. Задержка хвоста уменьшается путем ускорения сбоя, а единицы запросов и затраты на вычислительные ресурсы на стороне клиента сокращаются путем остановки повторных попыток после истечения времени ожидания. Длительность ожидания может быть задана CosmosItemRequestOptions. Затем параметры можно передать в любой запрос, отправляемый в Azure Cosmos DB:

CosmosEndToEndOperationLatencyPolicyConfig endToEndOperationLatencyPolicyConfig = new CosmosEndToEndOperationLatencyPolicyConfigBuilder(Duration.ofSeconds(1)).build();
CosmosItemRequestOptions options = new CosmosItemRequestOptions();
options.setCosmosEndToEndOperationLatencyPolicyConfig(endToEndOperationLatencyPolicyConfig);
container.readItem("id", new PartitionKey("pk"), options, TestObject.class);

Существующие проблемы

Если запросы часто зависают на длительное время или время ожидания истекает, обновите пакет SDK для Java версии 4 до последней версии. Примечание. Настоятельно рекомендуем использовать версию 4.18.0 и более позднюю. Дополнительные сведения см. в заметках о выпуске пакета SDK для Java версии 4.

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

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

Решение.

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

Регулирование подключения

Регулирование подключения может произойти из-за ограничения числа подключений на узле или нехватки портов Azure SNAT (PAT).

Ограничение числа подключений на узле

Некоторые системы Linux (например, Red Hat) имеют ограничение на общее число открытых файлов. Сокеты в Linux реализованы как файлы, поэтому это число также существенно ограничивает общее число подключений. Выполните следующую команду.

ulimit -a

Решение.

Максимальное разрешенное количество открытых файлов, которые определены как "nofile", должно быть равно не менее 10 000. Дополнительные сведения см. в советах по повышению производительности для пакета SDK Java версии 4 для Azure Cosmos DB.

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

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

Решение 1.

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

Решение 2.

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

Решение 3.

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

Решение 4.

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

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

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

Решение 1.

Следуйте советам по повышению производительности и используйте один экземпляр CosmosClient для всего приложения.

Решение 2.

Если одноэлементный CosmosClient не удается использовать в приложении, рекомендуется использовать общий доступ к подключению для нескольких клиентов Azure Cosmos DB через этот API connectionSharingAcrossClientsEnabled(true) в CosmosClient. При наличии нескольких экземпляров клиента Azure Cosmos DB в одном и том же JVM, взаимодействующих с несколькими учетными записями Azure Cosmos DB, это позволяет совместно использовать подключение в режиме Direct, если это возможно между экземплярами клиента Azure Cosmos DB. Обратите внимание, что при указании этого параметра конфигурация подключения (например, настройка времени ожидания сокета, конфигурация тайм-аут простоя) для первого созданного экземпляра клиента будет также использоваться для всех остальных экземпляров клиента.

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

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

Решение.

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

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

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

Решение.

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

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

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

Решение.

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

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

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

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

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

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