2016-11-23 3 views
1

私は、3つのマスタノードと18のデータノードを持つES 2.4.1クラスタを使用して、毎日新しいインデックスを作成してログデータを収集します。 1日のインデックスサイズは約2TBになります。 7日以上経過したインデックスは削除されます。クラスタで実行される検索はごくわずかなので、主な目的はインデックス処理のスループットを向上させることです。Elasticsearch:Lucene MergeスレッドのCPU使用率が高い

私は次の言おうとしています何の別の症状です以下の例外の多くを参照してください。

EsRejectedExecutionException[rejected execution of [email protected] on EsThreadPoolExecutor[bulk, queue capacity = 50, [email protected]9ef44f[Running, pool size = 8, active threads = 8, queued tasks = 50, completed tasks = 68888704]]];]]; 

クラスタ内のノードが常にCPUにペッグされています。インデックス更新間隔を30秒に増やしましたが、それはほとんど効果がありませんでした。ホットスレッドをチェックすると、100%CPUを使用するノードごとに複数の "Lucene Merge Thread"が表示されます。私はまた、セグメント数がシャードごとに常に約1000であることに気付きました。次は、セグメントのstatの例である:

"_2zo5": { 
    "generation": 139541, 
    "num_docs": 5206661, 
    "deleted_docs": 123023, 
    "size_in_bytes": 5423948035, 
    "memory_in_bytes": 7393758, 
    "committed": true, 
    "search": true, 
    "version": "5.5.2", 
    "compound": false 
} 

非常に高い「世代」の数は、私を心配し、私は、セグメント作成を最適化し、ノード上のCPU負荷を軽減するためにマージしたいと思います。インデックス作成およびクラスタ構成に関する

詳細:

  • 各ノードは8つのCPUコアとi2.2xl AWSインスタンスであり、1.6T SSDは
  • ドキュメントバルクサイズ1000年で6つのクライアントスレッドによって常にインデックス付けされているドライブ
  • 各インデックスが1つのレプリカ
  • 30のシャードを有するこれ1000のドキュメント
  • /_cat/thread_poolのバッチ当たり約25秒を要する?H =バルク* & vは番目を示します同じようにノード間でbulk.completed広がっているで
  • バッファサイズおよびトランザクション持続性をデフォルトのままにしている
  • インデックス
  • _allは無効になりますが、動的なマッピングは、マージ・スレッドの数は、デフォルトでこれがなければならない残され
  • を有効にしています

どうすればいいですか?

ありがとうございます!

+0

を支援します?ESRejectedExecutionExceptionsを出力します。バルクキューに関連する値は、通常、バルク要求でクラスタに過負荷がかかることを意味します。 – ryanlutgen

+0

いくつのレプリカがありますか?どの時点で書き込み可能なシャードはいくつありますか?あなたの一括サイズは何ですか?平均的なバルクリクエストの量はどれくらいですか?各バルクインサートは平均してどれくらいの時間(ミリ秒)かかりますか?/_cat/threadpool?h = bulk *&vを見ると、バルク要求はクラスタの周りに広がっているのでしょうか、あるいはいくつかの選択ノードを叩いていますか?インデックスのバッファサイズを増やしましたか?あなたはtranslog耐久性を非同期に設定することを見ましたか? _allを無効にしましたか?動的マッピングを許可していますか? – evanv

+0

また、SSDまたはスピンドルを使用していますか?いくつのマージスレッドがありますか? – evanv

答えて

1

ここでインデックスのスループットを向上させるために、私は、クラスタに行われた最適化は、次のとおりです。インデックス要求が頻繁に

  • 増加ディスク透かしをキューをオーバーロードされたため

    • は、デフォルトの設定ので、500にthreadpool.bulk.queue_sizeを増加私たちが使っていた大規模なSSDにはあまりにも積極的でした。私は "cluster.routing.allocation.disk.watermark.low": "100gb"と "cluster.routing.allocation.disk.watermark"を設定します。ハイ ":『10ギガバイト』
    • は、ESが50ギガバイトの下に保つシャードの大きさを目標に175に彼らの破片主要な破片の
    • 増加数を管理するために使用するリソースを解放するために使用されていないインデックスを削除し、プロセッサ
    • あたり約シャードを持っていますドキュメントのサイズが(KB単位からMB単位に)劇的に変化インデックスを作成するので、私たちのために非常にうまく動作するように見えた10メガバイトに
    • 設定クライアントインデックスのバッチサイズ、

    希望はこれがどのくらいの頻度は、ドキュメントのインデックスを作成している他の人

  • 0

    私は同様のワークロードを実行しましたが、時間軸インデックスを実行し、古いインデックスで最適化を実行して、セグメントをチェックしておくことをお勧めします。