理解Linux系统负荷

作者: 阮一峰

日期: 2011年7月31日

一、查看系统负荷

如果你的电脑很慢,你或许想查看一下,它的工作量是否太大了。

在Linux系统中,我们一般使用uptime命令查看(w命令和top命令也行)。(另外,它们在苹果公司的Mac电脑上也适用。)

你在终端窗口键入uptime,系统会返回一行信息。

这行信息的后半部分,显示"load average",它的意思是"系统的平均负荷",里面有三个数字,我们可以从中判断系统负荷是大还是小。

为什么会有三个数字呢?你从手册中查到,它们的意思分别是1分钟、5分钟、15分钟内系统的平均负荷。

如果你继续看手册,它还会告诉你,当CPU完全空闲的时候,平均负荷为0;当CPU工作量饱和的时候,平均负荷为1。

那么很显然,"load average"的值越低,比如等于0.2或0.3,就说明电脑的工作量越小,系统负荷比较轻。

但是,什么时候能看出系统负荷比较重呢?等于1的时候,还是等于0.5或等于1.5的时候?如果1分钟、5分钟、15分钟三个值不一样,怎么办?

二、一个类比

判断系统负荷是否过重,必须理解load average的真正含义。下面,我根据"Understanding Linux CPU Load"这篇文章,尝试用最通俗的语言,解释这个问题。

首先,假设最简单的情况,你的电脑只有一个CPU,所有的运算都必须由这个CPU来完成。

那么,我们不妨把这个CPU想象成一座大桥,桥上只有一根车道,所有车辆都必须从这根车道上通过。(很显然,这座桥只能单向通行。)

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

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

系统负荷为1.0,意味着大桥的所有路段都有车,也就是说大桥已经"满"了。但是必须注意的是,直到此时大桥还是能顺畅通行的。

系统负荷为1.7,意味着车辆太多了,大桥已经被占满了(100%),后面等着上桥的车辆为桥面车辆的70%。以此类推,系统负荷2.0,意味着等待上桥的车辆与桥面的车辆一样多;系统负荷3.0,意味着等待上桥的车辆是桥面车辆的2倍。总之,当系统负荷大于1,后面的车辆就必须等待了;系统负荷越大,过桥就必须等得越久。

CPU的系统负荷,基本上等同于上面的类比。大桥的通行能力,就是CPU的最大工作量;桥梁上的车辆,就是一个个等待CPU处理的进程(process)。

如果CPU每分钟最多处理100个进程,那么系统负荷0.2,意味着CPU在这1分钟里只处理20个进程;系统负荷1.0,意味着CPU在这1分钟里正好处理100个进程;系统负荷1.7,意味着除了CPU正在处理的100个进程以外,还有70个进程正排队等着CPU处理。

为了电脑顺畅运行,系统负荷最好不要超过1.0,这样就没有进程需要等待了,所有进程都能第一时间得到处理。很显然,1.0是一个关键值,超过这个值,系统就不在最佳状态了,你要动手干预了。

三、系统负荷的经验法则

1.0是系统负荷的理想值吗?

不一定,系统管理员往往会留一点余地,当这个值达到0.7,就应当引起注意了。经验法则是这样的:

当系统负荷持续大于0.7,你必须开始调查了,问题出在哪里,防止情况恶化。

当系统负荷持续大于1.0,你必须动手寻找解决办法,把这个值降下来。

当系统负荷达到5.0,就表明你的系统有很严重的问题,长时间没有响应,或者接近死机了。你不应该让系统达到这个值。

四、多处理器

上面,我们假设你的电脑只有1个CPU。如果你的电脑装了2个CPU,会发生什么情况呢?

2个CPU,意味着电脑的处理能力翻了一倍,能够同时处理的进程数量也翻了一倍。

还是用大桥来类比,两个CPU就意味着大桥有两根车道了,通车能力翻倍了。

所以,2个CPU表明系统负荷可以达到2.0,此时每个CPU都达到100%的工作量。推广开来,n个CPU的电脑,可接受的系统负荷最大为n.0。

五、多核处理器

芯片厂商往往在一个CPU内部,包含多个CPU核心,这被称为多核CPU。

在系统负荷方面,多核CPU与多CPU效果类似,所以考虑系统负荷的时候,必须考虑这台电脑有几个CPU、每个CPU有几个核心。然后,把系统负荷除以总的核心数,只要每个核心的负荷不超过1.0,就表明电脑正常运行。

怎么知道电脑有多少个CPU核心呢?

"cat /proc/cpuinfo"命令,可以查看CPU信息。"grep -c 'model name' /proc/cpuinfo"命令,直接返回CPU的总核心数。

六、最佳观察时长

最后一个问题,"load average"一共返回三个平均值----1分钟系统负荷、5分钟系统负荷,15分钟系统负荷,----应该参考哪个值?

如果只有1分钟的系统负荷大于1.0,其他两个时间段都小于1.0,这表明只是暂时现象,问题不大。

如果15分钟内,平均系统负荷大于1.0(调整CPU核心数之后),表明问题持续存在,不是暂时现象。所以,你应该主要观察"15分钟系统负荷",将它作为电脑正常运行的指标。

==========================================

[参考文献]

1. Understanding Linux CPU Load

2. Wikipedia - Load (computing)

(完)

留言(37条)

非常好,每次都有新收获。

想学PHP。以后就用LAMP了,坦然一些。

