Redis High ServerLoad and CPU Troubleshooting

作者:Rui 发布时间:December 23, 2016 分类:Redis 浏览:4,016

问题现象

最近工作中,遇到Redis serverload和CPU一直保持过高的问题,导致程序中很多redis的请求出现Timeout现象。当时的RPS远没有达到我们部署的redis的限制,但serverload和CPU就一直维持在90%以上,严重影响了redis的响应时间。之前我们做过基准测试,我们部署的redis可以存储54G数据,RPS可以达到25W/s,但事故时,却只有5W RPS,内存也只占用了24G左右。

有可能引起该问题的原因

  1. 资源受限,网络带宽,CPU性能,机器性能
  2. large request/response size(large object), 存储过大的数据。因为redis是单线程的,在处理请求时,如果某个请求处理的慢,就会堵塞后续的命令执行,独占资源,
  3. 执行过于复杂的LUA 脚本

问题分析

一般redis serverload和CPU过高,要先判断是否真的是资源受限,如果在正式使用之前做过基准测试,基本就可以知道部署的redis的一些性能指标。例如,RPS以及不同请求量下serverload和CPU的情况,网络带宽情况等。在这次事故中,监控的RPS远没有达到我们之前基准测试的标准。另外网络带宽也没有超出我们的限制。所以基本排除此次事故是由于资源受限。另外,我们在程序中也没有使用LUA脚本,所以也排除了第三种原因。所以最有可能是我们的程序中有可能写入了大量的large object。
之后,我们通过以往的监视数据和redis一些命令来排查,是否是业务中存在一些large object。首先,我们在看我们的内存变化的时候,我们发现,我们的内存变化并不是线性的,而是突然增加很高,并且是以G为单位的。这就很明显的说明了,在业务高峰时,应该有大量的写入large object的命令,我们的监视数据中也记录了请求的response size的统计,所以我们在统计了事故过程中的response size的分布,发现response size 大写在1M左右的命令,每秒钟大概执行了500次,甚至有很多超过4M的large object。所以这就可以确定了,该问题确实是由于large object导致。

解决方案

找到问题原因后,就需要解决该问题,首先要排查出这些大的large object的key,定位到具体的业务。因为之前的统计response size的日志中,并没有记录key信息。所以只能够借助redis-cli工具的命令查看
1.bigkeys, 借助redis-cli工具分析bigkeys,该命令是借助redis scan来实现,并不会带来太大的压力,如果你有疑虑,可以生产数据dump出来分析。具体使用:

redis-cli -h <your redis> -a <your redis password> --bigkeys

image005.jpeg
另外redis-cli也提供了很多有用的命令,方便排查redis的问题,请参考此文档:
https://redis.io/topics/rediscli
2.slowlog redis执行的最慢的命令的列表,找出相应的命令和对应的key。
image006.jpeg
具体可参考该文档:
https://redis.io/commands/slowlog
3.定位到问题的点之后,就需要修改业务,将比较大的object,拆分成很多小的key。这也是redis推荐的做法。另外redis社区通常推荐存储的数据大小为100K。
https://groups.google.com/forum/#!searchin/redis-db/size/redis-db/n7aa2A4DZDs/3OeEPHSQBAAJ
https://gist.github.com/JonCole/db0e90bedeb3fc4823c2#large-requestresponse-size.

更多参考文档:
cache-how-to-troubleshoot
How fast is Redis?

标签: redis, tsg

仅有一条评论 »

  1. [...]原文章地址:http://arui.me/index.php/archives/202/[...]

添加新评论 »