(转)load的小结

38 篇文章 0 订阅
14 篇文章 0 订阅
本文深入解析了Linux系统负载的概念、计算原理及误识,通过uptime命令输出实例,阐述了1、5、15分钟平均负载的意义,并提供判断系统负载是否过高的方法,以及负载与CPU、容量规划、系统预警的关系,旨在帮助工程师准确解读系统状态。
摘要由CSDN通过智能技术生成
  linux下UPTIME或者TOP后,经常看到CPU的LOAD,1分,5分,15分钟内的平均负载,
经常会有误区,因此转篇好文介绍下
http://www.sanotes.net/html/y2008/133.html
几乎每个接触类 Unix 操作系统的工程师都知道如何查看系统负载。但这东西的工作机理到底是怎样的,可能没有多少能说清楚。对比了一些相关信息,加上自己的理解,做一下笔记。

什么是 Load ? 什么是 Load Average ?
Load 就是对计算机干活多少的度量(WikiPedia: the system load is a measure of the amount of work that a computer system is doing)。也有简单的说是进程队列的长度. Load Average 就是一段时间 (1 分钟、5分钟、15分钟) 内平均 Load 。【最好的参考文章:UNIX® Load Average Part 1: How It Works】

下面是一个 uptime 命令输出:

$ uptime

18:57:48 up 423 days,  3:55,  2 users,  load average: 1.16, 1.12, 1.20尽管各种信息来源的定义都不太确定。能确定的一件事情是,你不能精确获取当前时间的 Load . 最小的计算粒度是 5 秒钟(CALC_LOAD 每 5HZ 计算一次, 5HZ 为 5秒钟). 参见 Linux Kernel 这段代码:

869        count -= ticks;
870        if (unlikely(count < 0)) {
871                active_tasks = count_active_tasks();
872                do {
873                        CALC_LOAD(avenrun[0], EXP_1, active_tasks);

874                        CALC_LOAD(avenrun[1], EXP_5, active_tasks);

875                        CALC_LOAD(avenrun[2], EXP_15, active_tasks);

876                        count += LOAD_FREQ;
877                } while (count < 0);
878        }
879}如何判断系统是否已经 Over Load ?
对一般的系统来说,根据 CPU 数量去判断,如上面的例子, 如果平均负载始终在 1.2 以下,而你是 2 颗 CPU 的机器。那么基本不会出现 CPU 不够用的情况。也就是 Load 平均要小于 CPU 的数量。

这是 Solaris 性能与工具(Solaris Performance Tools ) 一书推荐的评估方法。【在这里要推荐一下这本书,尽管在 Load 这个地方没有达到我期望的那么细致。但全书揭示了非常多的性能信息。每个 DBA、架构师 的必须书。】

这么说实际上带来另外两个疑问:

1 如果是多核 CPU / 超线程的机器怎么判断? 对这样的机器,我的建议是看操作系统怎么识别的 CPU,根据系统识别出来的逻辑 CPU 数量来判断。如果要考虑性能系数,建议参考一下 Oracle 针对不同架构下多核 CPU 的收费标准。

2 如果应用是面向线程的怎么判断? 这实际上和 M:N 线程模型有关。你的系统是怎样的? 把这个问题考虑进去即可了。

多数情况下,Load 过高都未必和 CPU 有关。或许倒是有一个例外的,就是应用场景的问题。比如用单 CPU 的机器去做高并发 Web 服务器,麻烦就来了

Load 与容量规划(Capacity Planning)
任何一个相对成熟的站点都会利用 Cacti(基于RRDTool) 等工具进行容量规划工作。抓取的 Load 会传 1、5、15 分钟列值过去,这三个度量采用哪个呢? 15 分钟为首选【参见Gunther 的 PPT】。

Load 与系统预警
很多对可用性要求比较高的环境都建立了 邮件或SMS 报警机制。关于 Load 报警阈值的制定也有看到不太合理的时候。这里建议 Critical 值(如果用 Nagios 之类的工具你明白这是什么)上限为 物理 CPU 的个数(当然你可以设置比这个低)。但比这个值高的话,意义就不大了。比如,数据库服务器有 4 颗 CPU,那么 Load 高于 4 就应该报警出来,设置比 4 高可能意义不大,因为接到报警还有个人为响应时间...

误解 一:系统 Load 高一定是性能有问题。
真相:系统 Load 高也或许是因为在进行 CPU 密集型的计算(比如编译)

误解 二:系统 Load 高一定是 CPU 能力问题或数量不够。
真相:Load 高只是代表需要运行的队列累积过多了。但队列中的任务实际可能是耗 CPU的,也可能是耗 I/O 乃至其它因素的。

误解 三:系统长期 Load 高,首选增加 CPU。
真相:Load 只是表象,不是实质。增加 CPU 个别时候会临时看到系统 Load 下降,但治标不治本。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值