Tokyo Tyrant (ttserver)在大数据量(20G以上)的不稳定性

[文章作者:孙立 链接:http://www.cnblogs.com/sunli/ 更新时间:2010-06-20]

ttserver不稳定案例

1. CMS a系统的文章采用了ttserver存储。在数据达到30多G的时候,经常出现写入失败,还出现了几次意外崩溃,无法重启成功,只得从slave恢复数据。

2.CMS b系统的图片使用ttserver存储,在数据导到65G的时候出现无法写入的情况,重启后问题依旧,只得从slave重新恢复数据重启。

3.BBS系统采用ttserver做缓存,设计上采用如果没有更新,那么缓存永久存在的策略。在数据达到65GB,数据条数在700多万条的时候,出现大量写入失败的情况,系统负载开始上升,日志出现大量do_mc_set: operation failed。当然这里作为缓存比较好处理,删掉,重新建个新的就OK。(注:启动参数data.tch#bnum=10000000#xmsiz=434217728#rcnum=20000)

测试中ttserver写入表现不稳定

1.#bum=10000000

插入940多万数据(一条7.2k)时出现崩溃(测了两次都一样,看起来好像内部出现了死锁,连上后,无法进行任何响应,没有任何操作时,也占了大量CPU)。越到后面插入的qps(每秒响应数)越小。而且波动比较大。

#bum=100000000

可以顺利插入上千万的数据,但是越到后面qps越小。越到后面插入的qps(每秒响应数)越小。而且波动比较大。

2.跟其他的nosql(mongodb,bdb je,cassandra)对比测试,在写入上,ttserver是表现最不稳定的,其他的nosql都非常好。

总结和注意

1.经过对Tokyo Cabinet 的测试,同样跟ttserver一样,所以应该是Tokyo Cabinet 导致的不稳定。在选择btree方式存储时,随着数据量的增加一样不稳定。在优化参数上也做了各种尝试。

2.ttserver在性能的表现上非常不俗,特别是内存占用和cpu占用都很低,能同时响应上万的并发。但是你应该注意,他一般在数据导到20G以上就会出现不稳定情况。

所以用ttserver来存储单条比较小的数据非常好,存储大文本或者大的二进制文件,由于空间占用上升很快,很快就会变得不稳定。

3.注意备份,使用master-slave是个非常好的主意,在ttserver崩溃导致文件损坏或者其他什么原因无法启动时,你可以从slave 拷贝数据文件来进行恢复。

4.如果你一定要使用ttserver,建议对数据进行分片(sharding)存储,或者你自己使用一个网络接口,底层使用Tokyo Cabinet 来进行分片存储。

5.以上只是个人在使用中遇到的情况,本人正在尝试在存储大文本的ttserver进行替换掉。

发表评论

电子邮件地址不会被公开。 必填项已用*标注