有用,谢谢!!

这个1 5 15分钟的负载测试是怎么获得的呢?
呵呵 比较好奇

引用sjtlqy的发言:
这个1 5 15分钟的负载测试是怎么获得的呢?呵呵 比较好奇

我也有同样的疑问。

和这篇文章 http://www.gracecode.com/archives/2973/ 是同一来源?

想知道windows的架構

uptime衡量的cpu负载并不能完全算作是「系统」负载。
在实际使用中,还要考虑网络负载(生产环境),以及磁盘负载(桌面环境);前者可以用netstat查看,后者目前未发现好用的统计工具(iotop有些弱)

用实例解释抽象的概念,是最好不过了,谢谢阮先生!

曾经见到过load为几千,因为硬盘的IO卡住了。

您好,我想了解下如果system load过高,我怎么去分析load过高的原因,都有那些命令或者手段来查看细节(比如io什么的)。如果有时间的话不妨写篇博客跟大家分析一下,相信很多人很感兴趣的。

引用依云的发言:

和这篇文章 http://www.gracecode.com/archives/2973/ 是同一来源?

都是翻译吧,没注明

终于懂这个 load 是什么意思了!

真是及时雨,昨天我还在想这三个值怎么解读。今天就看见这文章,赞

非常明了....学习了,yeah!!!

网上搜了半天mac电脑速度变慢应该如何解决,今天看到这篇文章后觉得出现了一丝曙光,但只知道如何查看电脑的负载是否超支,但不知应如何是15分钟负载从1.0降低到合理值。
我的电脑是双核处理器,目前的15分钟值是1.25左右

请教了

文章写得非常好!

看了好多文章,就这一篇文章写得load average我看懂了。
关键是后面的多核很管用。。。谢谢了。

"2个CPU,意味着电脑的处理能力翻了一倍,能够同时处理的进程数量也翻了一倍。" 对于实际应用时这个概念只是理论值,经过本人多年测试,基本上给应用提供的性能只能达到80%,所以在CPU的个数和提供的处理能力必须打8折。不知道您怎么看?

真的是通俗易懂。

写得很详细
非常感谢

thanks man, very nice!

难怪每次Google都会弹出你的博客

引用zkt211的发言:

"2个CPU,意味着电脑的处理能力翻了一倍,能够同时处理的进程数量也翻了一倍。" 对于实际应用时这个概念只是理论值,经过本人多年测试,基本上给应用提供的性能只能达到80%,所以在CPU的个数和提供的处理能力必须打8折。不知道您怎么看?

有没有测试过程文档共享参考下?

我的机器上2核CPU,执行uptime,结果如下:
09:35:19 up 547 days, 20:31, 2 users, load average: 2.21, 2.24, 2.19
这个怎么解释呢?系统负载一点也不大。

引用刘的发言:

我的机器上2核CPU,执行uptime,结果如下:
09:35:19 up 547 days, 20:31,2 users,load average: 2.21, 2.24, 2.19
这个怎么解释呢?系统负载一点也不大。

按照文章所说,你的系统超负荷了。。。

那对于具备多线程技术的 Intel 处理器,uptime 命令所显示值的参考性会有所变化么?比如值为 2 时的双核双线程处理器的状态相当于值为 4 时的双核四线程处理器的状态?有这个问题是因为我在我双核四线程的 Macbook 上尝试了使用 uptime,四个值均是 1.4 作用,但其实在 Activity Monitor 中,CPU 负荷只有 10% 左右。

引用Joilence的发言:

那对于具备多线程技术的 Intel 处理器,uptime 命令所显示值的参考性会有所变化么?比如值为 2 时的双核双线程处理器的状态相当于值为 4 时的双核四线程处理器的状态?有这个问题是因为我在我双核四线程的 Macbook 上尝试了使用 uptime,四个值均是 1.4 作用,但其实在 Activity Monitor 中,CPU 负荷只有 10% 左右。

同意

man uptime上面写的很清楚,那三个负载表示可运行状态进程和不可中断状态进程数量之和。
所有并不是只跟CPU负载有关

把load average的公式写出来就好了,你说的不对

挺厉害,人才,跟你学到不少东西。

当系统负荷持续大于0.7,你必须开始调查了,问题出在哪里,防止情况恶化。
当系统负荷持续大于1.0,你必须动手寻找解决办法,把这个值降下来。

这个我觉得写得不对。比如我的驱动程序就是在每个核上创建一个内核线程提供服务,没有任务的时候就在D状态等待。那什么都不做,平均load已经为1了。 这个时候怎么把这个值降下来?所以我觉得这个值到多少达到警戒值,完全是根据应用决定的。这种一刀切的说法是不负责任的。

我说看着这么眼熟呢,原来我在去年转行(首先接触的是MySQL运维)的时候出学Linux就看过这篇文章,没想到在我现在--把阮老师的博客加入收藏栏并一一阅读--又看到了,感谢阮老师

每个进程不都在抢时间片么?那么没有抢到的不就在等待么?和您文章中的等待有什么区别?

grep -c 'model name' /proc/cpuinfo是返回cpu个数吧?

单核多线程会影响吗?

文中理解的出发点是错误的。原文中load为1对应单核cpu利用率就是100%但是事实不是如此。可以去找一个load负载高的主机看看cpu利用率是多少

我要发表看法

«-必填

«-必填,不公开

«-我信任你,不会填写广告链接