诊断 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 系统（如 Red Hat）对打开的文件总数有上限。 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/秒）。 同时，其他物理分区上的 RU/s 将不可用。 作为一种症状，消耗的总 RU/s 小于数据库或容器上预留的总 RU/s，但仍然会观察到针对热点逻辑分区键的请求限流（429 错误）。 使用 规范化 RU 消耗指标 查看工作负荷是否遇到热分区。

解决方案

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

高度并发

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

解决方案

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

大型请求或响应

大型请求或响应可能导致通道上的行头阻塞并加剧争用，即使并发程度相对较低。

解决方案

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

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

应用程序应能够处理暂时性故障，并在必要时重试。 不会重试任何 408 异常，因为在创建路径上，无法知道服务是否创建了项。 再次发送同一项进行创建会导致冲突异常。 用户应用程序业务逻辑可能有自定义逻辑来处理冲突，这会从现有项的不明确性与创建重试中的冲突中断。

失败率违反了 Azure Cosmos DB for NoSQL 服务级别协议

请联系 Azure 支持部门。

相关内容

• 使用 Azure Cosmos DB for NoSQL Java v4 SDK 时诊断并解决问题。
• 了解 Java v4 的性能准则。