ES バッチリクエスト `es_rejected_execution_Exception`

php エディター Apple は、ES バッチリクエストの一般的な問題「es_rejected_execution_Exception」を紹介します。 Elasticsearch を使用してバッチ リクエストを行うと、この例外が発生することがあります。この例外は通常、同時リクエストの数が Elasticsearch サーバーの処理能力を超え、リクエストの実行が拒否されたことを示します。この記事では、この例外の原因を分析し、問題をスムーズに処理するための解決策を提供します。

質問の内容

約 500 万個のエントリのスライスがあります (わかりやすくするために、各エントリはバイト スライスであると仮定します。これは、getIndexerItem 関数インデクサー項目を使用してマップされます) ) を 200 回の碁ルーチンに均等に分割しました。次に、各 go ルーチンは push 関数を呼び出し、スライス長は 5M/200 です。

Refresh:wait_for についての私の理解では、elastic に対してリクエストが行われるときは常に、そのリクエストによって行われた変更が検索に表示される場合にのみ完了します (IMO では、バルク リクエストではなくなりました)この特定のリクエストのキュー))。では、なぜこのエラーが発生するのでしょうか?

すべてのエントリは同じインデックス ankit-test に入ります。

他のプロセスがいかなる形でもインデックスと対話しないと仮定します。

解決策

複数の ES ドキュメントを使用して、上記の問題の解決策を見つけることができました。以下の回答は私の理解に基づいています。改善/修正できる点を見つけた場合は、コメントを残してください。

これはリクエストのライフサイクルです:

1. golang es クライアントは、複数のリクエストを 1 つにマージし、単一のバッチ リクエストでサーバーに送信します。単一のバッチ リクエストには、複数のインデックスおよびシャード宛てのドキュメントを含めることができます。
2. バッチ リクエストがクラスター内のノード (コーディネーション ノードとも呼ばれます) に到着すると、そのリクエストは全体としてバッチ キューに配置され、バッチ スレッド プール内のスレッドによって処理されます。
3. 調整ノードは、ドキュメントのルーティング先となるシャードに応じてバッチ リクエストを分割します。 各バッチ サブリクエストは、対応するプライマリ シャードを保持するデータ ノードに転送されます。バルク サブリクエストはノードのバルク キューに入れられます。キューに空きスペースがない場合、バルク サブリクエストが拒否されたことが調整ノードに通知されます。
4. すべてのサブリクエストが完了するか拒否されると、応答が作成され、クライアントに返されます。バッチリクエスト内の一部のドキュメントのみが拒否された可能性があり、おそらくその可能性があります。

私の問題は、refresh = false (デフォルト) を使用してリクエストを送信することです。代わりに、 refresh = wait_for を使用してください。なぜ？リフレッシュには 3 つのモードがあります:

1. false: 更新関連の操作を実行しません。このリクエストによって行われた変更は、リクエストが返された後のある時点で表示されます。要求は、応答を受信するまでに完了する必要はありません。リクエストはまだノードのキューにある可能性があります。
2. true: 操作が発生した直後に、関連するプライマリ シャードとレプリカ シャードを更新します。応答を送り返す前に、リクエストが完了していることを確認してください。リクエストはノードキューから削除されました。
3. wait_for: 応答する前に、リクエストによる変更が更新によって表示されるまで待ちます。 true とは異なり、これは即時更新を強制するのではなく、更新が行われるのを待ちます。 refresh = true よりも (サーバー負荷の点で) 安価ですが、応答を送り返す前にリクエストが完了していることが保証されます。リクエストはノードキューから削除されました。

すべてのデータが同じノードにリダイレクトされ、refresh = false であるため、既存のリクエストがキューからクリアされる前に応答が返され、オーバーフローが発生しました。

以上がES バッチリクエスト `es_rejected_execution_Exception`の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。