Linux 服务器半夜负载飙高，我们一般按这个顺序往下查

凌晨两点，客户的运维群在喊：产线看板刷不出来了。系统跑在一台 Linux 服务器上，监控面板里那个负载数字已经飙到四十多。这种电话我们接过不止一次，赶到现场，有时候机器是真忙，有时候是它在空转。这两种情况处置方向完全相反，判断错了，重启也白搭。

一、先分清是"真忙"还是"卡住了"

很多人一看负载高，就以为 CPU 忙不过来，其实不是一回事。Linux 的负载值把正在跑和排队等资源的任务都算进去，一个进程卡在磁盘读写上不动，负载照样往上涨，可 CPU 闲得很。所以第一眼要看的不是 CPU 使用率，是那几个数字在持续往上爬，还是已经横住了。

如果负载长时间居高不下、CPU 使用率却很低，麻烦多半出在磁盘或者锁上。反过来 CPU 被打满、负载也跟着涨，那才是真有东西在死算。这个判断花不了两分钟，方向却能差出很远。

二、按固定顺序往下查，别跳步

我们的排查顺序基本是固定的。先用 uptime 看负载走势，再用 top 挑出吃资源最猛的几个进程，接着 free 看内存和 swap 有没有被打穿，然后 iostat 看磁盘的读写等待，最后 ss 看连接数是不是异常。

这五步走完，绝大多数问题自己就现形了。顺序不能乱，最忌讳一上来就重启，等于把现场毁了，问题下次还会原样再来。遇到过一家工厂，服务器反复卡死，前几次都是重启了事，等摩杰斯接手才发现，是日志文件把一个分区写满了，写日志的进程一直失败重试，把负载生生拖了起来。删掉旧日志、把轮转配好，这个毛病再没犯过。

三、工厂服务器上最常见的几个真凶

跑在工厂里的服务器，负载异常的原因翻来覆去就那么几样。最常见的是磁盘写满，尤其是日志目录和数据库的数据目录，一旦分区满了，不少进程会进入奇怪的重试状态，越试越忙。其次是数据库慢查询，一条没走索引的 SQL 就能把 CPU 拉满，白天业务一多就爆。再就是内存不够引起的 swap 抖动，机器看着没事，实际一直拿硬盘当内存用，慢得离谱。

还有一类容易被忽视：定时任务撞车。备份、对账、报表这些活，常常被排在同一个凌晨时段，几件事一起挤，磁盘和 CPU 瞬间就被顶上去了。把时间错开，往往就能消掉一大半的夜间告警。

四、平时做对几件事，半夜就不用爬起来

给客户部署系统时，我们有几个标准动作。日志必须配轮转、设上限，绝不让它无限长大；磁盘、内存、负载都接上监控，超阈值提前发告警，别等业务报错才知道出事；定时任务排开时间，别都堆在同一个点上。

这些预防做到位，能砍掉大半的紧急故障，剩下的才是真正需要连夜处理的意外。摩杰斯从 2012 年在昆山成立起，PMS9、PMS5 的后端就一直跑在 Linux 上，十四年下来，苏州、江苏一带几百家制造客户的现场服务器都经过我们的手，这类排查是日常。昆山、苏州一带的工厂，服务器半夜出问题、一时找不到人看的，可以找摩杰斯一起看。

总结：

负载飙高的第一反应不该是重启，而是先分清机器是真忙还是在空转，再按负载、CPU、内存、IO、网络这个顺序一步步看下去。工厂服务器的常见病根就那么几样——磁盘写满、慢查询、swap 抖动、定时任务撞车。把日志轮转、监控告警、任务错峰这几件事做在前面，很多半夜的电话就不会来。

相关阅读：《工厂 IT 服务总览》把这几类问题都归了类；同一主题下还有《产线系统分钟级拉起》、《14 年 Linux 服务器运维实录》。