ぱぱネット（仮）

_ 金ないといいつつ・・・

実は散財していた。休日に Advanced W-ZERO3[es] に機種変してきました。しかし、例によってWindows Mobile。 標準状態では全く使い物にならない訳で。 未だに[es]の方を使っています。こういう芸当が可能なのもW-SIMがあればこそ。差し替えてオンラインサインアップさえすれば使えるからな。

しかし困ったのは充電。Adesの電源端子が今まで見たこともない形状に なっていて焦る。Windows Mobileは電池持たないから、自宅,会社,実家, 車に充電環境が必要なんだが。今まで通りEIAJ#2にしてくれよ・・・

速攻で変換アダプタを予約 したけど来るのは10月下旬ということで気の長い話である。

で、お決まりの電子工作である。

無印良品の筆箱(210円)にAdesがすっぽりハマる（厚み方向がキチキチではあるが） ことに気付いた私。

昔、玄箱の基板にシリアル端子用のポストを立てるために買っておいた ピンをばらして、筆箱に千枚通しで穴あけて、6Vジャック(メス)に半田付けして差し込んだ。 Ades向かって左側がプラス、右側がマイナスね。

・・・端子にクッションの役割がないので接触がかなり怪しい。 が、意外と筆箱の厚みが足りないのがプラスに作用して、 本体をそーっと差し込めるから位置合わせが楽(重力を利用して上から グサッとやると、クッションないから本体側が壊れそうだしな）。 まあ工作としては失敗レベルだが・・・総工費400円前後だから目を瞑る。

なんせ、 プラスチックの充電台 が1980円もするウイルコム！。ACアダプターは3100円だから余裕で 5000円越えるわけだ。いくらなんでもボリ過ぎだろテメエ('A`)

とりあえず筆箱クレードルもう1コ作るつもり。出力5VのACアダプターで 安いのありませんかね？本当はPSPのがいいんだけど フザケルナ！っつー値段 なんだよなこれも・・・・

_ [ワンセグ野郎][雑記] チューナーまとめた

ツテを頼ってチューナーを集めている間にずいぶん間があいたなあ。 本数はちょっと少ないが仕方ない。 今回は付属品が一切ないので（失敗が許されないので）ひやひやした。

_ [ワンセグ野郎][PC] PCもチャレンジ

CENTURY CF-A8989BK150 / キューブタイプmini-ITXケース (ブラックモデル) 価格：7,318円（税込、送料別）

前回はATXケース（そのなかでも飛び抜けて重いSOLO）だったけど、 今回はminiITXケースを使って可能な限りコンパクトに納めるつもり... 5インチベイのところになんとかチューナーを詰め込めるかなと。

甘いかなー....

_ [開発][Linux] MongoDBを使うなお

最近「注目のNoSQLデータベースMongoDB！」みたいな持ち上げられ方をしているMongoDB。確かにSQLライクな複合構文を持ち、自動的なデータ分散のShardingなどを備えていてモダンな感じ。しかし.... とにかく不安定で困る....

以前、東京キャビネットを使っていた時も散々文句を言っていたけど、今考えればこいつは素直な部類であった。

例えば、多数のインデックスカラムを持つテーブルに対して、大量のデータを登録した場合：

• TokyoCabinet→各行の登録が遅延（グローバルロック）
• MongoDB→ 登録を諦める

お次は検索。全データをサーチするような用途ではどちらもカーソルを使うのだが：

• TokyoCabinet→何百万レコードあろうが最後まで回る
• MongoDB→ 突然検索を諦める（エラーにもならない)

最後はサーバ同士のレプリケーション(いわゆるプライマリー／セカンダリーというやつだ）性能：

• TokyoCabinet→データが立て込んでくるとクエリーが遅延する
• MongoDB→ セカンダリーが突然レプリケーションを諦める！自動復帰もしない！

............

....

本当に簡単に諦めて、しかもresultとってきても原因がわからないので困る。さらに、MongoDBでは、Shardingで複数サーバにデータが分散している場合 同じレコードが2,3個帰ってくる ことさえある。さらに登録したデータにensureIndexして、 すぐ検索できると思ったら大間違いで MongoDB が暇になったらインデックス貼ってくれるくらいの遅延をする。

もちろん....アプリ(クライアント)側でできることは沢山ある。追加時は{safe:1}をつけたり、find()の結果をみて検索処理を分割したり、そもそも巨大クエリーは投げないように工夫したり、snapshot()で重複データを除いたりするノウハウはあるんだよ。

でも.....半年くらい使ってきたけど ちょっとプロダクトレベルに達していない 印象が。2.2.0(stable)とか書いてあっても全然安定版じゃない。ふつーにデータ登録してふつーに検索(この場合のふつーはMySQLみたいな豪勢なものの話じゃなくてTokyoCabinetレベル)することが、できないよ。

補足として MongoDBを使うなという議論があったこともつけ加えておく。けど、 採用を検討してる人はもう一度考えなおした方がいいかも。

しかしこれらを すべて差し引いたとしても「許せない」ことがある ....それは mongos(プロキシー)が突然死する ことだ。たぶん実験室レベルでサーバ1台でやってるときは絶対気づかないだろう。Shadringも使わないだろうし。でも通信や負荷が少し不安定な環境で実運用に近い形でやってみれば、mongosのフリーズは10回や20回では収まらないことはわかるはず（同志いませんかね？)

しつこいが、何かクリティカルなことをしてるわけじゃなくて、単純なドキュメントを挿入してるだけなんだ。でもmongosは応答を返さなくなる。ポートlistenしたままプロセスが残るとか超極悪である。

@400000005074f7cb3b3478a4 *** glibc detected ***  /usr/local/bin/mongos: free(): invalid pointer:  0x0000000000b183e0 ***
@400000005074f7cb3b34f5a4 ======= Backtrace: =========
@400000005074f7cb3b35b50c /lib/libc.so.6(+0x71bd6)[0x7f558afe5bd6]
@400000005074f7cb3b36591c /lib/libc.so.6(cfree+0x6c)[0x7f558afea94c]
@400000005074f7cb3b382224 /usr/local/bin/mongos(_ZN5mongo13BackgroundJob7jobBodyEN5boost10shared_ptrINS0_9JobStatusEEE+0x1b9)[0x525119]
@400000005074f7cb3b39e35c /usr/local/bin/mongos(_ZN5boost6detail11thread_dataINS_3_bi6bind_tIvNS_4_mfi3mf1IvN5mongo13BackgroundJobENS_10shared_ptrINS7_9JobStatusEEEEENS2_5list2INS2_5valueIPS7_EENSD_ISA_EEEEEEE3runEv+0x74)[0x527394]
@400000005074f7cb3b3c3904 /usr/local/bin/mongos(thread_proxy+0x80)[0x806720]
@400000005074f7cb3b3c6014 /lib/libpthread.so.0(+0x68ca)[0x7f558ba888ca]
@400000005074f7cb3b3d2f1c /lib/libc.so.6(clone+0x6d)[0x7f558b04392d]

落ちた時のトレースとってみてもShardingのロック周辺に、何かバグがあると思うんだけどなー....俺も追いきれてない。

実際にMongoDBを大規模運用してるサイバーエージェントとかどうしてんでしょうね......本当に金払ってもいいから聞きたいわ。それ以前にこんなおっかなビックリしながらデータベース使いたくないけど。

_ [開発][Linux] 文句が長くなったがMuninプラグイン

こんな状態なので、当然MongoDBを監視するということを考える必要がある。しかし上記で散々グダグダ書いていたmongosはプロキシなのでほとんど何のデータも持たない。なのでこいつ自体はプロセスをmongostatか何かで監視して応答なくなったらKILLするスクリプトを書けばいい。問題は配下のconfig serverやsharding server。こいつらは状態監視する以外に特段の方策がない。

そこでサーバ監視ではお馴染みのMuninのプラグインを書きました。 実は本家にもプラグインはあるのだが、本家とコレとは 監視する箇所 が違うのである。

本家はオーソドックスな発行命令数が採れるだけである。 でも個人的なたった半年の経験からして 各コマンドの「重さ」と「命令数」 にはあまり強い相関がない気がする。 補足資料として Akihiro Kuwanさんのアレをアレする をご覧ください。

俺的にはMongoDBが落ちる時は mongostatでいうlockedが長時間高くなった 直後に落ちてる気がしているのでmongostatを監視するMuninプラグインを書きました。ついでにデータベースのモードがプライマリーかセカンダリーかリカバリーか不定かもグラフ表示できるようにした。これは便利！！

まあ、mongostatレベルでもたまにとんでもない値が出るのであくまで参考までに(俺のせーじゃないよ）。しかし...公式ツールでパーセンテージのカラムに6000とか出るのは正直どうなんだ？？？誰もデバッグしてねーだろ....これがMongoDBの正常なのけ。

_ [開発][Linux] インストール

mongostat_.txtをコピーして...

1. cp mongostat_.txt /usr/share/munin/plugins/mongostat_
2. chmod a+x /usr/share/munin/plugins/mongostat_

とかして拡張子をとってコピーしてください(アンダーバーは消さないでください)。

使う時はMongoDBのポート番号をつけてシンボリックリンクをはってください。つけないとデフォルトポート(27017)が使われます。

# ln -s /usr/share/munin/plugins/mongostat_ \
  /etc/munin/plugins/mongostat_5001

しかし、説明かいてて思ったけど、もしかして1サーバに多数のmongod起動してること自体が問題なのか？ちょっと鬱になってきた。