为确保接下来的工作是有意义的，首先确保您的CPU频率调节功能还没有启用~

# cd /sys/devices/system/cpu/cpu0
# ls -l

如果你看到一个名为cpufreq的文件夹，则说明频率调节功能已经启用，您可以直接跳至下一步。

如果没有看到名为cpufreq的文件夹，则先看一下可以用的驱动：

# ls /lib/modules/`uname -r`/kernel/arch/*/kernel/cpu/cpufreq

在我的电脑看到的是这样的，估计你的也差不多。

acpi-cpufreq.ko longrun.ko powernow-k8.ko speedstep-smi.ko
cpufreq-nforce2.ko p4-clockmod.ko speedstep-centrino.ko
gx-suspmod.ko powernow-k6.ko speedstep-ich.ko
longhaul.ko powernow-k7.ko speedstep-lib.ko

这些都是可选的驱动，但是与不同的CPU相匹配。 常用的是：

上表列出的只是常用的，如果不行，试一下其它的。

试的方法是：

1. 加载该内核模块，如

#modprobe p4-clockmod

又如

#modprobe powernow-k8

注意是模块名是把上面的文件名去掉.ko。

2. 如果没有错误信息，就对了。如果要确认，看一下

# cd /sys/devices/system/cpu/cpu0
# ls -l

是否有cpufreq。

提示：可以用cat看一下cpufreq文件夹下的文件，可以得到一些有用的信息

选择适当的调节器

调节器即Governor，用它来控制CPU频率。可选的有

查看当前的调节器：

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

更改使用的调节器，需要加载相应的内核模块，再更改scaling_governor文件，例如：

# modprobe cpufreq_conservative
# echo conservative > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

注意：如果使用的CPU比较老，使用speedstep-smi做为动态频率的模块，则不能使用ondemand等实时调频软件，原因是其调频延时较长。

当然也可以用GNOME的工具来调节，请参见后面的介绍。

使用软件管理CPU频率

内核模块的CPU频率管理功能已经很强大了，当然你也可以应用软件来管理，可选的软件有：

1. cpudynd
2. cpufreqd
3. cpufrequtils
4. powernowd
5. powersaved
6. speedfreqd

这些源里是有的，不过我认为都不怎么好用，感觉Fedora的cpuspeed比较好，不过源里没有。

使用gnome的CPU频率范围监视器

在gnome的面板上按右键，选择“添加到面板”，加入“CPU频率范围监视器”。 在那个图标上按右键，“首选项”，可以选择显示和调速的方式。 普通用户默认不能调节CPU频率，要解决这个问题，请参阅为普通用户提供CPU调频权限。

设置开机自动加载以上设置

Debian 4.0

1. 编辑 /etc/modules ，加入刚才modprobe挂载的内核模块

cpufreq-userspace
cpufreq-ondemand
cpufreq-powersave
cpufreq-conservative
speedstep-centrino  #请修改为相应的频率调节模块

2. 安装sysfsutils，

#apt-get install sysfsutils

以超级用户权限编辑/etc/sysfs.conf，文件内容：

devices/system/cpu/cpu0/cpufreq/scaling_governor = ondemand
devices/system/cpu/cpu0/cpufreq/scaling_max_freq = 1800000 #请修改为您的CPU的最高频率

如果是双核CPU，还应加入cpu1的内容，与cpu0完全类似。多线程CPU无需进行此项操作。

Archlinux

• 在/etc/rc.conf的MODULES变量中加入刚才modeprobe挂载的内核模块

cpufreq-userspace
cpufreq-ondemand
cpufreq-powersave
cpufreq-conservative
speedstep-centrino #请修改为相应的频率调节模块

• 可以安装cpudyn和acpid，并

# /etc/rc.d/cpudyn start
# /etc/rc.d/acpid start

启动自动调节，也可以把它们加到rc.conf中，让其自动启动。

Linux中的“load average“到底是什么意思
执行top,w,uptime，在最上一行，均能得到类似下面的一行：

21:25:38 up 59 min,  2 users,  load average: 0.33, 0.40, 0.38

前面的值还是比较好理解，但是这个load average就不太好理解了，虽然知道是平均负载，但是它到底意味着什么？
什么样的负载是正常的，什么样的负载表示系统负荷高？
man uptime显然是最快捷的办法，得到的解释如下：

uptime  gives  a  one  line display of the following information.  The current time, how long the system has been running, how many users are currently  logged  on, and the system load averages for the past 1, 5, and 15 minutes.

解释很明确，但是还是不知道什么是平均负载。显然需要祭出google大刀了。
google一把，分别得到了下面的解释
中文的很多解释如下

