一、 测试目的
测试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性能；
作者：廖诚
