弾性検索バルクの更新が極端に遅い

Question

私はelasticsearchにインデックスごとに大量の1日のデータ〜160GBのインデックスを作成しています。私は私の更新操作は、毎秒16000本のラインで起こっ始める私はフォーマットの

id1,data1 
id1,data2 
id2,data1 
id2,data2 
id2,data3 
. 
. 
. 

ある少量のデータ（〜16ギガバイト）と指数のほぼすべてのドキュメントを更新する必要があり、この場合に直面していますし、 5分以上経過すると、1秒間に1000本のラインになり、それ以降は上がらない。このデータの16ギガバイトのための更新プロセスは、それが起こるために160ギガバイトの私の全体のインデックス作成にかかる時間よりも、現在長い

output 
{ 
    elasticsearch { 
     action => "update" 
     doc_as_upsert => true 
     hosts => ["host1","host2","host3","host4"] 
     index => "logstash-2017-08-1" 
     document_id => "%{uniqueid}" 
     document_type => "daily" 
     retry_on_conflict => 2 
     flush_size => 1000 
    } 

} 

私が持っている最適化を次のように更新操作のための私のconfファイルは、現在見え

ここhttps://www.elastic.co/guide/en/elasticsearch/guide/current/indexing-performance.htmlの提案に基づいて、私のクラスタ内のインデックスをスピードアップするために行われている

1. 設定「indices.store.throttle.type」：「なし」
2. インデックス「REFRESH_INTERVAL」：「-1」

d2.8xlarge EC2インスタンスの4つのインスタンスでクラスタを実行しています。私は各ノードに30GBのヒープを割り当てました。 更新が起きている間はほとんどCPUが使用されておらず、負荷も非常に少なくなっています。

すべてにかかわらず、更新は非常に遅いです。この問題を引き起こしていることが分かりません。スレッドプールのデータを見ると、バルク操作で動作するスレッドの数は常に高くなっています。

この問題に関するすべてのヘルプはここにしようとするルールアウトのカップルがあり、事前

Answer 1

で

おかげで本当に役立つだろう。 RAMの244ギガバイトで

メモリプレッシャー

、これはひどくそうではありませんが、あなたはまだそれをチェックアウトすることができます。ご使用のプラットフォーム用のJDKでjstatコマンドを見つけてください。ただし、その一部にはビジュアルツールがあります。 Logstash JVMとElasticSearch JVMの両方をチェックしたいとします。

jstat -gcutil -h7 {PID of JVM} 2s 

これは、動作するように、そのJVMのさまざまなメモリプール、ガベージコレクションカウント、およびGCタイミングの読み取り値を提供します。 2秒ごとに更新され、ヘッダーは7行ごとに印刷されます。 FCTに過度の時間を費やすことは、あなたがHEAPのために配分されていないという兆候です。

I/O圧力

d2.8xlargeは、高密度ストレージインスタンスであり、高度にランダムな、小ブロックワークロードに最適ではないかもしれません。あなたがUnixプラットフォームの場合、topはあなたがIOWAIT状態でどれくらいの時間を費やしているかを伝えます。それが高い場合、あなたのストレージはあなたがそれを送信しているワークロードまでではありません。

この場合、インスタンスローカルのものではなく、プロビジョニングされたIOP EBSインスタンスを検討するとよいでしょう。または、あなたのものが合う場合は、代わりに高I/Oインスタンスのi3ファミリのインスタンスを考えてみてください。

Logstashバージョン

あなたが使用しているLogstashのバージョンを言っていません。 StackOverflowであれば、5.2を使用している可能性が高いです。そうであれば、これはルールアウトではありません。

しかし、2.xシリーズで何かを使用している場合は、最初に-wフラグを1に設定して作業することをおすすめします。はい、これはシングルスレッドです。しかし、ElasticSearchの出力には、5.xシリーズで主に修正されている2.xシリーズのいくつかの並行性の問題があります。

Answer 2

elasticsearchバージョン6.0では、awsでの遅いアップデートとまったく同じ問題があり、原因は低速のI/Oでした。同じデータがローカルのテストスタックで完全に正常に更新されていましたが、ec2スタックのクラウドでは、最初の数回の高速挿入が数分間続くだけですべてが死にました。

ローカルテストスタックは、メモリとCPUの面で低スペックのサーバでしたが、SSDを含んでいました。

s3スタックは、デフォルトのgp2 300 IOPSのEBSボリュームでした。

ボリュームをio1で3000 IOPSに変換すると問題が解決され、すべてが元に戻りました。