运维新手必避的5大服务器配置坑,第3个90%人中招
|
文章配图,仅供参考 跟老板拍桌子那天是下午三点,空调坏了,机房那边飘过来一股铁锈味儿。我盯着监控面板上那个跳着跳着就卡死的 CPU 曲线,直接把键盘推到一边——不是气他,是气自己居然又看漏了 swap 配置。去年九月份那波故障,三台 Web 节点全在半夜十二点之后轮着挂,K8s 自愈像中了邪,Pod 重启三次就进 Evicted 状态。我原以为是 readiness probe 太激进,结果扒开 kernel 日志一看:Out of memory: Kill process 1247 (node) score 892 or sacrifice child。好家伙,连 OOM Killer 都懒得挑人了,专逮 Node.js 主进程下手。第3个坑?就是 swap 默认关。不是“建议关”,是绝大多数发行版装完默认就关,而新手连 swapoff -a 都不记得敲第二遍。你查 /proc/swaps 是空的,/etc/fstab 里注释掉 swap 行,systemctl disable swap.target——全套操作做完,心里还美滋滋觉得“干净利落”。但问题是,Java 用 G1 垃圾回收器时,堆外内存涨得比水位线还快;Go 的 runtime.mstats.Sys 在 mmap 区没限制的情况下能悄无声息吃掉八百兆;就连 Rust 的 Box::leak,在 trace 开太多时也能绕过 cgroup 的 memory.limit_in_bytes 搔痒痒。这时候你靠什么缓冲?靠 OOM Killer 的骰子吗? PM 昨天还在群里发了个 Lighthouse 跑分截图,FCP 十九毫秒,LCP 三百七十二 KB,底下没人回。我看了一眼——全是本地 localhost,测的还是 dev-server。我也没回。谁去倒水?后端老张。他刚换了根 Type-C 充电线,银灰色那根,接口有点松,插进去得往左偏两毫米才充得上。桌面那个录屏一直没关,角落里窗口缩成一条白线,还在记着 Chrome DevTools 的 Network 面板。你说这些跟 swap 有关?没关。可你就得记住,真实世界的故障永远发生在这些缝隙里,不在 checklist 上。 我敢打包票:这坑,90% 新人栽。为什么?因为文档写“swap 影响性能”,可它没写“swap 关了会让 memory.overcommit_ratio 失效”,也没提“cgroups v1 下,swap=0 会彻底废掉 memsw.max_usage_in_bytes 统计逻辑”。更没人告诉你,Docker 默认 --oom-score-adj=-500,但宿主机内核一碰到 swap=0,OOM 分数计算就直接退化成按 RSS 堆叠猜——所以你以为 kill 掉的是 nginx worker,结果干掉的是 pgBouncer 连接池主进程。这事我们线上出过三次,最后一次是数据库连接数暴增到两千四,pgbouncer 日志里全是 couldn’t create socket,可 ulimit -n 明明设到了六万五。后来才发现,是 kernel 把 pgBouncer 的 file descriptor table 放在了匿名页,而匿名页没 swap 就没法换出,于是直接爆了 vm.max_map_area_count。这个我说不准是不是所有发行版都这样,CentOS 7.9 和 Rocky 9.2 表现就不一样。 还有人信“云厂商推荐关 swap”,我呸。他们只管单实例成本,不管你的服务集群会不会凌晨三点集体抖动——就像去年双十一,某家 CDN 回源节点突然全部延迟飙高,查下来是上游 SLB 的健康检查 TCP SYN 超时触发重试风暴,而 SLB 后面那批 ECS 全是 swap=0 的配置。账单倒是好看,CPU 使用率曲线平滑得像熨斗烫过,可实际 RT 标准差从三点七毫秒蹿到二十七毫秒。没人怪账单,只怪你没拦住运维同学在 terraform 模块里加那句 swap_enabled = false。 前端小李上周问我:“为啥我压测时 keep-alive 要调长?”我没答。不是不想说,是他问的时候正蹲在茶水间修咖啡机——水流出来一半停了,他拿纸巾堵着出水口,手肘碰歪了我的显示器支架。我就顺手把 /etc/sysctl.conf 里 vm.swappiness=10 那行发给他了。其实他还该看看 /proc/sys/vm/vfs_cache_pressure,但这事儿我不想教了。优胜劣汰是真的,不是鸡汤。活下来的不是最勤快的,是那个在第一次部署完就手动 echo 10 > /proc/sys/vm/swappiness 并且 grep -r “swappiness” 到所有 Ansible role 里的。 再说个跑题的:上个月 KPI 折算,我们组被要求把“MTTR 下降”拆成 7 个子指标,其中一条叫“配置类故障平均归因耗时”。我填了个“2.1 小时”,其实多数时候卡在查 swap 状态——不是技术问题,是团队没统一配置基线模板,有人用 cloud-init 生成器自动生成配置,有人手写 YAML,还有人复制三年前的旧模板。最后验收时 QA 提了个 bug:“配置校验脚本没报 swap 缺失告警”。我点了退回,写了句“非缺陷,属配置治理范畴”。没再改。 现在你去翻你们的 ansible-playbook,找找 roles/base/tasks/configure_memory.yml,如果里面没出现 swappiness、overcommit_memory、vm.min_free_kbytes 这仨词,趁还没上线新环境,把它删了重写。别等半夜收到 PagerDuty 弹窗——弹窗上写的永远是 “service_unavailable”,不会写 “you_forget_swap”。 (编辑:站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |


Windows多媒体站点权限配置:9年容器运维工程师的一键落地方案
5年运维实战:建站资源优化,首屏快3倍、存储省70%
边缘计算运维驱动营销与运营双轮提效37%
网站运维者必知的5大云安全防护盲区
运维老手血泪总结:5大服务器部署深坑
混合云运维视角:PHP实时交互卡顿3步优化
站长必修:SQL Server运维12大坑与交互避险指南
