利用可能なリソースを最大限に活用するためのストーム・クローラーのチューニング

Question

私はStorm-Crawlerベースのクローラー専用のノードを持っています。私は20個のデュアルコアCPU、130GbのRAM、10Gb/sのイーサネット接続を自由に使用できます。

トポロジをCollapsingSpout - > URLPartitionerBolt - > FetcherBoltに減らしました。注ぎ口はElasticsearchインデックス（約50Mレコード）から読み取ります。 Elasticsearchは、30 GBのRAMと2つのシャードで構成されています。

私はJVM専用の約50 GBのRAMを持つ1人のワーカーを使用します。 異なる設定（スレッドの合計数、キューごとのスレッド数、最大保留スパウト、バケット数やバケットサイズなどのElasticsearchに関連するもの）を使って再生すると、100 MB /秒の全体的な取り出し速度に達することができます。しかし、神経節のレポートを見ると、それは私に利用可能な帯域幅のわずか10％に相当します。 CPU使用率は約20％であり、RAMは問題ではないことに注意してください。

ボトルネックとなる可能性のあるヒントや、私の利用可能なリソースを十分に活用するためにクローラを調整/調整する方法に関するアドバイスを探しています。

ありがとうございます。

エティエンヌ

Answer 1

あなたはStormCrawlerによって生成されたメトリックを視覚化するKibanaまたはGrafanaを使用することができ、tutorialを参照してください。これにより、パフォーマンスにいくつかの洞察が得られます。また、Storm UIは、コンポーネントレベルのボトルネックを教えてくれます。

ステータスインデックスには2つ以上のシャードを使用でき、対応する数のspoutインスタンスを使用できます。これにより並列性が向上します。

ウェブページのアウトリンクをたどっていますか、またはインデックスのサイズは一定のままですか？ 50MのURLはそれほど多くないので、私はESが非常に忙しいとは思わない。

代わりにAggregationSpoutを試しましたか？ CollapsingSpoutはかなり新しいです+私はそれが各バケットのための別のクエリを発行すると思うので、バケットサイズ1でそれを使用する方がおそらく良いです。

トポロジが表示されていないと、問題がどこにあるかを正確に伝えるのは難しいです。上記の方法で明らかな犯人を見つけよう。

Answer 2

Julien、多くのフィードバックに感謝します。私はSpoutをAggregationSpoutに変更し、あなたのダッシュボードをKibanaにインポートしました。

私はスパウトが必要に応じて放射することができることを確認するためにaggregationSpout-> partitioner-> dummyIndexer-> statusUpdaterを使ってテストを行いました。これは大体0.3Mタプル/分です。私のトポロジ全体を10Mタプル/時をターゲットにしています）。

私はまだフェッチのパフォーマンスに満足していません。非常に変動するアクティブなスレッド数、キュー数、キューサイズという意味では、非常に不安定です。私はスレッドの総数（数千）をあまりにも多く増やした場合、フェッチャーは何とかグリップを失うと感じています。

あなたの経験から、フェッチャインスタンスごとに許可するスレッドの最大数はいくらですか？また、1人の作業者につき1つのインスタンスしか必要としないので、複数のワーカーを起動して同時にフェッチャを実行する際に問題が発生していませんか？