memcachedb ttserver 压力测试及调优

一.需求：

我们希望找到一个key-value型数据库，具有以下特点
1.稳定高效
2.基于memcache或其它方便调用的包,以便在PHP中分布调用
3.如果有热备能力更佳，但至少有主从结构。

可选择的 有：memcachedb和Tokyo Tyrant。它们的官方报告数据都不错。
我们曾经对Tokyo Tyrant-Tokyo Cabinet寄予厚望，因为它可以做双主。但结果是，在插入200万100字节的数据之后，Tokyo Tyrant就像蜗牛一样，而且不断报错。

 

二.测试数据：

软硬件环境：
CPU: 64位4核Intel(R) Xeon(R) CPU E5310 @ 1.60GHz
内存：8G
操作系统：centos
硬盘：120G
客户端：PHP PECL扩展
启动方式：memcachedb -p11211 -d -r -u root -H /opt/mdb/ -m 6144 -N -t 4

或memcachedb -p11222 -d -r -u root -H /opt/mdb/ -m 7000 -N -t 8 -E -X -v
网络环境：未明确标注的均为localhost

(1)400字节数据单主机新增数据测试（10万数据）
内网：ping值：time=0.151 ms 千兆带宽
400字节：2.8秒/万
100字节：2.0秒/万

本机:  ping值：time=0.010 ms
400字节：0.7秒/万

结论：
在小数据量的情况下，localhost和内网差别为4:1左右。
数据的大小对写效率有一定的影响，400字节和100字节的数据在写入数据时，速度差别为3：2左右，读数据效率差别较小。

(2)100 字节数据单主机测试结果：（2千万数据）
新增：7280条/秒 （客户端8进程，其余未标明的测试均为单进程）
更改：200万以前1860条/s，200万稳定在以后>10000条/秒（这个现象原因还未找到，更改数据测试有待重测）
读取：>10000万条/秒

结论：
客户端程序多进程与单进程对效率影响差别很小。甚至过多客户端进程写入时，反而影响效率。

(2)将数组转成字符串存取能提高效率么？压缩选项是否能较大地提高效率？
某数组（如下），序列化后长度为700字节，用分隔符将数组的值转成字符串为350字节左右。下面测试中，已经包含把数组序列化和转字符串的时间。
array ( 0 => 10735, 1 => 10720, 2 => 10705, 3 => 10690, 4 => 10675, 5 => 10660, 6 => 10645, 7 => 10630, 8 => 10615, 9 => 10600, 10 => 10585, 11 => 10570, 12 => 10555, 13 => 10540, 14 => 10525, 15 => 10510, 16 => 10495, 17 => 10480, 18 => 10465, 19 => 10450, 20 => 10435, 21 => 10420, 22 => 10405, 23 => 10390, 24 => 10375, 25 => 10360, 26 => 10345, 27 => 10330, 28 => 10315, 29 => 10300, 30 => 10285, 31 => 10270, 32 => 10255, 33 => 10240, 34 => 10225, 35 => 10210, 36 => 10195, 37 => 10180, 38 => 10165, 39 => 10150, 40 => 10135, 41 => 10120, 42 => 10105, 43 => 10090, 44 => 10075, 45 => 10060, 46 => 10045, 47 => 10030, 48 => 10015, 49 => 10000);

在内网环境：
数组直接存取：
无压缩 写3.5秒/万，读3.2秒/万
带压缩 写3.3秒/万，读2.6秒/万
字符串存取：
无压缩 写3.0秒/万，读2.3秒/万。
带压缩 写3.1秒/万，读2.4秒/万
把数组的值都改成一样时（可压缩性高，压缩后只占了10字节以内），带压缩地写2.6秒/万，读1.9秒/万。

在本机：
数组直接存取：带压缩地写1.9秒/万，读1.1秒/万
字符串存取：  带压缩地写1.1秒/万，读0.9秒/万

结论：
数组对象转成字符串存入能可以节约一半左右的空间，但在效率方面的提高非常有限，仅在本机上写数据上有所提高。
在数据可压缩性较好时，可以大量节省空间和时间。但可压缩性不太好时，几乎没有差别。

(4)主从测试结果：（100万数据以下）
100字节数据
新增：1000条/秒

400字节
更改：100条/秒（客户端单进程）
读取：3570条/秒 （客户端单进程）

结论：
在使用主从结构时，写效率很大影响，效率差别在100:1左右,所以不建议使用主从。

 
(5)使用SVN最新版本的测试情况(新增350字节数据)
方案1：32位4核CPU，内存8G，-m2048启动:
表现优秀：0-443万      4000条/秒，非常稳定
表现较差：在443-800万  2100条/秒，忽快忽慢  data.db在2.5G左右。
表现很差：在800-1千万  1400条/秒，忽快忽慢  data.db在4G左右  负载 load average在5左右，服务器基本不响应。
出错情况：17次/1千万

在本服务器上启动两个mdb时，负载比一个高，性能较快地达到瓶颈。三个mdb时，负载很高，启动5个mdb进程时，写数据在1000多条/秒了，基本就 没有性能可言。

 

