私たちのESはかなり遅いですが、それはまだ最適化されていませんが、this linkによれば、Elasticからのリクエスト拒否は、バルクのサイズ。エラスティックストレスで一貫性のない結果が出る
ブロッキングバルク（同時に送信された個々のリクエストのリストで、まだMSearchを使用していない）のサイズは、以前のバルクで拒否されたリクエストの数によって異なります。新しいバルクを開始する前に、現在のバルクが終了するのを待ちます。明らかに、すべての拒否された要求は、（クエリを構成するために必要なデータの形式で）要求キューに再投入されます。たとえば、Elasticが500件の同時リクエストを処理でき、600件を送信した場合、その一部は拒否され、新しいサイズは480（20％オフ）に縮小されます。
私たちが知ったことは、ESは以前に拒否された要求に対して異なる結果を返すことでした。たとえば、期待される結果のようなものが返されるかもしれませんが、オフセットは2です。アドレスには1つの結果しか持たないが、このバグのために何も持たないという結果もありません。
バルクサイズがESが処理できるしきい値より小さい場合は、すべてが期待どおりに進み、予期した結果が得られます。
ライブラリの（elastic4s）問題のように見えません。
弾性構成： 2 CPU、32ギガバイトのRAM 16 GBのヒープ：5つの破片ノード毎の各
有する2つのノード。それ以外のものはすべてデフォルトです
インターネット上に情報が見つかりませんでした。誰でもこの問題がありますか？解決策は何でしたか？我々はこれまでに試した何
：バルク間
Thread.sleepリンクは上記のとおり。クエリレベルでキャッシュを削除すると同時にインデックスから削除します。
別の（遅い）ハードウェアで同じインデックスを試しています。
競合状態ではないことを確認しました。
更新：
何the queryのような。
検索のためのスレッド・プール： "search" : { "type" : "fixed", "min" : 4, "max" : 4, "queue_size" : 1000 },
第二UPDATE：
我々はまた、私たちのクエリに優先度を設定してみました（それは破片に問題があったことを考える）：.preference(Preference.Primary)なし陽性の結果と（彼らもなかったです前よりもランダム）。この設定で2回連続して実行すると、「ランダム」な結果が異なるため、一貫性がありません。