诊断和排除 Azure Cosmos DB for NoSQL Java v4 SDK 请求超时异常

如果软件开发工具包(SDK)在超时限制发生之前无法完成请求,则会发生 HTTP 408 错误。

故障排除步骤

以下列表包含请求超时异常的已知原因和解决方案。

端到端超时策略

在某些情况下,即使实现此处的所有抢先解决方案,也会出现 408 个网络超时错误。 一个降低尾部延迟并提高在这些场景中可用性的一项通用的最佳实践是实现端到端超时策略。 通过快速出错来减少尾部延迟,请求单元和客户端计算成本通过在超时后停止重试来降低。超时持续时间可以设置在CosmosItemRequestOptions。 然后,可以将这些选项传递给发送到 Azure Cosmos DB for NoSQL 的任何请求:

CosmosEndToEndOperationLatencyPolicyConfig endToEndOperationLatencyPolicyConfig = new CosmosEndToEndOperationLatencyPolicyConfigBuilder(Duration.ofSeconds(1)).build();

CosmosItemRequestOptions options = new CosmosItemRequestOptions();
options.setCosmosEndToEndOperationLatencyPolicyConfig(endToEndOperationLatencyPolicyConfig);

container.readItem("id", new PartitionKey("pk"), options, TestObject.class);

现有问题

如果您发现请求被卡住的情况持续时间变长或超时变得更频繁,请将 Java v4 SDK 升级到最新版本。 注意:强烈建议使用版本 4.18.0 及更高版本。 有关更多详细信息,请查看 Java v4 SDK 发行说明

CPU 利用率较高

最常见的情况是 CPU 利用率较高。 为实现最佳延迟,CPU 利用率应大约为 40%。 使用 10 秒作为间隔来监视最大(非平均值)CPU 使用率。 对于可能会为单个查询执行多个连接的跨分区查询,更常见的情况是出现 CPU 峰值。

解决方案

使用 SDK 的客户端应用程序应进行纵向或横向扩展。

连接限制

连接限速可能由主机上的连接限制或 Azure 源网络地址转换(SNAT)端口耗尽导致。

主机上的连接限制

某些 Linux 系统(如 CentOS)对打开的文件总数有上限。 Linux 中的套接字以文件形式实现,因此,此上限也限制了连接总数。 运行以下命令。

ulimit -a

解决方案

最大允许打开的文件数(标识为 nofile)需要至少为 10,000 个或更多。 有关详细信息,请参阅 Azure Cosmos DB for NoSQL Java SDK v4 性能提示

套接字或端口可用性可能较低

在 Azure 中运行解决方案时,使用 Java SDK 的客户端可能会遇到 Azure SNAT 端口耗尽问题。

解决方案 1

如果正在 Azure VM 上运行,请按照 SNAT 端口耗尽指南操作。

解决方案 2

如果正在 Azure 应用服务上运行,请按照连接错误故障排除指南使用应用服务诊断操作。

解决方法 3

如果在 Azure Functions 上运行,请验证是否遵循 Azure Functions 建议 ,即为所有所涉及的服务(包括 Azure Cosmos DB for NoSQL)维护单一实例或静态客户端。 根据函数应用托管的类型和大小查看服务限制

解决方法 4

如果使用 HTTP 代理,请确保它支持 SDK GatewayConnectionConfig 中配置的连接数。 否则,将遇到连接问题。

创建多个客户端实例

创建多个客户端实例可能会导致连接争用和超时问题。

解决方案 1

按照性能提示操作,并在整个应用程序中使用单个 CosmosClient 实例。

解决方案 2

如果无法在应用程序中使用单一实例 CosmosClient ,建议通过 CosmosClient 中的此 API connectionSharingAcrossClientsEnabled(true) 跨多个 Azure Cosmos DB for NoSQL 客户端使用连接共享。 如果客户端的多个实例与多个帐户交互,则启用此设置可在 直接 模式下进行连接共享。 仅当 Azure Cosmos DB for NoSQL 客户端的实例之间可以进行连接共享时,才启用此模式。 请注意,设置此共享选项时,第一个实例化客户端的连接配置(例如套接字超时配置、空闲超时配置)用于所有其他客户端实例。

热分区键

Azure Cosmos DB for NoSQL 将总体预配吞吐量均匀分布到物理分区。 存在热分区时,物理分区上的一个或多个逻辑分区键会消耗物理分区的所有请求单位/秒 (RU/s)。 同时,将无法使用其他物理分区上的 RU/s。 作为一种症状,消耗的总 RU/s 小于数据库或容器上预配的总 RU/秒,但仍会看到针对热逻辑分区键的请求限制(429 错误)。 使用规范化 RU 使用量指标来查看工作负载是否遇到热分区。

解决方案

选择均匀分配请求量和存储的适当分区键。 了解如何更改分区键

并发度较高

应用程序正在执行高级别的并发,这可能会导致通道上出现争用。

解决方案

使用 SDK 的客户端应用程序应进行纵向或横向扩展。

大型请求或响应

较大的请求或响应可能导致通道上出现队头阻塞并加剧资源争用(甚至在并发度相对较低的情况下)。

解决方案

使用 SDK 的客户端应用程序应进行纵向或横向扩展。

故障率符合 Azure Cosmos DB for NoSQL 服务级别协议 (SLA) 的规定

应用程序应该能够处理暂时性故障,并在必要时重试。 任何 408 异常不会被重试,因为在创建路径时不可能知道服务是否创建了该项。 再次发送同一项进行创建时会导致创建过程中的冲突异常。 用户应用程序业务逻辑可能包含用于处理冲突的自定义逻辑,这会消除现有项的不确定性与来自“创建”重试的冲突。

失败率违反 Azure Cosmos DB for NoSQL 的服务级别协议 (SLA)

请联系 Azure 支持部门