redis线上问题排查解决
1 原文链接:http://carlosfu.iteye.com/blog/2254154
美团网的DBA负责人侯军伟给大家介绍了美团网在redis上踩得一些坑，讲的都是干货和坑。
分为5个部分：
一、周期性出现connect timeout
二、redis bgrewriteaof问题
三、redis内存占用飙升
四、redis内存使用优化
五、redis cluster遇到的一些问题
附赠PPT:
(1) 本次：美团在Redis上踩过的一些坑PPT
(2) 以往：《Redis在新浪的大规模运维经验》-演讲人：侯军伟新浪高级DBA.pdf
美团数据库运维平台介绍.pdf
有关Redis-Cluster的详细介绍有很多这里就不多说了，可以参考：
1. redis-cluster研究和使用
2. Redis Cluster 3.0.5集群实践
3. 本博客的一些Redis-Cluster的介绍(未更新完毕)
4. Redis设计与实现那本书（作者：黄建宏）：非常的推荐看这本书。
新书《Redis开发与运维》近期已经截稿。
2 美团在Redis上踩过的一些坑-3.redis内存占用飙升
http://carlosfu.iteye.com/blog/2254571
client_longes_output_list
3 Redis客户端查询缓冲区和输出缓冲区
https://github.com/ZhuoRoger/blog
每个Redis客户端（以下简称”Client”)都有多个状态属性，而理解和分析这些属性，对于我们设计Redis键空间和运营管理都有帮助。
本文将详细分析Client的两个重要属性：Query buffer（输入缓冲区）、Output buffers（输出缓冲区）
Redis Client属性一览
使用redis client命令可查看当前Redis实例的所有客户端；每行数据对应一个客户端。
| 1 2 3 |
127.0.0.1:6390> client list id=2 addr=127.0.0.1:53184 fd=8 name= age=33 idle=24 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=client id=3 addr=127.0.0.1:53190 fd=7 name= age=2 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client |
以上为两个客户端，每个包含18个字段属性；其中属性的基本含义此处简单说明，后文会对重启指标深入分析。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
id：客户端唯一标识, 每新创建一个连接就自增1；redis重启后重置1。 addr: 客户端源ip:port;用于分析异常的客户端，定位是由哪个服务器哪个进程引起的； 如id=2的客户端 netstat -anp | grep 53184 fd: socket的文件描述符；数值同lsof的FD字段相同 name: 客户端的名字，默认不会设置，一般用处不大。可手动执行[clientsetname](http://redis.io/commands/client-setname) age: 客户端存活的秒数 idle: 空闲的秒数；用于回收客户端和分析大量连接时有用 flages:客户端类型的标志, 共13种，常用的几种：N(普通客户端),M(master),S(slave),O(执行monitor) db:客户端当前使用的database序号 sub/psub: 快订阅的频道/模式数 multi:当前事务中已执行命令个数 qbuf: query buffer的字节数 重要 qbuf-free: query buffer的剩余字节数 obl:定长Output buffer的使用字节数 oll:可变大小output buffer的对象个数 omem:可变大小output buffer的内存使用字节数 重要 events: 文件描述符事作件(r/w) cmd:客户端最近一次执行的命令，不包含参数 |
Redis Client Query Buffer
每个Client都有一个query buffer(查询缓存区或输入缓存区), 它用于保存客户端的发送命令，redis server从query buffer获取命令并执行。
query buffer size
每个客户端query buffer自动动态调整使用内存大小的，范围在0~1GB之间；当某个客户端的query buffer使用超过1GB, server会立即关闭它，为避免过度使用内存，触发oom killer。
很遗憾query buffer的大小限制是硬编码的1GB,没法控制配置参数修改。
| 1 2 3 |
server.h#163 /* Protocol and I/O related defines */ #define PROTO_MAX_QUERYBUF_LEN (1024*1024*1024) /* 1GB max query buffer. */ |
如果程序的Key设计不合理，客户端使用大量的query buffer，这会导致redis server比较危险，很容易达到maxmeory限制，导致缓存数据被清空、数据无法写入和oom.
query buffer不受maxmeory限制
模拟100个客户端，连续写入大小为500MB(生产建议小于1KB)的Key; redis server设置maxmemory为4gb,但redis实际已用内存43gb(见used_memory)。
结论是query buffer使用内存不受maxmemory的限制，这BUG已经提给官方, 如不能限制redis使用的内存量，
很易导致redis过度使用内存，无法控制出现oom.
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
127.0.0.1:6390> info memory # Memory used_memory:46979129016 used_memory_human:43.75G used_memory_rss:49898303488 used_memory_rss_human:46.47G used_memory_peak:54796105584 used_memory_peak_human:51.03G total_system_memory:134911881216 total_system_memory_human:125.65G maxmemory:4294967296 maxmemory_human:4.00G maxmemory_policy:allkeys-random mem_fragmentation_ratio:1.06 mem_allocator:jemalloc-4.0.3 ## 当client断开后，rss会马上释放内存给OS |
query buffer占用内存，会计入maxmemory, 如果达到maxmemory限制，会触发KEY的LRU淘汰或无法写入新数据。
| 1 2 |
127.0.0.1:6390> set a b (error) OOM command not allowed when used memory > 'maxmemory'. |
query buffer使用查看
如前文介绍，用client list命令，观察qbuf和qbuf-free两个字段，就是client query buffer使用内存大小。
如下示例（省去部分字段）
| 1 2 3 4 5 |
27.0.0.1:6390> client list id=169 qbuf=128679888 qbuf-free=425984 obl=0 oll=0 omem=0 events=r cmd=NULL id=171 qbuf=128679888 qbuf-free=425984 obl=0 oll=0 omem=0 events=r cmd=NULL id=218 qbuf=128679888 qbuf-free=425984 obl=0 oll=0 omem=0 events=r cmd=NULL id=151 qbuf=128696272 qbuf-free=425984 obl=0 oll=0 omem=0 events=r cmd=NULL |
避免query buffer过度使用
- 禁用大KEY，尽量保证key小于1KB; 虽redis支持512MB大小string。
- 监控redis内存使用，如果忽高忽低，极有可能query buffer引起
- 核心Redis集群定期收集client list并分析qbuf的使用量
- 建议官方提供query buffer size的设置参数，以保证过载保护
Client Output buffer
客户端输出缓存区：执行命令所返回的结果会保存到output buffer，返回给客户端。
每个客户端都有2个query buffer：
- 静态定长16KB的缓存区；主要快速存储返回比较小的结果；如简单的get等
- 动态大小缓冲区；存储返回较大的结果，如大的集合类型:set/list/hash
因为静态的buffer，一般无性能和风险影响，这里简单介绍。1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#define PROTO_REPLY_CHUNK_BYTES (16*1024) /* 16k output buffer */
/* With multiplexing we need to take per-client state.
* Clients are taken in a linked list. */
typedef struct client {
uint64_t id; /* Client incremental unique ID. */
redisDb *db; /* Pointer to currently SELECTed DB. */
robj *name; /* As set by CLIENT SETNAME. */
sds querybuf; /* Buffer we use to accumulate client queries. */
list *reply; /* List of reply objects to send to the client. */
/* Response buffer */
int bufpos;
char buf[PROTO_REPLY_CHUNK_BYTES];
} client;
我们常说的output buffer都是指“动态大小的输出缓冲区”。
output buffer大小限制
和qeury buffer不同，output buffer提供配置参数”client-output-buffer-limit”设置buffer的使用大小。
下面是limit的设置格式
| 1 2 3 |
client-output-buffer-limit normal 10mb 5mb 60 client-output-buffer-limit slave 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60 |
redis对3种不同客户端类型，可设置对应的buffer limit规则
- normal: 普通的客户端
- slave: 从库复制，连接到主库的客户端
- pubsub: 发布/订阅客户端
设置的limit规则3个值： hard limit size, soft limit size, soft limit second;
只要客户端使用output buffer内存大小超过hard limit限制，redis会立即关闭此客户端；
使用buffer内存大小超过soft limit，并且持续soft limit秒数，redis也会立即关闭此客户端。
被关闭客户端信息会打印到redis日志文件中，格式如下：
| 1 2 3 |
569:M 18 Jun 21:12:57.775 # Client id=972 addr=127.0.0.1:57934 fd=107 name= age=2 idle=0 flags=O db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=366 omem=10492208 events=rw cmd=monitor scheduled to be closed ASAP for overcoming of output buffer limits. |
查看output buffer使用
主要查开client list的obl(静态定长buffer)
omem: 当前客户端使用output buffer的内存字节数
如下客户端执行monitor命令(cmd=monitor), 已使用buffer内存是10492208，超过normal的hard limit 10mb
所以被redis关闭。
| 1 |
id=972 addr=127.0.0.1:57934 idle=0 flags=O db=0 qbuf=0 qbuf-free=0 obl=0 oll=366 omem=10492208 events=rw cmd=monitor |
另外output buffer受maxmemory的限制，基本不会超过maxmemory设置值
合理使用output buffer
因为output buffer是每个客户端都有，如使用不当，每个占用1mb * 10000 clients就约使用10G内存；
所以要有效限制程序滥用。
- 对于normal限制尽量小，可避免程序过度使用output buffer.
- 监控redis used_memory如果抖动严重，极有可能
- 增加slave的limit限制，避免slave同步线程被杀，导致无限循环同步数据；且slave线程和挂载的slave个数相同，理论只有几个
- 禁止生产环境使用monitor命令，在高QPS环境下，monitor很快会产生output query使用
如何监控output buffer和query buffer
从前文可见, 如果业务使用redis不当，两个buffer有可能导致内存爆涨，redis缓存数据被全部淘汰，甚于出现oom.
那么怎么监测两个buffer的使用情况，提前发现系统的异常行为，并告警就显得很重要。
这里提供两种不同监控采集方法：
- 通过采集client list输出，并分别统计求各所有客户端的(qbuf+ qbuf-free) 和 omem
- 使用info的clients section中的client_biggest_input_buf和client_longest_output_list两个指标来监控告警
第一种方法可精确统计当前时刻(buffer完全动态分配回收), redis使用的buffer内存容量；但要使用client list命令周期性统计，对于连接数较大redis实例，会导致数十毫秒卡顿(基准测试1w空连接，client list命令耗时约14.5ms)；
因为至少每隔几分钟要采集一次，在高并发实例下，这样耗时是不能被接受的，这就是常用的观察者效应。
在open-falcon的redis监控插件redismon, 我们用第二个方法，通过info采集；
两个指标表示的含义:
- client_biggest_input_buf：当前实例所有客户端中，最大query buffer内存的字节数。 告警阈值建议10485760(10M),根据业务再调整。
- client_longest_output_list:当前实例所有客户端中, 最长output buffer的个数。告警阈值建议500长度（前文例子中monitor客户端长度是336，output buffer约10M），不过常用keys,monitor,或复制sync过程，会触发告警。
两个指标只能反映，其中使用buffer最厉害那个客户端的使用的内存量；不能直接反映所有客户端使用两个buffer内存消耗。
但合理设置告警值，也能直接监测试redis系统用于buffer内存有异常，并跟踪定位异常导致的点；
因第二种方法，每分钟监控采集一次对系统无影响；虽没前者直观，也能定位发现问题了，觉得这就是一个tradeoff点。
Redis两个客户端的Buffer就简单介绍这些。后续文章会讲redis的监控和buffer相样的故障问题。
更多：https://github.com/ZhuoRoger/blog/tree/master/2016