kvrocks压测-set命令服务器资源无法吃满

[VIVALXH]

压测目的

我们希望在实际生产一定压力下，确定最优的资源配比，以确保kvrocks能够尽可能利用服务器资源。

压测问题

• 单看set命令，cpu/内存/磁盘/网络/连接数这些硬件相关资源基本上都没有打到瓶颈，但是我们无论怎么加压，qps都无法上去，我们无法确定是哪个地方出现瓶颈了，请问是否有配置限制或者其它相关限制？。
• 固态/机械的磁盘都用过，也用过其它压测客户端，资源依然吃不满。
• 升级过被打压机器的规格(8c16g)，虽然qps可以上去，但资源依旧吃不满。

压测结果

• kvrocks_exporter ：https://snapshots.raintank.io/dashboard/snapshot/XAdP9Oh2tjypUg66H5E5yXGKvrlOOgOC
• node_exporter : https://snapshots.raintank.io/dashboard/snapshot/nmCITcPNMU1h2B57cZpDWJaMQvzMC50p

测试环境

被打压机器：

• 规格：linux 4c8g
• 运行服务命令：docker run -it -p 6666:6666 apache/kvrocks --bind 0.0.0.0
• kvrocks 镜像版本：sha256:707f93473e7265df39593d38d83081ec1a6a36da31c97b391008858eb45a437f
• 运行监控命令：./kvrocks_exporter --kvrocks.addr kvrocks://192.168.1.72:6666
• kvrocks_exporter 版本：(RocksLabs/kvrocks_exporter@0135649)

打压机器：

• 规格：linux 12c24g redis-benchmark
• 运行命令：redis-benchmark -t set -r 100000 -n 1000000 -h 192.168.1.72 -p 6666

[git-hulk]

1. 关注一下 ioutil 的情况
2. redis-benchmark 要使用(Redis 版本 >= 7)，提高 --threads 参数来压测

[VIVALXH]

@git-hulk 感谢回答，我们更换了阿里云的机器进行测试：

规格

服务器(4c8g ecs.c7.xlarge 挂载ssd云盘)

压测命令

redis-benchmark -t set -r 100000 -n 10000000 -h 1.0.105.255 -p 6666 --threads 100
redis-benchmark -t get -r 100000 -n 10000000 -h 1.0.105.255 -p 6666 --threads 100

压测结果

set 命令 iostat

• cpu空闲率依旧有10-20左右
• 虽然%wrqm和w_await较高，但并不持续，可能有可配置的刷盘策略？
• ioutil也并不是很高，感觉磁盘没有到瓶颈？
  

set 命令 top htop

• top命令中，kvrocks占用的核数只有2.5(62%)，但是总占用已经达到了85%，理论上这两个指标应该一致吧，怎么感觉有额外的系统调用？
• 从我们之前的测试结果看，限定核数1c的qps是3w qps/s，理想情况4c应该是12w qps/s，但是实际只有8w qps/s，我们的结论是kvrocks的性能和kvrocks占用的cpu(62%CPU)成正比，但并不与总占用成正比，我们提升服务器规格(8c) 后得出的结论也是这样的，这性能转换率是否正常呢？
  
  

get 命令 iostat

• cpu基本吃满，应该都是从内存读的，磁盘基本没有压力，能压到cpu上限这个是我们认为正常的。
  

[PragmaTwice]

• you can try to adjust workers to a higher number (e.g. equals to number of cpu cores)
• you can connect kvrocks via a connection pool to utilize the multi-thread processing in kvrocks

[VIVALXH]

@PragmaTwice Thank you

1. We've tried tweaking the workers configuration, but it didn't work much.
2. We used not only redis-benchmark, but also redigo's connection pooling scheme, and the results were consistent.
   redigo: https://github.com/gomodule/redigo