以下内容来自转载和自己的初用体验。
vmstat
[root@master ~]# vmstat -n 3
procs ---memory-- --swap-- --io----system----cpu---
r bswpd free buff cachesisobiboin
csus sy id wa st
0 0 115516 6043024 430340869184000
222111 0 99 0 0 0 0115516 6043024
430340869184000001124751
0 0 100 0 0 0 0 115516 6043148
4303448691840000251070762
0 0 100 0 0
PROC
如果在processes中运行的序列是连续的大于在系统中的CPU的个数表示系统现在运行比较慢，有多数的进程等待CPU。
如果r的输出数大于系统中可用CPU个数的4倍的话，则系统面临着CPU短缺的问题，或者是CPU的速率过低，系统中有多数的进程在等待CPU，造成系统中进程运行过慢。
SYSTEM
in: 每秒产生的中断次数
cs: 每秒产生的上下文切换次数
上面2个值越大，会看到由内核消耗的CPU时间会越大
CPU
us:用户进程消耗的CPU时间百分比，其中us值比较高时，说明用户进程消耗的CPU时间多；如果长期超50%的使用，那么我们该考虑优化程序算法或者进行加速
sy: 内核进程消耗的CPU时间百分比(sy的值高时，说明系统内核消耗的CPU资源多，并不是良性表现，我们应该检查原因)
wa:IO等待消耗的CPU时间百分比(值高时，说明IO等待比较严重，这可能由于磁盘大量作随机访问造成，也可能磁盘出现瓶颈，如块操作)
id: CPU处于空闲状态的百分比，如果空闲时间持续为0并且系统时间是用户时间的两倍，那么系统则面临CPU资源的短缺
解决方法：
当发生以上问题的时候请先调整应用程序对CPU的占用情况，使得应用程序能够更有效的使用CPU，同时可以考虑增加更多的CPU，关于CPU的使用情况还可以结合mpstat、ps
aux 、top、mpstat
-a等等一些相应的命令来综合考虑关于具体的CPU的使用情况，和那些进程在占用大量的CPU时间，一般情况下，应用程序的问题会比较大一些。
sar
Usage: sar [ options... ] [ [ ]
]
Options are:
[ -A ] [ -b ] [ -B ] [ -c ] [ -d ] [ -i ] [ -p ] [
-q ]
[ -r ] [ -R ] [ -t ] [ -u ] [ -v ] [ -V ] [ -w ] [ -W ] [ -y ]
[ -I { | SUM | ALL | XALL } ] [ -P { | ALL
} ]
[ -n { DEV | EDEV | NFS | NFSD | SOCK | ALL } ]
[ -x { | SELF | ALL } ] [ -X { | SELF | ALL
} ]
[ -o [ ] | -f [ ] ]
[ -s [ ] ] [ -e [ ] ]
在命令行中，n和t两个参数组合起来定义采样间隔和次数，t为采样间隔，是必须有的参数，n为采样次数，是可选的，默认值为1， -o
file表示将命令的结果以二进制格式存放
在文件中，options为命令可选项：
-A：所有报告的总和。
-u：CPU利用率
-v：进程、I节点、文件和锁表状态。
-d：硬盘使用报告。
-r：内存和交换空间的使用统计。
-g：串口I/O的情况。
-b：缓冲区使用情况。
-a：文件读写情况。
-c：系统调用情况。
-q：报告队列长度和系统平均负载
-R：进程的活动情况。
-y：终端设备活动情况。
-w：系统交换活动。
-x { pid | SELF | ALL
}：报告指定进程ID的统计信息，SELF关键字是sar进程本身的统计，ALL关键字是所有系统进程的统计。
用sar进行CPU利用率的分析
[root@master ~]# sar -u 2 10
Linux 2.6.18-194.el5 (master) 12/13/
06:50:01 PM
CPU %user
%nice %system %iowait
%steal %idle
06:50:03 PM
all
1.50
0.08
0.58
7.24 0.00
90.60
06:50:05 PM
all
3.25
0.17
0.58
6.74 0.00
89.26
06:50:07 PM
all
1.33
0.08
0.67
8.01 0.00
89.91
06:50:09 PM
all
1.25
0.00
0.67
7.35 0.00
90.73
06:50:11 PM
all
1.08
0.25
0.42
7.75 0.00
90.50
06:50:13 PM
all
1.33
0.08
0.58
8.00 0.00
90.00
06:50:15 PM
all
1.42
0.08
0.42
7.18 0.00
90.90
06:50:17 PM
all
1.25
0.08
0.42
8.01 0.00
90.24
06:50:19 PM
all
1.33
0.08
0.50
8.17 0.00
89.92
06:50:21 PM
all
1.25
0.25
0.42
7.17 0.00
90.92
Average:
all
1.50
0.12
0.53
7.56 0.00
90.30
在显示内容包括：
%user：CPU处在用户模式下的时间百分比
%nice：CPU处在带NICE值的用户模式下的时间百分比
%system：CPU处在系统模式下的时间百分比
%iowait：CPU等待输入输出完成时间的百分比
%steal：管理程序维护另一个虚拟处理器时，虚拟CPU的无意识等待时间百分比
%idle：CPU空闲时间百分比
在所有的显示中，我们应该主要注意%iowait和%idle，
%iowait的值过高，表示硬盘存在I/O瓶颈，%idle值高，表示CPU较空闲。
如果%idle值高但系统响应慢时，有可能是CPU等待分配内存，此时应加大内存容量。反之如果持续低于10，那么系统的CPU处理能力相对较低，表明系统中最需要解决的资源是CPU。
用sar进行运行进程队列长度分析：
[root@master ~]# sar -q 2 10
Linux 2.6.18-194.el5 (master) 12/13/
06:57:55 PM runq-sz plist-sz
ldavg-1 ldavg-5 ldavg-15
06:57:57 PM
0 1196
0.63
0.48 0.30
06:57:59 PM
0 1196
0.63
0.48 0.30
06:58:01 PM
0 1196
0.58
0.47 0.30
06:58:03 PM
0 1198
0.58
0.47 0.30
06:58:05 PM
0 1198
0.61
0.48 0.30
runq-sz：准备运行的进程运行队列
plist-sz：进程队列里的进程和线程的数量
ldavg-1：前一分钟的系统平均负载(load average)
ldavg-5：前五分钟的系统平均负载
ldavg-15：前15分钟的系统平均负载
顺便说一下load average的含义
load avarage可以理解为每秒钟CPU等待运行的进程个数。
在liunx系统中，有很多命令都会有系统平均负载load average的输出，那么什么是系统负载呢？
定义：在特定时间间隔内运行队列中的平均任务数。如果一个进程满足以下条件则其就会位于运行队列中：
1、它没有在等待I/O操作的结果
2、它没有主动进入等待状态(也就是wait)
3、没有被停止
例如：
[root@master ~]# uptime
09:34:05 up 69 days, 4:00, 1 user, load
average: 0.08, 0.02, 0.01
命令输出的最后内容表示在过去的1、5、15分钟内运行队列中的平均进程数量。
一般来说只要每个CPU的当前活动进程数不大于3那么系统的性能就是良好的，如果每个CPU的任务数大于5，那么就表示这台机器的性能有严重问题。
对于上面的例子来说，假设系统有两个CPU，那么其每个CPU的当前任务数为：0.08/2=0.04，这表示该系统的性能是可以接受的。
这里有个思考问题，就是当CPU是支持超线程的时候，那么这时候是除以物理个数，还是逻辑个数？？？？？
iostat
[root@master ~]# iostat -c 2 10
Linux 2.6.18-194.el5 (master) 12/14/
avg-cpu: %user %nice %system %iowait
%steal %idle
1.08 0.15
0.14 0.05 0.00
98.58
avg-cpu: %user %nice %system %iowait
%steal %idle
0.00 0.00
0.00 0.00 0.00 100.00
avg-cpu: %user %nice %system %iowait
%steal %idle
0.42 0.25
0.00 0.00 0.00
99.33
avg-cpu: %user %nice %system %iowait
%steal %idle
0.00 0.08
0.08 0.00 0.00
99.83
avg-cpu: %user %nice %system %iowait
%steal %idle
0.00 0.00
0.00 0.00 0.00 100.00
mpstat
是Multiprocessor
Statistics的缩写，是实时系统监控工具。其报告与CPU的一些统计信息，这些信息存放在/proc/stat文件中。
在多CPU系统里，其不但能查看看到所有CPU的平均状况信息，而且能够查看特定的CPU的信息。
mpstat语法如下：
Usage: mpstat [ options... ] [ [ ]
]
Options are:
[ -P { | ALL } ] [ -V ]
参数含义如下：
-P {| ALL} 表示监控哪个CPU，cpu在[0,cpu个数-1]中取值
internal 相邻的两次采样的间隔时间
count 采样的次数，count只能和delay一起使用
当没有参数时，则显示系统启动以后所有信息的平均值。(参数解释从/proc/stat获得数据)
[root@master ~]# mpstat -P 1 2 3
Linux 2.6.18-194.el5 (master) 12/14/
09:56:35 AM CPU %user
%nice %sys %iowait
%irq %soft %steal
%idle intr/s
09:56:37 AM 1
0.00 0.50
0.00 0.00
0.00 0.00 0.00
99.50 0.00
09:56:39 AM 1
0.00 0.00
0.00 0.00
0.00 0.00 0.00
100.00 0.00
09:56:41 AM 1
0.00 0.50
0.00 0.00
0.00 0.00 0.00
99.50 0.00
Average: 1
0.00 0.33
0.00 0.00
0.00 0.00 0.00
99.67 0.00
补充说明下，nice值的含义
[root@master ~]# ps -l
F S
UIDPID
PPID C PRI
NIADDRSZ
WCHAN
TTY TIME
CMD
4 S0 29493
29491 0
75
0 -
16559
wait pts/1 00:00:00 bash
4 R 0 29871
29493 0
77
0 -
15887-pts/1
00:00:00 ps
UID : 代表执行者的身份
PID : 代表这个进程的代号
PPID ：代表这个进程是由哪个进程发展衍生而来的，亦即父进程的代号
PRI ：代表这个进程可被执行的优先级，其值越小越早被执行
NI ：代表这个进程的nice值
这里的前面的三个信息，我们都是比较好容易理解的，但是后面的两个奇怪的信息，一个是PRI，一个是NI，这到底是什么东西？相对而言，PRI也还是比较好理解的，即进程的优先级，或者通俗点说就是程序被CPU执行的先后顺序，此值越小进程的优先级别越高。那NI呢？就是我们所要说的nice值了，其表示进程可被执行的优先级的修正数值。如前面所说，PRI值越小越快被执行，那么加入nice值后，将会使得PRI变为：PRI(new)=PRI(old)+nice。这样，当nice值为负值的时候，那么该程序将会优先级值将变小，即其优先级会变高，则其越快被执行。
进程在创建时并不是平等的,他们被赋予不同的优先级值，例如有些对计算机本身的操作至关重要的程序必须比其他次要的程序具有更高的优先级(则其有更小的优先级值)。而如前面所说，nice的值是表示进程优先级值可被修正数据值，因此，每个进程都在其计划执行时被赋予一个系统nice值，这样系统就可以根据系统的资源以及具体进程的各类资源消耗情况，主动干预进程的优先级值。这个过程，用户也可手工干预其中，但是要被赋予相应的权限。
在UNIX系统或者LINUX系统中，使用从-20到+19的一个可变数值来表示这个nice值(LINUX和AIX是这种情况，HP-UX系统的值范围是从0到39)，并且在通常情况下，子进程会继承父进程的系统nice值。具有最高优先级的程序，其nice值最低，所以在UNIX和LINUX系统中，值-20使得一项任务变得非常重要(HP-UX为0)；与之相反，如果任务的
nice 为+19(HP-UX为39)，则表示它是一个高尚的、无私的任务，允许所有其他任务比自己享有宝贵的 CPU
时间的更大使用份额，这也就是nice的名称的意会来意。
[root@master ~]# nice
0
root用户把nice加3.
[root@master ~]# nice -n 3 ls
123.txt
Desktop
install.log
jrockit-jdk1.6.0_29-R28.1.5-4.0.1
MySQL-python-1.2.3.tar.gz Python-2.7.3.tgz
setuptools-0.6c8.tar.gz vmtouch.c
anaconda-ks.cfg file1
install.log.syslog
jrockit-jdk1.6.0_29.tar.gz
part-00000.bz2
root
soft
yum_r.txt
cmake-2.8.7.tar.gz file2
integer.sh
MySQL-python-1.2.3
Python-2.7.3
setuptools-0.6c8 vmtouch
而root用户就可以给其子进程赋予更小的nice值，如下：
[root@dbbak root]# nice
0
[root@dbbak root]# nice -n -3 ls
123.txt
Desktop
install.log
jrockit-jdk1.6.0_29-R28.1.5-4.0.1
MySQL-python-1.2.3.tar.gz Python-2.7.3.tgz
setuptools-0.6c8.tar.gz vmtouch.c
anaconda-ks.cfg file1
install.log.syslog
jrockit-jdk1.6.0_29.tar.gz
part-00000.bz2
root
soft
yum_r.txt
cmake-2.8.7.tar.gz file2
integer.sh
MySQL-python-1.2.3
Python-2.7.3
setuptools-0.6c8 vmtouch
对于后台进程，其nice会在其被显示赋予的值过后再加上4。如“nice 12 command
&”命令执行时，则其会以nice=36值来运行程序(HP-UX系统)。这里有个问题，即如果用户设置的nice值超过了nice的边界值(LINUX和AIX为-20到19，HP-UX为0到39)会怎样，则系统就取nice的边界值作为进程的nice值。
与进程的nice相关的命令有2个，分别是nice和renice。
nice命令就是设置一个要执行command进程的nice值，其命令格式是 nice –n adjustment command
command_option，这里就设置要执行的command的nice，如果这里不指定adjustment，则默认为10。
renice命令就是设置一个已经在运行的进程的nice值，如假设一运行进程本来nice值为0，renice为3后，则这个运行进程的nice值就为3了。renice的执行必须要有相应的权限方可执行。它可以根据用户、进程ID、进程组来设置进程的nice值。
对nice值一个形象比喻，假设在一个CPU轮转中，有2个runnable的进程A和B，如果他们的nice值都为0(如果是HP-UX则为20)，加上内核会给他们每人分配1k个cpu时间片。但是假设进程A的为0，但是B的值为-10，那么此时CPU则会可能分别给A和B分配1k和1.5k的时间片。故可以形象的理解为，nice的值影响了内核分配给进程的cpu时间片的多少，时间片越多的进程，其优先级越高，其优先级值越低。
从使用top、ps等命令看到的nice值，就是进程所拥有的nice值，使用iostat等看到的%nice，就是用户进程空间中改变过优先级的进程的占用CPU的百分比，如上例中就说0.5k/2.5k=1/5=20%。
到目前为止，更需要强调一点的是，进程的nice值不是进程的优先级，他们不是一个概念，但是进程nice值会影响到进程的优先级变化。
