转载自：http://yfyfj.blog.163.com/blog/static/154247842013264398931/?suggestedreading

简介

ttserver有两个参数#bnum和#xmsiz，其中，bnum设置桶数量，标明有多少桶ttserver中的“热数据”会交换到内存；xmsiz是使用内存的大小限制，如果不设置默认为64M。

我们在线上的部分ttserver经检查都没有设置xmsiz参数，并且bnum参数设置的值也不是很合理，所以在这里提供一个优化这两个参数的策略。

案例1：

用“群组”功能举例：群组功能在ttserver中存储每个用户的群组数量信息，每个用户要读取三种key（总数、今日数量、昨日数量），每个value约200字节，按热用户3000人计算，理论热数据应该只有2M，正常情况下即使不设置xmsiz参数应该也可以把所有热数据交换到内存，从而降低磁盘io开销。。。但事实并非如此！杯具了！

查看ttserver中stats发现数据量已达500万，容量11G，此进程IO较高，这是为啥嗫？原来程序结构中“今日数量”“昨日数量”两个数据的key中拼有日期，也就是说，每个用户除了“总数”这个数据的key是固定之外，每天都会有2条新数据产生。而当用户读取的时候在ttserver里就出现了数据冷热不均的情况，“总数”这个一直是热数据，其他两个数量一直是冷数据，所以所有用户的“总数”热数据越来越大，占据了64M内存，之后的所有读取操作都走了磁盘IO。

解决方案：

这种情况调整热数据区的方法就木有作用了，只能从程序结构中进行调整，把“今日数据”“昨日数据”两个key固定，把日期放到value里即可。这样就不会出现一个用户的三份数据冷热不均的情况了。预计调整程序后热数据区应只有2M左右即可满足需要。

案例2：

BBS，bbs使用主贴（2个）、回帖（2个）总共4个ttserver，均表示读取IO较高，带动服务器整体load冲上5。

查看ttserver中stats发现数据量已达千万，容量20G，bnum=1000，xmsiz未设置。这个问题应该就在热数据区未设置使用内存大小，所以ttserver使用的是默认的64M内存，显然这点内存是无法满足bbs热数据需要的。

解决方案：

BBS中的热数据分布较合理，一般新数据较热，旧数据较冷，预计调整ttserver热区内存可降低磁盘IO消耗。但由于bbs在tt中存储的数据（帖子内容）长度不固定，无法推算热区大小，所以只能通过逐渐加大缓存区并监控磁盘io降低情况来进行调整，预计次调整为500M。

Tokyo Cabinet 单个数据库文件记录数超过1亿，性能会急剧下降。Tokyo Tyrant 的新版本支持了数据库文件拆分，例如 ttserver -mul 256 database.tcb 启动TT时，将会自动拆分成256个文件，存取时，根据key哈希到不同的文件。

本文转自UltraSQL51CTO博客，原文链接：http://blog.51cto.com/ultrasql/1647326 ，如需转载请自行联系原作者