TTServer参数介绍
1 概述
Tokyo是Tokyo Cabinet和Tokyo Tyrant的简称，合在一起用也称ttserver。
Tokyo Cabinet 是日本人 平林�中� 开发的一款 NoSQL 数据库，数据库由一系列key-value对的记录构成，类似bdb。
Tokyo Tyrant 是由同一作者开发的 Tokyo Cabinet 数据库网络接口。它拥有Memcached兼容协议，也可以通过HTTP协议进行数据交换。Tokyo Tyrant 加上 Tokyo Cabinet，构成了一款支持高并发的分布式持久存储系统Tokyo。
对Tokyo内部机制感兴趣的请参考UC优视-陈海涛 [email protected]：《Tokyo代码分析》;
2 Tokyo的安装
测试了在32位机器和64位机器都运行正常，64位机器可以支持>2G的单个db文件；
32位机器加上编译选项” --enable-off64”后也能支持>2G的单个db文件,但是不能突破32位Linux 3G用户内存空间的限制，所以内存最大只能用3G的，除非安装64位操作系统。
可用普通用户安装和运行。
Tokyo Cabinet依赖下面的库，一般Linux会自带，编译出错的话则需先安装：
zlib : 用来压缩. 1.2.3版本或更新的.
bzip2 : 用来压缩. 1.0.5版本或更新的.
下面的例子都是基于$HOME/local目录，使用时可更改。
下载最新的包（注意别下载到旧包了），2011年推荐用的最新版本是：
Latest Source Package (version 1.1.41)
Latest Source Package (version 1.4.47)
1.1. Hash关键参数
Hash方式写入数据时直接写入文件或文件映射，并非写缓存，是比较安全的数据存储方式。
Hash方式可看作内嵌了Memcached，可减轻读压力；
但随机写入或随机更新频繁（每秒超过200次）的场合，要么内存映射尺寸xmsiz要大于db文件，要么磁盘做RAID或用高速盘。目前已知其他存储方案也类似。但要求每秒写入200次的应用场景不多，而且可通过分布式来分散写入压力。
| 参数 |
作用 |
备注 |
| xmsiz |
指定文件内存映射尺寸，单位字节. 32位机应用程序不能设置达到3G，因为后面的rcnum还会指定占用内存，所以建议32位机xmsiz配置2G； 64位机不受这个限制。但都不能设置超过机器可用内存。 在小数据量“特快”用法中，这个最重要的参数必须>=db文件尺寸，依赖内存来保证每秒几万的读写性能,缺点是耗内存，例如db文件几个月后达到8G，则xmsiz设置为8G； 在大数据量“普快”用法中，例如30G数据，xmsiz可小于db，例如8G，随机读写性能接近磁盘速度，依赖磁盘的性能，随机读写每秒只能几百次。“普快”用法中，即使不设置xmsiz，TT也会强制将刚启动时的db初始大小映射到内存,包含header、hash桶，这些频繁访问的信息一定要在内存中。 |
重启可修改 |
| bnum |
hash桶尺寸，用来保存计算完hash值后的每个key在db文件的位置，要减少hash碰撞次数，推荐设置bnum为key个数的4倍（75%的一次命中率）以上，尤其是“普快”用法中依赖磁盘性能时，如一年后key要达到1亿个，bnum则设置为4亿。 碰撞的key依次用hash map链接起来，二分法查找，增加了磁盘读写次数； 该值默认很小是131071，最大可以设几十亿以上，bnum持久化到db文件，全映射在内存，重启不可修改，能用tcrmgr optimize命令吗慢慢重写db文件。 |
重启不可修改 |
| fpow |
用来指定管理的空闲块数目，默认10表示2的10次方（即默认只能管理1024个空闲块，多余的成为碎片，不能重复利用），最大可设20（表示1024*1024）但CPU占用太高。 设置”#fpow=15”可满足批量删除32768个记录,经基准测试，设置fpow 10~17是OK的。 |
重启不可修改 |
| opts |
指定压缩方式（hash的短数据压缩比不高）和bucket array对每条数据用4字节还是8字节保存文件偏移量。 要支持db文件>64G请加“#opts=l”。 要用gzip压缩记录后存储到db文件，请加“#opts=d”。 要支持db文件>64G并且用gzip压缩记录后存储到db文件，请加“#opts=ld”。 hash方式单条数据平均长度<1KB时压缩效果差，所以hash一般不压缩。 记录数很少时，压缩让性能降低到30%，记录数越多降低越明显。 |
重启不可修改 |
| rcnum |
热点数据缓存hash map能缓存的记录数，在有明显热点数据时或xmsiz小于db尺寸时，需要设置这个参数，推荐设置为1000万~2000万，会把rnum条key和value不加压缩地放内存cache。 流程参考《TTServer源码分析》，get时将key写到这个缓存，set时从缓存清掉该key，默认0不缓存，设置则最小256，B+tree不需这个参数。 |
重启可修改 |
| dfunit |
动态碎片整理的步长，表示更新多少次记录后进行一次动态碎片整理（unit step number of auto defragmentation），而且碎片整理时只检查2 * dfunit个位置（记录或空闲块），发现记录的前面有空闲块则往前挪动记录. 如此逐步将db从头到尾整理一遍后再返回db文件记录区的开始位置继续整理。 示例“#dfunit=1024”，默认为0表示不动态碎片整理，基准测试设置16~1024的范围是OK的。 |
重启可修改 |
1.1. B+tree关键参数
B+tree是基于hash机制实现的，复用上述的db文件格式和文件映射，不同的只是最上层缓存是读写cache。写入db数据时，是按叶节点或非页节点进行了打包分页，整页写入,压缩也是整页压缩，压缩比更高。
读写都进行了缓存，写到上层缓存的树里面，树满了才交换到磁盘，所以B+tree不像hash对内存要求很高，例如2G内存可以支撑超过20G的数据。
但必须在备机上定期执行tcrmgr sync，否则异常重启会丢掉数据。
l "fpow", 同hash方式的，只需约设置为hash的1/10；
l "bnum", 同hash方式的，只需约设置为hash的1/10，因为B+tree是整页保存到hash db内。
l "opts", 同hash方式的,B+tree方式压缩是整页（128条记录）压缩，压缩效果很好，数据量大于xmsiz时用B+tree时带压缩，降低内存使用量效果明显，可加“#opts=d”进行压缩。
l "xmsiz"，同hash方式的。
l "dfunit", 同hash方式的。
以上参数详细原理请参考《TTServer源码分析》。
1.2. B+tree其他参数
l "mode", 打开db文件的操作模式，同hash。
l "apow", 记录的对齐大小（power of record alignment）, 同hash。
下面是两组性能参数
首先是分页大小，对短数据设置大些会压缩比更高：
l "lmemb", 每个叶上记录数（number of members in each leaf），默认128。重启不可修改。
l "nmemb", 每个节点上成员数（number of members in each node），默认256。重启不可修改。
然后是缓存页个数，一般不设置，除非热点数据较多,设置大了stop和sync会更费时间:
l "lcnum", B+tree缓存叶节点数，每个叶节点上默认可放128条记录作为一页，减轻读写压力，缓存热点数据的，默认1024，设的话最小64。重启可修改这个参数。
l "ncnum", B+tree缓存非叶节点数，每个树节点上默认可放256条索引作为一页，索引指向叶节点，减轻读写压力, 缓存热点数据，默认512，设的话最小64，通常为叶节点数的一半。重启可修改这个参数。
l #define BDBDEFLCNUM 1024 // defaultnumber of leaf cache
l #define BDBDEFNCNUM 512 // defaultnumber of node cache
在xmsiz足够大时以上性能参数都可不设置。
另外不用设置hash的rcnum参数，B+tree对rcnum不生效
转自：http://blog.sina.com.cn/s/blog_53781bb80100xrr7.html