最近经常收到告警，CPU load大于阈值告警。查看系统的CPU是12核，告警阈值设置的是8。对于CPU load一直有个模糊的概念，具体是什么意思还真搞不明白，趁这个机会好好搞搞究竟。
1.查看CPU load
查看CPU load的方法很多，我经常用个最简单的命令：uptime
[linux@b28-34-98 ~]$ uptime
16:09:32 up 530 days, 1 min, 1 user, load average: 2.71, 2.44, 1.99
命令结果的后三位就是load的值了，分别代表1分钟、5分钟、15分钟的平均值。因为是平均值，15分钟更能代表系统的整体负载情况，如果1分钟的值很高，其他两个值很低，只能说明系统有瞬间的高负载。如果15分钟内，系统的平均负载都很大，表明问题持续存在，不是暂时现象。那么CPU load这个值多少算大呢，和CPU核数又有什么关系呢？
2.CPU load含义
CPU load是一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息。
2.1单核CPU
当CPU完全空闲的时候，平均负荷为0（即load average的值为0）；当CPU工作量饱和的时候，平均负荷为1；当有线程等待时，平均负荷为等待线程数+1，如果这个时候等待线程过多，等待时间就会长，需要考虑增加CPU 了。
来个经典比喻：
不妨把这个CPU想象成一座大桥，桥上只有一根车道，所有车辆都必须从这根车道上通过（很显然，这座桥只能单向通行），大桥的通行能力（一次10辆车），就是CPU的最大工作量；桥梁上的车辆，就是一个个等待CPU处理的进程（process）。
1）系统负荷为0，意味着大桥上一辆车也没有。
2）系统负荷为0.5，意味着大桥一半的路段有车。
3）系统负荷为1.0，意味着大桥的所有路段都有车，也就是说大桥已经"满"了。但是必须注意的是，直到此时大桥还是能顺畅通行的。
4）系统负荷为1.7，意味着车辆太多了，大桥已经被占满了（100%），后面等着上桥的车辆为桥面车辆的70%。
以此类推，系统负荷2.0，意味着等待上桥的车辆与桥面的车辆一样多； 系统负荷3.0，意味着等待上桥的车辆是桥面车辆的2倍。 总之，当系统负荷大于1，后面的车辆就必须等待了；系统负荷越大，过桥就必须等得越久。 CPU的系统负荷，基本上等同于上面的类比。为了服务器顺畅运行，系统负荷最好不要超过1.0，这样就没有进程需要等待了，所有进程都能第一时间得到处理。 很显然，1.0是一个关键值，超过这个值，系统就不在最佳状态了，就需要动手干预了。
2.2多核CPU
当CPU核数是4时，系统的处理能力是单核CPU的4倍，这时候CPU工作量饱和时，平均负荷为4，即每个CPU正在处理一个负荷。
类比到这个小车过桥的比喻中，4核CPU相当于4车道大桥。
1）系统负荷为0，意味着大桥上一辆车也没有。
2）系统负荷为1.0，意味着大桥只有一条车道占满，其他车道空闲着，其实也不一定所有车辆挤一条车道上，可以平均分配到不同车道，每条车道负载0.25。
3）系统负荷为4，意味着大桥的4条路段都有车，也就是说大桥已经"满"了。但是必须注意的是，直到此时大桥还是能顺畅通行的。
4）系统负荷大于4，意味着车辆太多了，大桥已经被占满了（100%），后面已经有等着上桥的车辆了。
3.CPU load多大合适
这个仁者见仁，有人觉得CPU负载小于等于"内核数乘以0.5-0.7"算是一种理想状态。 比如4核CPU的服务器，理想负载是小于等于2，最好不要超过2.8，否则性能多少会受影响。个人感觉这个要具体情况具体分析，在监控中设置成CPU核数即可，当然如果长时间观察到CPU load饱满运行，就需要多加注意了。
