ぱぱネット（仮）

_ [Linux][開発] TokyoCabinet(Tyrant)のパフォーマンス

仕事が忙しくてずいぶん間が空いてしまったのだが、またTT/TCをいじり始めています。 実は性能が出なくて困っていた。特に 20万件を越えたあたりからライトが激烈に遅く ちょっと使い物にならないレベルに。

で、ちょっとぐぐったらとても良い資料見つけました。 SSDとTokyoTyrantやMySQLの性能検証(by 株式会社ゆめみ)。 こんなノウハウを惜しげもなく公開してくれるなんて....大変ありがたい。

_ [Linux][開発] 読んだ限り

所詮HDDだろうがSSDだろうがディスクI/Oが混むと手のつけようがないので、 「メモリ大量に用意してxmsizデカくしてオンメモリで処理しろ」 というアプローチが 正道らしい。

TC/TT開発者mikioさんがブログ等でTTを「状態をディスクに保持してくれるmemcached」という 立ち位置で説明してるので誤解しやすい(俺だけかもしらんが俺は誤解してた)けど、 やっぱりメモリ最強 ということですか....。

具体的にはttserverを起動するdbname行にxmsiz指定をつける(パラメータは256mとか1gとか)。

cascket.tct#xmsiz=1g#opts=ld#apow=6#dfunit=4

みたいな感じ。ウチでは80万件のデータベースに対してキャッシュ1G指定したら、 だいたいライトが80倍くらいになりました(今までは何だったの....)。 データベース全体は600MBくらいなのでまるっきりメモリに入ってしまう模様。

_ [Linux][開発] さらに速くする方法もしくはmget知らなかったバカを責めて

通常、Perlにおける、TTのRDBTBL(SQLライクなテーブル状データへのアクセス)に対する検索の 贋コードは以下のとおり。概ね「ptokenカラム内をタグ検索して、ptime順にオーダーして、最大100件出力」という意味です。

my $qry = TokyoTyrant::RDBQRY->new($pm);
$qry->addcond('ptoken', $qry->QCSTRAND, $tokens);
$qry->setlimit(100);
$qry->setorder('ptime', $qry->QONUMASC);
my $rv = $qry->search();

ここで$rvに返ってくるのは キーリストのリファレンス である。なので、 以下のようにforeachで回したくなる。get関数は指定キーのデータ本体をとってくるものね。

foreach my $rkey (@$rv) {
  my $rcols = $pm->get($rkey);
  # print Dumper($rcols);
}

しかしこれは遅いのだ。 TT/TCにはmget関数というものが用意されている。 mget関数は あらかじめキーを入れたハッシュのリファレンスを渡す と、 データが存在するものは値セットしてくれ、データがないものはキーごと削除してくれる...らしい。 getだと毎回サーバに対してリクエストを出してしまうけれど、mgetだと1回で済むわけだ。

mgetを使った贋コードは以下のとおり。リストはmap関数でハッシュに直しています。

my %rtable = map { $_=>undef } @$rv;
my $count = $pm->mget(\%rtable);
foreach my $rkey (@$rv) {
  next if (!exists $rtable{$rkey});
  my $rcols = $rtable{$rkey};
  # print Dumper($rcols);
}

結果... MGET:0.006553sec GET:0.030858sec ということで mgetはgetのおよそ4.7倍 という結果でした。 ああ、俺が使い方知らなかっただけなのね。これは便利だし副作用ないしガンガン使っていこう。

_ [Linux][開発] しかし....

それでも私の環境では数万QPSにはまったく届きません。Core i3でもPhenomII X4でも。 特にライトは1000QPS出ているかでていないかで、件のレポートでいう「極端に悪い状況」です。 まあメモリ4GBしかないので、せいぜいttserverに割り当てられるキャッシュメモリは1GBということもあるけど。

なんでだろう...と思っていろいろ試しているのですが、確定的なことは言えません。

でも、ttserverを同じマシンで10コ起動するという場面は、 もしかして想定してない？ と は思っています。

通常のSQLデータベースだと、1サーバ＜複数データベース＜複数テーブルという階層構造で、 通信用のワーカースレッドが複数個立ち上がっても、データベース自体の書き込みは比較的シリアライズされていると 考えられます。

しかしttserverの場合は1サーバ＝1データベース＝1テーブルという単一構造で、 どうしても実用的なアプリケーションを作成しようとすると、複数個ttserverを起動したくなる訳ですが、 どうも 全員がガムシャラにディスクをアクセスするよう なんですよね....常に全力全開マジモードで。

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.05   32.62    0.00   67.33
Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda              27.00         0.00      1206.40          0       6032

これは...O/Rマッパーを書いて複数のテーブルを1つのttserverに押し込めるように したほうが良かったですかね。

_ [Linux][開発] 副作用ないとか書いたmgetが...

PerlからTokyoTyrantを使っているのですが、ときおり

Odd number of elements in hash assignment
 at /usr/share/perl5/TokyoTyrant.pm line 1397.

というワーニングが出ることに気づいた。 出ているところは昨日使い始めたばかりのmget関数。 使い方が間違ってるのかなーと思っていろいろやっていたのですが.... 以下サンプル。

#!/usr/bin/perl

# 別窓でttserver -port 10100 test.tctで起動しておく

use strict;
use TokyoTyrant;
use Data::Dumper;

