聊一聊CPU负载 自己原文公众号： https://mp.weixin.qq.com/s/erwBcEHeDlKQDRMo6A8GPQ

下面一段话是我转载的：

行车过桥：
一只单核的处理器可以形象得比喻成一条单车道。设想下，你现在需要收取这条道路的过桥费 — 忙于处理那些将要过桥的车辆。你首先当然需要了解些信息，例如车辆的载重、以及 还有多少车辆正在等待过桥。如果前面没有车辆在等待，那么你可以告诉后面的司机通过。如果车辆众多，那么需要告知他们可能需要稍等一会。因此，需要些特定的代号表示目前的车流情况，例如：0.00 表示目前桥面上没有任何的车流。实际上这种情况与 0.00 和 1.00 之间是相同的，总而言之很通畅，过往的车辆可以丝毫不用等待的通过。1.00 表示刚好是在这座桥的承受范围内。这种情况不算糟糕，只是车流会有些堵，不过这种情况可能会造成交通越来越慢。超过 1.00，那么说明这座桥已经超出负荷，交通严重的拥堵。那么情况有多糟糕？例如 2.00 的情况说明车流已经超出了桥所能承受的一倍，那么将有多余过桥一倍的车辆正在焦急的等待。3.00 的话情况就更不妙了，说明这座桥基本上已经快承受不了，还有超出桥负载两倍多的车辆正在等待。上面的情况和处理器的负载情况非常相似。一辆汽车的过桥时间就好比是处理器处理某线程 的实际时间。Unix 系统定义的进程运行时长为所有处理器内核的处理时间加上线程 在队列中等待的时间。

和收过桥费的管理员一样，你当然希望你的汽车（操作）不会被焦急的等待。所以，理想状态 下，都希望负载平均值小于 1.00 。当然不排除部分峰值会超过 1.00，但长此以往保持这 个状态，就说明会有问题，这时候你应该会很焦急。假设当前服务器只有一个CPU，那么上面的"load average"就告诉我们在最近一分钟内，平均有0.14个进程在等待CPU；最近五分钟内，CPU有30%的idle时间；而最近15分钟，平均有3.06个进程在等待CPU。而当服务器有4个CPU的时候，则是另外一番景象。“所以你说的理想负荷为 1.00 ？”嗯，这种情况其实并不完全正确。负荷 1.00 说明系统已经没有剩余的资源了。在实际情况中 ，有经验的系统管理员都会将这条线划在 0.70：“需要进行调查法则”：如果长期你的系统负载在 0.70 上下，那么你需要在事情变得更糟糕之前，花些时间了解其原因。“现在就要修复法则”：1.00 。如果你的服务器系统负载长期徘徊于 1.00，那么就应该马上解决这个问题。否则，你将半夜接到你上司的电话，这可不是件令人愉快的事情。“凌晨三点半锻炼身体法则”：5.00。如果你的服务器负载超过了 5.00 这个数字，那么你将失去你的睡眠，还得在会议中说明这情况发生的原因，总之千万不要让它发生。

以上我觉得说的非常对。我有一次参加一个技术大会，OracleRWP团队的成员为我们演示了一次完美的压力测试来说明数据库压力和CPU负载的关系。这个团队是Oracle主攻性能的团队。实验过程我这里就不描述了，结果就是当CPU使用率超过50%，即上面的那个值大于0.5.那么你的数据库就应该判断有问题，不是说这个时候数据库不能用，而是开始有CPU等待的现象出现了。也行人感知不到，但是数据库的响应已经不如之前的好了。我这里想表达的是，不是大多数人认为的那样，80%还可以，85%报警，90%才算是问题，100%是故障。100%毫无疑义那个时候连用户都知道你故障了，因为已经卡的不能用了。

你要是不想出问题，请把你的阈值重新设定，提高检测标准。当然我也见过不少系统几百、上千个会话也在踉踉跄跄的运行。（用户期待低或者已经放弃了，不想改善了就这样吧）有人会说这样也能用。对，毕竟还没宕机。这个我们不争论了。但是这样的维护能力对维护者来说没太大长进，你只求不死，至于一个SQL执行几分钟，用户在屏幕前吐槽也感受不到。

但是我觉得为了自己成长去查查问题，尽可能优化，我经历太多了CPU负荷100%我处理过后5%以下甚至更低，我经历的一个数据库通过AWR看负荷千分之七，其实它可以做到千分之二左右的，但是相关人员觉得不用过渡优化就这样吧。

这里不排除查到了也没人去改（不出问题不改，只有酿成故障再说）我也经常遇到，这种没有办法。但是自己对自己负责，能力提升是自己的。

来自我自己的公众号：

地址：https://mp.weixin.qq.com/s/erwBcEHeDlKQDRMo6A8GPQ