诡异的linux系统负载问题

CPU的系统负载通常指的是CPU在处理任务时的繁忙程度，它反映了CPU正在执行或等待执行的任务数量。系统负载可以通过多种方式来衡量，其中最常见的是使用系统负载平均值（Load Average）来表示。

可移至linux系统负载对系统的意义

如果你从网上查询如何分析系统负载，大概率可以查到两大类系统负载高的问题。

1. CPU使用率高，iowait不高，系统负载高
2. CPU使用率高，iowait高，系统负载高

这两大类问题，实际都是比较简单的类型。因为CPU使用率高，那就可以查询到哪个进程占用CPU高，那基本就定位到了问题所在。

而我很不幸遇到了第三种情况，即CPU使用率不高、iowait也不高，就只有系统负载高。

分析流程

分析问题时，还是按照常规流程进行的。

发现系统负载高后

1. top（或sar -u 1）查看问题期间cpu使用率的情况

获取cpu使用率的情况后，发现，cpu的总体使用率很低，空闲80%以上，user、sys、iowait均为个位数。

1. free查看是否有swap使用的情况

发现有swap使用的情况，怀疑是因为swap使用磁盘了，导致交互变慢。所以先从这里入手，把swap关了（swapoff -a）。结果依然感人，系统负载并没有下降。

1. 火焰图

前两步没找到原因，那就使用大杀器试试。使用perf命令抓取火焰图，发现有1/3的时间系统都在处理file lock，但是只能看到pid，所以也不知道是谁在占用file lock。

1. 进程数量

重新退回到top（或ps）分析，发现总的进程数量并没有什么异常，跟正常节点之间差距只有200个进程左右。

1. 队列个数

使用sar -q 1查看系统负载情况，发现plist（进程队列大小）个数竟然有17w+。

1. 线程数量

既然进程数对不上，那就看看线程数，使用ps -eLf查看进程及线程关系，发现有一个进程竟然有10w+的线程数。

结论

基于上述的分析，推导出来的结论：进程创建了10w+的线程，并且出现了类似死锁的问题，导致大量线程等锁，从而导致了系统负载的飙升。