系统平均负载被定义为在特定时间间隔内运行队列中的平均进程树。如果一个进程满足以下条件则其就会位于运行队列中：
– 它没有在等待I/O操作的结果
– 它没有主动进入等待状态(也就是没有调用’wait’)
– 没有被停止(例如：等待终止)

例如：

[root@www2 init.d]# uptime
7:51pm up 2 days, 5:43, 2 users, load average: 8.13, 5.90, 4.94

命令输出的最后内容表示在过去的1、5、15分钟内运行队列中的平均进程数量。
一般来说只要每个CPU的当前活动进程数不大于3那么系统的性能就是良好的，如果每个CPU的任务数大于5，那么就表示这台机器的性能有严重问题。对于上面的例子来说，假设系统有两个CPU，那么其每个CPU的当前任务数为：8.13/2=4.065。这表示该系统的性能是可以接受的。
而且还说这个值会接近１，这显然不对，我今天就看到了负载超过５０的。
AIX系统中给出解释是

The uptime command prints the current time, the length of time the system has been up, the number of users online, and the load average. The load average is the number of runnable processes over the preceding 5-, 10-, 15-minute intervals.

比Linux还一点的是给出了一个可运行的进程，不过还是不很明确，继续
《UNIX Power Tools》一书中给出的解释是

The load average tries to measure the number of active processes at any time. As a measure of CPU utilization, the load average is simplistic, poorly defined, but far from useless.

不知道这里的“active processes"和AIX中的"runnable processes"是什么关系，我想不应该等同吧。还得继续
这本书继续写道

What’s high? … Ideally, you’d like a load average under,say, 3, … Ultimately, ‘high’ means high enough so that you don’t need uptime to tell you that the system is overloaded. …
different systems will behave differently under the same load average.
… running a single cpu-bound background job can bring response to a crawl even though the load avg
remains quite low.

这里说的3是什么意思？又是从哪里来的，他的3指的平均负载中的哪个呢，1分钟的？5分钟的？还是15分钟的？
不得而知，继续找找，看看有没有更详细的解答
在《Sun Performance and Tuning》一书的“Understanding and Using the Load Average”一节中，作者这样写道

The load average is the sum of the run queue length and the number of jobs currently running on the CPUs. In Solaris 2.0 and 2.2 the load average did not include the running jobs but this bug was fixed in Solaris 2.3.

这里提到了运行队列(run queue)，那么如何理解run queue,runnable processes和active processes三者的关系，是他们的平均值还是其和呢？
现在要做的就是去“Read The Fucking Source Code"了。
uptime这类程序属于procps包，拿到源代码，现看uptime.c,很简单就是下面几行

#include <stdio.h>
#include <string.h>
#include "proc/whattime.h"
#include "proc/version.h"
int main(int argc, char *argv[]) {
    if(argc == 1) {
        print_uptime();
        return 0;
    }
    if((argc == 2) && (!strcmp(argv[1], "-V"))) {
        display_version();
        return 0;
    }
    fprintf(stderr, "usage: uptime [-V]\n    -V    display version\n");
    return 1;
}

而whattime.h的中代码是

#ifndef PROC_WHATTIME_H
#define PROC_WHATTIME_H
 
#include "procps.h"
 
EXTERN_C_BEGIN
 
extern void print_uptime(void);
extern char *sprint_uptime(void);
 
EXTERN_C_END
 
#endif

如此顺藤摸瓜，找到了实际函数所在地include/linux/sched.h，他定义了一个宏

#define FSHIFT      11      /* nr of bits of precision */
 #define FIXED_1     (1<<FSHIFT) /* 1.0 as fixed-point */
 #define LOAD_FREQ   (5*HZ)      /* 5 sec intervals */
 #define EXP_1       1884        /* 1/exp(5sec/1min) as fixed-point */
 #define EXP_5       2014        /* 1/exp(5sec/5min) */
 #define EXP_15      2037        /* 1/exp(5sec/15min) */
 
 #define CALC_LOAD(load,exp,n) \
  load *= exp; \
  load += n*(FIXED_1-exp); \
  load >>= FSHIFT;

有两个疑惑

1）常量的那些值如何来的？

2）CALC_LOAD到底想做什么？

这个宏可以用下面的数学表达式描述

load(t) = load(t ? 1) e^(? 5/60m )+ n(t) (1 ? e^(? 5/60m ))

其中：

m = 1, 5, 15 表示经过的时间

load(t) 表示现在的负载

load(t ? 1) 表示上一次时间的负载

