enbug diary

_ 一周年

ようやくなのか、早くもなのか、ピンと来てませんが、 とにかく来仏して一年が経ちました。

やっぱり海外に住むというのは、 自分の国に住むのとはまた一味違った、 いろいろな出来事があって、それはそれで感慨深いものです。 しかし、別にこれで終りってわけじゃないので、 あんまり感傷にふけるのはやめておこう、と思ってます。

ちなみに、今まで作ってみたら面白いかもと思って、 頭で考えただけでやってないもの。

フランスの看板集

日本とは趣が違う立て看板が結構あるので、 写真集にしたら面白いかと思った。 随分エロいのもあるし。 でも、写真撮るのは面倒だし、少々気恥ずかしくもあるので、 やめた。

海外流出の勧め

日本に不満を持っている技術者に、 積極的に海外に出てしまうことをお勧めるコラムを書こうかと考えた。 別に永遠に出ろというのではなく、 ある程度の規模で、 有能な人材が常時海外に流れていく事態になったら、 ちょっとは国の政策に影響を与えられるかもね、と。 ネタが暗いのでやめた。

フランスの生活とか、海外で働くこととか

人様に偉そうなことが言えるほど経験を積んでないので、やめた。

_ バカンス＋仕事

最近、熱を出してしまって寝込んだり、 Euro 2004でサッカーに燃えたり、 まあいろいろでした。 明日からしばらくバカンスです。

とは言っても、半分休み、半分仕事です。 LSM/RMLL 2004 に参加して、発表しなきゃいかんのです。 おかげで旅費は会社持ち。 大部分はさぼって、遊ぶつもりですが。

ボルドーは何年か前に本当は招待されるはずだったのに、 結局主催者側が貧乏で行けず仕舞いになったことがあったので、 ようやく行けるのか！と少々感動ものです。 ボルドー自体には大して興味はないのですけど、 周辺が面白そうです。

あまりうつつを抜かさず、発表の準備をちゃんとやらねば。

_ ボルドー

日曜日の夜に帰宅しました。 何か工事中のやたらと多い街で、 まるで京都のようでした。

明日は終戦記念日（だったっけ？）でまた休日。 旅行に行くと、休みとは言っても、結構ばたばたしてしまって、 完全には疲れが取れないので、実はかなり明日が待ち遠しいのです。

_ 最近の自分の方針

かずひこさんが「 take and take の身で何の謝意も払わない態度はちょっとどうか 」と書いておられるのを見て、 思わず同情を禁じ得ないのでした。 私も同じような経験を随分させられてきましたから。

世の中には、文句をいう権利がある、 そして、文句を言うのは良いことだ、と信じて憚らない輩がいます。 決して多くはありませんが、そういう人は声がでかいし、 粘着性でしつこいので、非常に目立ってしまいます。 文句を言うこと自体が悪いとは思わないけど、 物事には限度とか節度とかいうものがあるってことを知るべきでしょうね、 そういう人は。

最近の私は、「文句があるならあなたがやってくれ」 の方針をかなり堅持するようになりました。 時間も精神力も足りないので、現実問題、他に手がないからです。 私にやらせたいなら、金払って急がせるか、 私のペースで物事を進めるのを黙って見てもらわないと。 別にこっちは義務でやってるわけじゃないんだから。

tDiary.Netについて言えば、 私自身は全く何もしないで、 一方的にサービスして頂いている立場だから、 私だったら、仮にサービスをいきなり停止されても文句言わないだろうなあ。 今まで書いた分のデータを送って下さい、とお願いするだろうけど。

_ GRUB

