现象如上图,发现读写耗时高,通过top查看redis进程cpu占用高,再通过ps查看该进程发现是bgsave进程。
那导致读写耗时高的原因就是主节点不停的调用bgsave。
那为啥会不停的调用bgsave呢。
通过查看config get save也没发现问题。
那问题应该就出现在主从同步了。
主从出现了频繁全量同步,从库连接断开从连并尝试增量同步失败,结果做了全量同步。这个操作开销很大:
主库bgsave->传到从库->从库加载rbd到内存(加载的时候是无法操作redis的)
通过config get client-output-buffer-limit
发现结果为:"normal 0 0 0 slave 256 64 60 pubsub 33554432 8388608 60"
这个slave明显有问题,导致主从同步失败,值这么小会导致增量同步失败,然后会做全量同步,主节点会bgsave。这样就导致主节点不停的bgsave。
重新设置主节点的client-output-buffer-limit的slave值:
config set client-output-buffer-limit "slave 0 0 0"
为了以防超时,并主从节点都设置
config set cluster-node-timeout 15000
问题解决。
redis节点失联调整client-output-buffer-limit及cluster-node-timeout
通过redis monitor命令监控ip发送的命令,但不能监控config等命令
./redis-cli -p 6379 monitor
通过tcpdump抓取终端发过来的命令
抓取从eth0网口到10.102.16.126:6379调用keys及config命令的ip
tcpdump -nn -vv -s0 -i eth0 dst host 10.102.16.126 and dst port 6379 -A|awk 'BEGIN{output=">>>>>>\n"} { if($0~/^$/){ if(output~/keys|config/) print output"<<<<<<"; output=">>>>>>\n"} else {output=output$0"\n"; } }'
-A 以ASCII码方式显示每一个数据包
-s snaplen
设置tcpdump的数据包抓取长度为snaplen, 如果不设置默认将会是68字节
-i interface
指定tcpdump 需要监听的网口
-nn 数字显示地址端口
也可以通过grep或sed进行命令过滤
sed命令n,N,d,D,p,P,h,H,g,G,x解析
sed的模式空间和保持空间
查询某个ip的流量可以用iftop命令
iftop -iehth0 -n -N -B -P
-i设定监测的网卡,如:# iftop -i eth1
-B 以bytes为单位显示流量(默认是bits),如:# iftop -B
-n使host信息默认直接都显示IP,如:# iftop -n
-N使端口信息默认直接都显示端口号,如: # iftop -N
-P使host信息及端口信息默认就都显示
进入iftop后的操作
按t切换显示格式为2行/1行/只显示发送流量/只显示接收流量;
按S切换是否显示本机的端口信息;
按D切换是否显示远端目标主机的端口信息;
按T切换是否显示每个连接的总流量;
按l打开屏幕过滤功能,输入要过滤的字符,比如:6379,只查看6379端口
iftop命令详解
 
redis被攻击问题排查:等您坐沙发呢!