【故障公告】Memcached 的“惹祸”,不知在为谁背锅

.NET 5.0 背锅Memcached 的惹祸缓存雪崩之后,我们没有找到问题的真正原因,我们知道没有找到根源的故障总是会再次光临的,不是在这周就是在下周,也许就在双11前后。

就在今天双11的前一天晚上,在我们 20:30 进行常规发布的时候,它来了。。。

原本平滑的 memcached 服务器 tcp 连接数走势曲线开始爬坡,博客站点大量的访问请求响应缓慢,每次都“惹祸”的 memcached 自然首当其冲地成为嫌疑的焦点。

我们重启了所有 memcached 服务,tcp 连接数飞流直下三千尺地降了下来,但是降落之后却又开始新的一轮爬坡,故障没有恢复,网站访问速度依然缓慢。

这时,我们突然醒悟,memcached 没有惹祸,问题不在 memcached ,问题可能在前方阵地(用阿里云服务器自建的kubernetes集群)的 pods 发生了 tcp 连接泄漏,立马赶赴前线。

博客站点的多个 pod 处于 CrashLoopBackOff 状态

复制代码
NAME                        READY   STATUS             RESTARTS   AGE   IP                NODE       
blog-web-6644bfd597-2fpd6   1/1     Running            0          48m   192.168.86.93     k8s-n20    
blog-web-6644bfd597-4cnc5   1/1     Running            0          49m   192.168.168.112   k8s-n6     
blog-web-6644bfd597-bqbmf   0/1     CrashLoopBackOff   11         49m   192.168.73.63     k8s-node10 
blog-web-6644bfd597-db8jk   0/1     Running            13         48m   192.168.107.238   k8s-node3  
blog-web-6644bfd597-dthtn   0/1     CrashLoopBackOff   13         49m   192.168.104.103   k8s-node11 
blog-web-6644bfd597-fxzml   1/1     Running            13         48m   192.168.195.224   k8s-node5  
blog-web-6644bfd597-qvgkf   1/1     Running            12         47m   192.168.89.229    k8s-n8     
blog-web-6644bfd597-slmp7   0/1     CrashLoopBackOff   13         49m   192.168.201.126   k8s-n14    
blog-web-6644bfd597-txg5h   0/1     CrashLoopBackOff   13         45m   192.168.42.57     k8s-n13    
blog-web-6644bfd597-wc57c   0/1     Running            13         47m   192.168.254.167   k8s-n7     
blog-web-6644bfd597-xt5hc   0/1     CrashLoopBackOff   11         47m   192.168.228.53    k8s-n9     
blog-web-6644bfd597-zz564   1/1     Running            0          47m   192.168.118.27    k8s-n4  
复制代码

怀疑造成 tcp 连接泄漏可能是这些处于 CrashLoopBackOff 状态的 pod ,于是将 pod 全部强制删除,在删除后过了一段时间,memcached 服务器 tcp 连接数从爬坡状态回归平滑状态,故障就恢复了。

查看 k8s 集群 node 服务器的 tcp 连接情况,在故障期间,node 服务器的 tcp 连接数上蹿下跳,大量 tcp 连接无法建立。

到目前我们还是没有找到问题的根源,但我们知道了 memcached 没有惹祸,memcached 是在背锅,但不知道在为谁背锅。

非常抱歉,今天 20:35~21:35 左右博客站点发生的故障给您带来麻烦了,请您谅解。

posted @   博客园团队  阅读(2700)  评论(14编辑  收藏  举报
编辑推荐:
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· C++代码改造为UTF-8编码问题的总结
· DeepSeek 解答了困扰我五年的技术问题
· 为什么说在企业级应用开发中,后端往往是效率杀手?
阅读排行:
· 2分钟学会 DeepSeek API,竟然比官方更好用!
· .NET 使用 DeepSeek R1 开发智能 AI 客户端
· autohue.js:让你的图片和背景融为一体,绝了!
· 10亿数据,如何做迁移?
· 推荐几款开源且免费的 .NET MAUI 组件库
历史上的今天:
2014-11-10 上周热点回顾(11.3-11.9)
点击右上角即可分享
微信分享提示