Linux服务器明明没跑几个程序，CPU却狂飙到95%，改参数像开盲盒，最后发现压根没对症。

这事儿发生在我上个月帮公司一台老数据库服务器“急救”的时候。不是硬件坏了，也没被黑，就是用户一多，登录慢、查询卡、日志刷屏，重启服务顶多撑两小时。运维老张甩给我一串`top`截图，说“你懂点技术，看看是不是得加内存”。我真去看了，结果`free -h`显示还有2.3G可用，`MemAvailable`甚至比上周还多了一截。

原来问题出在`systemd-journald`上。它把所有服务日志全塞进二进制文件里，没配轮转策略，半年下来占了18G，而且每天还在涨。更坑的是，只要它一刷盘，`iostat -x`里`await`就跳到80ms以上，所有进程排队等IO，`load average`直接飙到12。但这不是CPU真忙，是磁盘被日志堵死了。

很多人第一反应是`echo 3 > /proc/sys/vm/drop_caches`，我也试过，清完立马变快，但半小时后又卡。后来查`/var/log/journal/`发现，里面全是`.journal~`的备份碎片，`journalctl --disk-usage`回显22G，而`df -h`却只显示用了11G——说明日志索引和数据已经错乱了。

正确做法不是删文件，是让systemd自己重建。先建好目录，再用`systemd-tmpfiles --create`初始化结构，最后重启journald。整个过程不到40秒，之后`journalctl -n 20`能正常读，`iostat`的`avgqu-sz`从7降到0.3，load也回落到1.2。这不是玄学，是它重新加载索引后，不再反复扫描坏块。

还有一次，Java服务每小时来一次Full GC，堆从4G涨到7G，`pmap -x PID`里`anon`列每天+300MB。开发说“肯定是内存泄漏”，结果用`jstat -gc PID`看了10分钟，发现是`Metaspace`满了，`-XX:MaxMetaspaceSize=512m`压太死，类加载器反复卸载又加载。改成1G，GC次数直接归零。

别信什么“调高swappiness就能救内存”。我们真试过，把值从60改成90，结果OOM killer半夜干掉Redis，因为系统误判“内存够，只差换出”，其实Cache全是热点数据，一换就崩。后来发现，`/proc/meminfo`里`SReclaimable`有1.8G，这部分根本不能动，`MemAvailable`才是真可用的，它当时只剩200MB。

排查网络问题也一样。看到`ss -s`里`time_wait`有8000个，第一反应是改`tcp_tw_reuse`。但`netstat -s | grep "TIME_WAIT"`显示的不是连接数，是累计关闭次数，再看`ss -tn state time-wait | wc -l`才真正只有23个。那8000是过去两天的总和。真正堵的是`accept()`卡住，用`perf record -e syscalls:sys_enter_accept`抓了30秒，发现Nginx上游超时重试太多，把连接池打满了。

工具不是越多越好。`pidstat -u 1 5`比`top`靠谱，因为能捕获0.3秒的CPU尖峰；`bpftrace`脚本一行能盯住块设备延迟，比`iostat`准；但最常用的还是`vmstat 1 5`，看`r`(运行队列)和`b`(阻塞队列)两个数字，一个高是CPU忙，两个都高，十有八九是磁盘或网络卡在底层。

调参得写清楚为啥改。我在`/etc/sysctl.d/99-custom.conf`里加了一句`net.core.somaxconn=65535 WHY: 解决高并发下accept queue overflow，2025-11-18 by 小陈`。没人再瞎改`/etc/sysctl.conf`主文件，因为改了会被覆盖，而子配置优先级更高。

最后压测不是走形式。`stress-ng --cpu 2 --io 1 --vm 1 --timeout 30s`跑三遍，看`uptime`和`dmesg | tail`有没有OOM记录。有一次改完`vm.swappiness=1`，压力一上来，`kswapd`线程占满一个核，反而更卡——原来SSD写入延迟低，swap不是洪水猛兽，但设成1后，系统宁可死扛也不换出，最后进程直接被kill。

优化这事，跟修自行车差不多。链条响不一定是缺油，可能是飞轮歪了；服务器卡，也不一定是CPU不行。你得蹲下来，听听哪块在响，摸摸哪根线烫手，再动手。

x，x，x。