陈少文的博客
·
从 CPU 到网络记录一次排查应用慢的过程
💡
原文中文，约8800字，阅读约需21分钟。
📝
内容提要
本文记录了一次排查应用慢的过程，发现是应用 app-b 在 HPA 扩容调度时调度到了同一节点上，导致节点的网络 IO、CPU 使用剧增，影响到了应用 app-a。解决办法是利用 Pod 的反亲和性，将应用 app-a 和应用 app-b 从调度层隔离开来。
🎯
关键要点
-
业务反馈应用 app-a 接口慢，发现是某个 Pod 慢，删除该 Pod 后问题解决。
-
监控显示 Pod 和节点的 CPU 使用率剧增，主要是 System CPU 增加。
-
排查发现磁盘 IO 没有瓶颈，iowait 低，磁盘 IO 指标正常。
-
网络 IO 监控显示节点的网络流量异常波动，找到流量异常的 Pod。
-
应用 app-b 在 HPA 扩容时调度到同一节点，导致影响应用 app-a 的性能。
-
解决方案是利用 Pod 的反亲和性，将 app-a 和 app-b 隔离调度。
-
应用 app-a 的慢问题有所改善，但仍偶尔出现慢的情况。
-
排查未发现 Pod CPU 被限流的证据，可能是对限流机制的误解。
-
CFS 限流机制设定了 CPU 使用的时间上限，监控指标未显示限流。
-
告警系统可能错过 CPU 限流的毛刺，但未发现相关证据。
-
kube-proxy 日志显示 iptables 操作被其他进程阻塞，可能导致网络流量转发慢。
-
kube-proxy 更新 iptables 速度慢，可能影响 Pod 流量转发。
-
应用 app-a 使用 PyTorch 框架在 CPU 上运行推理，CPU 使用率低但推理时间长。
-
总结排查思路：检查 CPU 限流、磁盘 IO、网络流量和应用依赖服务。
➡️
