运维老炮儿绝不会说的服务器调优潜规则

　　掘金上看见个帖子问“服务器调优的底层逻辑”，底下清一色讲 cgroups、bpftrace、pagecache 水位、irqbalance 亲和性——呵，这哪是调优，这是给面试官交作业。

　　去年冬天，三号机房那台跑定时任务的老家伙突然开始掉 connection reset。不是报错，就是连着连着没了，像被谁悄悄拔了网线。我蹲在 rack 前头看 dmesg，手指冻得打滑，监控面板反光映出我后颈那块没刮干净的胡茬。旁边老张叼着半截没点着的烟，在工单系统里敲“疑似网络抖动”，敲到一半停住，抬头问我：“你信抖动？”

　　我原以为是内核参数太保守，把 net.ipv4.tcp_fin_timeout 从六十秒砍到十八秒，net.core.somaxconn 提到一千二——结果半夜三点，它反而在凌晨两点零七分准时挂一次，整整齐齐，像有人按表打卡。我盯着屏幕右下角时间跳成 02:07:00 的那一帧，窗外雨声突然变大，机房顶棚漏的那滴水也刚好砸进接水桶，“咚”一声，跟 NTP 同步日志里的 timestamp 严丝合缝。

　　后来查出来？啥都没查出来。就发现它每回掉线前四十秒，/proc/interrupts 里某个 CPU 的 IO-APIC-level 那一行，中断计数会诡异地平掉两秒——不是突增，是平，像被橡皮擦抹过。我截图发群里，运维老炮儿老周秒回：“关掉 irqbalance，手绑亲和。”我没动。第二天他路过我工位，顺手把我桌上那盒冷掉的酸辣粉往右边推了七厘米，说：“别碰。”

文章配图，仅供参考

　　再后来……算了，不说了。反正上周那个新来的实习生，按文档把 vm.swappiness 改成一，然后去吃午饭。回来发现 swapfile 还在，但 /proc/swaps 显示空——其实 swapoff 失败了，只是 error 被 journalctl 的 log_level=warning 给吞了。没人告诉过他：swap 不是你设了 swappiness 就认你当爹的，它得看你内存碎片够不够松软、有没有人偷偷 mmap 了 MAP_HUGETLB 还没 munmap……

　　老炮儿绝不会说的潜规则？根本不是什么“留百分之二十余量”“CPU 别超七十”这种蠢话。是优胜劣汰。你调参调得越准，越暴露你在哪一层裸泳。调内核？说明你没压住应用层的锁争用；调磁盘 IO 调度器？说明你连 pgpgin/pgpgout 和 pgmajfault 都分不清谁在啃 page cache；连 sysctl 都背不全，好歹先让业务代码别在 for 循环里 new String() 啊。可现在呢？监控告警一响，三个组同时抢 root 权限改 sysctl，没人点开 jstack 看第十一行到底是不是在等一个永远拿不到的锁。我敢打包票，上周五生产库慢查询 Top3 里，有两个是同一个 ORM 的 with_for_update 方法嵌套在 lambda 表达式里触发的——这个我能截图证明，但我不放，怕你们截图去怼 DBA。

　　那天下午五点四十七分，保洁阿姨推着拖把经过我们工位，水渍在瓷砖上拖出一条细长反光，正好横切过老周显示器右下角——他正开着 htop，所有 CPU 核心都趴着，唯独那个负责处理 cron 的 core，负载尖刺高得离谱，像被钉在柱子上。他没动鼠标，只是把左手小指翘起来，轻轻搭在键盘最右边的 delete 键上，停了大概三秒。我看见他袖口磨出了毛边，但没看见他动。

　　其实我试过在 K8s 集群里跑 perf record -e 'syscalls:sys_enter_accept'，抓到过三百七十二次 accept 系统调用被拒——不是资源不足，是 listener socket 的 backlog 队列满了，而那个值，被 nginx.conf 里一个带注释的 keepalive_timeout 行，悄悄继承了三次，最终覆盖掉 sysctl 里配的 net.core.somaxconn。这事我说不准是谁的手抖，但我知道，那行注释最后写着：“# 此处为历史兼容，不可删”。

　　对了，机柜第三层那个风扇，从十一月起就有异响，像指甲刮白板。我们听习惯了，值班表上也没写“该修”，就每天换班时，有人会下意识抬一下下巴，示意下一个人记得盯它——但这跟调优有屁关系。真没关系。但它就在那儿，呼噜…呼噜…呼噜……

　　我今早重看了遍 strace 日志，发现那个掉线瞬间，程序其实在尝试 connect() 到本机 127.0.0.1:6379，但 timeout 前 0.008 秒，它读到了一个 EOF。不是 RST，不是 FIN，是 EOF。这意味着 socket 已经被 close() 过一次，又强行 write() 了一次。可 Redis 客户端 SDK 明明做了连接池回收检查啊……所以我在想，会不会是某个测试用例，执行完忘记 shutdownSpringContext，而 context 里那个 @PostConstruct 初始化的 JedisPool，早就随着 JVM 卸载被干掉了，只剩个 dangling fd 在那里装死？

　　这事儿我懒得追了。下午打算去趟三号机房，把那个漏雨的桶换个位置——不能让它总在整点砸下去。要是砸偏了，说不定能多撑两天。

（编辑：站长网）

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