性能衡量指标与监控系统指标梳理

性能衡量指标一般有以下几个：

1. 响应时间

2. 并发用户数

3. 吞吐量

4. TPS

   上面几个指标的具体理解我就不说了，网上有很多。那么在实际的性能测试中，一般我们拿到线上的pv值，那么根据pv值我们怎么算出合适的线程数，以及系统的吞吐量呢？

首先分享一下TPS的计算方式：

2种方式：峰值法和二八法

1. 峰值法：取一段峰值访问时间的pv，除以时间长度，得到TPS

2. 二八法：TPS平均值 = ( (PV80%)/(24606020%))/服务器数量 = pv/s

TPS峰值 = (((PV80%)/(24606020%))*1.6) /服务器数量= pv/s

对于金融产品组，一般pv值指的是每天的请求数（如果是web页面访问，PV有可能值交易数，一个交易可能有多个请求，这个需要和PD确认清楚），如果是请求数，那么我们得到的TPS可以理解为系统的吞吐量。以信用卡快捷支付为例：

改产品预计的pv值为3000w/天，按照一天24小时80%的访问量集中在20%的时间来计算系统每秒钟处理的请求数为：

TPS平均值 = ( (PV80%)/(24606020%))=1388个请求/S ，线上有8台机器，但我们的压力按照4台机器来计算的，再除以4为347/s.得到这个吞吐量后，我们的并发线程数如何来设置来，可以用单线程的方式来确定，在jmeter中设置并发线程数为1，运行时间为1s，观察聚合报告，看1s的时间内一个线程可以发多少个请求，结果为25个请求左右，那么再用347/25=13.88，

最后设置的最佳并发数为15，在该并发下tps大于并超过预期的347/S20%左右。于是我们可以认为这是比较合理的并发线程数。

系统指标：

1. cpu

2. load

3. mem

4. I/O

5. jvm

cpu：

在linux系统下可以用top命令查看，(发现不能贴图，先算了)
主要关注这几个指标：Cpu(s): 0.0% us, 0.2% sy, 0.0% ni, 99.8% id, 0.0% wa, 0.0% hi, 0.0% si

用户时间【User Time】表示用户进程所花费的CPU百分比，包括Nice时间。在用户时间值很高的情况下，表明系统正在执行实际的工作。

系统时间【System Time】表示内核操作所花费的CPU百分比，包括硬中断【IRQ】和软中断[SoftIRQ]。系统时间值持续很高表明网络或驱动器堆栈可能存在瓶颈。通常系统只花费很少时间在内核时间上。

Nice时间【Nice time】表示花费在执行re-nicing（改变进程的执行顺序和优先级）进程的CPU百分比

等待【Waiting】花费在等待I/O操作所需的CPU时间总和，系统不应该花费过多的时间等待I/O操作；否则你应该检查一下I/O子系统各方面性能。

空闲时间【Idle time】表示CPU空闲的百分比。

一般cpu指标低于60%比较合理，具体指标可以根据产品情况调整。

load Average：平均负载值

这个值很多开发都弄不清楚应该怎么计算，曾经看见一个开发发的监控报告说：系统负载值已超过2，认为系统负载过高，要求加硬件扩容。这个在系统内核数没有说明的情况下是完全不合理的，下面来解释一下：

Load Average是CPU的Load，它所包含的信息不是CPU的使用率状况，而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息，也就是CPU使用队列的长度的统计信息。这个和cpu的核数有关（查看cpu核数的命令为：cat /proc/cpuinfo，会展示出处理器的个数和每个处理器的内核数，把每个处理器的内核数相加即为系统的内核数），现在一般的配置为8核。那么该系统可同时处理8个进程，所以在没有排队的情况下，cpu都在处理的话，load值为8都是很合理的。一般在性能测试中要求load <＝cpu核个数*2，那么我们认为load Average等于16，我们认为都是可以接受的，这时系统有8个进程在处理，8个进程在排队，但每个cpu平均只有1个进程在排队。同样，这个指标也可以适当调整，一般我取的值是load <＝cpu核个数+2

内存

mem：用free可以查看

total used free shared buffers cached
Mem: 2048132 2028508 19624 0 10256 593292
-/+ buffers/cache: 1424960 623172
Swap: 1052248 5160 1047088
实际的物理内存使用为1424960.

Cache：一般指频繁读写的文件被cache的内存大小

Buffer：一般值内存中读写磁盘的缓冲大小

Total=used+free

实际使用的内存为：used-buffers-cached

实际空闲的内存为：free+buffers+cached

即是第2行的数据

