正文
不同信创服务器Redis7.0.5性能表现总结
背景以及基础约定
随着美帝2022.10收紧EAR规定的硬件出口规定
信创事业迎来了一波新的高潮.
最近不仅仅要求国产化的硬件.
更要求国产化的OS,以及数据库和中间件.
最近因为涉及到一些产品新版本的迭代
准备了很多信创操作系统. 计划进行一次简要的性能测试.
基准:
都采用同一台硬件服务器
配置为 E5-2630V4 2.2Ghz的两路浪潮NF5270M4的服务器
虚拟机配置同为: 8c32G内存配置.
Redis 都为最新版本 7.0.5 的默认编译版本.
下载与编译安装
https://github.com/redis/redis
下载之后直接进行安装
国产的信创OS都自带电池的有了GCC 可以直接进行编译
cd redis-7.0.5
make
make install
就可以实现安装.
需要注意的是 make install 会在如下目录创建二进制:
/usr/local/bin/redis-cli
将redis-7.0.5/src 下面的二进制拿走的情况 没法直接在命令行里执行.
E5-2630V4 make的时间大约是2分半钟左右.
下载与编译安装
为了验证一下国产的设备.
也在飞腾2000+/64 银河麒麟v10 Tercel的物理机上面
进行了编译与测试.
编译时长为:
三分半
能够明显看出. 飞腾的部分性能还是距离 六年前的E5-2640V4有差距.
E5-2630V4 状态 Launched 发行日期 Q1'16
测试脚本简要编写
编写思路:
复制一个 redis.conf 的配置文件.
保证所有的带测试的服务器都保持一致的参数.
然后修改里面的port端口, 比如我这边修改为了 16379
不会影响业务redis的使用.
第一步先清理服务. 重新启动进程, 保证redis里面无异常数据.
第二步启动服务.进行测试.
第三部分筛选部分结果并且打印出来.
第四步分汇总分析.
测试脚本简要编写
lsof -i:16379 |grep -v grep |grep -v PID |awk '{print $2}' |xargs kill -9
sleep 1
./redis-server redis_localhost.conf
sleep 1
./redis-benchmark -h 127.0.0.1 -p 16379 > redis_benchmark.txt
echo "合计结果为"
cat redis_benchmark.txt |grep -E "requests per second|====="
cat redis_benchmark.txt |grep -E "requests per second|=====" >redis_benchmark_final.txt
mv redis_benchmark_final.txt $(hostname)_redis_perf.txt
sleep 1
echo "清理进程"
lsof -i:16379 |grep -v grep |grep -v PID |awk '{print $2}' |xargs kill -9
测试结果简要分析
| 操作系统 |
PING |
SET |
GET |
INCR |
MSET |
地址 |
| UOS1050A |
72674.41 |
75018.76 |
79936.05 |
72992.7 |
68634.18 |
198 |
| UOS1050E |
96525.09 |
86206.9 |
94607.38 |
93545.37 |
107411.38 |
200 |
| OpenEuler2209 |
70521.86 |
69686.41 |
71736.01 |
63897.76 |
68399.45 |
196 |
| KylinV3.4 |
67204.3 |
66934.41 |
66889.63 |
65573.77 |
61349.7 |
194 |
| CentOS9Stream |
61387.36 |
75700.23 |
78926.6 |
81900.09 |
71787.51 |
195 |
| KylinV10_On_FT2000+ |
55710.31 |
56306.3 |
55279.16 |
55928.41 |
52438.39 |
112 |
| Win2025 |
52493.44 |
56625.14 |
61050.06 |
73909.83 |
50942.43 |
201 |
| Win2022_On_Gold5218 |
58241.12 |
61652.28 |
66181.34 |
64350.06 |
52083.34 |
202 |
另外一个测试场景
如果Key值较多时,性能情况会如何呢.
抓取一个公司较大的key的rdb文件进行处理.
然后再次测试验证.
这次选择性能最好的 UOS1050E 进行验证.
大概插入 470万个key 进行验证.
想着分别插入 470万(内存4.23G)和 140万(内存占用750M)进行验证
结果比较诡异:
ping set get 随着键值数的增多都有提高
只有MSET 有下降. 感觉比较奇怪
怀疑redis在并发比较小的情况下. 键值对的多寡影响性能不大
但是如果并发上来 client多了 虽然单线程, 但是NIO进行切换的话依旧会导致性能下降.
Key数量测试场景
| 操作系统 |
PING |
SET |
GET |
INCR |
MSET |
地址 |
| UOS1050E |
96525.09 |
86206.9 |
94607.38 |
93545.37 |
107411.38 |
200 |
| UOS1050E 470万key |
93109.87 |
102040.81 |
105485.23 |
99304.87 |
75471.7 |
200 |
| UOS1050E 140万key |
99502.48 |
103626.95 |
103519.66 |
105485.23 |
78678.2 |
200 |
