TwitterでつぶやいたStormの雑多な情報まとめ（その４

こんにちは。

#stormjp のタグでStormの雑多な情報まとめその４です。
とりあえず最後までやりきる方針で。

○28.StormのNimbus、UI、Supervisorにはデフォルトでは終了コマンドはない。
　Storm-Installer等一段階ラッピングするか、killで落とすしかない。

▽29.TransactionalBoltは『Spoutから１回に取得したデータ群』の処理が終わった段階で
　finishBatchメソッド呼び出しとなる。
　全Tuple処理完了を意味する模様。

○30.各Taskの多重度とWorkerのスロット数の関係。
　storm.yamlの「supervisor.slots.ports」は『そのマシンでいくつWorkerプロセスを動作させるか』を示す。
　SpoutとBoltの多重度は合算されてStormクラスタ内のWorkerプロセスに等分される。
　例として、WorkerSlotが2のマシンAと、WorkerSlotが3のマシンBがあって、
　その中でSpoutAlphaを多重度10、BoltBetaを多重度20、BoltGammaを多重度5で起動させたとすると、
　各Workerプロセスでは(10+20+5)　/ 5 ＝ 7のSpout/Boltが実行されることとなる。
　マシンAではWorkerプロセスが2プロセス、マシンBではWorkerプロセスが3プロセス起動される。

○31.TopologyContextから取得できるgetThisTaskIdと、getThisTaskIndexの内容は下記。
　getThisTaskId＝Task全体のインデックス
　getThisTaskIndex＝Spout/Boltの内部でのインデックス

○32.declared していないフィールドをグルーピングに使うと実際に動作した際にNullPointerExceptionが発生する。

○Stormが主に使用するのはCPU。
　そのため、CPU使用率をベースに性能を決めればいい。
　但し、これはStormのみの場合。
　当然ながら使用するライブラリ次第では性能状況は変わる。

○33.Spout/BoltのnextTuple/executeメソッド中で例外が発生した場合は検知可能だが、
　何かしらの原因で処理が終了しないケースにおいては検知できない。
　そのため、時間がかかる処理には各々タイムアウトを設定してやる必要がある。

○34.CPUのコア数に対するTaskの目安はコア数×3程度。
　但しIO待ちが多く発生するTaskの場合はもっと多くてもいい。

○35.Storm UIで表示されるタプル数にはサンプリングレートが設定できる。
　例えば、0.05と設定した場合は各Tupleを処理した場合に20分の1の確率でサンプリングされ、
　20個のTupleが処理したと扱われる。

・・・ちなみに、これまであげてきた一部の情報って、
実際のソースコードと併せて見ないとわかりませんよね（汗
なので、これが一段落したらソースコードを追加して見やすいようにしますか・・・
・・・一部Clojure混じりそうな気もしますがｗ

積み残しＡＩ：
メッセージIDとAck/Failの概念については別途まとめる
さらなるまとめサイトの必要性について
実際の実装を添付してまとめる