6/30 PuTTYの色変更

PuTTYでコンソールを表示すると、青色が見難くて悲惨なことになる。
これを解消する手段として、bashの色分け設定を変更するなどといった方法が存在する。
しかし、これではsuのときやvimでの表示などではあの忌々しい青色が復活してしまう。

これを根源的に解決する手法として、PuTTYの設定そのものを変更するという手段がある。
やり方は簡単で、PuTTYの左側のメニューから「ウィンドウ」の「色」を選び、
「変更する色を選択」から「ANSI Blue」を選び、値を赤：0、緑：0、青：187から、
赤：85、緑：85、青：187などといった適当な値に変えればよい。
この色は、bashで色を薄くした際の表示と同じなので整合性が取れると思われる。

PuTTY常用者なら試す価値あり！

6/25 拡張したHadoopのJarファイル

Eclipseで拡張したHadoopをjarファイルに戻す方法。

今回はTaskTracker.java周辺を拡張したので、
そこから生成されるファイルを更新すればよい。

大本のファイルはhadoop-VERSION-core.jarに入っているので、
これをどこかへ一度展開する。

$ jar xvf hadoop-VERSION-core.jar

解凍したファイル中のorg/apache/hadoop/mapredに、
JobTrackerと周辺のファイルからできた.classが収まっている。
これを、Eclipseのworkspaseのbin以下の同じディレクトリからコピーする。

$ cp SRC/JobTracker* DST/

その後、何事もなかったようにjarで圧縮しなおして、
HadoopのHOMEディレクトリに返せばOK。

$ jar cvf hadoop-VERSION-core.jar SRC_DIR/*
$ cp hadoop-VERSION-core.jar HADOOP_HOME/

以上。

6/23 データディレクトリ

/nfs/data0、/nfs/data1の運用を開始。
それぞれ2TB。

6/20 ICDE勉強会

ICDEによる過密スケジュールがようやく終わった。
研究が進んでいないのでがんばりたいが、他の課題も控えているため難しい。

個人的にはGenerating Code for Holistic Query Evaluationと、
例のFPGAの研究が非常に面白かった。
L2を意識してクエリを動的にコーディングしたり、
オーダーを悪化させてもハードウェアパイプラインに適した処理を
実装したほうが最終的な計算時間を短縮できたりと、
やはりハードウェアを意識した研究は楽しいと思う。

あとは、中国勢の論文が多いことにも驚かされた。
数は力なのだろうか。

6/11 DSMS + Hadoop

講義や論文提出などに終われ、自分の研究のアップデートが遅れてしまった。
近傍の予定
・動的負荷分散アルゴリズムの出力を用いてノード数を決定するモジュールの作成
・拡張したHadoopのJar化
・DSMSによる文字列マッチングオペレータの作成

一つ一つのジョブは軽いので、早く終わらせなければ。

6/7 DE研究会

ようやく論文を投稿できました。
協力してくださった皆さん、ありがとうございます。

6/4 HDDのテスト

研究室に新しいDiskが二枚やってきた。
WD20ARS 2.0TB 5400RPM 32MB

このディスクはセクタが4kBなので以下のようにFormatする必要がある。
トラックあたりのセクタ数が8の倍数になるので書き込みが高速化する。
fdisk -H 224 -S 56 /dev/sdb

WDのチェックにはWESTERN DIGITAL DATA LIFEGUARD DIAGNOSTICSを使う。
CDから起動できるISOイメージもあるが、Windowsから実行できるものもある。
今回はDR-DOSでの起動が失敗したのでWindows上から実行した。
Short Testは2分ほどで終わるが、Zero Fillは5時間ほどかかる。
2台並列実行ができるのが救いかもしれない。

某掲示板のスレッドによると、
1. 電源を入れて温度が安定するまで放置 (室温次第、10分～2時間)
2. ShortTest (この時点の不良で以降の検査を省いて返品交換するならLongTest)
3. ゼロフィル
4. LongTest
5. OSでクイックフォーマットを実行してファイルシステムを作成、運用
このような順番でチェックするのが望ましいらしい。

チェックの内容
○Extended self-test / Long Test / ロングテスト
　　HDDのセルフテスト 全セクタ読み出し検査 原則的に既存データに影響なし 1TBで250分前後
○Conveyance self-test / Short Test / ショートテスト
　　HDDのセルフテスト 簡易検査 原則的に既存データに影響なし 3～5分
　　容量にかかわらずで検査が終わる
○Zero Fill / ゼロフィル / ゼロ埋め / 物理フォーマット(歴史的用語)
　　全セクタに書き込むので、未知の不良セクタがあっても自動代替される
　　既存パーティション・データ等はすべて消える
　　PCからHDD間に容量分のデータを送るのでLongTestと同等以上の時間を要する

6/4 Hadoopでのユーザアプリの実行

ユーザアプリはHadoop内のmapredに置かれているMapReduceBaseをインポートして作る。
packageは設定しないほうが楽だが、設定した場合は実行時にも影響する。

$HADOOP_HOMEをHadoopをインストールしたディレクトリで設定する。
これがないとうまく実行できない。

$HADOOP_HOMEにjavaファイルを置いてコンパイルする。
$ mkdir class_tmp
$ javac -classpath ${HADOOP_HOME}/hadoop-0.20.2-core.jar -d class_tmp SOURCE.java
$ jar -cvf JARNAME.jar -C class_tmp/ .

package hoge.foo.bar;
となっている場合は、SOURCE.javaの部分を./hoge/foo/bar/SOUECE.javaにする。

実行。
$ ${HADOOP_HOME}/bin/hadoop jar JARNAME.jar CLASSNAME ARG0 ARG1 ...

packageが指定してある場合は、CLASSNAMEをhoge.foo.bar.CLASSNAMEとする。
引数はjavaの設定に依存。


参考：ttp://www.unfindable.net/~yabuki/blog/2010/02/hadoop_1.html
今回は正しい情報に行き当たるまでにすさまじく多くの時間を無駄にしてしまった。
ショック。

6/3 NFS高速化

簡潔に言えば、非同期書き込みに読み書きサイズを増やせばよい。
加えて、TCPを使うことでRPC再送のオーバーヘッドを緩和できる。

・NFSの設定
### /etc/exports ###
NFS_DIR IP_ADDR/SUBNET(rw,async,no_root_squash,no_subtree_check)

・マウント時のコマンド
# mount -t nfs -o tcp,rsize=8192,wsize=8192 NFS_DIR LOCAL_DIR

・fstab
### /etc/fstab ###
ADDR:NFS_DIR LOCAL_DIR nfs hard,rsize=8192,wsize=8192,tcp 0 0

exportsの設定にasyncを足すのがポイント。
SUBNETと括弧を詰めて書かないとエラーが出るので注意。
exportfs -raコマンドでexports設定ファイルの確認と更新ができる。

6/1 JSON

Twitterのログを操作するPerlスクリプトを作成しているが、
JSONのPerlモジュールがうまく動かないため立ち往生してしまっている。
そもそも実装例がほとんどない。困った。