n(t) 表示当前活动进程(active processes)的数目。

暂时我只能分析到这里了，再分析我头大了，有时间再分析吧。

到此，只是知道负载的计算与进程有关，但是到底值的大小如何具体衡量系统负载还是未知数

通过下面的几个部分的了解，可以一步一步的找出Load Average在压力测试中真正的作用。

CPU时间片

为了提高程序执行效率，大家在很多应用中都采用了多线程模式，这样可以将原来的序列化执行变为并行执行，任务的分解以及并行执行能够极大地提高程序的运行效率。但这都是代码级别的表现，而硬件是如何支持的呢？那就要靠CPU的时间片模式来说明这一切。程序的任何指令的执行往往都会要竞争CPU这个最宝贵的资源，不论你的程序分成了多少个线程去执行不同的任务，他们都必须排队等待获取这个资源来计算和处理命令。先看看单CPU的情况。下面两图描述了时间片模式和非时间片模式下的线程执行的情况：

图 1 非时间片线程执行情况

图 2 非时间片线程执行情况

在图一中可以看到，任何线程如果都排队等待CPU资源的获取，那么所谓的多线程就没有任何实际意义。图二中的CPU Manager只是我虚拟的一个角色，由它来分配和管理CPU的使用状况，此时多线程将会在运行过程中都有机会得到CPU资源，也真正实现了在单CPU的情况下实现多线程并行处理。

多CPU的情况只是单CPU的扩展，当所有的CPU都满负荷运作的时候，就会对每一个CPU采用时间片的方式来提高效率。

在Linux的内核处理过程中，每一个进程默认会有一个固定的时间片来执行命令（默认为1/100秒），这段时间内进程被分配到CPU，然后独占使用。如果使用完，同时未到时间片的规定时间，那么就主动放弃CPU的占用，如果到时间片尚未完成工作，那么CPU的使用权也会被收回，进程将会被中断挂起等待下一个时间片。

CPU利用率和Load Average的区别

压力测试不仅需要对业务场景的并发用户等压力参数作模拟，同时也需要在压力测试过程中随时关注机器的性能情况，来确保压力测试的有效性。当服务器长期处于一种超负荷的情况下运行，所能接收的压力并不是我们所认为的可接受的压力。就好比项目经理在给一个人估工作量的时候，每天都让这个人工作12个小时，那么所制定的项目计划就不是一个合理的计划，那个人迟早会垮掉，而影响整体的项目进度。

CPU利用率在过去常常被我们这些外行认为是判断机器是否已经到了满负荷的一个标准，看到50%-60%的使用率就认为机器就已经压到了临界了。CPU利用率，顾名思义就是对于CPU的使用状况，这是对一个时间段内CPU使用状况的统计，通过这个指标可以看出在某一个时间段内CPU被占用的情况，如果被占用时间很高，那么就需要考虑CPU是否已经处于超负荷运作，长期超负荷运作对于机器本身来说是一种损害，因此必须将CPU的利用率控制在一定的比例下，以保证机器的正常运作。

Load Average是CPU的Load，它所包含的信息不是CPU的使用率状况，而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息，也就是CPU使用队列的长度的统计信息。为什么要统计这个信息，这个信息的对于压力测试的影响究竟是怎么样的，那就通过一个类比来解释CPU利用率和Load Average的区别以及对于压力测试的指导意义。

我们将CPU就类比为电话亭，每一个进程都是一个需要打电话的人。现在一共有4个电话亭（就好比我们的机器有4核），有10个人需要打电话。现在使用电话的规则是管理员会按照顺序给每一个人轮流分配1分钟的使用电话时间，如果使用者在1分钟内使用完毕，那么可以立刻将电话使用权返还给管理员，如果到了1分钟电话使用者还没有使用完毕，那么需要重新排队，等待再次分配使用。

图 3 电话使用场景

上图中对于使用电话的用户又作了一次分类，1min的代表这些使用者占用电话时间小于等于1min，2min表示使用者占用电话时间小于等于2min，以此类推。根据电话使用规则，1min的用户只需要得到一次分配即可完成通话，而其他两类用户需要排队两次到三次。

电话的利用率 = sum (active use cpu time)/period

每一个分配到电话的使用者使用电话时间的总和去除以统计的时间段。这里需要注意的是是使用电话的时间总和(sum(active use cpu time))，这与占用时间的总和(sum(occupy cpu time))是有区别的。（例如一个用户得到了一分钟的使用权，在10秒钟内打了电话，然后去查询号码本花了20秒钟，再用剩下的30秒打了另一个电话，那么占用了电话1分钟，实际只是使用了40秒）

