ぱぱネット（仮）

_ フィアット公式

日本のヲタク文化って、当の日本人からの評価が一番低いのかもしれないなあ。ちょｗｗｗｗｗフィアット公式ページｗｗｗｗなんでアニメ絵なの？ｗｗ

_ 本当の現実

本当は労働環境の改善が急務だと思うんだけどね。問題なのは、当人たちの 見積もりが甘いとかじゃなくて、元々キツ過ぎる予算と日程なんだと思うわけよ。 元凶は多分ＴＶキー局。

世の中、京アニみたいな異常集団ばっかりじゃないからな・・・・

_ 日曜日に毛布仕舞ってコートをクリーニングに出した俺涙目

マジさみーし！

_ 夕食

えーと・・・・なにこれ？。

豚肉ロース薄切り100gは解凍後、しょうがチューブ適量と醤油小さじ1,酒小さじ1で味付けてしばらく置く。ニラ1束を洗って切る、にんじん1/2本を短冊切り、ネギ1/2本を適当に切り、もやしを洗う。にんにく1かけをサラダ油5gで炒めて、豚肉、にんじん、ネギ、ニラ、もやしの順で炒めて、最後に鳥ガラスープの素適量と片栗少量を水で溶いたものでからめ、卵を落とす。

のだが。ぼーっとガンダム００を見ながら調理していたら乾いてしまった。反省。カロリーは370KCalほど。

_ 1週間の成果

• 体重： 69.3Kg→68.5Kg (減)
• 体脂肪： 24.1%→25.2% (増)
• 筋肉量： 49.9Kg→48.6Kg (減)

えー・・・・やっぱり運動しなくちゃだめか。

_ [テレビ] ２００９ワールドベースボールクラシック決勝日本ｖｓ韓国

ネット中がこの話題でもちきりなので俺が書くまでもないのだが それでも書かずにはいられない。

ランナー2,3塁においてツーエンドツーと追い込まれてから 粘る粘る。 そして会心の一撃！この2点は本当に 値千金 だよなあ。 本人も相当気持ちよかったらしいが(笑)とにかく優勝おめでとう日本。

_ [開発][Linux] Tokyo Cabinet / Tyrantで遊ぶ(3)

一番気になっているのは、Q-GRAM転置インデックスを作成するだけで、登録時間がわずかではあるが級数的に伸びていること。これがlogみたいなグラフを描くのなら安心して使えるのだが 2000万件超えた当たりで1登録あたり257時間かかりますね(^^; とか言われるとマジ死ぬ。

わかったことをいくつか。インデックス生成含め検索操作の関数群はtctdb.cにほぼ全てまとまっている。 そこでtctdbsetindeximpl関数をみると

  case TDBITQGRAM:
    idx->db = tcbdbnew();
    idx->cc = tcmapnew2(TDBIDXICCBNUM);
    idx->name = tcstrdup(name);
    tcxstrprintf(pbuf, "%cqgr", MYEXTCHR);
    if(dbgfd >= 0) tcbdbsetdbgfd(idx->db, dbgfd);
    if(tdb->mmtx) tcbdbsetmutex(idx->db);
    if(enc && dec) tcbdbsetcodecfunc(idx->db, enc, encop, dec, decop);
    tcbdbtune(idx->db, TDBIDXLMEMB, TDBIDXNMEMB, bbnum, -1, -1, bopts);

てなわけでB+木データベースそのものらしい。実際に出来上がった*.qgrファイルをhoge.tcbという ファイル名にリネームしてtcbmgrでダンプしてみる。

$ tcbmgr inform hoge.tcb
path: hoge.tcb
database type: btree
additional flags:
comparison function: lexical
max leaf member: 64
max node member: 256
leaf number: 34150
node number: 191
bucket number: 9209
alignment: 256
free block pool: 1024
inode number: 1171692
modified time: 2010-03-24T10:44:13+09:00
options: large
record number: 594699
file size: 305556224

あー....20万行しか登録してないのに59万個の単語にわかれているのか。 そりゃ遅いかもな。でも、BTreeの素直な実装だと検索時間はO(log n)に依存し、登録操作もほぼ同様なはず（どくらいの単位でひとまとめにしてるかに依存するが）。 でもこれって、6万行を超えたあたりから急速に処理時間が延びる説明にはならないんだよね。

まあdcbdbtuneを読んでいる箇所はわかったので、 基本仕様書のB木チューニングの章を 読んでチューニングしてみたが、これまた芳しくない。一応、

tcbdbtune(idx->db, 24, TDBIDXNMEMB, bbnum, 12, -1, bopts)

が一番速いようだがせいぜい数％.....ボトルネックは別にあるのかな。

リーフ内メンバ数やバケット数をいじっても、ほとんど変わらないかむしろ悪化する場合が大半だった。

1. TDBIDXLMENBを24に変更
2. bbnumを20000000変更
3. TDBIDXQGUNITを3から4に
4. TDBFTSBMNUMを524287から687903に変更
5. tcbdbsetxmsiz(idx->db, 1024*1024*1024);

などなど。

_ [開発][Linux] gprofの結果

TC/TTのconfigureはプロファイル出力をサポートしており

$ ./configure --enable-profile

でコンパイルしなおすとgmon.outを作ってくれる。これでインデックスありとなしを比べれば 特徴的な処理が洗い出せる....はずだと思ったんだけど。

インデックス一切無しの場合：

Q-GRAMインデックス有りの場合：

正直パーセンテージだけ見ると違いがわからん。Q-GRAMの時だけ、特定関数がものすごい勢いで 呼ばれてるとか、とても時間を食う関数が呼ばれているとか、そういう単純な問題ではないようだ。 総合的なI/Oスループットの問題だとすると、チューニングは実に厄介だ。

_ [開発][Linux] 抜き身のナイフ

読んでみてなんとなくわかったのは設計思想で、 Tokyo Cabinetはいわゆる安全側に振ってあるRDBMSとは全く違う。抜き身のナイフのようなもの。 俺みたいな素人がお気軽に手を出せるモンじゃねーな.....

例えば。tcmapput関数などを生でmmapしたファイルにガンガンポインタベースでmemcpyしちゃう。 「え？普通じゃん？」と思うかもしれないけど、RDBMSではまずやらない。 書き込めない場合の回避処理が大変だからね。

実際、昨日のサンプルを、少量のtmpfsを切った上で実行したら ttserverがバスエラーで落ちてワロタ 。バグじゃなく仕様なんだろうなあ、これ。

ああ、TCのネガティブキャンペーンをしている訳ではありませんので。念のため....。

_ [雑記] papa.to.ドメインを支払った

こんな脅しメールがきていたので...

Your registration for the domain name 'papa.to' will expire
in less than 60 days, on Sun May 22 2011 TGT.
The renewal fee can be paid by credit card.
Renewal terms and  rates are:
1 year:    US $50
2 years:   US $100
3 years:   US $135
5 years:   US $200
10 years:  US $350
25 years:  US $750

仕方なく3年分払いました。今、.comとかすごい安いから.toドメインの高さが身にしみるぜ。ほんと....なんでトンガにしてしまったんだ。俺は俺は。