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の概念については別途まとめる
さらなるまとめサイトの必要性について
実際の実装を添付してまとめる