方案2：64位4核CPU，内存8G，-m6144启动:
0-1200万   5000条/秒，非常稳定
1300万后   2000条/秒，忽快忽慢 data.db在6G左右
1800万后   1400条/秒，忽快忽慢 data.db在8G左右  此时读数据性能也不太稳 定，但大部分保持在3000-4000条 /秒以上。负载load average在3左右，服务器仍然响应。
出错情况： 20次/1千万

 

在本服务器上，起2个mdb进程的效率比一个稍好一些，写数据在5599条/秒左右，读数据在10000条/秒左右。在32位CPU的服务器上则相反，性 能更快地达到瓶颈。

在重新启动mcdb后，读和写的速度都又恢复到了最好的状态，测试到单个文件大小达到14G时， 仍然能和刚开始的速度一样。另外，当负载 下降后，再插入数据也能有很高的性能。

mdb停止时不能删除日志，否则不能 在原数据基础上再重启。

 

结论：
mcdb根据硬件的情况，对应着相应的性能瓶颈。强烈建议使用CPU4核64位，8G内存的服务器，测试大数量时，表现很稳定和高效。而32位的服务器因 为不能管理大内存，差别很大,很容易达到瓶颈，进入不稳定状态，如果负载重需要人工重启干预。

重新启动mcdb，可以达到释放内存，提 高性能的效果。隔一断时间插入数据，也可以降低负载。
应该使用SVN的版本。SVN的最新版本整体数据也比发布版在开始时更为稳定。

一 台服务器上最好不要超过两个以上mdb服务。
mcdb出错的概率比较低，在20次/1千万左右，如果出错率更高，可能是服务器负载很大造成。有些写错误实际上已经写入，报错的原因仅仅是返回的数据未 读到。

 

(6)并发测试（内网环境）

10并发读和写  每线程50000次 每线程错误量15次左右 错误率0.03%
500并发读和写 每线程100次   每线程错误量5次左右  错误率5%，允许失败重连，最高连接数达到2300个。

300并发写 每线程100次   每线程错误量2次左右  错误率2%，

100并发读 每线程50次   错误率5%以上，允许失败重连，最高连接数达到2650以上。

50并发读 每线程5000次 错误率1%，速度很快，正常。

 

结论：

mdb不是一个可靠db,不能独立 作为db使用，可作为大缓存。我理解，mdb虽说是持久层，但它继承自缓存的性质， 决定了它不可能是可靠的。

mdb对高并发的支持并不好，读写分离解决不了问题，客户端如使用并发的长连接不断地读写，长连接数保持在50左右时效率是可靠的。

 

 

 

三.总结：在并发较高的环境下，将memcachedb定义为大缓存更合适，而不适用 为单独的db.

1.memcachedb 必须使用多线程启动，需要在编译时加上--enable-threads，否则在100万左右数以后据时，写入数据将不断报错，并效率极低，且读写并行能 力极差。另外，如果要使用-m参数，需要从SVN拿，发布版不行。

2.使用8G内存与2G内存对比，速度差别在2：1左右。(2G的数 据就不提供了)

3.使用localhost和千兆内网速度比为4:1。

4.在使用主从结构时，写效率很大影响，效率差别 在100:1左右,所以不建议使用主从。

5.数据的大小对写效率有一定的影响，400字节和100字节的数据在写入数据时，速度差别为 3：2左右，读数据效率差别较小。

6.客户端程序多进程与单进程对效率影响差别很小。甚至过多客户端进程写入时，反而影响效率。

7.数组对象转成字符串存入能可以节约一半左右的空间，但在效率方面的提高非常有限，仅在本机上写数据上有所提高。

8.在数据可 压缩性较好时，可以大量节省空间和时间。但可压缩性不太好时，几乎没有差别。

9.mcdb根据硬件的情况，对应着相应的性能瓶颈。在方案1中，存放3G以下数据量能得到最佳性能，方案2则在6G以下。可以启动多个进程来解决单个文 件太大的问题。
10.单线程连接时，mcdb出错的概率比较低，在20次/1千万左右

11.如果将log全都删除，重启数 据库会失败。可以在启动时用-E选项，由mdb自动管理日志。

12.并发时，mdb不是一个可靠db,有一定的出错率，不能独 立 作为db使用，可作为大缓存。

13.mdb对高并发的支持并不好，读写分离解决不了问题，客户端如使用并发的长连接不断地读写，长连接数保持在50左右时效率是可靠的。

四.参考：
1.memcachedb官方测试结果： http://memcachedb.org/benchmark.html
2.Tokyo Cabinet的测试结果和介绍：http://blog.s135.com/read.php?362&guid=9
3.某网友的Tokyo Cabinet测试:http://blog.zol.com.cn/861/article_860439.html 结果比我在基于Tokyo Tyrant的测试好看多了，但也明确表示在200万数据以后变慢很多。

官网：http://memcachedb.org/
作者的讨论组:http://groups.google.com/group/memcachedb
安装和启动指南：http://blog.csdn.net/simonlsy/archive/2008/01/07/2027940.aspx