一、 测试目的
测试Redis主从热备,在key随机大小的情况下性能如何,其中主机不带持久化,从机带持久化,且写、改在主机上操作,读则在从机上操作。
二、 测试环境
1、 网络环境
如图1所示,42、45、43均连接至千兆交换机,其中42为服务端master,45为服务端slave,43为客户端:
图1
2、 硬件环境
IP
|
型号
|
OS
|
CPU
|
内存
|
硬盘
|
网卡
|
用途
|
192.168.0.42 |
HP刀片 |
RedHat6.2 x86_64 |
Intel(R) Xeon(R) E5410 @ 2.33GHz 8核 |
16G |
68G |
1000Mb/s |
被压主机 |
192.168.0.45 |
HP刀片 |
RedHat6.2 x86_64 |
Intel(R) Xeon(R) E5410 @ 2.33GHz 8核 |
16G |
68G |
1000Mb/s |
被压从机 |
192.168.0.43 |
HP刀片 |
RedHat6.2 x86_64 |
Intel(R) Xeon(R) E5410 @ 2.33GHz 8核 |
16G |
68G |
1000Mb/s |
加压机 |
3、 软件环境
软件名称
|
软件版本
|
是否开源
|
redis |
v2.6.5 |
是 |
三、 测试结果
在2到100字节范围内生成随机大小的key,加上10字节的value组成每条数据记录内容;每次操作线程数为50个,每线程10万条记录,在老数据基础上进行测试;老数据基础分别为7000万、7500万、8000万条……,依次类推每次测试增长500万条,分别测试insert、select、update情况;
Redis主从热备过程如下:
1) Slave与Master建立连接,然后发送SYNC命令;
2) Slave无论是第一次或者重新连接,Master都会启动一子进程,将数据库快照保存到.rdb文件中,同时Master主进程收集新的写命令并缓存;
3) 子进程完成写文件后退出,Master再把文件发送给Slave,Slave将文件保存到磁盘上,完了之后再加载到内存中;
4) 接着Master再把缓存的命令转发给Slave,后续Master将收到的写命令都同步发送给Slave;
5) 如果Master同时收到多个Slave发来的同步连接命令,Master只会启动一个子进程来写数据库镜像,然后再发送给所有的Slave;
注:Slave第一次或者重新连接到Master,都会进行全量同步数据,之后如果Master有新数据,才进行增量同步,且Slave在同步数据过程中不接受任何操作请求。
1、 insert操作性能情况
1) 在老数据基础上,进行50个客户端并发,每客户端操作100,000次写,平均用时如图2-1、图2-2示:
7.00
|
7.50
|
8.00
|
8.50
|
9.00
|
9.50
|
|
master
|
74794.32 |
74471.25 |
74460.16 |
73540.23 |
73583.52 |
6777.64 |
slave
|
图2-1
图2-2
说明:纵轴为平均用时(单位:次/秒),横轴为老数据基础(单位:千万);
2) CPU使用情况,如图3-1、图3-2示:
7.00
|
7.50
|
8.00
|
8.50
|
9.00
|
9.50
|
|
master
|
86.71 |
95.20 |
92.46 |
93.90 |
93.85 |
10.18 |
slave
|
21.93 |
31.47 |
26.53 |
29.78 |
29.01 |
0.99 |
图3-1
图3-2
说明:纵轴为平均占用单个CPU百分比,横轴为老数据基础(单位:千万);
3) MEM使用情况,如图4-1、图4-2示:
|
7.00
|
7.50
|
8.00
|
8.50
|
9.00
|
9.50
|
master
|
68.11 |
72.16 |
76.42 |
80.56 |
84.78 |
84.87 |
slave
|
68.09 |
72.11 |
76.45 |
80.52 |
84.79 |
75.52 |
图4-1
图4-2
说明:纵轴为占用内存平均百分比,横轴为老数据基础(单位:千万);
4) 每秒页面错误,如图5-1、图5-2示:
7.00
|
7.50
|
8.00
|
8.50
|
9.00
|
9.50
|
|
master
|
0.00 |
0.00 |
0.00 |
0.00 |
0.00 |
81.06 |
slave
|
0.00 |
0.00 |
0.00 |
0.00 |
0.00 |
2.40 |
图5-1
图5-2
说明:纵轴为每秒产生的页面错误数,横轴为老数据基础(单位:千万);
5) 磁盘IO读情况,如图6-1、图6-2示:
7.00
|
7.50
|
8.00
|
8.50
|
9.00
|
9.50
|
|
master
|
0.00 |
0.00 |
0.00 |
0.00 |
0.00 |
1986.25 |
slave
|
0.00 |
0.00 |
0.00 |
0.00 |
0.00 |
75.99 |
图6-1
图6-2
说明:纵轴为磁盘IO读的数量(单位:kB/s),横轴为老数据基础(单位:千万);
6) 磁盘IO写情况,如图7-1、图7-2示:
7.00
|
7.50
|
8.00
|
8.50
|
9.00
|
9.50
|
|
master
|
0.82 |
0.73 |
0.64 |
0.83 |
1.06 |
0.57 |
slave
|
518.44 |
2317.03 |
1437.87 |
255.83 |
667.09 |
0.62 |
图7-1
图7-2
说明:纵轴为磁盘IO写的数量(单位:kB/s),横轴为老数据基础(单位:千万);
2、 select操作性能情况
1) 在老数据基础上,进行50个客户端并发,每客户端操作100,000次读,平均用时如图8-1、图8-2示:
7.00
|
7.50
|
8.00
|
8.50
|
9.00
|
9.50
|
|
master
|
||||||
slave
|
94984.80 |
94304.04 |
93057.88 |
92165.90 |
94589.48 |
68728.52 |
图8-1
图8-2
说明:纵轴为平均用时(单位:次/秒),横轴为老数据基础(单位:千万);
2) CPU使用情况,如图9-1、图9-2示:
7.00
|
7.50
|
8.00
|
8.50
|
9.00
|
9.50
|
|
master
|
0.00 |
0.00 |
0.00 |
0.00 |
0.00 |
0.00 |
slave
|
79.45 |
90.41 |
84.83 |
89.12 |
93.42 |
70.92 |
图9-1
图9-2
说明:纵轴为平均占用单个CPU百分比,横轴为老数据基础(单位:千万);
3) MEM使用情况,如图10-1、图10-2示:
7.00
|
7.50
|
8.00
|
8.50
|
9.00
|
9.50
|
|
master
|
69.99 |
74.34 |
78.45 |
82.68 |
86.92 |
53.48 |
slave
|
69.97 |
74.21 |
78.43 |
82.66 |
82.43 |
90.93 |
图10-1
图10-2
说明:纵轴为占用内存平均百分比,横轴为老数据基础(单位:千万);
4) 每秒页面错误,如图11-1、图11-2示:
7.00
|
7.50
|
8.00
|
8.50
|
9.00
|
9.50
|
|
master
|
0.00 |
0.00 |
0.00 |
0.00 |
0.00 |
0.00 |
slave
|
0.00 |
0.00 |
0.00 |
0.00 |
0.00 |
39.55 |
图11-1
图11-2
说明:纵轴为每秒产生的页面错误数,横轴为老数据基础(单位:千万);
5) 磁盘IO读情况,如图12-1、图12-2示:
7.00
|
7.50
|
8.00
|
8.50
|
9.00
|
9.50
|
|
master
|
0.00 |
0.00 |
0.00 |
0.00 |
0.00 |
0.00 |
slave
|
1.55 |
0.00 |
0.00 |
0.00 |
0.00 |
1261.71 |
图12-1
图12-2
说明:纵轴为磁盘IO读的数量(单位:kB/s),横轴为老数据基础(单位:千万);
6) 磁盘IO写情况,如图13-1、图13-2示:
7.00
|
7.50
|
8.00
|
8.50
|
9.00
|
9.50
|
|
master
|
0.48 |
0.87 |
0.68 |
0.83 |
0.80 |
0.75 |
slave
|
0.78 |
0.80 |
0.90 |
0.67 |
0.76 |
0.62 |
图13-1
图13-2
说明:纵轴为磁盘IO写的数量(单位:kB/s),横轴为老数据基础(单位:千万);
3、 update操作性能情况
1) 在老数据基础上,进行50个客户端并发,每客户端操作100,000次改,平均用时如图14-1、图14-2示:
7.00
|
7.50
|
8.00
|
8.50
|
9.00
|
9.50
|
|
master
|
65019.51 |
65163.56 |
64566.12 |
65265.63 |
64366.63 |
28851.70 |
slave
|
图14-1
图14-2
说明:纵轴为平均用时(单位:次/秒),横轴为老数据基础(单位:千万);
2) CPU使用情况,如图15-1、图15-2示:
7.00
|
7.50
|
8.00
|
8.50
|
9.00
|
9.50
|
|
master
|
92.68 |
92.59 |
88.38 |
92.73 |
91.99 |
43.33 |
slave
|
29.94 |
25.35 |
27.00 |
27.47 |
27.75 |
3.42 |
图15-1
图15-2
说明:纵轴为平均占用单个CPU百分比,横轴为老数据基础(单位:千万);
3) MEM使用情况,如图16-1、图16-2示:
7.00
|
7.50
|
8.00
|
8.50
|
9.00
|
9.50
|
|
master
|
70.20 |
74.56 |
78.46 |
82.72 |
87.17 |
61.02 |
slave
|
69.97 |
74.21 |
78.43 |
82.66 |
82.43 |
86.91 |
图16-1
图16-2
说明:纵轴为占用内存平均百分比,横轴为老数据基础(单位:千万);
4) 每秒页面错误,如图17-1、图17-2示:
7.00
|
7.50
|
8.00
|
8.50
|
9.00
|
9.50
|
|
master
|
0.00 |
0.00 |
0.00 |
0.00 |
0.00 |
94.72 |
slave
|
0.00 |
0.00 |
0.00 |
0.00 |
0.00 |
64.50 |
图17-1
图17-2
说明:纵轴为每秒产生的页面错误数,横轴为老数据基础(单位:千万);
5) 磁盘IO读情况,如图18-1、图18-2示:
7.00
|
7.50
|
8.00
|
8.50
|
9.00
|
9.50
|
|
master
|
0.00 |
0.00 |
0.00 |
0.00 |
0.00 |
2067.77 |
slave
|
0.00 |
0.00 |
0.00 |
0.00 |
0.00 |
2036.16 |
图18-1
图18-2
说明:纵轴为磁盘IO读的数量(单位:kB/s),横轴为老数据基础(单位:千万);
6) 磁盘IO写情况,如图19-1、图19-2示:
7.00
|
7.50
|
8.00
|
8.50
|
9.00
|
9.50
|
|
master
|
0.68 |
0.58 |
0.51 |
0.82 |
0.87 |
0.70 |
slave
|
797.51 |
191.29 |
147.11 |
0.92 |
1356.34 |
9.19 |
图19-1
图19-2
说明:纵轴为磁盘IO写的数量(单位:kB/s),横轴为老数据基础(单位:千万);
四、 分析及结论
1、 insert操作性能情况
1) 相同的数据模型,相同的服务器环境,在达到内存上限前,Redis不带持久化,能保存的热数据要比带持久化时多些,前者能保存约9千万条,后者能保约8千万条;
2) 在达到内存上限前,Redis带主从热备写性能要比不带时低些,前者约7万4千条每秒,后者约7万8千条每秒;
3) Redis主机在达到内存上限后,写性能会急剧下降;
4) Redis主机平均占用单个CPU百分比,在达到内存上限前一直稳定在90%左右,而从机一直稳定在29%左右;达到内存上限后,二者均受内存swap每秒产生大量页面错误影响,CPU使用率会急剧下降;
5) Redis主从机内存占用均随着写入数据的逐渐增多而增大,但达到内存上限后,二者均受内存swap每秒产生大量页面错误影响而持续下降,从机还受子进程dump数据竞争内存而下降更明显;
6) Redis主从机在达到内存上限后,由于需要把部分数据转到交换分区,均会每秒产生大量的页面错误;
7) Redis主从机在达到内存上限前,均没有磁盘IO读操作,之后就有明显的磁盘IO读操作,尤其主机最明显;
8) 在整个插入数据过程中,Redis主机磁盘IO写操作不是很明显,而从机磁盘IO写操作很明显且不规则;
2、 select操作性能情况
1) Redis主从热备情况,数据可以从Slave读出,从而分担Master压力,性能约9万4千条每秒,而单机情况下读性能约8万5千条每秒;
2) Redis主机在达到内存上限后,读性能会急剧下降;
3) Redis从机平均占用单个CPU百分比,在达到内存上限前,一直稳定在90%左右,之后受内存swap每秒产生大量页面错误影响而持续下降;
4) Redis主从机内存占用均随着写入数据的逐渐增多而增大,但达到内存上限后,二者均受内存swap每秒产生大量页面错误影响而持续下降;
5) Redis从机在达到内存上限后,由于需要把部分数据转到交换分区,会每秒产生大量的页面错误;
6) Redis从机在达到内存上限前,没有磁盘IO读操作,之后就有明显的磁盘IO读操作;
7) 在整个查询数据过程中,Redis从机磁盘IO写操作不是很明显且不规则;
3、 update操作性能情况
1) 在达到内存上限前,Redis带与不带主从热备,改性能都差不多,约6万5千条每秒;
2) Redis从机在达到内存上限后,改性能会急剧下降
3) Redis主机平均占用单个CPU百分比,在达到内存上限前一直稳定在90%左右,而从机一直稳定在29%左右;达到内存上限后,二者均受内存swap每秒产生大量页面错误影响,CPU使用率会急剧下降;
4) Redis主从机内存占用均随着写入数据的逐渐增多而增大,但达到内存上限后,二者均受内存swap每秒产生大量页面错误影响而持续下降;
5) Redis主从机在达到内存上限后,由于需要把部分数据转到交换分区,均会每秒产生大量的页面错误;
6) Redis主从机在达到内存上限前,均没有磁盘IO读操作,之后就有明显的磁盘IO读操作;
7) 在整个修改数据过程中,Redis主机磁盘IO写操作不是很明显,而从机磁盘IO写操作很明显且不规则;
五、 后续测试及开发建议
1、 测试建议
1) 是否可以加入删除情况测试;
2、 开发建议
1) 在达到内存上限后,主从机性能都会急剧下降;
2) 如果需要持久化,最好把持久化设置在Slave上,且Master与Slave最好在同一局域网内;
3) Slave第一次或重新连接Master,如果Master原库数据量大,主从数据同步时,会严重影响Master性能;
作者:廖诚