容;每次操作线程数为
50
个,每线程
10
万条记录,在老数据基础上进行测试;老数据基
础分别为
0
万、
500
万、
1000
万、
1500
万条……,依次类推每次测试增长
500
万条,分别
测试
insert
、
select
、
update
情况;
因为
Redis
在写入
8
千万条时,开始启动虚拟内存,此时意味着物理内存不够用,再加
上受快照持久化子进程同时抢占系统资源的影响性能出现拐点,在此拐点前其性能都与
7
千
500
万的情况差不多,所以性能曲线图将只描述
7
千
500
万后的测试情况;
Redis
快照持久化过程如下:
1)
达到持久化条件,
Redis
调用
fork
创建一子进程;
2)
父进程继续维护自己的内存空间并同时处理
client
端的请求,而子进程负责将
fork
时刻整个数据库的一个快照写入到临时文件;
3)
当子进程将快照写入临时文件结束后,会用这个临时文件替换原来的快照文件,
然后子进程退出;
注:每次快照持久化都是将内存数据完整的写入磁盘一次,并不是增量的同步数据;
1
、
insert
操作性能对比
1)
在老数据基础上,进行
50
个客户端并发,每客户端操作
100,000
次写,平均用时
如图
2-1
、图
2-2
示:
7.50 8.00 8.50 9.00 9.50 10.00 10.50 11.00
mem
ca
99800.40 102796.05 100020.00 103950.10 105086.17 76405.87 104733.98 100260.68
redis 69213.73 32784.74 37855.84 1964.88 1204.61 1032.06 636.27 396.13
图
2-1
图
2-2
说明:纵轴为平均用时(单位:次
/
秒),横轴为老数据基础(单位:千万);
2) CPU
使用情况,如图
3-1
、图
3-2
示:
7.50 8.00 8.50 9.00 9.50 10.00 10.50 11.00
mem
ca
151.74 149.50 150.27 151.53 147.30 322.40 172.72 176.30
redis 92.33 51.18 54.77 3.64 2.15 1.81 1.19 0.85
图
3-1
相关文档
评论