PS： 如果 cache 的值很大，说明cache住的文件数很多。如果频繁访问到的文件都能被cache住，那么磁盘的读IO 必会非常小

磁盘I/O：

用iostat查看

Linux 2.6.9-78.ELxenU (http://settlecore.stable.alipay.net) 2010年12月21日

avg-cpu: %user %nice %sys %iowait %idle
2.32 0.00 2.43 0.15 95.10

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
xvda 19.25 252.40 198.77 2030789004 1599294722
xvda1 0.56 2.91 6.05 23401490 48659936
xvda2 18.49 246.56 190.30 1983818598 1531117202
xvda3 0.21 2.93 2.43 23564324 19517584

参数不一一解释，重点介绍下%idel

idle小于70% IO压力就较大了,一般读取速度有较多的wait.
同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)

PS：在实际的性能测试中，用命令监控太麻烦，可以借助工具：nmon、jpofile等监控这些性能指标。

此外，在这些性能指标中，对于java进程，mem并不能具体反应出被测的java进程占用的内存，需要用专门的监控工具，例如jconsole、visualVM等来监控jvm的回收情况。

---

当一台服务器的性能出现问题时，通常会去看当前的CPU使用情况，尤其是看下CPU的负载情况(load average)。对一般的系统来说，根据cpu数量去判断。比如有2颗cup的机器。如果平均负载始终在1.2以下，那么基本不会出现cpu不够用的情况。也就是Load平均要小于Cpu的数量。

对于cpu负载的理解，首先需要搞清楚下面几个问题：

1）系统load高不一定是性能有问题。
因为Load高也许是因为在进行cpu密集型的计算

2）系统Load高不一定是CPU能力问题或数量不够。
因为Load高只是代表需要运行的队列累计过多了。但队列中的任务实际可能是耗Cpu的，也可能是耗i/0奶子其他因素的。

3）系统长期Load高，解决办法不是一味地首先增加CPU
因为Load只是表象，不是实质。增加CPU个别情况下会临时看到Load下降，但治标不治本。

4）在Load average 高的情况下需要鉴别系统瓶颈到底是CPU不足，还是io不够快造成或是内存不足造成的。

===============================================================================================================
要想获得服务器的CPU负载情况，有下面几种命令：
1）w命令
[root@localhost ~]# w
12:12:41 up 167 days, 20:46, 2 users, load average: 0.00, 0.01, 0.05
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root pts/0 192.168.1.5 10:01 1.00s 0.11s 0.00s w
root pts/2 192.168.1.5 10:19 1:47m 0.04s 0.04s -bash

2）uptime命令（一般首先会根据最后那个15分钟的load负载为准）
[root@localhost ~]# uptime
12:12:55 up 167 days, 20:46, 2 users, load average: 0.00, 0.01, 0.05

3）top命令
[root@localhost ~]# top
top - 12:13:22 up 167 days, 20:47, 2 users, load average: 0.00, 0.01, 0.05
Tasks: 272 total, 1 running, 271 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.1 sy, 0.0 ni, 99.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 65759080 total, 58842616 free, 547908 used, 6368556 buff/cache
KiB Swap: 2097148 total, 2097148 free, 0 used. 64264884 avail Mem
…

对上面第三行的解释：
us（user cpu time）：用户态使用的cpu时间比。该值较高时，说明用户进程消耗的 CPU 时间比较多，比如，如果该值长期超过 50%，则需要对程序算法或代码等进行优化。
sy（system cpu time）：系统态使用的cpu时间比。
ni（user nice cpu time）：用做nice加权的进程分配的用户态cpu时间比
id（idle cpu time）：空闲的cpu时间比。如果该值持续为0，同时sy是us的两倍，则通常说明系统则面临着 CPU 资源的短缺。
wa（io wait cpu time）：cpu等待磁盘写入完成时间。该值较高时，说明IO等待比较严重，这可能磁盘大量作随机访问造成的，也可能是磁盘性能出现了瓶颈。
hi（hardware irq）：硬中断消耗时间
si（software irq）：软中断消耗时间
st（steal time）：虚拟机偷取时间

以上解释的这些参数的值加起来是100%。

4）vmstat
[root@localhost ~]# vmstat
procs -----------memory---------------------swap-------io---------system--------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 0 0 1639792 724280 4854236 0 0 4 34 4 0 19 45 35 0 0

解释说明：

procs部分的解释
r 列表示运行和等待cpu时间片的进程数，如果长期大于1，说明cpu不足，需要增加cpu。

b 列表示在等待资源的进程数，比如正在等待I/O、或者内存交换等。

