Trance Shift 7 - Notes

現Trance Shift 8.0の前バージョンのログ

TokyoCabinetのチューニングメモ

KVS TokyoCabinet

　KVSとかのストレージによく使われているTCについてKVSをより使うためのチューニングメモ。kumofs/Flare等を想定してます。基本的には公式ドキュメント*1読んだまんまですが、よく使う設定をここに。KVSを想定しているので速度を目的としたチューニングです。

コンパイルオプション

　以下は指定してからconfigureしておくといいかも。

Option Note
--enable-fastest 最速最適化
--enable-static 静的リンク
--enable-off64 64bitファイルオフセット(OSが64bitなら不要) 
./configure --enable-fastest --enable-static --enable-off64

　--enable-staticまでやるかどうかは検討した方がいいかも。--enable-fastestは-O3の最適化オプションなので指定推奨(私的には)。--enable-off64はLFS(Large File Summit)を利用するもの。要は32bitOSでも2GB以上のファイルを扱えるようになる。

if test "$enable_off64" = "yes"
then
  MYCPPFLAGS="$MYCPPFLAGS -D_FILE_OFFSET_BITS=64"
  enables="$enables (off64)"
fi

　以前このオプションを知らず32bitOSで2GB以上のファイルが扱えずハマったことが[(:3[　　]

ストレージファイルオプション

バケット数

　マニュアルにはレコード数想定と2〜4倍となっているので従うといいかと。例えば1億件のレコードが想定されるなら2^28 = 268435456(2億)程度を指定すると上手くいくと思います。

アラインメント力

　概念については、平林先生のTCに関する記事*2がとても参考になります。間違えやすいですが、設定するのは「アラインメント"力"」です。「アラインメント」は「2^(アラインメント力)」で計算できます。

  • 1.キーサイズ+データサイズ+パディングサイズ(余白)が、8byte(32bitなら4byte)*?を溢れないような値を設定する

デフォルトのアラインメント力は4なので、アラインメントは2^4=16。データは32bitなら4*16 = 64byte(64bitなら128byte)ごとに分布することになる。
この場合、|key(8)|data(8)|padding(48)|という感じになるということ。

tcucodec conf | grep blksize
4096

　例えばこの環境だとブロックサイズ4096byte。ファイルIOではブロック単位でファイルを読み書きするので、アラインメントを調整するのもまたよし。例えば4096であれば、

環境 設定するアラインメント力 備考
32bit 10 4byte * 1024(2^10)
64bit 9 8byte * 512(2^9)

　という感じにするのも手ということ。ただ、アラインメント力を単純に増やしてもファイルサイズが増大してしまうので、目安として利用するのが良いと思います。

　なので、キーサイズとデータサイズに基づいて計算したアラインメントを設定するのを基本として、もしブロックサイズの理想の値と近ければブロックサイズに合わせた値にしてしまう、という戦略がいいんじゃないかなと。

*1:Tokyo Cabinet第1版基本仕様書: http://fallabs.com/tokyocabinet/spex-ja.html

*2:mixi's Engineers' Blog Inside Tokyo Cabinet その参: http://alpha.mixi.co.jp/blog/?p=90