2010年7月25日日曜日

7/24 雑記

無事(?)論文を提出できました。
忙しい中時間ご指導してくださった先生、実験やモジュールの提供などで協力してくださった皆さん、どうもありがとうございました。
そしてG君はメールを見よう。

明日からはインターンのため千葉の某所に行ってきます。
二週間頑張ろう。

今一番心配なのは、下宿する寮でWiMAXの電波を受信できるかどうかだ!!

2010年7月21日水曜日

7/21 締め切り二日前

締め切り二日前にも関わらず悠長に実験しているのだが、
Hadoopと統合実行するとレイテンシが発散してしまう。
どうやら、Hadoopのジョブの粒度が大きすぎるせいのようだ。

Hadoopで処理するファイルは現在合計178MBのテキストファイルなのだが、
現在は1時間ごとのデータなのでたった24個のファイルしか存在せず、
一つのジョブの粒度が数メガ単位になってしまっている。
これでは思うようにジョブの切り替えが行えないので、
ファイルをsplitコマンドで1万行ごとに区切ることに。

1000行で分割すると、ファイルが多すぎてHadoopの処理が極端に遅くなるため、
今は10000行ずつ分割するパターンで試している。
1000行ずつ分割すると2000個以上のファイルができるが、10000行ずつだと225個のファイルとなる。


この実験に差し掛かる前に、Hadoopへのコマンドがうまく渡せないというエラーがあったが、
SPADEのコードをコメントアウトしていたのを忘れていただけだった。まぬけだ。

2010年7月18日日曜日

7/18 タプル数+レイテンシによる負荷分散


レイテンシの変動も監視する機構を追加することで、
ヘッドノードのみが発散してしまうという現象を食い止めることができた。
そろそろHadoopと同時に実行してみる予定。

2010年7月17日土曜日

7/16 SDAR組み込み


G君のSDARアルゴリズムによる未来予知を組み込んだ動的負荷分散プログラムの実行結果です。
色々改善されていますが、まだヘッドノードの応答性が改善されていません。
これは統合実行環境そのものの負荷なのでどうにかしないといけないでしょう。

2010年7月16日金曜日

7/16 CPU使用率の測定


gxpcとperl、シェルスクリプトを組み合わせることでCPU使用率もうまく測定することができた。
topコマンド単体では0.01秒までの測定を行うことができるため、
topコマンドのバッチモードの結果をうまくパースすることでミリ秒単位の測定が行える。
topコマンドの応答時間は本当に正しいか怪しく、マイクロ秒単位での実時間との関係もわからないため、
コマンドの実行前後でUNIX時間からのマイクロ秒数を設定し、topの測定回数を決めることで、
だいたいの測定時刻を設定することができる。現在は等間隔に実行されていると仮定して出力している。

まずはSDARなしの場合の実行結果を掲載する。
次はSDARを組み合わせた結果をすぐに載せる予定。

topの測定間隔と入力レートの測定間隔は0.05秒、マッチ個数は2000で実行している。

2010年7月14日水曜日

7/14 帰ってきた負荷分散


タプルをもとにした動的負荷分散プログラムの実行結果。
アプリケーションは今までと同じくTwitterの発言からの文字列検出だが、
マッチングの数が2000に増えている。

実行環境は2ソケット8台クラスタで16プロセスを用いて動的負荷分散を行っている。

結果を見たところ、高負荷時には全体的に発散してしまっているが、
その中でも特に2番目のプロセスの発散の度合いが大きい。
これは、1台目の計算ノードでスケジューリングを行っている点が大きいと思われる。
このノードにはデータが集中しないよう配慮する必要があるかもしれない。

また、ノード数が十分なはずなのに発散が起きてしまっているのは、
入力レートが不安定なところに引きずられて、うまくノード数を増やせていないせいだと思われる。
これはG君のSDARを適用するだけでうまく解決できるかもしれない。

2010年7月7日水曜日

7/7 タプル数とレイテンシ


理由は何故かよくわからないが、測定がうまくいった。
検索単語50個における1プロセスでのレイテンシとタプル数の関係を測定。
タプル数は出力側で100から2000まで50ずつとした。
出力は1700前後で飽和しているが、1500前後でレイテンシが発散しているため問題ない。

1500前後における詳細な挙動を観測し、これを閾値として今後の実験を行う予定。

7/7 七夕

アルゴリズムの実験を行うために、アプリケーションの負荷を測定中。
しかし、計算負荷が軽すぎるのでなかなかうまくいかない。
入力データレートによるレイテンシの差異より、揺らぎによる差異のほうが大きくなってしまう。
マッチングを取る数を、50にまで増やしたものの、その傾向は変わらない。

2010年7月5日月曜日

7/6 UDOPによる文字列探索


U君が作ってくれたTwitterの汎用UDOPを用いて文字列探索プログラムを作成した。
これのレイテンシの評価を行ったので掲載するが、あまりいい結果にはならなかった。

負荷が増大してもレイテンシの値が小さい部分がある。
これは入力レートがうまく増大していない可能性があるので、
今度はレイテンシの値にも実測値を用いて計測を行おうと思う。