cpu部分的解释
us 列显示了用户方式下所花费 CPU 时间的百分比。us的值比较高时，说明用户进程消耗的cpu时间多，但是如果长期大于50%，需要考虑优化用户的程序。
sy 列显示了内核进程所花费的cpu时间的百分比。这里us + sy的参考值为80%，如果us+sy 大于 80%说明可能存在CPU不足。
wa 列显示了IO等待所占用的CPU时间的百分比。这里wa的参考值为30%，如果wa超过30%，说明IO等待严重，这可能是磁盘大量随机访问造成的，也可能磁盘或者
磁盘访问控制器的带宽瓶颈造成的(主要是块操作)。

id 列显示了cpu处在空闲状态的时间百分比

system部分的解释
in 列表示在某一时间间隔中观测到的每秒设备中断数。

cs列表示每秒产生的上下文切换次数，如当 cs 比磁盘 I/O 和网络信息包速率高得多，都应进行进一步调查。

memory部分的解释
swpd 切换到内存交换区的内存数量(k表示)。如果swpd的值不为0，或者比较大，比如超过了100m，只要si、so的值长期为0，系统性能还是正常
free 当前的空闲页面列表中内存数量(k表示)
buff 作为buffer cache的内存数量，一般对块设备的读写才需要缓冲。

cache: 作为page cache的内存数量，一般作为文件系统的cache，如果cache较大，说明用到cache的文件较多，如果此时IO中bi比较小，说明文件系统效率比较好。

swap部分的解释
si 由内存进入内存交换区数量。

so由内存交换区进入内存数量。

IO部分的解释
bi 从块设备读入数据的总量（读磁盘）（每秒kb）。
bo 块设备写入数据的总量（写磁盘）（每秒kb）

5）也可以使用dstat命令查看cpu信息
[root@localhost ~]# dstat
----total-cpu-usage---- -dsk/total- -net/total- —paging-- —system–
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
19 45 35 0 0 0| 30k 265k| 0 0 | 0 0 |9025 12k
9 18 73 0 0 0| 0 144k|2578k 65k| 0 0 |3956 4343

6）可以使用iostat查看IO负载
[root@localhost ~]# iostat 1 1
Linux 2.6.32-696.16.1.el6.x86_64 (nc-ftp01.kevin.cn) 2017年12月29日 x86_64 (4 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
19.32 0.00 45.44 0.06 0.26 34.93

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
xvda 14.17 29.94 265.17 63120486 558975100

解释说明：
avg-cpu: 总体cpu使用情况统计信息，对于多核cpu，这里为所有cpu的平均值
%user: 在用户级别运行所使用的CPU的百分比.
%nice: nice操作所使用的CPU的百分比.
%sys: 在系统级别(kernel)运行所使用CPU的百分比.
%iowait: CPU等待硬件I/O时,所占用CPU百分比.
%idle: CPU空闲时间的百分比.

Device段:各磁盘设备的IO统计信息
tps: 每秒钟发送到的I/O请求数.
Blk_read /s: 每秒读取的block数.
Blk_wrtn/s: 每秒写入的block数.
Blk_read: 读入的block总数.
Blk_wrtn: 写入的block总数.

[root@localhost ~]# iostat -x -k -d 1
Linux 2.6.32-696.el6.x86_64 (centos6-vm02) 01/04/2018 x86_64 (4 CPU)

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
scd0 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 0.36 0.36 0.00 0.36 0.00
vda 0.01 0.13 0.04 0.13 0.60 0.89 18.12 0.00 2.78 0.19 3.53 2.55 0.04
dm-0 0.00 0.00 0.04 0.22 0.58 0.88 11.25 0.00 3.27 0.25 3.82 1.61 0.04
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 0.13 0.13 0.00 0.04 0.00
dm-2 0.00 0.00 0.00 0.00 0.00 0.00 7.91 0.00 0.19 0.10 5.00 0.16 0.00

解释说明：

rrqm/s: 每秒对该设备的读请求被合并次数，文件系统会对读取同块(block)的请求进行合并
wrqm/s: 每秒对该设备的写请求被合并次数
r/s: 每秒完成的读次数
w/s: 每秒完成的写次数
rkB/s: 每秒读数据量(kB为单位)
wkB/s: 每秒写数据量(kB为单位)
avgrq-sz:平均每次IO操作的数据量(扇区数为单位)
avgqu-sz: 平均等待处理的IO请求队列长度
await: 平均每次IO请求等待时间(包括等待时间和处理时间，毫秒为单位)
svctm: 平均每次IO请求的处理时间(毫秒为单位)
%util: 采用周期内用于IO操作的时间比率，即IO队列非空的时间比率

如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。
idle小于70% IO压力就较大了,一般读取速度有较多的wait。
同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)
简单说下CPU负载和CPU利用率的区别

