Tag Archives: Linux

Unix/Linux 的 Load 初级解释

几乎每个接触类 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秒钟,这里的 HZ 是系统定义的变量). 参见 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 下降,但治标不治本。

小小一个 Load 讲究其实不少。英文信息其实比较全的,尽量保证加入一点新信息到这篇文章里。入看到有写的不合理的地方或者有异议,请指正或告知。

--EOF--

FAQ 1:数据库服务器突然 CPU 100% 繁忙,咋办?

A :一般情况下,这是由糟糕的 SQL 引起。建议抓取 Slow Query Log ,针对 I/O 开销比较大(重点看全表扫描)的 SQL 进行优化。根据经验值,每个 CPU Core 一秒钟能处理 100-400MB 数据量。如果是大量的并发 I/O 操作,尽管存储的吞吐可能还没那么大,也可能会把 CPU "塞满"。

Linux 的 Out-of-Memory (OOM) Killer

同事在 Linux 服务器上遇到点小问题,我也上去折腾半天。这还是第一次注意到 Linux 这个多年来就存在的特性:OOM Killer 。说白了 OOM Killer 就是一层保护机制,用于避免 Linux 在内存不足的时候不至于出太严重的问题,把无关紧要的进程杀掉,有些壮士断腕的意思。

先要学习点老知识,在 32 位CPU 架构下寻址是有限制的。Linux 内核定义了三个区域:

# DMA: 0x00000000 -  0x00999999 (0 - 16 MB) 
# LowMem: 0x01000000 - 0x037999999 (16 - 896 MB) - size: 880MB
# HighMem: 0x038000000 - <硬件特定>

LowMem 区 (也叫 NORMAL ZONE ) 一共 880 MB,而且不能改变(除非用 hugemem 内核)。对于高负载的系统,就可能因为 LowMem 利用不好而引发 OOM Killer 。一个可能原因是 LowFree 太少了,另外一个原因是 LowMem 里都是碎片,请求不到连续的内存区域【根据我遇到的一个案例,一个猜想是 有些应用一次性请求比较大的内存,恰恰又是 880M 之内的,空闲的(LowFree)不够大,就会触发 OOM Killer 出来干活】。检查当前 LowFree 的值:

# cat /proc/meminfo |grep LowFree 

检查LowMem内存碎片:

# cat /proc/buddyinfo

上面这条命令要在 2.6 Kernel 环境下有效。据说使用 SysRq 的方式更好,不过 Hang 的时候再用吧。参见 Metalink Note:228203.1 。

根据一些文档描述,OOM Killer 在 2.4 与 2.6 上表现是不一样的。2.4 的版本中是把新进来(新申请内存)的进程杀掉。而 2.6 上是杀掉占用内存最厉害的进程(这是很危险的,很容易导致系统应用瘫痪)。

对于 RHEL 4 ,新增了一个参数: vm.lower_zone_protection 。这个参数默认的单位为 MB,默认 0 的时候,LowMem 为 16MB。建议设置 vm.lower_zone_protection = 200 甚至更大以避免 LowMem 区域的碎片,是绝对能解决这个问题的(这参数就是解决这个问题出来的)。

而对于 RHEL 3 (Kernel 2.4) 似乎没什么好办法,一个是用 Hugemem 内核(天知道会不会引入新的毛病),一个是升级到 2.4.21-47 并且使用新的核心参数 vm.vm-defragment 控制碎片的数量。再就是使用 RHEL 4 (Kernel 2.6),这又绕回去了。说白了,如果遇到 OOM Killer ,基本上是低版本 Kernel 设计上有点缺陷。

其它,如果去查询 RedHat 的 Bug 库,会发现不少 Kernel 版本也有 Bug 的。尤其在使用 NFS 的场景。

Tip: OOM Killer 的关闭与激活方式:

# echo "0" > /proc/sys/vm/oom-kill 
# echo "1" > /proc/sys/vm/oom-kill

更多参考信息:

EOF

头疼欲裂,零散记录点东西,备查。

Linux 服务器可用性技巧关注与积累

好多 Windows 平台的 DBA 一定比较烦操作系统升级时 “重启动才能生效” 这个问题,可能就是因为这个原因,可能没多少人愿意管理 Windows 平台的数据库。其实 Linux 有的时候也有类似的毛病,对 Kernel 打 Patch 基本也要重启动操作系统,除非你不去理它。而最近 Slashdot 一则关于 Linux 的新闻值得关注, Ksplice: Rebootless Linux kernel security updates,对于非常关注系统可用性的 DBA 来说,这是个很关键的技术改进。

提高可用性技术,前期细致周密的规划是重要一环。比如大文件系统的 fsck 问题,默认情况下达到一定 mount 次数或者超过一定时间,系统会自动启动 fsck 检验操作。而一个运行一段时间的 Linux Server 如果崩溃 reboot 后,文件系统校验时间漫长的叫人绝望。如果最初对这个问题进行预处理,即可避免不必要的停机时间。

另外维护中能尽量积累那些”可用性高”的技术或技巧也是必不可少的。比如 Kernel 重新读取分区表的问题,Fdisk 命令是搞不定的,而这里提到的 partprobe 命令 刚好派上用场。

以前我也记录过类似 Linux 如何不重启而识别新增的 LUN 的话题,积少成多,也就有用了。

EOF
Updated:

不疯魔 不成活

开源软件界的大牛往往都有点魔症。这几天看到两个相关的信息:一个是 Richard Stallman 根本不用浏览器,另外一个是 Linus Torvalds 从不用手机 ,可以说相映成趣。

R.M.S 和 Linus 都属于比较有脾气的人,R.M.S 属于那种比较”犟”的人,我们常说 “Only the Paranoid Survive”,如果没有 Richard Stallman 这样的 “偏执” 怕是也没有今天的 GNU 运动; Linus 呢,我感觉属于那种比较”拧巴”的人,不过没有 Linus 的”拧巴” 也不会有 Linux 。

Richard Stallman 的另外一个趣闻是在征婚。有个朋友在论坛上的签名是”不疯魔 不成活”,用来比喻这两位大约是蛮适合的。

EOF