ぱぱネット（仮）

_ [Linux][開発] TokyoTyrantが固まる固まる

TokyoTyrantでシステムを組んで、ようやく（俺側の）バグも減ってまともに動き出したのだが... 何かおかしい。特に80万件ほど突っ込んでいる検索サーバが 使っているうちにどんどん遅く、しまいに応答を返さなくなる のだ。これがひどくて、検索クエリだけならともかく レコード数さえ数えられなくなる のでマジ異常。

# tctmgr inform -port 20301 localhost

だけで5分くらい固まるからな。

_ [Linux][開発] 先に結論

xmsizってのは

`xmsiz' specifies the size of the extra mapped memory.  If it is
not defined or not more than 0, the extra mapped memory is
disabled.  The default size is 67108864.

というわけでmapped I/Oのためのメモリ領域のようだ。特にデータベース全体が メモリにすっぽり収まっているサイズの場合は高速化が期待できる。

しかし.....これを11テーブル(プロセス)、各10スレッドで動かすとこうなる。

特に注目すべきはcommitedの値。overcommitが許されるからといって 実メモリの倍ってどういうことだ？！ 感覚的には何かおかしなことが 起こってもおかしくない（持って回った言い方だが俺もこれが本来の状態かわからんのだ）。

しかし、当然のごとく運用実績の乏しいTokyoTyrant/TokyoCabinetでは 似たような事例はなく。しょうがないからソースを読んだのだが..... テーブルDBにつけてる全部のインデックスでmmap()呼んでるうううう(^^;

なんでこんな実装になってるんだ。11プロセスで打ってあるインデックスは99個。 各テーブル自体もtchdbなので 99+11=110回mmmap()をコールするわけだxmsizのサイズで。 デフォルトが67MBだから....67*110=7370MB....

グラフとだいたい計算もあう。もちろんLinuxのVMががんばるから多少オーバーしても大丈夫なんだ。 でも、1日くらい20並列くらいでクエリーを投げつづけているとだんだん遅くなってきて...というパターン。

やっぱりTokyoTyrantのテーブルDBって「おまけ」で、 誰もまともに使ってないんだね....大失敗だ。しかも初期の負荷テストでは全く 気付くことは不可能だと思いませんかね。

_ [Linux][開発] んで対策

全部に#xmsiz=8mをセットして みた。

実際にはVMに収まらない部分はどうせディスクにアクセスしにいかなければならない。 でもB木のリーフノードなどのチャンクがメモリに入っていると若干都合がいいので、 多少は確保しておいた方がいいかもと思って8MBだけ設定してみた。

これで様子みるわ。