Cassandra分布式Hash表系统测试报告

0-环境

1-写性能

2-读性能

3-灾备

 

---------0.环境---------

共四台服务器:29.mzhen.cn - 32.mzhen.cn

Cassandra使用DHT结构，不存在主从服务器区别。

但是Cassandra设置了一台机器为每台机器分配Hash范围，称为Seed机器，在本次测试中Seed机器设置为29.mzhen.cn

 

机器配置：16*Xeon 2.27, 16GB, 2TB * 2(7200k, raid5, XFS 文件系统）, 1Gbps

 

Java虚拟机的配置为，64位，Xms512MB, Heap 8GB

 

测试发现CPU利用率在700%/1600%左右，内存利用率较高，虚拟内存使用在50GB-100GB，物理内存使用在4-5GB

 

测试数据结构，64B key + (5B col) * 3

 

---------1.写性能---------

1.1-写程序

c_benchmark/load-data.cpp

使用多线程/批量写的方式，且把写入进程分布在4台机器上。

 

1.2-测试结果

多线程，1,000,000key/150s, (6667key/s)

磁盘IO显示写入速度较慢，为5MB/s/每台机器，最大可以达到10MB/s但不稳定。

通过nodetool -h 29.mzhen.cn ring分析写入结果，得到Cassandra的实际写入速度为6-15MB/s/集群

通过iptraf -g分析网络速度，得到速度为50-100Mbps，约12.5MB/s，基本和Cassandra报告的数据符合

另外，通过添加机器可以提高写入速度，但并非线性关系。

 

1.3-异常情况

写入过程中会出现错误，提示Cassandra服务器Unavaliable，写程序会异常退出。

在邮件列表中求助，得知这是由于写入速度过快，系统难以响应导致的。因此可以认为1.2中报告的写入速度是最大速度。

 

---------2.读性能---------

2.1-读程序

c_benchmark/scan-data.cpp

 

2.2-测试结果

顺序读，单进程，100,000key/45s (2222key/s)

顺序读，多进程，400,000key/45s (8888key/s)

多进程读取时，进程均匀的分布在测试机器上。增加到3个进程时仍然保持在45s，增加到4个进程时时间开始小幅增加。

可见使用4个进程能够完全发挥系统能力。

随机读，单进程，70%命中率，10,000key/15s (666key/s)

随机读，多进程，70%命中率，40,000key/15s (2667key/s)

和顺序读基本一致。

 

2.3-读写同时进行-相同表

顺序读速度，单进程，70%命中率，10,000key/18s (555key/s)

写速度，多线程，1,000,000key/150s, (6667key/s)，和1.2节结果一致。

可以认为Cassandra优先处理写请求。

 

2.4-读写同时进行-不同表

和2.3节测试结果一致。Cassandra将数据存储在离散的文件中，可以认为处理不同表时性能基本不变。

 

2.5-异常情况

无

 

---------3.灾备---------

3.1-写过程灾备

写程序需要指定响应机器，设为A。停掉集群中除A外的任意机器，写程序可以继续运行。

有时会报告某台服务器Unavaliable错误，写程序抛出异常并退出，但重启写程序后可以继续

停掉A，写程序报告如下错误并退出。

terminate called after throwing an instance of 'apache::thrift::transport::TTransportException'

 

3.2-读过程灾备

和3.1节完全相同。

 

3.3-数据受损

停掉某台机器的Cassandra进程，并删除所有数据文件。重新启动进程后，日志中没有出错信息

用nodetool -h localhost ring检查数据量，得到本地数据量被清空

但尝试读取数据文件，集群仍能返回结果。

尝试用nodetool -h localhost loadbalanace/repair修复，均未能使数据恢复

注意，

数据恢复办法参见3.4节

 

3.4-元数据受损

停掉进程后删除所有的元数据文件。重启进程得到如下提示，

INFO [main] 2010-06-07 13:26:12,969 StorageService.java (line 378) Joining: getting bootstrap token

Boostrap过程结束后(这个过程很长，且期间访问数据会出现Unavaliable异常)，该机器的元数据和用户数据都得到恢复。