遅いelasticsearch応答の原因を見つける

Question

私は、SQLクエリを避けるために、検索だけでなく製品データ（/ index/type/{id}）を取得するために、かなりの時間eCommerceサイトにelasticsearchを使用しています。

通常、これは本当にうまく動作し、ほとんどのリクエストは1ms〜3msの間に応答されます。しかし、/ index/type/{id}のようなGETリクエストの場合、実際の検索は行われず、通常は1-2msかかるので、100ms〜250msかかる要求もあります。サーバーがRAMの多くを持っているので、何かが間違っていなければならないと思われます。&速い6コアCPU、データは非常に高速なSSDに保存され、150,000エントリー（Elasticsearchでは約300MB）、負荷はほとんどありません。 Elasticsearchには5GBのRAMがあり、Luceneがすべてのエントリを常にキャッシュするのに十分なスペアRAMがあります。要求は、専用のスイッチを使用してローカルネットワークを介して行われます。インデックスには1つの断片しかなく、私はElasticsearch 2.3を実行しています。

私はPHPでリクエストしています。私はすでにElginsearchのリバースプロキシとしてNginxを使ってみましたが、これは何も解決しませんでした。

：遅い要求は、（要求の総数に対して）約1％の時間で発生します。私はまた、Elasticsearchの/ index/type/{id}にPHPで1000件のリクエストを行うだけで再現できます。/ index/type/55のような同じIDを使用していても常に1％は本当に遅くなりますIDが存在する）。これは、「キャッシュエフェクト」がないことを意味します。最初のリクエストElasticsearchの後に、データが「準備完了」である必要がありますが、同じIDを何度も要求しても、遅いリクエストの数は同じです。

EDIT2：私はマーベル& Kibanaと私のノードの統計を見ていない、と何もスローダウンを示していない：JVMのヒープメモリの20から40パーセントの間で使用され、0.1msと0.5の間にほとんどのレイテンシ（ミズ）。十分なリソースがあることを確認して、遅いリクエストの原因に対する相関やヒントがないことを確認します。多くのテストの後

：これらは今、私の明確なテスト結果です

：

• 大きなElasticsearchからの応答を、より多くの可能性が遅いリクエストが起きようとしています。小さなレスポンスの多くは、1つの大きなレスポンスに比べて例外的に遅くならない可能性が非常に高くなります。
• 簡単なGETリクエストでBombarding Elasticsearchを使用すると、より多くのリクエストを並行して実行すると応答が遅くなる可能性が低くなります。
• Elasticsearchは、1つのキーワードに対して簡単な検索を繰り返して使用すると、アプリケーションが受信するまでに応答が200msかかる場合でも、応答に「2-3ms」かかることがわかります。しかし、ここでも：応答が大きければ、応答が遅い可能性が高くなります。要求のループを実行すると1KBの応答が遅くなることはありません。2.5KBはごくわずかな遅さ（30ms）ですが、10KBの応答は常に200msまでの遅い要求の1％まであります。

私は、特にElasticsearchが遅いと思っている場合には、ネットワークの「問題」があると考えました。しかし、私の設定はとても標準的なので（Debian Jessie）、それは奇妙な根本原因になるでしょう。また、キープアライブ接続とTCP_NODELAYは、この問題を改善するために何もしません。

根本的な原因を見つける方法を知っていて、何が起こっている可能性がありますか？

Answer 1

私は最終的に、測定可能な遅い応答の理由を見つけました。それは、ネットワークドライバか、ネットワークカード上のハードウェアの実装でした。

ノード自体からテストを実行すると、遅い応答が消えてしまいました。古いサーバー（わずか2歳の新しいサーバーと比較して8歳の古いサーバー）は、テストを実行しても応答が遅くなく、応答しているESサーバではなく、要求しているサーバが故障していることが示されましたが、ネットワーク自体は問題ありませんでした。

私はTCP /ネットワーク設定のウサギの穴に行って、ethtoolを見つけました。これはネットワーク設定を表示し、それを変更することもできます。私は、ネットワーク運用の多くは、ネットワークカードにオフロードされ、「オフロード」と呼ばれるものは、（特にセグメントにリクエストとレスポンスを分割）があった学び、すべてのオフロードを無効にするには、次のコマンドを試してみました：

ethtool -K eth1 tx off rx off sg off tso off ufo off gso off gro off lro off rxvlan off txvlan off rxhash off 

その後、ESからのリクエスト1000件の同一検索は予想通り速かったですが、遅いリクエストはもうありませんでした。私のネットワークカード（e1000eドライバを実行するSuperMicro X9SRL-F上のインテル®82574LデュアルポートGbE LAN）は、ハードウェア内で応答を遅くしたり、バックを保持したりするものがあります。古いサーバではtg3ドライバが実行されています（ethtoolによるとオフロードが有効になっていますが、これらの遅延応答は発生しません）。オフロードを無効にすることはCPU負荷に顕著な影響を与えませんでした。おそらく現代のCPUで予想されます。

新しい設定では、Elasticsearchの応答が遅いために低速ページの数を0.07％に減らすことができました。その前の約1％でした。また、NginxをElasticsearchのリバースプロキシとして使用すると、応答速度が遅くなっていました。通常、150,000ごとに約3〜5回の応答が50ms以上でした。 Nginxなしでは、Elasticsearchに直接問い合わせるだけで、私は大規模でも、もはや遅い要求をもう再生できません。

UPDATE 2017分の11

Debianのストレッチに更新し、カーネル4.9でサーバーを実行した後、残りのすべての「遅い要求が」消えました。だから、この問題は古いLinuxカーネルに根ざしているようだ。