0）load average：系统平均负载是CPU的Load，它所包含的信息不是CPU的使用率状况，而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息，也就是CPU使用队列的长度的统计信息，这个数字越小越好。

1）CPU使用率：显示的是程序在运行期间实时占用的CPU百分比。

2）CPU负载：显示的是一段时间内正在使用和等待使用CPU的平均任务数。CPU使用率高，并不意味着负载就一定大。

举例来说：如果我有一个程序它需要一直使用CPU的运算功能，那么此时CPU的使用率可能达到100%，但是CPU的工作负载则是趋近于"1"，因为CPU仅负责一个工作啊。

如果同时执行这样的程序两个呢？CPU的使用率还是100%，但是工作负载则变成2了。所以也就是说，当CPU的工作负载越大，代表CPU必须要在不同的工作之间进行频繁的工作切换。

3）CPU利用率高，并不意味着负载就一定大。

举例来说：

如果有一个程序它需要一直使用CPU的运算功能，那么此时CPU的使用率可能达到100%，但是CPU的工作负载则是趋近于"1"，因为CPU仅负责一个工作！

如果同时执行这样的程序两个呢？CPU的使用率还是100%，但是工作负载则变成2了。所以也就是说，当CPU的工作负载越大，代表CPU必须要在不同的工作之间

进行频繁的工作切换。

------------------------下面通过一个电话亭打电话的比喻来说明这两者之间的区别---------

某公用电话亭，有一个人在打电话，四个人在等待，每人限定使用电话一分钟，若有人一分钟之内没有打完电话，只能挂掉电话去排队，等待下一轮。

电话在这里就相当于CPU，而正在或等待打电话的人就相当于任务数。

在电话亭使用过程中，肯定会有人打完电话走掉，有人没有打完电话而选择重新排队，更会有新增的人在这儿排队，这个人数的变化就相当于任务数的增减。

为了统计平均负载情况，我们5分钟统计一次人数，并在第1、5、15分钟的时候对统计情况取平均值，从而形成第1、5、15分钟的平均负载。

有的人拿起电话就打，一直打完1分钟，而有的人可能前三十秒在找电话号码，或者在犹豫要不要打，后三十秒才真正在打电话。如果把电话看作CPU，人数看

作任务，我们就说前一个人（任务）的CPU利用率高，后一个人（任务）的CPU利用率低。当然， CPU并不会在前三十秒工作，后三十秒歇着，只是说，有的程

序涉及到大量的计算，所以CPU利用率就高，而有的程序牵涉到计算的部分很少，CPU利用率自然就低。但无论CPU的利用率是高是低，跟后面有多少任务在排队没有必然关系。

正确理解%iowait和CPU使用率

1）%steal

一般是在虚拟机中才能看到数值，比如CPU overcommitment很严重的VPS，而%guest和%nice一般都很低,所以也可以根据/proc/stat或者top可得，user + nice + system + idle + iowait + irq + softirq + steal = 100

2）Linux进程状态

运行状态（TASK_RUNNING）：是运行态和就绪态的合并，表示进程正在运行或准备运行，Linux 中使用TASK_RUNNING 宏表示此状态可中断睡眠状态（浅度睡眠）（TASK_INTERRUPTIBLE）：

进程正在睡眠（被阻塞），等待资源到来是唤醒，也可以通过其他进程信号或时钟中断唤醒，进入运行队列。Linux 使用TASK_INTERRUPTIBLE 宏表示此状态。

不可中断睡眠状态（深度睡眠状态）（TASK_UNINTERRUPTIBLE）：

其和浅度睡眠基本类似，但有一点就是不可被其他进程信号或时钟中断唤醒。Linux 使用TASK_UNINTERRUPTIBLE 宏表示此状态。

暂停状态（TASK_STOPPED）：

进程暂停执行接受某种处理。如正在接受调试的进程处于这种状态，Linux 使用TASK_STOPPED 宏表示此状态。

僵死状态（TASK_ZOMBIE）：

进程已经结束但未释放PCB，Linux 使用TASK_ZOMBIE 宏表示此状态。

3）%iowait 的正确认知

%iowait 表示在一个采样周期内有百分之几的时间属于以下情况：CPU空闲、并且有仍未完成的I/O请求。

对 %iowait 常见的误解有两个：

一是误以为 %iowait 表示CPU不能工作的时间，

二是误以为 %iowait 表示I/O有瓶颈。