my $pm = TokyoTyrant::RDBTBL->new();
$pm->open("localhost", 10100);
# 値に空値を含んだハッシュを作成
my $cols = {
    '1'=>'hoge',
    '2'=>'',
    '3'=>'piyo',
};
# 登録
$pm->put("123", $cols);
# getで取得,これはワーニングでない
my $rcols = $pm->get("123");
print "(1)" . Dumper($rcols);
# mgetで取得
my %rtable = ( "123"=>undef );
# ここでOdd number of elements in hash assignment
my $rcount = $pm->mget(\%rtable);
# データ自体は正しいように見える
print "(2)" . Dumper($rcols);
$pm->close();

まさかこんな仕様ではなかろう。Perl module側のバグな気がする。 そこでTokyoTyrant.pmのsub mgetを読んでみると...

while(my ($pkey, $value) = each(%$recs)){
  $$recs{$pkey} = split(/\0/ , $value);

となっている。これはゼロ値を終端子としたバイナリプロトコルの一部なのかな....。 とりあえず改悪してみたけど、これでいいとは思えない。

while(my ($pkey, $value) = each(%$recs)){
  my @coll = split(/\0/ , $value);
  push(@coll, '') if (scalar @coll % 2 == 1);
  my %cols = @coll;
  $$recs{$pkey} = \%cols;

これ末尾だけ帳尻合わせしてるだけなんだけど、 データの途中でインデックスとバリューのアラインが狂うことはないのか というのがすごい気にかかる。

一応最新バージョンを使ってるつもりなんですが。

• tokyocabinet-1.4.45.tar.gz
• tokyocabinet-perl-1.33.tar.gz
• tokyotyrant-1.1.40.tar.gz
• tokyotyrant-perl-1.16.tar.gz

OSはLinux-2.6.32(Debian squeeze)です。

なんせ2000レコード読み出すと 2000行エラー出る ので ログがものすごい勢いで流れるのです。参った参った。

_ [Linux][開発] あれ？これやばくね？

TokyoTyrant.pmのmisc関数の配列プッシュしてる部分の直前にprintf。

printf STDERR "esiz:%d eref:%s\n", $esiz, $$eref;
push(@res, $$eref);

これで先ほどのテストスクリプトを実行すると...

esiz:1 eref:1
esiz:4 eref:hoge
esiz:1 eref:3
esiz:4 eref:piyo
esiz:1 eref:2
esiz:0 eref:  # ちゃんと送られている
(1)$VAR1 = {
    '1' => 'hoge',
    '3' => 'piyo',
    '2' => ''
};

しかしmget関数(規定クラスの方)をダンプしてみると....

printf STDERR "SIZ:%d VREF:[%s]%s\n", $vsiz, $$vref, unpack("H*", $$vref);
$recs->{$$kref} = $$vref;

SIZ:16 VREF:[1hoge3piyo2]3100686f67650033007069796f003200
Odd number of elements in hash assignment at
/usr/local/share/perl/5.10.0/TokyoTyrant.pm line 1382.
(2)$VAR1 = {
  '1' => 'hoge',
  '3' => 'piyo',
  '2' => ''
};

何が起きているのか整理すると....

• '31'はインデックス'1'
• 次の'00'はインデックス'1'の終端子
• '686f6765'は値'hoge'
• 次の'00'は値'hoge'の終端子
• '33'はインデックス'3'
• 次の'00'はインデックス'3'の終端子
• '7069796f'は値'piyo'
• 次の'00'は値'piyo'の終端子
• '32'はインデックス'2'
• 次の'00'はインデックス'2'の終端子
• ないじゃん！！！

サーバ側じゃないのかこれ...と思って辿っていったらttserver.cのtcadbget()で既に16バイトで TCのtctdb.cのtctdbget()まで追うハメになっているでござる.... もしかしてTC/TTのテーブルデータベースってほとんどテストされてなくね？ 仕様書に「空値は一切許さない」という記述も見つけられないし.....

_ [Linux][PC] そういやIntel SSDの具合は....

SSDには寿命がある。搭載されてるフラッシュメモリに かなり短い書き換え寿命(数千回〜)があるため。 気になるところではある。 (※まあHDDも酷使すると壊れるんだが...このサーバのHDDも1年で壊れたしナ...)

_ [Linux][PC] smartmontools

Linuxの場合、HDDのS.M.A.R.Tの情報を取得するには smartmontoolsを使うが、これにSSD寿命を表す数値が でるらしいので試してみた(UNKNOWNながら)。

# apt-get install smartmontools
# smartctl -s on -d ata -a /dev/sda (最後は調べたいデバイス名に)

どれどれ....

=== START OF INFORMATION SECTION ===
Device Model:     INTEL SSDSA2M080G2GC
Serial Number:    CVPO952601H4080BGN
Firmware Version: 2CV102HA
User Capacity:    80,026,361,856 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   7
ATA Standard is:  ATA/ATAPI-7 T13 1532D revision 1
Local Time is:    Sun Jun  6 22:59:48 2010 JST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
(省略)
232 Unknown_Attribute 0x0033  100  100  010   Pre-fail  Always
233 Unknown_Attribute 0x0032  099  099  000   Old_age   Always
184 Unknown_Attribute 0x0033  100  100  099   Pre-fail  Always

過去の偉人の考察を 参考にすると、232がE8, 233がE9で確定であろう。 しかし...100と99か.... 全然減ってないな(^^; .... このSSDにはTokyoTyrantサーバが8個起動して常時ガリガリ2週間くらい 書いているわけだけど、実際のデータ量自体は大したことないのかもしれぬ。

件の考察でもE9が寿命に関係しそうということまでは 分かっているようだが、リニアに変化する数値でもないようだ。 でも０に達したら壊れるんだろうなあ.....まあsmartctlでいつでも 寿命を調べられるということがわかっただけで良しとするか。

_ [Linux][開発] TokyoCabinet/Tyrantの複合検索について

もちろん、ディスクに永久保持されるKVSとしての側面も十分魅力的ですが。 RDBMSばりのテーブルインデックスを備え複合検索ができるTC/TTは、 「どうしてもMySQLとかの代わりに使ってみたくなる」 のが人情といふもの。

実際にはたくさんのカラムを登録してある(横に長い表)だけど、 一応以下のようなテーブルだとだと思ってください。

時刻はUNIX起源時間(epoch_time)。トークンは実際は文章タグ検索用のテキスト。 TCでは、カラム名を各セルに付与するのでデータサイズを考慮して番号に置換してある。

また、それぞれのカラムには以下のインデックスが張ってある。 ptime(3)では数値型の比較速度アップ(ITDECIMAL)が、 ptoken(14)ではトークン単位(上の例だとカンマ(,)で区切られた箇所ごと)の比較速度アップ(ITTOKEN)が期待できる。

$db->setindex('3', $db->ITDECIMAL);
$db->setindex('14', $db->ITTOKEN);

これはレコード数が数千規模では十分うまく動いていた.....のですが。

_ [Linux][開発] しかしこれが遅い

まあ基本的には 110万件も登録するなよ という話なんですが。 以下サンプルプログラム。単純に 時刻範囲を指定して検索トークンを指定しているだけ です。

#!usr/bin/perl
use strict;
use Time::HiRes qw( gettimeofday tv_interval );
use TokyoTyrant;
my $db = TokyoTyrant::RDBTBL->new;
$db->open("localhost", 1991);
my $qry = TokyoTyrant::RDBQRY->new($db);
$qry->addcond('3', $qry->QCNUMGE, 1275591600);
$qry->addcond('3', $qry->QCNUMLE, 1276196400);
$qry->addcond('14', $qry->QCSTRAND, 'はやぶさ');
$qry->setlimit(1000);
my $t1 = [gettimeofday];
my $rv = $qry->search();
printf "TIME: %.2f s\n", tv_interval($t1);
printf "RESULT: %d records\n", scalar @$rv;
printf "%s\n" . $qry->hint;
$db->close();

検索結果。

TIME: 19.83
RESULT: 53 records

using an auxiliary index: "3" desc (NUMLT/NUMLE)
auxiliary result set size: 1191219
using an index: "3" asc (NUMGT/NUMGE)
limited matching: 1000
result set size: 53
leaving the natural order

119万件から53件見つけるのに20秒弱(！)かかる 。これはいったい............ そもそも多くのRDBMSではlike演算子以外にテキスト検索の手法を持たないから、 検索時間を責めるのは不当に感じる人もいるかもしれないけど。

何かおかしいので以下の2行を抜いてみる。時刻レンジはなくなってしまうけれど.....

# $qry->addcond('3', $qry->QCNUMGE, 1275591600);
# $qry->addcond('3', $qry->QCNUMLE, 1276196400);

TIME: 0.10 (速い)
RESULT: 100 records(増えてる)

これはひどい......条件を減らして件数が多くなるほうが速いとか何なの。 複合検索の意味あるのかよ、と。

_ [Linux][開発] ソースコードを追いました

本質的な問題はTokyo Cabinetのtctdb.cにあります。全体はこういうループなのね。 で、mcondという変数にメインの検索条件を、ncondという変数にサブの検索条件を登録する。

static TCLIST *tctdbqrysearchimpl(TDBQRY *qry){
(省略)
 for(int i = 0; i < cnum; i++){
   TDBCOND *cond = conds + i;
   for(int j = 0; j < inum; j++){
     TDBIDX *idx = idxs + j;
     if(!strcmp(cond->name, idx->name)){
     (省略)
   }
 }
}

まずこれがいけない。iがカラム方向で、jが使われているインデックスの種別だから。 本当に順番に検索条件を指定してしまっている。 古くから売っているRDBMSでここまでずさんなのは存在しないだろう。 検索条件の適用順ソート、つまりコスト推定は必須のアルゴリズム だと思います。 メインの検索条件には、なるべく件数を絞り込める条件を持ってこなければならないわけ。

例えば新聞データベースで「東京」って入力したら数万件ひっかかってくるだろうけど、 「パラダイス」だったら数百件かもしれない。だったら「東京」＋「パラダイス」という複合検索だったら、 「パラダイス」を先に検索して、その結果から東京を含むものを抜く...って当然するよね。

数値型でも同様。データの特性にもよるけど、全体が均一に入っていることを期待しなくても、 数値の分布を集計しておいて、投機コストを算定するくらいは商用RDBMSはやっているはず。 極端な話、最小値が10000で最大値が20000である数列に対して「検索条件は数値100未満」と 指定したら、それは結果ゼロ件に決まっているわけです。そんなに難しい話じゃないです。

このように、投機コストによる複合検索条件のソート、というものは検索時間に大きな影響を与えるわけです。 むしろこれがインデックスと並んでRDBMSの各社がアルゴリズムにしのぎを削っているところ、と言っても良いんじゃない でしょうか。

真に重要なのは検索結果レコードを取得する（投機）前に、コストの見積もりを行う ということなのです。

_ [Linux][開発] さらに良くないことに....

こちらは本質的な話じゃないけれど。富豪プログラミングというんですかね。 tctdb.cではサブの検索条件の結果をnmapというテーブルに格納してしまうらしい。

 if(ncond){
   ncond->alive = false;
   acnum--;
   nmap = tctdbqryidxfetch(qry, ncond, nidx);
   max = tclmin(max, TCMAPRNUM(nmap));
 }

いやこれはダメでしょう。なぜかって？ 検索結果が110万件でも全部メモリに読み込むのかい？ と いうことですわ。実際、TC/TTは 読み込んでいても110万件をたった19秒！ で済ませている(AthlonII X4 605e時) ので、とても優秀だと褒めるべきなのだろうか....

検索システムを作るときは、何の入力に検索時間や品質が比例してほしいか、 最悪値はどこか、トンでもない条件でトンでもないことにならないか、これらを良く考える必要があります。

まあ所詮、俺のRDBの知識は2000年前半、メモリ32MB,HDD320MBのPC、読んでいた本は リコーの研究所の中の人が書いた絶版RDBMSアルゴリズム本（笑）なので、 最近のオンメモリDBとかの常識は知らんのですが、俺の常識ではこんなことはしない.... するとしても投機コスト（つまり件数が少なくてメモリに読み込めば高速化が見込めるということ）がわかってからだね。

_ [Linux][開発] なのでadhocパッチ

http://linux.papa.to/images/20100610.tctdb.patch

いや本当にアドホックで、ncondの条件にITTOKEN/QGRAM系が優先的に入るようにしただけですヨ。 数値条件を2つ以上指定すると、やはり上記のnmap問題にぶつかります。

まあ、KVS一派を「RBDMSより速いデータベース」「21世紀はNO SQLの時代でしょーHAHAHA」などと 呆けた認識をしている人間は 俺以外にいないと思いますが(爆死) ........いないよね？ゴクリ

_ [Linux][開発] Lua拡張

まあLua拡張でも勉強してみますか....素性がいいだけにもったいないよねえ。

_ [雑記] BOOKSCAN

BOOKSCANに出した初回の漫画スキャンが 帰ってきた。漫画はここらへん....

ヤンデレ彼女 1 (ガンガンコミックスJOKER)(忍)

ヤンデレ彼女 2 (ガンガンコミックスJOKER)(忍)

ヤンデレ彼女 3 (ガンガンコミックスJOKER)(忍)

BOOKSCANの納品は、 自社サーバにアップロードしてPDFをダウンロードする タイプ。一冊100円と言ってもファイル名を変更するのにもお金が とられるのでなかなか厳しい。

_ [雑記] スキャンの品質は....

まあ、自分でやるより汚いかなあ。中の人たちの作業ラインによって、技術力も違うようです。全然考えてなかったんだけど カバーはスキャンされない のが地味に痛かった。 漫画スキャンはちょっと悲しいPDFになって帰ってきます。

原本を捨てられる のでリカバリーは不可能。 次からはせめてカバーとカラーページと表紙だけでも スキャンしておこう。自宅にはブラザーの複合FAX機があるので USBメモリを差してボタン押すだけでスキャンできますから。

BROTHER Mymio A4インクジェットFAX複合機 デジタル子機1台 MFC-935CDN

じゃあ最初から自分でやれば？...うん、昔はやってた。 でもスキャン以前に 悪魔の裁断 で手が痛くなる。 業務用の裁断機があるわけじゃないからな。 そういう意味では、代ゼミの横にあるようなコピー屋さん？ で裁断機を貸してもらえればイナフなのかもしれぬ。

.......エロ漫画分解してるところは見られたくないが。 肉厚の雑誌はアイロンで背表紙を溶かしていたなあ(しみじみ)

_ [雑記] 出版の真の敵

まあ、こういう新しいサービスが出てくると、 もはや破綻してる著作権法やら私的利用の範囲をもちだして ギャンギャン言う連中がいるんだが、冷静に考えると 実はブックオフよりマシ なんだよな。

はっきり言えば、古本は再販制度と絶版という２つの 書籍流通の「欠陥」によってもたらされているわけだが、 ブックオフでいくら流通しようが 出版社には一銭もはいらん とおもうのだが俺何か間違ってる？

BOOKSCANはあまりに古い本はスキャンしてくれないし、 折れたり縒れてる本もはじくわけ。 新設されたプレミアム会員制度を見ればわかるけど、 利用者はAMAZONから直接新品を買って送りつけてるわけだ。 つまり 少なくとも1冊は売れる.... どっちがいいと思う？

BOOKSCANを今すぐ認めてくれ、とは言わない。 例えば、同一本の スキャンデータを使い回し、余った実本をブックオフに売って ウマー！という問題が考えられる。

いや、今のBOOKSCANがそんなあくどいことしてるとは言わないけど。 でも、非常に手間のかかるスキャンを1冊100円でひきうける.... そのことに裏があると考えるのは普通の思考でしょう。 人件費、事務所代、裁断機やスキャナのメンテナンスなどを 考えると、どー考えても500円/冊はとらないとペイしないと思う。 おまけに鳥取あたりでやってるならともかく、事務所は 東京だしなあ...

というわけで、出版社さん、 日経新聞電子版みたいなこと、つまり 実本を買えば電子データもついてくる というのが 理想のビジネスモデルだと思うんだがいかがでしょうか？ これなら誰も痛まないと思うし、完全な電子化がなされるまでの 時間稼ぎにはなると思いますよ。

まあ、そうこう言ってる間にiBookは何回もダウンロード可能、 iPadでもiPhoneでもインストール可能ってわかっちゃいましたな。 残された時間は決して多くはないよな。

日本の音楽業界はほとんど死に絶えたけど、 次は出版業界が死に絶えるんだろうなあ。どうしてこう馬鹿なのかね。

_ [雑記] ただひとこと

_ [雑記][テレビ] しかしリアルタイムではどこも中継しねーのな！！テレビは！！

もっと遠くへ行った探査機は他にもあるさ。ボイジャーとかな。 でも帰ってきたのはこいつだけだ。唯一無二のものなんだぞ。 そういう意味では中国ロシアはおろかNASAをも上回る成果をあげている。 それをJAXAの連中は、少ない予算で、度重なる故障を乗り越えて、 知恵を絞って成し遂げたわけだ。

が、その頃テレビは仲間由紀恵に藤原紀香に志村けんかwwww 本当にどうしようもない。付ける薬がない。 リアルタイムであることがテレビコンテンツが生き残る 唯一の生命線なんだが....

_ [雑記][テレビ] 近い将来

今から10〜20年くらいで、団塊の世代と呼ばれる大半が 徐々にではあるが人生からフェードアウトしていく。 そうなると....もう地上波のテレビなんて誰も見なくなる んじゃないか？

案外10年後、デジタルテレビは存在しても、見てるコンテンツは UstreamだったりYoutubeだったり ニコニコ動画だったりするかもしれないね。 その時代に今のテレビ局が、今の形で生き残ってる可能性は イトカワに軟着陸して地球に帰還するくらい低いと思うもの。

_ [雑記] 弟の引っ越しを手伝いに

18日から弟の引っ越しを手伝いに静岡某所に行って まいりました。しかし弟は結局仕事で来れなかった... 俺が引っ越すわけじゃねーんだぞ！ふざけんな！ ひとりで掃除してひとりで片付けてた。これなんて苦行プレイ？ おまけにスコールのような土砂降り！天は我を見放した....

なのでこの日は写真が全く残っていない...

ちなみに引っ越したところは 悪名高きレオパレス です。 ここらへん参照。有名なコピペはヨハネスブルグコピペに似た阿鼻叫喚の地獄絵図らしい。

• エアコンが勝手に切れる
• チャイムならされたと思って玄関を開けたら、四軒隣の部屋だった
• チャイムが聞こえ今度こそはと思ったけど、やっぱり隣の部屋だった
• チャイムを鳴らしたら住人全員が出てきた
• ティッシュを取る音が聞こえてくるのは当たり前、携帯のポチポチが聞こえることも
• 爪切りの音も聞こえる
• 納豆をかき混ぜる音も
• 壁ドンしたら壁に穴が開いた
• というか、穴が開いたあとも開くまえと聞こえてくる音は変わらなかった
• 壁に画鋲をさしたら隣の部屋から悲鳴が聞こえた
• 隣二部屋を借り、「これで防音ばっちりだ」と思ったがさらにその向こうの部屋の音が聞こえてきた
• 右の隣の部屋の住人が屁をこいたら、左の部屋の住人が壁ドンしてきた
• すかしっ屁の音が聞こえる、というか臭いもする
• だけど家賃6万
• 業績悪化でさらに壁が薄くなる
• 将来的には壁がなくなる可能性も

ほぼ新築なのでここまで酷くはなかったが....エアコンは確かに3時間で切れるけど。しかし 長い間住むとレオパレ住人は忍者と化すらしいので、たまたま周囲が忍者だらけだったのかもしれない。

それより驚いたのは、給湯器を切るスイッチが最後まで見つけられなかったことだ.....お湯だしっぱなしにしたらいろいろオワル。

あとネットは悪名高きLEO-NETそのものであり、しかもSTB以前から分岐してもDHCPアドレスはもらえるがIPルーティングしてくれない（認証しないと使えないし、認証したMACアドレスからしか通信できない）クソ仕様でした。

まあ俺が住むわけじゃないからいいけどさ....

_ [雑記] お茶の郷

そんなわけで18日は水道ガス開通と掃除で潰れ。 19日は母が合流したので、掃除機や風呂マットなどを買い、 最後に お茶の郷に行ってきました。 Q.なぜお茶の郷・・・・？ A.ここしか観光地がないから

お茶飲み放題だったのでガブガブ飲んだ。

_ [雑記] いまさら思い出した

富士製パン（株）のようかんパン！探すの忘れたー！ いや、いっぺん食ってみたいんだよね、ようかんパン....

_ [雑記] 我慢は身体に良くない（長文注意）

先月からiPhoneにAPNDisablerという通信禁止プロファイルを インストールし、「ソフトバンクの通信費を抑えよう」という 実験を行っていたわけだが......

おととい金曜日から静岡に弟の引っ越しを手伝いに行っていたのだが、 もうGoogle Map見られないのが不便で不便で発狂 していた。 ちょっと昼飯を食う店を調べるにもネットが必要。 メールのチェックもTwitterもできなかった。 携帯電話がなかった時代、どうやって店舗を調べてたのかさえ 思い出せない.....ネットジャンキーすなあ。

そんなの「APNDを削除して再起動すればiPhone今まで通り使えるじゃん」、 というのは、まあ禁断症状出ているときは四六時中考えていたんだけど。

俺のiPhoneはiPhone for everybodyキャンペーンに登録していない旧プラン(２年縛りが死ぬほど嫌）なので、 パケットをフルにつかうと5985円/月かかるわけです。ソフトバンクはやることが汚くて、 ホワイトプランもいつのまにか2年縛りになってて （しかもプラン名自体には何も変更がなくて）、なかなかに酷いのだが。 日本でiPhone使って修理も受けられるように するには、まだソフトバンクに依存せざるをえない、そんな 揺らぐ乙女ごころ 。

というわけで、他にPCを持ち歩いた時とか、これからiPad（買うのか？)や任天堂3DSみたいなゲーム機と共用するのに、モバイルルーターを 検討していた。iPhoneの標準パケットプランだと使わない月は 1029円/月で済むので差額は4900円ほど。これでまかなえる範囲で あれば2台持ちでもいいわけだ。

この手のポケットルーターの先駆者と言えば イーモバイルPocketWiFi なんだけど...どうもたった数十万会員さえまかなえなくなったのか、 先日 従来の30倍に帯域制限を強化したばかり.... イーモバイルは散々煽ってたけどね、営業部長自ら「もう家の固定回線は解約しました！」みたいな。信じて買った人は本当に騙されたようなもんだよ。

いくら安くても2年縛りのリスクは当然ある というのが俺の感想です。特に通信業界は進歩が速いしねえ〜 俺が2年縛り嫌いで、端末も割賦せずに満額で買うのはこういう訳。

_ [PC][小物] シンセイURoad-7000

前置きが長くなってきたけど、本日開店直後のビックカメラへ行って、 ビックカメラWiMAXと シンセイCo.WiMAX URoad-7000を契約してきました。

一応事前に疑問に思ったことをUQのヘルパーさんにぶつけまくって きたんだけど。ほぼ聞いていた通りだった。

1. 30日未満解約で2100円(税込...たった？！)の契約解除料が発生
2. URoad-7000はビックカメラWiMAX契約前提
3. 解約してもビックカメラであれば何度でも再加入可能
4. 月の途中の解約は日割り計算(日割り？！)
5. 新規契約事務手数料2835円(税込、これは普通)
6. BIC定額加入で本体4800円(税込、これもまあ普通かな)
7. BIC定額はプロバイダ費込みで4480円/月(税込、今キャンペーン中なので13ヶ月間3780円)
8. 途中でBIC定額Wに変更可能(380〜4980円/月税込、380円で寝かせられる)

あまりの素直さに逆に呆れた。ドコモ／au／ソフトバンク／イーモバイル、全部2年縛りの解約金1万円弱がデフォルトみたいになってるからなあ。 「縛り」と呼べるものはプロバイダがBICWiMAX専用であることと、30日未満の解約以外何もない 。これは実はすごくないか？

即日解約すると4800+2835+3780/30+2100=9861円で本体が手にはいる計算になるが.....いくらプロバイダがBIC WiMAX縛りとは言え、これでいいのか、という気になるな。まあプロバイダ縛りに関しては「そんなこと言ったらau光oneなんて詐欺同然」ちう話になってしまうので考えないことにする。 ちなみに シンセイ直販で縛りなしURoad-7000は 19800円 だからな....

というわけで、文句のつけようがないので契約してしまったわけさ。

_ [PC][小物] 速度はどうよ？

自宅ではWiMAX電波のランプは黄色(あまりよくない) http://www.speedtest.net/で測定してみた。 クライアントはMacbook、接続はWPA2/AESで。

けっこう満足 。使わければ380円プランに変更しようと思う。

_ [PC][小物] URoad-7000の起動時間

iPhone側はWifiTrak(自動接続ソフト)を起動しておいて、 URoad-7000の電源ボタンを押した。

1. 電源押した瞬間からWifiTrakがSSIDを発見するまで： 24秒
2. そこからWifiTrakが接続を確立するまで： 21秒

ということで 一応45秒くらいで使えるようにはなる みたいです。 まあ遅いっちゃー遅いよね。 b-mobile WiFiという日本通信のモバイルルーターが ボタンを押してから60秒かかるようなので心持ち早い、くらいかなあ。 まああちらはつながっても300Kbpsだけど。

_ [PC][小物] レイテンシが長い

自宅でのBIC WiMAXの最高記録。測定はiPhoneアプリで。

自宅のGyao!光VDSLマンションタイプをバッファローWHR-G300Nで中継すると、こうなる。遅いのは多分マンションタイプなせい。

遜色ない...といえば遜色ないんだが WiMAXのレイテンシが長いのが気になるな....

TCPのフロー制御は、パケットの欠落率と、レイテンシの２つで左右されるので、多分長いファイルをダウンロードしようとすると自然と速度が抑制されるようになると思う。そもそも、11gの無線LANを使っている時点で80msくらいの遅延はあるはずなので、あんまり気にしてもしょうがないんだが。

iPhoneアプリのせいかな？と思ってMacbookをURoad-7000につないでpingをyahoo.co.jpに打ってみたのだが。

PING www.ya.gl.yahoo.co.jp (124.83.147.202): 56 data bytes
64 bytes from 124.83.147.202: icmp_seq=0 ttl=52 time=177.572 ms
64 bytes from 124.83.147.202: icmp_seq=1 ttl=52 time=106.275 ms
64 bytes from 124.83.147.202: icmp_seq=2 ttl=52 time=106.224 ms
64 bytes from 124.83.147.202: icmp_seq=3 ttl=52 time=202.067 ms

よけいひどいわい(笑) ばらつきが激しいのはエリアぎりぎりなのも影響していると思うけど。なんせLEDはずっとオレンジ(ギリギリ)で、一度も緑(つかみOK)になったことはないからな。

ちなみに、通常のNTTフレッツ光＋大手プロバイダだと、レイテンシは15ms以下のことも多々あるはず。まあ、WiMAXでシビアなネトゲとかはやるなってことですな。素直に光ひいてEthernet接続ですな。

_ [PC][小物] とはいえもう少し努力しようか...

この方のブログの情報に従い、簡易リフレクタを作ってみた。

はははご冗談でしょう...こんなもので改善するわけが....

こりゃすごい。力の限り感謝。 下りは5Mbpsから6Mbpsへ、上りは0.5Mbpsから1Mbps越え。 100均で金属ボウルを買ってくるべきか！！！

_ [PC][小物] URoad-7000のちょっとどうかなと思うところ

不満の大半は電源周りなんですけどね。

(1) USBでは充電できない、ランプが点かない、コネクタが独自

URoad-7000は本体側に充電を表すLEDが全くないため、 アダプター側にLEDがついている。しかしUSB給電ケーブルだと 本当に給電しているのか全くわからない....一応LEDがつきそうな 部分はあるんだがなあ。ACアダプターではこの位置に赤色のLEDが点灯する。

思わず不安になったので電池外してテストしてしまった。 ランプはつかなくても給電はされている ようです。

しかしこの平型の独自コネクタは本当に困るわ。 素直にminiUSBにしてくれれば良かったのに。

(2) 充電残量を見る方法が本体LED3段階だけ

一応、無通信状態(待ち受け)だと4時間強持つんだけど、 Web管理UIから電池残量を見る方法が全くないんだよね...... 放電テストしていても、どのくらいの時間で、どのくらい減るのか、 わからないから不安。 目安の数値くらい出してくれてもバチはあたらんでしょーに。

(3) 節電機能が全くない

Portable Wi-Fi 並みのスタンバイ節電機能が欲しいとはいわないが、 せめて無通信1時間で電源OFFにする機能くらい 用意して欲しい。 いくらなんでも手を抜き過ぎだろう。

_ [PC][小物] でも速い！

今日外で使ったけど、歩きながらでも十分使えるねえ。 そして速い。iPhoneの特性上、接続確立は3Gの方が当然速いし 快適なのだが、WiMAXの方は、まさにWiFiアクセスポイントを外へ 持ち歩いている感覚だ。 WiMAX自体がモバイル通信回線なんだから、例えとしてはおかしいんだが、 要するに家や会社の回線を持ち歩いてる感覚だってことですわ。 Google Earthみたいな通信量の多いソフトだと如実にわかります。

_ [PC][小物] でもシビア

かばんの外ポケットにいれていると6Mbpsくらい出てる状態で、 かばんの中にいれるとダメ。ペットボトルのそばにおくと3Mbps切る。 オフィスの窓際だとサクサクつながっているが、ほんの2,3m内側の デスクだとつながらないとか。

ソフトバンク3Gもかなり難物だったけど、ここまでは酷くなかったよーな。やっぱりWiMAXは2.5GHz帯だから浸透性が低いのかなあ。 商用WiFiホットスポットの範囲が糞狭い(2.4GHz帯なので)のと、 ほとんど同じ理由なのかもしれぬ。

いや素人考えだけどね。

_ [iPhone][小物] iPhone4機種変完了

まあいまさらだけど 速いね！ なんせ3Gから2年だからなあ。 特に日本語入力パネルの表示されるスピードが段違いで笑った。 3GだとTwitterクライアントからパネル呼び出すと余裕で30秒は 出てこなかったからな！！

まあ3GSをパスったからこその感動かもしれない....。 今3GS持ってる人は微妙かもね。3GはiOS4でかなり機能制限されちゃ ってるけど、3GSとiPhone4はソフト的には(解像度以外)ほとんど 同じみたいだから。

_ [小物] しかし汚いわ

なーんの説明もなくWホワイトと基本オプションパック強制 でしたよ。田舎の代理店はダメだねえ。はよ解約せな.....

こういう小汚い商法は自分の首締めるだけじゃないかな。 ヤクザのシノギじゃねーんだから。

逆に「説明して」「納得して」 『満足』した顧客は、きっとリピーターになってくれる と思うんだよね。 基本的に小売が生き残る道はそれしかないと思うんだけど。 量販店の方がおかしなプラン強制も頭金もなく便利、 となれば街のお店で買う理由なんてゼロだろうに。

_ [iPhone] 普通の携帯はそのまま使うのになあ

なぜかiPhoneは外装に凝りたくなるんだよね。 デザインとしては単品で完成していながら、実用性はない、みたいな(笑)

_ [iPhone] Brighton CRYSTAL CASE For iPhone 4 BI-IP4CRL/C

まず最初に買ったのはこれ。 契約した地方商店に唯一入荷していたケースだったの。

Brighton iPhone4専用 クリスタルケース CRYSTAL CASE For iPhone 4 BI-IP4CRL/C

でもかろうじて角が保護されるくらいで、 ケースは非常にヤワくて 保護機能はほとんどない と 思われる。その割には一度ハメると外しにくいし。 要するに使っていて不安なのだ。あとホームボタンの切り込みが浅くて、 微妙に押せないというか押したと思ったらすぐ上のアイコン（俺はメール） を起動してしまったことが多々あった。

付いている保護シートは 前面のみ であり、ケースも背面は 開いているだけなので保護は全くない。

_ [iPhone] BUFFALO 液晶保護フィルム&背面保護フィルム BSIPP5FS

2日ほどCRYSTALを使っていたが、背面保護がないのに嫌気が差して、 買ったのがバッファローの両面フィルム。

BUFFALO iPhone 4 (16GB・32GB)用 液晶保護フィルム&背面保護フィルム BSIPP5FS

まあデザイン見ればまんまである。指の滑りもよく障り心地も悪くない。 が！とにかく貼りにくくて気泡だらけになってしまった..... CRYSTALのほうが貼りやすかったなあ。最終的に中性洗剤入りスプレーで 水張りを強行したが これも大失敗 であり 俺の甲子園は終ったのである(何)。

_ [iPhone] Brighton TPUケース TPU CASE FOR iPhone 4 ブルー BI-IP4TPU/B

今はこれで我慢してる。

Brighton iPhone4専用 TPUケース TPU CASE FOR iPhone 4 ブルー BI-IP4TPU/B

やたらBrightonに貢いでる気がしないでもない....が、 TPU素材なのでポッケにも入りやすく、背面も保護できるので なかなかよろしいです。つなぎとしてはよいのではないか。 青は展示ではチープだけど、iPhone4黒本体とあわせると なかなかシックですよ。

あと余談だけど、iPhone4って背面がつるっつるの平坦なので スイカとか入れられます(^^;これは便利。まあこのケースの 特徴じゃないけどね。

_ [iPhone] 理想のケースを求めて...

3Gでは最も長く使ったのは実は スキンエボリューションなんだけど。ケースじゃなくて全面保護シートね。

でも......これはもうやりたくないくらい 貼りにくかった ので、 できれば避けたい。丈夫だから保護って意味ではいいんだけどねえ。 なんせ 2回コンクリに落とした けど、このシートはって あるだけで無事だったんで(※注意：個人的な感想で製品の特徴を表すものではありません）

その後、汚くなって剥がしたら、普通のフローリングの床に 落としただけでマナーボタンの端からクラックはいったわ..... なので俺の3Gは売れないのです。

_ [Linux][開発] TokyoCabinetの複合検索を高速化した

http://linux.papa.to/image/tokyocabinet-1.4.45.scost.patch.tar.gz がパッチとバッチ。 彗星の煌めきのごときmikio wareに、俺のゴミパッチを当てたら当然 クォリティは下がりますので、そこんとこよろしく。責任とれまへん。 ライセンスはオリジナル準拠です。

_ [Linux][開発] 内容説明

TokyoTyrantのサーバであるttserverを起動しておいて、

% sh server.sh [ENTER]

setindex.plを実行してインデックスを作成し、ins.plで100万レコードを 登録したデータベースに対して、search.plで複合検索を行う、という実験です。 パッチ自体はTokyoCabinetに対するものですが。

登録するデータは、ニコニコ動画のタグや掲示板の書き込みのようなものを思い浮かべてください。 投稿者(uname)と、投稿本文またはタグ(ptoken)と、投稿時刻(time)がある。 時刻はUNIX起源時間にすると見辛いので1〜100万までの整数にしてある。

search.plは、このTTに対して複合的な検索クエリーを発行する。例えば 「ある開始時刻〜終了時刻の、ユーザほげほげさんの投稿を、古い順に100件探す」みたいなかんじです。 ありがちな処理でしょ？

my $qry = TokyoTyrant::RDBQRY->new($db);
my $start = ($j * 12345) % 1000000;
my $end = $start + 3600;
my $user = $users[$j % 50];
print "TIMERANGE: $start - $end  USER $user\n";
$qry->addcond('uname', $qry->QCSTREQ, $user);
$qry->addcond('time', $qry->QCNUMGE, $start);
$qry->addcond('time', $qry->QCNUMLE, $end);
$qry->setorder('time', $qry->QONUMASC);
$qry->setlimit(100);
my $rv = $qry->search();

完全乱数だと実行結果の比較がしにくいので、検索時刻範囲やユーザ名は、 剰余によって、同じものが決まった順番で繰り返し出るように細工してあります。

_ [Linux][開発] ベンチマーク

search.plの100クエリーの総実行時間(秒)

各クエリーのラウンドトリップタイムの分布(X軸: 試行回数, Y軸：秒)。

条件によってはオリジナルの方が速いこともありますが、 概ね安定していることがこのパッチのメリットであります。

当たり前ですが

検索結果自体はパッチ前と後で同じです(grep KEY:したテキストを比較して確認)。 ただし、このパッチでは20秒以上かかる検索は問答無用で打ち切りますので、 検索結果が異なることはあります。

_ [Linux][開発] なぜ速くなるのか？

検索条件に対して 投機的コスト算定とソーティング を行っているためです。 但し、まともな算術アルゴリズムではなく、tctdbqryidxfetch()にタイムアウトを付加した アドホックなものです。Athlon64/2.4GHzより速かったり遅かったりするマシンでは 動かないかもしれません。

_ [iPhone] iPhone4のカメラには青カビが潜んでいる

蛍光灯下でiPhone4でクリーム色の壁を撮影してみる。

どうしてお空は青いの？

フラッシュを炊いてみた。

やっぱり青いな... これは新しい裏面照射型CMOSの特性ですか？ 前のiPhone3Gもカメラの画質に関してはかなり酷かったが、 フォーカスなどをいじっても全く治らないという点で今回の方が 深刻だ。

せめてトイデジカメくらいの画質にはなって欲しいんだが...... やはり別途デジカメが必要だなあ。