微服务网关工程师亲历：服务器调优五大隐性陷阱

　　去年冬天，凌晨三点十七分，监控钉钉弹窗震得我手机在充电线上直跳——网关集群的 502 率从 0.03% 蹦到 12.8%，持续十七秒。我抓了件羽绒服就冲进公司，电梯里还在解 ssh 密码，手抖输错两次。运维老张已经蹲在屏幕前，嘴里叼着半截没点的烟，说：“查过了，后端全活，日志没报错，负载不超，你先看看。”

　　我连上测试节点，curl 一遍 upstream，正常；再 curl 同一个 endpoint 十次，第七次开始卡住——三秒、四秒、五秒……然后直接 timeout，返回 502。但 tail -f /var/log/nginx/error.log，干干净净，连个 upstream timed out 都没写。我原以为是 upstream keepalive 漏设，结果翻完全部 config，keepalive_requests 是 1000，keepalive_timeout 是 60s，都对。我原以为是 kernel net.ipv4.tcp_tw_reuse 没开，结果 sysctl -a | grep tw_reuse，回显是 1。

文章配图，仅供参考

　　老张把椅子往后一推，说：“要不你看看 conntrack？”他随手敲了条命令：conntrack -S ——那行“insert_failed”数字，正以每秒三到四的节奏往上跳。我盯着它看了二十来分钟，第八次刷新时，它停在了 65535。我敲了下 conntrack -L | wc -l，回显 65535。我原以为是连接数爆了，结果 lsof -i :80 | wc -l 才一千二百多。不对劲。真不对劲。

　　这时候小陈端了杯速溶咖啡过来，袖口沾着泡面汤渍（他昨晚通宵改 OpenResty 的 JWT 插件，刚合代码）。他扫了眼屏幕，问：“你 reload 过几次？”我说：“三次，都是用 systemctl reload nginx。”他皱眉：“reload 不清理 conntrack 表啊。”我愣了下，顺手敲 service nginx stop，等了五秒，ps aux | grep nginx，没了；再 service nginx start ——conntrack -S 里 insert_failed 归零了，502 就没再出来。不是 reload 本身错，是它不触碰 conntrack。这玩意儿压根不在 nginx 管辖范围内，它归 netfilter 管。可 netfilter 不跟 nginx 说话，nginx 也不管它死活。

　　反正我就记住了：reload = nginx worker 换血，conntrack 表继续躺平发霉。它不报警，不拒绝新连接，只在第 65536 个新建连接时悄悄扔掉——丢包无声，超时无日志，502 无上游痕迹。那天早上六点，我盯着那个插在墙上的路由器指示灯（蓝色常亮，其实它上周就坏了，一直闪红，只是灯罩裂了反光成蓝），想不通为什么没人早提一句。老张后来补了句：“厂商文档第 387 页脚注里写了，‘部分内核版本下 reload 可能导致 conntrack 条目滞留’。”我翻了，真有。可那页上面印着一行加粗黑体：“本节内容与业务稳定性无关。”

　　我也不知道该笑还是骂。我们天天调优 listen backlog、调优 worker_connections、调优 epoll，调优到连 TCP Fast Open 的 SYN-cookie 都能手动绕过……结果卡死我们的，是一张默默数到 65535 就罢工的表，连 error log 都懒得打一声招呼。小陈那杯咖啡凉透了，他吹了吹浮沫说：“上个月 QA 测过这个 case，报告压箱底了，没人看。”

　　后来我在另一个集群上又撞见一模一样的 insert_failed 涨停——这次是阿里云 SLB 后面挂了自建 Kong，Kong reload 后 conntrack 同样锁死，但阿里云控制台根本看不到这个指标，只看到“后端健康检查失败”，而健康检查探针明明跑通了。我们对着 dashboard 干瞪眼的时候，北京办公室那边发来消息说：“你们接口昨天半夜响应慢，用户投诉了。”——其实用户根本没收到慢响应，他们收到的是空白页和浏览器默认 502 提示。连提示都不是我们写的。

　　我原以为服务器调优是算力、内存、IO 的排列组合，结果最狠的刀藏在 netfilter 和 reload 的间隙里，静默，不报错，不落日志，只等你刚好凑够六万五千五百三十六次握手。有谁碰到过这个吗

（编辑：航空爱好网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!