解剖一个Redis性能问题

解剖一个Redis性能问题

---

---

病理特征

最近有个项目(它叫黑洞，是一个服务于很多项目的报警系统)生病了，黑洞从rabbitmq源源的吞食着各种项目数据，但是最近黑洞越来越沮丧，于是来找我看病。他吞食的一些项目，处理率非常低，这些项目数据不大，数据结构也很简单，但是就是无法提高吞吐量，连cpu都跑满了。
我大致给黑洞做了下检查，发现问题出在redis的调用上。

诊断过程

全面检查

由于不能确定其发病原因，所以，我决定先对其进行一个全面检查：
* 通过slowlog get 查看了一下，并没有发现什么异常现象，其实这也是意料之内的事情，毕竟Redis的slowlog只计算了其处理的时间，并没有把排队等待的时间算进去
* 接着用redis-cli --latency，观察了一下，也没有发现异常状况
* 由于出问题的数据都是本机存取操作，所以，基本排除了网络原因
* 为了确定是不是机器资源瓶颈，我查看了info数据，发现，这部分也无比正常，内存占比正常，IO和CPU正常，不是资源瓶颈，排除了swap和I/O引起的问题

诊断结果

当一切看起来是无比正常的时候，我决定从项目收到的数据找找问题。
找到这个数据之后，发现这个object无比巨大，因为黑洞为了计算一些监控数据的两次差值，才使用redis进行缓存的，而这个异常的监控数据，竟然每天变换一个实例，导致这个object保存了几个月的数据……哎……这也没有办法，毕竟黑洞是个下游系统，上游的监控插件写错了，下游也只能承受着，想办法进行改进吧
* 首先肯定要与监控系统沟通一下，看看能不能修复一下这个异常插件
* 其次，黑洞本身也要预防类型情况，一方面压缩大数据，另一方加速处理，我的方案就是改变原来的get为2次hash方式
具体有多少改观呢？

未完待续……(代码 + 优化对比数据)稍后整理

病历记录

本次处理，也用到了一些分析工具
1. tcprstat: 本来想用这个看一下处理时间的，但是由于这个工具自身限制，无法判别本地请求
2. strace：查看系统调用及其时间
3. vmstat、iostat等查看基本资源