最近查看消息推送的监控信息,日推送量到百万,但是随之而来的是 TP99 搞到 5秒,详细对日志打了埋点,监控其瓶颈,最终定位是 Redis 的性能问题。

但是令人疑惑的是,对比了其他应用系统 Redis 的性能,日吞吐量亿次的 TP99 才 5~10ms,故猜测一定是应用问题导致了 Redis 的性能下降!
查看了应用服务器的网络 IO,发现网络吞吐量异常的汹涌!

查看了 Redis 服务器的配置参数,发现 Redis 内存占用 7G+,Key键值对 1200万+,Reids 的使用可见一斑!但这并不能直接影响 Redis 的性能下降!

于是,我们又查看了 Redis 的 Showlog,终于发现详细,Redis 被大量的调用 SMEMBERS 命令,而每次调用几乎耗时 5s+。

SMEMBERS 命令是从一个 Set 结构获取集合,但这个集合数据量已经很大,当这个结合被频繁的调用,会极大的占用网络 IO,当网络被占满时,其余的操作也变得慢下来!
同时,查看了 Redis 的连接情况,发现连接数 1000 左右,保持的比较高,又重新查看 Redis 的配置文件!

配置文件中 timeout = 0,这表明 Redis 默认不会断开客户端的连接,这造成的问题:已经无效的连接会造成网络 IO 的浪费!

这次问题排查的反思,跟之前 502 有些相似,都是隐藏极深的问题导致的,问题不再是赤裸裸的暴露出来,而是蒙上了一层面纱!
本文转载自http://www.linkedkeeper.com/detail/blog.action?bid=37(文/Frank)
网友评论