记一次Redis连接超限排查

.example_responsive_1 { width: 200px; height: 50px; } @media(min-width: 290px) { .example_responsive_1 { width: 270px; height: 50px; } } @media(min-width: 370px) { .example_responsive_1 { width: 339px; height: 50px; } } @media(min-width: 500px) { .example_responsive_1 { width: 468px; height: 50px; } } @media(min-width: 720px) { .example_responsive_1 { width: 655px; height: 50px; } } @media(min-width: 800px) { .example_responsive_1 { width: 728px; height: 50px; } } (adsbygoogle = window.adsbygoogle || []).push({});

记一次Redis连接超限排查

目录

• 记一次Redis连接超限排查
  • 第一步 重启并抢先占一个连接
  • 第二步 记录全部客户端
  • 第三步 找出异常IP
  • 第四步 定位服务并把锅扔过去
  • 欢迎关注公众号(代码如诗)
  • 推荐阅读

记一次Redis连接超限问题排查经过. 文章地址: https://cloud.tencent.com/developer/article/1557583 项目起不来了! … 项目又起不来了! … 又双叒叕???!!!

上周经常听到组里同事说项目又双叒叕挂了, Redis连不上, 笔者在另一套正常的环境忙着开发新需求, 没空关心这个问题.(PS: 反正我的环境能用(´థ౪థ）σ , 先忙完我的再说).

于是乎, 看了一眼日志, 连接数过多… emmm, 顺手帮同事把Redis配置里连接数上限加了个0, 问题排查什么的等忙完再说.

ERR max number of clients reached

终于… 该来的总逃不掉, 笔者用的环境也被搞崩了, 而且是莫名其妙地就凉了.

不过… 因吹斯汀 !

修改连接数上限毕竟治标不治本, 本来连接数上限就是10000, 微服务总共才几十个, 按理说根本用不完.

肯定有人没关连接, 查他.

已知:

1. Redis服务重启后, 用一段时间连接就又满了.
2. 服务总共几十个, 配置的一万连接数正常情况下不大可能用完.

第一步 重启并抢先占一个连接

笔者重启了Redis后, 立即连接到Redis, 查看客户端数量(晚了就连不上了):

$ docker exec -it $(docker ps | grep redis | awk '{print $1}') redis-cli -a {pwd}
127.0.0.1:6379> info
...
# Clients
connected_clients:391
...

tips: info命令能查看关于 Redis 服务器的各种信息和统计数值.

第二步 记录全部客户端

几分钟后再次查看:

127.0.0.1:6379> info
...
# Clients
connected_clients:10002
...

此时, 连接已经被全部占满了.

将全部客户端信息保存到文件准备抓出这个搞事情的老哥.

127.0.0.1:6379> client list
id=7863 addr=172.18.0.104:56836 fd=6150 name= age=72 idle=72 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping
id=7864 addr=172.18.0.50:56262 fd=6151 name= age=72 idle=72 flags=N db=9 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping
id=7865 addr=172.18.0.104:56840 fd=6152 name= age=72 idle=72 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping
...

tips: client list: 列出全部客户端信息.

第三步 找出异常IP

有了全部的客户端连接信息, 就能找出到底是谁的锅了. 使用命令输出连接数前五的IP:

$ cat client-list | awk '{print $2}' | awk -F "[=:]" '{print $2}' | sort | uniq -c | sort -k1,1nr | head -5
5432 172.18.0.50
4244 172.18.0.104
  43 172.18.0.59
  40 172.18.0.54
  32 172.18.0.55

到目前为止, 锁定了172.18.0.50和172.18.0.104两个IP. 这两个都是docker内部网络的地址.

tips: awk '{print $2}: 输出第二列, 即IP. addr=172.18.0.104:56836. awk -F "[=:]" '{print $2}': 通过等号和冒号拆分addr=172.18.0.104:56836, 并输出中间的IP. sort: 排序. uniq -c: 统计数量并在每列旁边显示该行重复出现的次数.

第四步 定位服务并把锅扔过去

拿到了IP就离目标不远了, 通过docker inspect能输出docker实例的信息, 其中就包括IP.

$ docker inspect --format='{{.Name}} - {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $(docker ps -aq) | grep 172.18.0.50
/docker_xxxxx-service - 172.18.0.50
$ docker inspect --format='{{.Name}} - {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $(docker ps -aq) | grep 172.18.0.104
/docker_yyyyy-service - 172.18.0.104

tips: docker inspect: 获取容器/镜像的元数据. --format: 用模板格式化输出.

至此, 定位到了xxxxx和yyyyy,嗯… 隔壁Py (thon)组的服务. 来, 锅给你.

​

推荐阅读

• 不停服迁移数据
• MySQL查漏补缺
• 开放API网关实践(一) ——设计一个API网关
• 开放API网关实践(二) —— 重放攻击及防御
• 开放API网关实践(三) —— 限流
• Kubernetes(一) 跟着官方文档从零搭建K8S
• Kubernetes(二) 应用部署
• Kubernetes(三) 如何从外部访问服务

我的博客即将同步至腾讯云+社区，邀请大家一同入驻：https://cloud.tencent.com/developer/support-plan?invite_code=2lbkh8cwv72z

© 2019, 朴瑞卿.

版权声明

 本文发布于[朴瑞卿的博客](https://blog.piaoruiqing.com/), 允许非商业用途转载, 但转载必须保留原作者[朴瑞卿](https://blog.piaoruiqing.com/) 及链接:[https://blog.piaoruiqing.com](https://blog.piaoruiqing.com/).      如有授权方面的协商或合作, 请联系邮箱: [piaoruiqing@gmail.com](https://blog.piaoruiqing.com/mailto:piaoruiqing@gmail.com).