服务器一卡，大家的第一反应就是敲top或者uptime看负载，然后盯着load average那三个数字犯嘀咕：5.32 4.18 3.05，这到底算高还是低？更让人懵的是，有时候负载都飙到好几了，一看CPU占用率却不高，这又是咋回事？今天我就把这层窗户纸捅破，让你看完能真正读懂负载，而不是光会念那三个数。
load average到底在统计啥
别被它英文名字唬住，负载统计的就是系统里正在干活和排队等干活的进程数量。想象一个柜台，正在办理业务的算一个，排队等待的也算，这三个数字就是过去1分钟、5分钟、15分钟的平均排队人数。理解了这点，你就知道它跟CPU核数有直接关系：单核机器负载到1.0就相当于柜台排满，四核机器负载到4.0才叫满。所以看负载必须带着核数看，脱离核数谈负载，那都是耍流氓。
最迷惑人的场景：负载高CPU却不忙
这就是新手和老手的分水岭了。很多人以为负载就是CPU占用率，其实负载统计的进程里，有一类是在等东西的——等磁盘读写、等网络、等锁。打个比方，柜台服务员确实闲着，可客户都在门口排队等着交资料（数据从硬盘读出来），队伍照样很长。所以当CPU不高、负载却很高的时候，别盯着CPU瞎猜了，重点去查磁盘IO和那些等待中的进程。
三个数怎么配合着看
有人问，三个数字到底看哪个？其实要对比着看：1分钟的数比15分钟高很多，说明负载正在往上冲，可能是流量上来了或者任务扎堆了；15分钟的数一直高居不下，说明高负载是常态，不是偶发。我的习惯是：看趋势比看绝对值有用，负载的走向比某个瞬间的数更能说明问题，就跟看股票似的，单日涨跌不如看均线。
定位负载来源，三步走
第一步，top按CPU排个序，看看是不是真有进程在猛吃CPU，顺手按内存排个序，排除内存问题；第二步，用vmstat看两个关键列，r列是真正排队等CPU的，长期比核数还高说明CPU确实不够用，wa列是等待IO的，wa一高就是磁盘在拖后腿；第三步，wa高的话再用iostat看具体是哪块盘在忙，%util接近100%基本就是磁盘饱和了。
这套组合下来，负载高到底是CPU的锅、磁盘的锅还是其他等待的锅，基本就水落石出了。最怕的就是不查直接重启，重启完当时是好了，过俩小时又犯，那等于没治。
不同情况咋对症下药
CPU型负载高，就优化程序、减负担，或者干脆升级CPU核数；IO型负载高，看看是不是数据库没索引在疯狂全表扫，或者备份任务在高峰期抢IO，该加索引加索引、该错峰错峰；运行队列堆积，多半是进程开太多或者锁竞争，检查线程池、连接数，还有定时任务是不是全挤在同一个时间点跑。每类问题的解法都不一样，先分清楚类型再动手，才不会白费劲。
顺手补几个细节
还有几个细节值得记一下：查负载的时候，top里那行跟uptime是同一个东西，不用开两个窗口；虚拟机或者云服务器看负载，偶尔会看到瞬时飙升又回落，这有可能是同宿主机上其他虚拟机在折腾，属于邻居噪音，偶尔一次不用太在意，持续高才是真问题。另外，负载排查别忘了看平均负载跟核数的比值，超过核数还不回落，那基本就是常态性饱和了，该认真对待。
还有个很常见的乌龙：有人用宝塔或者云监控看到负载高，就以为是中了病毒，先杀毒软件跑一圈再说。其实多数时候就是业务本身或者配置问题，先按CPU、IO、队列这三类排查，实在查不到再说安全的事，别本末倒置。
说个实战案例，帮你加深印象
有回一个朋友的论坛半夜卡成PPT，负载常年两位数，他以为是CPU不够，都准备下单升级了。我上去一看，CPU占用才三成，wa高得吓人——再一查，是论坛的搜索功能没索引，用户一搜索，数据库就全表扫描，把磁盘IO直接打满。后来给搜索字段加了索引，负载当场就下来了，一分钱没花。所以你看，排查清楚类型，比盲目加配置重要得多，钱要花在刀刃上。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