首先 %iowait 升高并不能证明等待I/O的进程数量增多了，也不能证明等待I/O的总时间增加了。例如：

在CPU繁忙期间发生的I/O，无论IO是多还是少，%iowait都不会变；

当CPU繁忙程度下降时，有一部分IO落入CPU空闲时间段内，导致%iowait升高。

再比如：IO的并发度低，%iowait就高；IO的并发度高，%iowait可能就比较低。

可见%iowait是一个非常模糊的指标，如果看到 %iowait 升高，还需检查I/O量有没有明显增加，

avserv/avwait/avque等指标有没有明显增大，应用有没有感觉变慢，如果都没有，就没什么好担心的。

4）查看CPU使用率，推荐如下Linux命令：

top

sar -u 1 5

vmstat -n 1 5

mpstat -P ALL 1 5

查看Load的值，推荐如下Linux命令：

top

uptime

sar -q 1 5

load average相关梳理

（一分钟，五分钟，十五分钟的平均CPU负载，最重要的指标是最后一个数字，即前15分钟的平均CPU负载，这个数字越小越好。所谓CPU负载指的是一段时间内任务队列的长度，通俗的讲，就是一段时间内一共有多少任务在使用或等待使用CPU。（当前的"负载值除以cpu核数"就是cpu的利用率））

load average表示的是系统的平均负荷，即CPU的Load。

它所包含的信息不是CPU的使用率状况，而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息，也就是CPU使用队列的长度的统计信息。

它包括3个数字，分别表示系统在1、5、15分钟内进程队列中的平均进程数量（即处理的进程情况），

原则上来说这3个数字越小越好，数字越小表示服务器的工作量越小，系统负荷比较轻

当CPU完全空闲的时候，平均负荷为0（即load average的值为0）；当CPU工作量饱和的时候，平均负荷为1。

这里需要注意的是：

load average这个输出值，这三个值的大小一般不能大于系统逻辑CPU的个数

比如一台服务器有4个逻辑CPU，如果load average的三个值长期大于4时，说明CPU很繁忙，负载很高，可能会影响系统性能；

但是偶尔大于4时，倒不用担心，一般不会影响系统性能。

相反，如果load average的输出值小于CPU的个数，则表示CPU还有空闲，比如本例中的输出，CPU是比较空闲的。

-------------load average举例理解---------------

判断系统负荷是否过重，必须理解load average的真正含义。假设当前我的一台服务器只有一个CPU，所有的运算都必须由这个CPU来完成。

不妨把这个CPU想象成一座大桥，桥上只有一根车道，所有车辆都必须从这根车道上通过（很显然，这座桥只能单向通行）。

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

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

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

4）系统负荷为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，就意味着服务器的处理能力翻了一倍，能够同时处理的进程数量也翻了一倍。

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

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

---------至于load average是多少才算理想，这个有争议，各有各的说法---------

个人比较赞同CPU负载小于等于"内核数乘以0.5-0.7"算是一种理想状态。

比如4核CPU的服务器，理想负载是小于等于2，最好不要超过2.8，否则性能多少会受影响。

不管某个CPU的性能有多好，1秒钟能处理多少任务，可以认为它无关紧要，虽然事实并非如此。

在评估CPU负载时，只以5分钟为单位做统计任务队列长度。如果每隔5分钟统计的时候，发现任务队列长度都是1，那么CPU负载就为1。

假如现在某台服务器只有一个单核的CPU，负载一直为1，意味着没有任务在排队，还不错。

但是这台服务器是双核CPU，等于是有4个内核，每个内核的负载为1的话，总负载为4。这就是说，如果这台服务器的CPU负载长期保持在4左右，还可以接受。

但是每个内核的负载为1，并不能算是一种理想状态！这意味着服务器的CPU一直很忙，不得清闲。

-----------load average返回三个平均值应该参考哪个值？------------

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

如果15分钟内，平均系统负荷大于1.0（调整CPU核心数之后），表明问题持续存在，不是暂时现象。

所以应该主要观察"15分钟系统负荷"，将它作为服务器正常运行的指标。

----------如何来降低服务器的CPU负载？--------------

最简单办法的是更换性能更好的服务器，不要想着仅仅提高CPU的性能，那没有用，CPU要发挥出它最好的性能还需要其它软硬件的配合。

在服务器其它方面配置合理的情况下，CPU数量和CPU核心数（即内核数）都会影响到CPU负载，因为任务最终是要分配到CPU核心去处理的。两块CPU要比一块

CPU好，双核要比单核好。因此，需要记住的是：除去CPU性能上的差异，CPU负载是基于内核数来计算的。有一个说法是"有多少内核，即有多少负载"。