おぉ、 uchさん、お久しぶりでございます。 今でもNetBSDやってるんですか？ って、ここに書くような事じゃないか。(^^;

そういや昔、uchさんに 「いつまでもGRUBやっても云々」 と言われた事があるような気がするんですけど、 最近もう大分嫌になってきちゃいましたよ。 いろいろニーズはあるので、やる意味はあると思ってるんですけど、 こんなにテスター集まらないようになると、 「やってられるかよ！」って気分になります。 メーリングリストでももうキレ気味 だし。 段々Hurd時代に逆戻りしてきたかも。

いやね、 もう以前の経験で、正論だからといっても、 言っていい事と悪い事があるというのはよく分かっておるのです。 そういうことやっても、 どうせやらない人はやらないんだし、 自分も気分悪くなるだけですから。 だから、ぶつぶつ言ってやらなくなるよりは、 黙って潮時を選ぶべきですね。

しかしまあ、テストするだけでもこんなに現れなくなると、 時代の変化なのかなあ、なんて考えちゃいます。 やっぱりあの頃は自分でコンパイルして試すのを厭わない人はたくさん居ました。 最近はそういう人はめっきり減ってしまいましたね。 ディストリビューション有害論を唱えてしまいたくなります。

テストはディストリビューションに任せて、 パッケージ・テスト屋さんに報告させるのが現代のやり方なんですかね。 しかし、そういうまわりくどいやり方だと、 なかなかソースコードのレベルに結果が跳ね返ってこないので、 すごく効率が悪いです。 ディストリビューションに載せると、 同じ問題を何回も報告されたり、 直った問題をさらに何度も報告されるので、 かなりうっとうしいですし。

何やらまとまりがありませんが、 古い方のGRUB（GRUB Legacy）のメンテからはもう手を引こうと考えてます。 こんなことをいつまでやってても、 新しい方（GRUB 2）が成長しませんし、 何より古い方の管理なんて、ちっとも面白いとは思えないからです。 やりたいっていう人が現れたら、その人に任せますが、 それまでは見捨ててしまおうかと。 どうせそんな人は現れないと思いますが。 これだけ人が居ないのに、 そんな奇特な方が急にやってくるはずがありません。

でも、GRUB 2は「全アーキテクチャ制覇」という究極の目的がありますから、 結構面白いんじゃないかと思ってます。 現時点では一般ユーザにはちっとも役に立たない代物ですけど、 私の場合、そもそも「広く使われる」ことが動機になってないので、 それはどうでもいいこと。 開発して楽しい方を選びます。

でもこんなことしてると、 本来やりたかったのはGRUBじゃないのを忘れてしまうかな。 GRUBは必要性があるから、やり始めただけでしたしね。

やっぱりまとまらないなあ。 まあいいか。

_ Distributed Replicated Blob Server

Googleのパクリだけど、安定したら結構いいかも。 ファイルをたくさん作るみたいだけど、 データベース使うのと、どっちの方が速いのか、ちょっと気になります。 時間作って、試してみようかな。

_ Optimizing MySQL/InnoDB Performance

innodb_log_file_sizeを増やそうとしてたんですが、 MySQLが起動できずにこけるので、何でかなと思ってたら、 一旦ログを取り除いて再起動しないと駄目なんですね。 それぐらい自動でやってくれたらいいのに。

_ ベンチマークしてみた

上に書いたやつの続きですが、 Pythonでへっぽこプログラムを書いて、早速試してみました。 使用した環境は、 Pentium 4 2.66GHz、メモリ 500MB、IDE HDD 40GB、 Mandrake Linux 10.0 (Linux 2.6.3-13mdk) です。

ファイルベースの方はとりあえず、/tmpの下にディレクトリ掘って、 IDをそのままファイル名にして、たくさんぶちこむだけにしました。 TCPのソケットで簡単なプロトコルを作って、 クライアントがデータやMD5のチェックサムを送って、 IDでデータが取れるようにしました。 一応MD5でちゃんとデータが取れてるか確認してますが、 エラーチェックはいい加減です。

データベースの方は、サーバをMySQLにして、 クライアントは同じくPythonで。 これもTCP経由で接続することにしました。 トランザクションは要らないし、 InnoDBはクエリーの最適化が完了するのに時間がかかるので、 MyISAMでテーブルを作りました。 全部一つのテーブルにぶちこむので、 ファイルシステム上では一つのファイルになります。

これで、300から3000バイトの範囲で、ランダムにデータを作りました。 数は10万ということにしました。 この数はディスクキャッシュに全部載らない程度に多く、 残り少ないディスク容量で収まる程度、という条件で選びました。 実際には200MBぐらいのデータが作られたようです。 データの取得は10万回、毎回ランダムにIDを選んで行ないました。

結果から言うと、MySQLの圧勝です。 ファイルを使った方は17:40、MySQLの方は12:03で終りました。 CPUの利用率は非常に低く、Pythonで書いたことは影響ないと思われます。 完全にディスクがボトルネックのようでした。 実際のところ、MySQLはSQLの解釈の分だけ少し不利なはずなので、 あんまり気にする必要はないでしょう。

しかし、これだけで判断するのは難しいです。 なぜなら、私はファイルシステムにext3を使ったからです。 しかも、一つのディレクトリに全部入れてしまったので、 これだとindirect blockを3段階使わないといけません。 ext3がこの手のやり方に弱いのは明白なので、 squidみたいにディレクトリを多段にするべきだったし、 reiserfsならもう少し良い結果が出るでしょう。

まあ、それを言い出すと、 MySQLも完全にはチューニングしてませんでしたし、 完全な結果を得るのはそう簡単じゃないようです。

このテストで言えることは、手っ取り早く良い性能が欲しかったら、 MySQL使うのが一番ってぐらいですかね。 読むだけなら400オブジェクト/秒ぐらいなので、 普通にレプリケーションしても、サーバ5台なら、 2000オブジェクト/秒読めることになります。 100万オブジェクトが8分で読めるなら、そう悪くないんじゃないかな。

_ バカンス

来週いっぱい、休みをとることにしました。 土日を併せると、九連休ですか。

フランスでは、 基本的に仕事始めの一年目はバカンスがとれないことになっているのですが、 私はとっても構わないのにとらないでいました。 だから、フランスに来てから、これが初めての長期休暇です。 のんびり疲れを取りたいものです。

_ ZODB

休みになっても、やっぱりZopeいじっている自分が哀しくなりますが、 これは技術的興味だけでやっていることです。

はっきり言って、ZODB（正確にはFileStorageと言うべき）は遅い。 書き込みは確かに速いけど、 ZMySQLStorageより速いわけじゃありません。 実際的にはZMySQLStorageはバグだらけで使えたものではありませんが。

何が遅いって、 オブジェクトの数が膨大なときに、 ルート・オブジェクトから全探索すると、よく分かります。 FileStorageが使うData.fsでは、 関連するオブジェクトが近接して置かれたりはしないので、 ディスクをシークしまくることになってしまい、 ほとんどスラッシングみたいな状態になります。

仕事の上では、まだ耐えられる程度なので、すごく困ってはいませんが、 速くなったらすごく嬉しいし、 技術的に面白いことなので、ちょこちょこ考えたり、 試したりしてるわけです。

忘れてしまわないように、いくらかアイデアを書き留めておきます。

差分？

仮にデータベースの大部分がシリアライズされたオブジェクトのデータで埋め尽くされているとすると、 バージョニングのやり方を改良できるかもしれない。 例えば、現状のように全てをimmutableにはせずに、 過去のバージョンは差分だけを保存するということが考えられる。 もし多くのオブジェクトがそう大きく急激に変化することがないなら、 かなりデータを減らすことができる。

圧縮？

単純にzlib使うということも考えられる。 しかし全体を圧縮すると、 シーク時のオーバーヘッドが洒落にならないかもしれない。 オブジェクト単位で圧縮すると、 オブジェクトのデータは一つだけでは小さ過ぎて、 圧縮率が非常に悪いかしれない。

再配置？

オブジェクト間の関連度に応じて、 準最適な配置を計算し、Data.fsを再配置する。 すごく重そうだし、 そもそもどうやったら出来るのか。 アプリケーションの高いレベルで関連性が定義されると、 Data.fsを探査するだけでは情報が得られない。 ということは、実際に使用している時に、 統計を集めないといけないということか。 リアルタイムでやるのはファイルの一次元性を考えると、 多分無理だという気がする。

分割？

Data.fsがでかいのが良くないのだから、 いっそのことあまり見ないオブジェクトは別のファイルに追い出してしまう。 あるいは、よく使うものを別ファイルにする。 これをやると、FileStorageの「ただひらすらファイルの最後に追加する」 というルールが破られてしまうので、 逆にパフォーマンスが落ちるかもしれない。

徹底分割？

もっと分割しまくることもできる。 極端なのはDirectoryStorageだが、非常にパフォーマンスが悪いと聞いた。 以前の私のテストでも、 ファイルシステムをデータベース代わりにするのは駄目なようだったので、 インデックスをファイルシステムに任せるのは悪いアイデアだと思う。 だから、この方法は多分駄目だろう。

仮定が多いので、実際のデータを解析して、 統計をちゃんと取らないといけません。 気が向いたら、休みの間にやるつもりです。

_ GRUB Legacy

自分自身、まだ実用では使わざるを得ない状況なので、 完全にやめるのもどうかと思い直しました。 というわけで、 これからの方針を投稿しました。

基本的に私は最小限しかやらない、 やりたければやりたい人がやってください、ということ。 管理者としてお世辞にも親切とは言えない方針ですが、 他の開発も兼ねるには、この辺が限度でしょう。 これが気に入らないなら、 文句言わずに、私の代わりに働いてくれい。 愚痴でソフトウェアは育たない。

早くこの中途半端な管理状態から脱却するためにも、 これからは出来るだけGRUB 2の実用性の向上に努めます。 同等の機能を備えるのはそう簡単ではありませんが、 ディスク・ベースでの利用に絞って開発すれば、 そう遠くない将来に使えるレベルにできるでしょう。

_ Trouville

天気予報ではすごく悪かったのですが、 実際に行ってみると、 二日目からは晴れ上がってくれました。 おかげで大西洋のビーチで泳ぐこともできましたし、 料理も堪能できて、良い旅ができました。 カマンベール・チーズも食べたし（ノルマンディが本場です）、 Fruits de Merでカニを食べたり、 Calvados（これも本場です）を飲んだり。 めでたし。

Trouvilleは庶民的で、家族連れが多かったです。 おかげでゆっくりできました。

Deuvilleは美しい街で、海水浴場もよく整備されていました。 だから泳いだのはDeuvilleです。 Deuvilleはさすがに金持ちが集まるだけあって、 車もすごかったです（フェラーリとか、ジャガーとか...）。

帰ってからはちょっとダレ気味。 旅行のせいで、精神的にも完全にバカンス状態に陥った模様です。

_ How to install and use gpg-agent ?

ssh-agentの次はgpg-agentか... こういうのって、統合できないもんなんですかね？ KDEのKWalletとか、Mozillaに組み込みの記憶機能とか、 自分から見れば同じ目的としか思えないものがこうもたくさんあると、 うっとうしく感じませんか？

_ MySQL Clusterを試す - クラスタ化した分散アドレス帳をつくる

結論としては、NDBの耐故障性はまだ機能していないってことか。 私としてはパフォーマンスの方が気になるので、 誰か試して欲しいのぉ。 こればかりはある程度ハードウェアが整わないと実験できないので、 自分は人柱になれそうにもありませぬ。

_ ZODB の続き

とりあえず、とある顧客のある時点でのData.fsを使って、 いくらか調べてみました。 ファイルの大きさは1942154571バイト。 これはpackしてしまっているので、すごく小さくなってますが、 しばらく放って置くと、40GB超える事がよくあります。

得られたデータはこんな感じ。

トランザクションの数

338682

オブジェクトの数

5705925

オブジェクトのデータ部分の総和

1687537394バイト

オブジェクトの平均長

296バイト

トランザクション当たりの平均オブジェクト数

16.8

トランザクション当たりの平均データ量

4983バイト

ヘッダのオーバーヘッド

254617177バイト

データの全体に占める割合

86.9%

packしてしまっているので、abortされたトランザクションは全く無し、 同一oidのオブジェクトはごく僅かしか含まれていません。 この状況では明らかに差分を使う意味はありません。

次にgzipかけたらどうなるかを見てみました。 gzipはデータ部分のみで、 ヘッダやバージョン等は含まないことにしました。

圧縮したオブジェクトの大きさの総和

1135171881バイト

圧縮したオブジェクトの大きさの平均

199バイト

圧縮率

67.3%

ヘッダも含めた全体での圧縮率

71.6%

トランザクション当たりの平均データ量

3566バイト

案外データ長が短くても、gzipは圧縮率は良いことが分かります。 ちなみに、デフォルトのレベル6で圧縮してます。

これで分かるのは、圧縮なしだと、一つのトランザクションが（平均で） 4KBを越えるのに対し、圧縮ありだと、 ヘッダを含めても越えなくなるということ。 ファイルシステムが2KBや4KB単位のブロックを利用することが多いのを考慮すると、 一つのトランザクション内のオブジェクトが少ないブロック数に収まる可能性が高くなるので、 多少はパフォーマンスが上がるかもしれません。 同じトランザクションに存在するオブジェクトは関連性が高いと考えられるので、 意味があるかもしれないという訳です。

しかし、こればかりは実際にベンチマークしないとよく分かりません。 実装するのは面倒そうだなあ。 FileStorageを改造するのは簡単だと思いますが、 既存のData.fsを変換するのは大変そうです。 オブジェクトの位置関係を保持したままテストしたいのですが、 圧縮するとバイト位置が変化してしまいますからね。