夢とガラクタの集積場

落ちこぼれ三流エンジニアである管理人の夢想=『夢』と、潰えた夢=『ガラクタ』の集積場です。

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

こんにちは。

#stormjp のタグでStormの雑多な情報まとめその9です。
とりあえず、2013/02までの内容はこの回で収まりそうなペースです。

91.DisruptorQueueから情報を取得するのはシングルスレッドとなる。
 そのため、Worker数を増やすことでボトルネックが解消するケースもある。

○92.Workerプロセスごとに異なるポートを確保したい場合の技術解は、
 %ID%の値を使えばおそらく可能。

93.Spout/BoltのTuple処理メソッドが長引いてもHeartBeatの制限には引っかからない。
 なので、Tuple処理ライン側で何らかの原因でフリーズしても、プロセスの再起動はされない。

94.DRPCClientはスレッドごとに生成する必要がある。

95.Anchorは複数の子Tupleを持つことが可能ですが、子Tuple側も複数の親Anchorを持つことが可能。

96. MessageId自体は同じものを複数回emitしてもStorm側では別ID割り振るから問題ない。
 ただ、実際のところはack/fail呼ばれたときに区別できないという問題は残る。

○97.StormからのZookeeperへの負荷はそれなりに高い。
 理由としては、HeartBeatをZooKeeperを用いて行っているための可能性が大きい。
 ZooKeeperは何かしらのアクセスがあった際にファイルIOが伴うため、
 HeartBeatのように頻度が高いアクセスを行うとその都度ファイルIO発生となってしまう。

○98.Storm0.8.1ではZeroMQのブロッキングでWorkerが停止して再起動される事象が発生しえる。
 この事象に限らず、Stormはバージョンが進むと問題が解消していくため、極力その時点の最新バージョンを用いるのが望ましい。

99.シリアライズがきちんと可能かの確認を行う場合、複数のWorkerプロセスで実施する必要がある。
 「シリアライズが可能か?」についてはLocal ModeであってもWorkerのプロセス数を複数に設定しておけば確認可能。

100.Stormを使用する際にはFireWall.SELinuxはきること。
 ふつうはあまり使用しないポートも使用するため。

101.「存在しないStream」にメッセージを流しこんだ場合、エラーも発生せずメッセージは消滅する。
 動的に流し込むStreamの名称を決めている場合は気をつけること。

これでようやく2013/02までの呟きの結果がまとめ終わりました!
101ということでいまいちキリが悪いですが、とりあえず今回のシリーズは完了。
積み残しAIについては・・・ま、また今度にでもw

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