タイムアウト制限が発生する前にソフトウェア開発キット (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% ほどである必要があります。 最大 (平均ではない) CPU 使用率を監視する間隔として、 10 秒を使用します。 CPU スパイクは、1 つのクエリに対して複数の接続を実行する可能性があるクロスパーティション クエリでより一般的です。
解決策
SDK を使用するクライアント アプリケーションをスケールアップまたはスケールアウトする必要があります。
接続の調整
接続の調整は、ホスト コンピューターの接続制限または Azure ソース ネットワーク アドレス変換 (SNAT) ポートの枯渇が原因で発生する可能性があります。
ホスト コンピューターの接続制限
Red Hat などの一部の Linux システムでは、開いているファイルの合計数に上限があります。 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 App Service で実行している場合は、 接続エラーのトラブルシューティング ガイド に従い、 App Service 診断を使用します。
解決策 3
Azure Functions で実行している場合は、関連するすべてのサービス (Azure Cosmos DB for NoSQL を含む) のシングルトンまたは静的クライアントを維持する Azure Functions の推奨事項 に従っているかどうかを確認します。 Function App ホスティングの種類とサイズに基づいて 、サービスの制限 を確認します。
解決策 4
HTTP プロキシを使用する場合は、SDK GatewayConnectionConfigで構成されている接続の数をサポートできることを確認します。 そうしないと、接続の問題が発生します。
複数のクライアント インスタンスを作成する
複数のクライアント インスタンスを作成すると、接続の競合やタイムアウトの問題が発生する可能性があります。
解決策 1
パフォーマンスの ヒントに従い、アプリケーション全体で 1 つの CosmosClient インスタンスを使用します。
解決策 2
シングルトン CosmosClient をアプリケーションで使用できない場合は、CosmosClient のこの API connectionSharingAcrossClientsEnabled(true) を使用して、複数の Azure Cosmos DB for NoSQL クライアント間で接続共有を使用することをお勧めします。
クライアントの複数のインスタンスが複数のアカウントと対話している場合、この設定を有効にすると 、ダイレクト モードでの接続の共有が可能になります。 このモードは、Azure Cosmos DB for NoSQL クライアントのインスタンス間で接続共有が可能な場合にのみ有効になります。 この共有オプションを設定する場合、最初にインスタンス化されたクライアントの接続構成 (ソケット タイムアウト構成、アイドル タイムアウト構成など) が、他のすべてのクライアント インスタンスに使用されることに注意してください。
ホット パーティション キー
Azure Cosmos DB for NoSQL は、プロビジョニングされた全体的なスループットを物理パーティション間で均等に分散します。 ホット パーティションがある場合、物理パーティション上の 1 つ以上の論理パーティション キーが、すべての物理パーティションの 1 秒あたりの要求ユニット数 (RU/秒) を消費します。 同時に、他の物理パーティションの RU/秒は使用されません。 症状として、使用された RU/s の合計がデータベースまたはコンテナでプロビジョニングされた全体の RU/s よりも少なくなっていますが、ホットな論理パーティションキーに対する要求でスロットリング (429 エラー) が依然として発生します。 正規化された RU 消費量メトリックを使用して、ワークロードでホット パーティションが発生しているかどうかを確認します。
解決策
要求ボリュームとストレージを均等に分散する適切なパーティション キーを選択します。 パーティション キーを変更する方法について説明します。
高度なコンカレンシー
アプリケーションが高レベルのコンカレンシーを実行しているため、チャネルで競合が発生する可能性があります。
解決策
SDK を使用するクライアント アプリケーションをスケールアップまたはスケールアウトする必要があります。
大きな要求または応答
要求または応答が大きいと、比較的低いコンカレンシーであっても、チャネルで行頭がブロックされ、競合が悪化する可能性があります。
解決策
SDK を使用するクライアント アプリケーションをスケールアップまたはスケールアウトする必要があります。
障害率が Azure Cosmos DB for NoSQL サービス レベル アグリーメント (SLA) 内にある
アプリケーションは、一時的な障害を処理し、必要に応じて再試行できる必要があります。 作成パスではサービスがアイテムを作成したかどうかを知ることができないため、408 個の例外は再試行されません。 作成のために同じ項目を再度送信すると、競合例外が発生します。 ユーザー アプリケーションのビジネス ロジックには、競合を処理するカスタム ロジックが含まれている可能性があります。これは、既存の項目のあいまいさと、作成の再試行からの競合から切り離されます。
エラー率が Azure Cosmos DB for NoSQL SLA に違反する
Azure サポートにお問い合わせください。
関連コンテンツ
- Azure Cosmos DB for NoSQL Java v4 SDK を使用する場合の問題を診断してトラブルシューティングします。
- Java v4 のパフォーマンス ガイドラインについて説明します。