診斷和疑難排解 Azure Cosmos DB Java v4 SDK 要求逾時例外狀況
適用於：
NoSQL
如果 SDK 在發生逾時限制之前無法完成要求，就會發生 HTTP 408 錯誤。
疑難排解步驟
下列清單包含要求逾時例外狀況的已知原因和解決方案。
端對端逾時原則
在某些情況下，即使已實作下列提及的所有先佔式解決方案，還是會發生 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);
現有問題
如果您遇到要求卡住正常時間或更常逾時的情形，請將 Java v4 SDK 升級至最新版本。 注意：強烈建議使用 4.18.0 及以上的版本。 如需更多詳細資料，請參閱 Java v4 SDK 版本資訊。
高 CPU 使用率
高 CPU 使用率是最常見的情況。 為了達到最佳延遲，CPU 使用率應保持在約 40% 之間。 請使用 10 秒的間隔來監視最大 (非平均) CPU 使用率。 跨分割查詢最容易遇到 CPU 尖峰問題，因為其可能會為單一查詢進行多個連線。
解決方案：
應該擴大或擴增使用 SDK 的用戶端應用程式。
連線節流
連線節流的發生原因可能是因為主機電腦上的連線限制或 Azure SNAT (PAT) 連接埠耗盡。
主機電腦的連線限制
某些 Linux 系統 (例如 Red Hat) 具有開啟檔案的總數上限。 Linux 中的通訊端會實作為檔案，因此，這個數字也會限制連線總數。 執行下列命令。
ulimit -a
解決方案：
允許的開啟檔案數目上限 (識別為 "nofile") 必須至少是 10,000 或以上。 如需詳細資訊，請參閱 Azure Cosmos DB Java SDK v4 效能秘訣。
通訊端或連接埠可用性可能很低
在 Azure 中執行時，使用 Java SDK 的用戶端可能會達到 Azure SNAT (PAT) 連接埠耗盡。
解決方案 1：
如果您是在 Azure VM 上執行，請遵循 SNAT 連接埠耗盡指南。
解決方案 2：
如果您是在 Azure App Service 上執行，請遵循連線錯誤疑難排解指南和使用 App Service 診斷。
解決方案 3：
如果您是在 Azure Functions 上執行，請驗證您有遵循針對所有相關服務 (包含 Azure Cosmos DB) 維護 singleton 或靜態用戶端提出的 Azure Functions 建議。 請根據您函數應用程式裝載的類型與大小，查看服務限制。
解決方案 4：
如果您使用 HTTP Proxy，請確定它可以支援在 SDK GatewayConnectionConfig 中設定的連線數目。 否則就會遇到連線問題。
建立多個用戶端執行個體
建立多個用戶端執行個體可能會導致連線競爭或逾時問題。
解決方案 1：
遵循效能秘訣，並在整個應用程式間使用單一 CosmosClient 執行個體。
解決方案 2：
如果應用程式中不能有 singleton CosmosClient，則我們建議在 CosmosClient 中透過此 API connectionSharingAcrossClientsEnabled(true) 跨多個 Azure Cosmos DB 用戶端使用連線共用。
當您在與多個 Azure Cosmos DB 帳戶互動之同一個 JVM 中有多個 Azure Cosmos DB 用戶端執行個體時，如果 Azure Cosmos DB 用戶端之間的直接模式連線共用可行，則啟用此項目可允許以直接模式進行連線共用。 請注意，設定此選項時，第一個具現化之用戶端的連線設定 (例如通訊端逾時設定、閒置逾時設定) 將用作其他用戶端執行個體的設定。
經常性分割區索引鍵
Azure Cosmos DB 會將整體佈建的輸送量平均散發到實體分割區。 當有經常性分割區時，實體分割區上的一或多個邏輯分割區索引鍵會取用實體分割區的所有每秒要求單位 (RU/秒)。 同時，將不會使用其他實體分割區上的 RU/秒。 徵兆是取用的總 RU/秒將小於資料庫或容器的整體佈建 RU/秒，但您仍會在對經常性邏輯分割區索引鍵的要求上看到節流 (429 秒)。 請使用標準化 RU 使用量計量來查看工作負載是否遇到經常性分割區。
解決方案：
選擇可平均散發要求磁碟區和儲存體的良好分割區索引鍵。 了解如何變更分割區索引鍵。
高度並行
應用程式正在進行高度並行，這可能會導致通道上發生競爭。
解決方案：
應該擴大或擴增使用 SDK 的用戶端應用程式。
大型要求或回應
大型要求或回應可能會導致通道上發生隊頭阻塞並加劇競爭問題，即使有相對低度的並行也是如此。
解決方案：
應該擴大或擴增使用 SDK 的用戶端應用程式。
失敗率在 Azure Cosmos DB SLA 內
應用程式應該能夠處理暫時性失敗，並在必要時重試。 因為在建立路徑尚無法得知服務是否建立了項目，所以不會重試任何 408 例外狀況。 重新傳送相同的項目進行建立，將導致衝突例外狀況。 使用者應用程式商務邏輯可能有自訂邏輯能處理衝突，這能打斷現有項目與建立重試所產生之衝突之間的混淆。
失敗率違反 Azure Cosmos DB SLA
請連絡 Azure 支援。