电话的Average Load体现的是在某一统计时间段内，所有使用电话的人加上等待电话分配的人一个平均统计。

电话利用率的统计能够反映的是电话被使用的情况，当电话长期处于被使用而没有的到足够的时间休息间歇，那么对于电话硬件来说是一种超负荷的运作，需要调整使用频度。而电话Average Load却从另一个角度来展现对于电话使用状态的描述，Average Load越高说明对于电话资源的竞争越激烈，电话资源比较短缺。对于资源的申请和维护其实也是需要很大的成本，所以在这种高Average Load的情况下电话资源的长期“热竞争”也是对于硬件的一种损害。

低利用率的情况下是否会有高Load Average的情况产生呢？理解占有时间和使用时间就可以知道，当分配时间片以后，是否使用完全取决于使用者，因此完全可能出现低利用率高Load Average的情况。由此来看，仅仅从CPU的使用率来判断CPU是否处于一种超负荷的工作状态还是不够的，必须结合Load Average来全局的看CPU的使用情况和申请情况。

所以回过头来再看测试部对于Load Average的要求，在我们机器为8个CPU的情况下，控制在10 Load左右，也就是每一个CPU正在处理一个请求，同时还有2个在等待处理。看了看网上很多人的介绍一般来说Load简单的计算就是2* CPU个数减去1-2左右（这个只是网上看来的，未必是一个标准）。

补充几点：

1．对于CPU利用率和CPU Load Average的结果来判断性能问题。首先低CPU利用率不表明CPU不是瓶颈，竞争CPU的队列长期保持较长也是CPU超负荷的一种表现。对于应用来说可能会去花时间在I/O,Socket等方面，那么可以考虑是否后这些硬件的速度影响了整体的效率。

这里最好的样板范例就是我在测试中发现的一个现象：SIP当前在处理过程中，为了提高处理效率，将控制策略以及计数信息都放置在Memcached Cache里面，当我将Memcached Cache配置扩容一倍以后，CPU的利用率以及Load都有所下降，其实也就是在处理任务的过程中，等待Socket的返回对于CPU的竞争也产生了影响。

2．未来多CPU编程的重要性。现在服务器的CPU都是多CPU了，我们的服务器处理能力已经不再按照摩尔定律来发展。就我上面提到的电话亭场景来看，对于三种不同时间需求的用户来说，采用不同的分配顺序，我们可看到的Load Average就会有不同。假设我们统计Load的时间段为2分钟，如果将电话分配的顺序按照：1min的用户，2min的用户，3min的用户来分配，那么我们的Load Average将会最低，采用其他顺序将会有不同的结果。所以未来的多CPU编程可以更好的提高CPU的利用率，让程序跑的更快。

以上所提到的内容未必都是很准确或者正确，如果有任何的偏差也请大家指出，可以纠正一些不清楚的概念。

用户可以使用多少CPU资源

做为一个量化的指标，DreamHost使用CPU minutes来衡量用户使用CPU资源的情况，通常情况下，每个用户允许使用60 CPU minutes（60分钟CPU），如果超过了这个数字不过，那也没什么关系，如果达到这个数字的三、四倍以上，那么就很有可能会被禁用，通常情况下，当你的页面总是出现500错误的时候，你就需要关注一下自己到底使用了多少CPU minutes。

如何减少使用的CPU资源

通常降低CPU minutes的方式是，禁用主机上的gzip压缩传输（有时可以降低高达75%，WordPress可以在管理界面禁用gzip），减少数据库查询，优化脚本。

如何查看自己的CPU资源报告

首先登陆DreamHost管理台，在Manage Users中编辑你的用户，选中CPU Reporting，通常一天以后就可以看到报告了。

查看报告有两种方法，一种是通过FTP或者SSH登陆后，在logs/resources/目录下可以看到最近七天的报告文件。

另一种方法是通过WEB页面访问，每个域名都会有一个统计页面，使用 http://yourdomain.com/stats/resources 这个地址可以直接查看报告文件。

在CPU资源报告文件中，通常我们只要注意CPU seconds这一列就可以了，将里面的数字除以60，就可以得到用户当天的CPU minutes，看看这个数值是不是大于60，如果是的话，就要注意减少使用CPU资源了，如果超过150 CPU minutes还不解决的话，那就离被封不远了。

根据我的一些经验，达到60 CPU minutes其实并不难，一个每天有3000IP的WordPress或者一个每天500IP的Discuz论坛都有可能达到这个标准，这里面的原因也有DreamHost自己过度销售的错误。

转自：月光博客