读懂系统负载(Load Avg)的含义 | Devops

有过运维Linux服务器的选手,想必对于系统平均负载(load averages)参数不会陌生吧,我们可以通过top, htop, uptime这些命令找到它们(如下图),那么我们又改如何理解它们呢,今天这篇就来一起看看应该如何读懂这个load averages参数。

系统平均负载的取值分别来自1分,5分,15分这三个时间区间,对于单核CPU而言,当平均负载为0时,表示CPU完全空闲,当平均负载为1时,表示CPU为满负荷状态,但两个极端都不应出现在我们的服务器上,前者说明系统没有被充分利用到,后者说明系统濒临奔溃,都不是什么好事情。

关于负载的含义,网上最广泛的示例,是通过桥梁的通过率来解释的。讲的真心好,所以直接「借鉴」过来,需要看原文的直接从参考引用处自行穿越。注意这里的比喻是基于单核CPU的。

系统负荷为0,意味着大桥上一辆车也没有

系统负荷为0.5,意味着大桥一半的路段有车。

系统负荷为1.0,意味着大桥的所有路段都有车,但任然可以顺次通行

系统负荷为1.7,除了桥满之外,在桥的入口处还有70%的车辆在等待

就目前情况来说,单核的个人PC是不应该的,当然服务器就是另一回事儿了,比如可能你买了某云主机商的单核廉价套餐来搭梯子,但实际的真实环境中单核真的是很少,所以光知道单核的表现还不行,还得会换算到多核处理器上,其实这也简单,直接在单核的负载上乘以核数就可以了,换到刚才的大桥示例,多核就是多车道(下图),车道多了通过率自然就嘎嘎滴。

好了,知道了数值的含义,我们再来看看恰当的经验值该是多少,到底应该以三个值中的哪个位准,以及预告系统奔溃的经验值该设置成多少?

前面说到平均负载是1,5,15这三个时间区间的均值。因为偶尔系统负载会出现峰值,短时间1,5分钟的负载都不够客观存在抖动,所以最可靠的肯定是第三个,15分钟内的均值,如果系统平均负载的第三个值长时间居高不下,那么就应该考虑提升配置或者给系统进程做做减法了。

第二个问题,知道了基准值的位置,那么基准值该是多少呢?其实这个值完全是靠个人经验的,只能是种预判,就像阴天不一定下雨一样,好了不卖关子,实际中最好能让负载保持在满负载的75%左右,长时间高于这个值就应该考虑做出调整了,当然也恭喜你业务得到拓展了(2333~),另外在生产环境中,你可以通过Monit,Nagios等这样的监控软件来监控系统性能指标,从而做到「早发现,早治疗」。

如何获取CPU的核数

Mac

sysctl -n hw.ncpu

Linux

cat /proc/cpuinfo

-完-

你还可以看:

Monit让你的服务持续在线

关于Github的两个小技巧

教你如何在Commit时有话可说

使用Gulp-Rsync部署前端项目

Linux查看当前端口状况

几种服务端推送技术方案的比较

参考引用

http://www.wtoutiao.com/p/1faPwo8.html

原文地址:https://www.cnblogs.com/softidea/p/5728956.html