分类： 系统运维
2016-01-26 17:56:53
HPUX中很多种不同的性能工具。有些工具提供实时的性能信息，其他还有一些在后台收集信息供后续的分析。还有一些工具允许系统参数被调整优化。
这一章节的目的是简介各个工具是如何工作的，可以作为选择工具的一个快速的参考。
注意：这里不包括如何解释工具的输出
标准的工具是在UNIX base系统上常见的工具，使用标准工具的优点是可以和其他平台上相应工具的结果进行对比。
HPUX特有工具是由HP开发的。这些工具通常在其他UNIX平台上是没有的。这样的工具包括像Glance,Measureware,PerfView,NNM和ITO。
注意：本文档中不包含对HPUX特有工具的介绍
Sar = System Activity Reporter
Sar工具用来收集一段时间的性能数据（常在cron job中使用），或是实时显示。
当用来采集一段时间的数据时，常用的是sar相关的命令，sa1和sadc. Sadc是真正用来收集数据的程序，sa1实际上是一个前端程序，每隔几秒种，重复n次来调用sadc.
采样性能数据时，sar对kernel中的变量（也叫计数器）进行采样，包括了资源的请求数、资源的IO访问数、队列长度等。
Sar命令的报告通常用于观察系统中在发生什么，瓶颈在哪里。
sar对指定周期内的数据采样，可以在crontab里定期进行，也可以由用户发起。
通过crontab来进行，有助于分析一个长期的系统状态。有两种可能的方式：sadc或是sa1.
sadc每隔t秒，进行n次，来收集数据，并输出到一个二进制的文件(ofile). 如果输出文件名没有指定，就输出到标准输出(也就是终端屏幕上)。 如果t和n也没有指定，sadc会写一条特定的记录，用来在系统启动时标记计数器归零的时间。
sa1用t和n参数调用sadc，把输出结果写到/usr/adm/sa/sadd中，其中dd是当时的日期。如果t和n没有指定，sa1会传递t=1,n=1.
sar命令可以按照时间间隔采样，输出到文件中（如果指定了），在标准输出上显示报告。如果n参数没指定，就只采样一次。
数据收集到以后，有不同的方式来生成报告。如果要自动做，可以用sa2在crontab里运行。sa2是一个脚本程序，调用sar命令，通过较早前收集并存放在/var/adm/sa/sardd的二进制文件生成报告。具体是哪一种类型的报告，通过选项来确定(-ubdyswaqvmA). 同样地，时间区域可以通过指定开始时间(-s time)与结束时间(-e time)来确定。时间间隔也可以用(-I seconds)来指定，这个间隔可以与收集数据时的时间间隔不同。
用sar命令可以交互式地完成，与sa2的选项相同，再加上(-f file)来指定输入文件。 如果没有指定输入文件，默认采用/var/adm/sa/sadd. 报告会输出到标准输出上。
Sample crontab entries:
0 * * * 0,6 /usr/lbin/sa/sa1
0 8-17 * * 1-5 /usr/lbin/sa/sa1 1200 3
0 18-7 * * 1-5 /usr/lbin/sa/sa1
User invocation:
# sar -A -o sar.out 1 3600>/dev/null &
# sar -b -f sar.out
上面的crontab条目可以生成供后续分析的二进制文件，例子里列出来的情况会在每个周六与周日的整点，工作日的工作时间内每20分钟，工作日的下班时间内每小时 来收集数据。
第一行用户调用的例子会每秒收集数据，时长为1小时，将输出结果写到sar.out中，是二进制的格式。因为命令会同时输出到标准输出上，所以把它重定向到/dev/null，在后台运行。
第二行用户调用的例子会生成一个buffer 活动的报告，数据源是前一个例子里生成的文件。
? sar -u
? %usr = time spent in user mode
? %sys=time spent in system mode
? %wio=time spent in block, raw, and virtual memory management I/O
? %idle=CPU time not being used
? sar -uM: option for multiprocessor platforms.
sar –u会报告CPU的整体利用率。它报告在用户模式下CPU的时间(%usr),系统模式下(%sys),块设备、裸设备和虚拟内存管理的IO(%wio),还有其他的空闲时间(%idle). 每行显示一个时间间隔内的数据，最后会有一行平均值。
先看%idle是不是接近0. 如果%idle接近0，就看%wio是不是大于7. 如果是的话，就要研究是不是有IO的瓶颈。
如果%wio很低，但是%idle并不是0，就要研究%usr和%sys。如果大部分时间用在%usr,可能是用户应用引起的CPU瓶颈。这些应用要检查一下为什么占这么多CPU时间。如果是%sys占用了大部分时间，就要分析系统为什么占用这么多时间。其他的可能性，比如说太多磁盘swapping操作，可能用很多系统时间。
在多CPU环境加上-M选项。
|
07:00:01 |
%usr |
%sys |
%wio |
%idle |
|
08:00:01 |
8 |
5 |
6 |
82 |
|
09:00:01 |
7 |
20 |
43 |
31 |
|
10:00:01 |
4 |
11 |
19 |
67 |
|
11:00:01 |
9 |
10 |
47 |
34 |
|
12:00:01 |
1 |
3 |
1 |
95 |
|
13:00:01 |
1 |
3 |
2 |
95 |
|
Average |
5 |
9 |
20 |
67 |
SuggestedRatios |
60 |
25 |
0 |
15 |
这个例子中，从07:00AM到01:00PM每小时收集一次数据。输出是通过cron生成的。sar需要大概2%的负载来完成这样的事。
建议的比率是一个粗略的估算，太高的比率通常指示下列性能瓶颈。
%usr: CPU 瓶颈
%sys: 内存瓶颈 (paging and/or swapping is occurring)
%wio I/O 瓶颈 (external disk access, read/write to tape)
所谓’瓶颈’可能是一个暂时的现象，比如说备份到磁带上时%wio比较高。许多时候合理地安排对性能有强需求的事务可以解决性能问题，比如安排在晚上用户数少的时候进行备份。
? sar -d
? %busy=portion of time a device was servicing transfer request(s)
? avque=average number of requests outstanding
? avwait vs. avserv
sar –d报告每个硬盘或磁带驱动器块设备的活动(黄金甲按：原文如此，存疑，裸设备的利用率是可以看到的). 它显示设备文件名，忙于传输请求的时间(%busy),在这个期间outstanding的请求的数目(avque),每秒钟数据传输的数据(r+w/s),传数的数据量的大小,以512字节的块为单位(blks/s),在队列中等待的平均时间，以毫秒为单位(avwait),提供服务的时间，以毫秒为单位（avserv）.
如果一个硬盘设备的%busy>50,就存在硬盘的瓶颈。如果avwait>avserv,也说明有硬盘的瓶颈。 avque指示有多少任务在队列中等待。
在观察sar –d输出时，一个优化的系统应该显示不同硬盘之间的负载比较均衡。
|
15:31:55 |
device |
%busy |
avque |
r+w/s |
blks/s |
avwait |
avserv |
|
15:32:00 |
c0t5d0 |
85 |
2.9 |
31 |
248 |
51 |
27.2 |
|
15:32:05 |
c0t6d0 |
1 |
1.2 |
0 |
1 |
5 |
30 |
|
c0t5d0 |
84 |
3.4 |
29 |
232 |
71.3 |
29.3 |
|
|
15:32:10 |
c0t6d0 |
0 |
1 |
0 |
1 |
5 |
30 |
|
c0t5d0 |
89 |
3.5 |
31 |
245 |
74.1 |
29.1 |
|
|
15:32:15 |
c0t5d0 |
82 |
2.7 |
30 |
242 |
47 |
27.2 |
|
15:32:20 |
c0t5d0 |
82 |
2.8 |
29 |
235 |
51.7 |
28 |
|
Average |
c0t6d0 c0t5d0 |
0 |
1.1 |
0 |
0 |
3.3 |
23.3 |
|
Average |
85 |
3.1 |
30 |
30 |
58.9 |
28.1 |
这个例子显示的是用-d选项来运行sar命令。每5秒收集一次，共20秒。
例中，第一个硬盘非常繁忙，而第二块硬盘则很空闲。所以第一块硬盘存在瓶颈。这是一个很好的负载不均衡的例子。
IO瓶颈的指示可以归纳为：
%busy >50
avwait > avserv
? sar -b
? %rcache=read cache hit ratio
? %wcache=write cache hit ratio
? pread/s & pwrit/s are generally obsolete due to the lack of dumb terminal use
sar –b报告系统缓冲区的情况。提供了每秒传送的数据块的数量(bread/s,bwrit/s)，每秒对缓冲区读写的数量(lread/s,lwrit/s),cache命中率%rcache=(1-bread/lread)*100, %wcache=(1-bwrit/lwrit)*100),每秒以raw模式传送的数量(pread/s,pwrit/s). pread/s和pwrite/s还可以用来指示裸设备的访问，数据库经常会选择使用裸设备。
主要关注的参数是%rcache和%wcache. 要想获得理想的性能，%rcache要高于90，%wcache高于70。
|
### |
bread/s |
lread/s |
%rcache |
bwrit/s |
lwrit/s |
%wcache |
|
15:31:55 |
0 |
286 |
100 |
24 |
93 |
74 |
|
15:32:00 |
0 |
114 |
100 |
20 |
57 |
65 |
|
15:32:05 |
0 |
467 |
100 |
34 |
129 |
74 |
|
15:32:10 |
0 |
114 |
100 |
2 |
22 |
92 |
|
15:32:15 |
2 |
430 |
100 |
39 |
148 |
73 |
|
Average |
1 |
282 |
100 |
24 |
90 |
76 |
本例中，有很好的cache命中率。对于进行很多随机IO操作，或是buffer cache很少的系统，这些比率可能会比较低。
指示IO瓶颈的一个快速参考是：
? %rcache < 90
? %wcache < 70
? sar -w
? swpin/s & bswin/s= units transferred by swapins per second
? swpot/s & bswot/s= units transferred by swapouts per second
显示以block为单位(512字节)每秒传输的swapin(swpin/s,bswins/s)和swapout（swpot/s,bswot/s），还有每秒钟进程切换的数量(pswch/s).
swpot/s大于0就需要继续分析
|
|
Swpin/s |
Bswin/s |
Swpot/s |
Bswot/s |
Pswch/s |
|
### |
7.7 |
90 |
45 |
2304.7 |
1327 |
|
### |
22 |
272 |
23 |
1190 |
1307 |
|
### |
29 |
483 |
16 |
760 |
1519 |
|
### |
24 |
490 |
15 |
769 |
1345 |
|
### |
27 |
590 |
18 |
990 |
1681 |
|
Average |
22 |
385 |
24 |
1202 |
1436 |
本例中，平均每秒有22个进程swapin,24个进程swapout，还有很高的进程切换。这说明内存很紧张。内存的使用情况需要被关注，这个例子里是有程序使用了大量数据空间(大形的阵列)造成了瓶颈。
要是主机内存很充沛，上面swpin/s,bswin/s,swpot/s和bswot/s都会是0. 适当的进程切换是可以接受的，比如说小于50.
指示内存瓶颈的指标是：
swpout/s > 0
? sar -q
? runq-sz=length of the run queue
? %swpocc=percentage of time the swap queue was occupied
这个选项给出运行队列的长度(runqsz),运行队列被占用时间的百分比(%runocc),swap队列的长度（在swap设备上准备运行的进程的数量）(swpq-sz),还有swap队列被占用时间的百分比（%swpocc）.
这些数值都是越小越好。如果run-sz大于4或是%swapocc大于5，sar –q的输出就需要和sar –w的输出对照分析
|
15:00:10 |
runq-sz |
%runocc |
swpq-sz |
%swpocc |
|
15:01:10 |
42.6 |
100 |
17.8 |
60 |
|
15:02:10 |
41.5 |
101 |
21 |
101 |
|
15:03:10 |
43.2 |
99 |
23.3 |
99 |
|
15:04:10 |
35.7 |
100 |
31.4 |
100 |
|
15:05:10 |
43.1 |
103 |
40.3 |
102 |
|
15:06:10 |
36.8 |
99 |
42.9 |
99 |
本例中，有大量进程在运行队列中，队列的占用率接近100%。 这说明主机内存紧张，正在进行过度的swapping. 大量的swapping操作也会使得sar –u的输出中%sys偏高。
内存充足的系统中，swpq-sz和%swpocc接近空值。适度的运行队列长度是可以接受的（<5）
指示内存瓶颈的指标：
? runq-sz > 4 (across all CPUs)
? %swpocc > 5 (across all CPUs)
? sar -c
? scall/s=number of system calls per second
? fork/s=number of fork/vfork system calls per second
? exec/s=number of execs per second
它给出每秒进行的系统调用的次数(scall/s),读系统调用的次数(sread/s),写系统调用的次数(swrit/s),fork与vfork操作的次数(fork/s),exec调用的次数(exec/s),读写调用的字符数量(rchar/s,wchar/s).
如果系统调用的总数很高，需要进行分析，因为这会造成CPU的%sys变高。通过观察fork/s和exec/s可以看到时系统中生成的进程数。
|
1:29:48 |
scall/s |
sread/s |
swrit/s |
fork/s |
exec/s |
rchar/s |
wchar/s |
|
1:29:53 |
116 |
13 |
41 |
0 |
0 |
373965 |
18432 |
|
1:29:58 |
68 |
10 |
42 |
0 |
0 |
614 |
0 |
|
1:30:03 |
69 |
10 |
41 |
0 |
0 |
7168 |
4096 |
|
1:30:08 |
67 |
10 |
41 |
0 |
0 |
819 |
0 |
|
1:30:13 |
67 |
10 |
41 |
0 |
0 |
1843 |
0 |
|
Average |
77 |
11 |
41 |
0 |
0 |
76882 |
4506 |
本例中，每25秒收集一次数据。平均的系统调用数为77(scall/s),这是一个中等的数字。另外，没有新的进程生成(fork/s和exec/s).
rchar/s和wchar/s在今天已经基本没用了。这一区域一般是与哑终端相关
指示CPU瓶颈的指标：
? scall/s > 3000
? fork/s
? exec/s
? sar -v
? The only tool (other than HP GlancePlus/UX that reports on system tables.
? ov = overflows
这是除了Glance之外唯一可以报告系统表的工具，显示主要的系统表的大小和占用的条目。它给出文本表的已占用条目数/大小(text-sz),采样时间内溢出的数目(ov),进程表空间的已占用条目数/大小(proc-sz和ov),还有inode表相关的(inod-sz和ov).
如果存在溢出的情况，控制台上与syslog.log中会有报错信息。用sar工具，可以观察不同时间段内各种表的占用情况。
|
0:00:00 |
text-sz |
ov |
proc-sz |
ov |
inod-sz |
ov |
file-sz |
ov |
|
1:00:00 |
29/76 |
0 |
75/276 |
0 |
137/356 |
0 |
113/590 |
0 |
|
2:00:00 |
27/76 |
0 |
75/276 |
0 |
138/356 |
0 |
113/590 |
0 |
|
3:00:00 |
28/76 |
0 |
75/276 |
0 |
135/356 |
0 |
113/590 |
0 |
|
4:00:00 |
29/76 |
0 |
75/276 |
0 |
142/356 |
0 |
117/590 |
0 |
|
5:00:00 |
29/76 |
0 |
75/276 |
0 |
148/356 |
0 |
113/590 |
0 |
|
6:00:00 |
30/76 |
0 |
79/276 |
0 |
144/356 |
0 |
121/590 |
0 |
本例中，基本上所有的表都没用到一半。
如果存在溢出overflow,ov会大于0。
? sar -a
? iget/s=number of file system iget() calls per second
? namei/s=number of file system lookuppn() (pathname translation) calls per second
? dirblk/s=number of file system blocks read per second doing directory lookup
给出每秒执行iget例程的数量(iget/s) (这时读了多少inode);vfs_lookup例程被调用的数量(namei/s,就是路径解析的数量)，还有目录块被读取的数量(dirbk/s).
? sar -mS
? msg/s=Number of System V msgrcv() calls per second.
? sema/s=Number of System V semop() calls per second.
? select/s=Number of System V select() calls per second. Requires "-S" option.
它给出每秒钟通过进程间message机制传送的message数量(msg/s)和进程间通信的semphore的数量(sema/s). sema/s值在semop()例程中被增加，这个例程是用来获取和释放semaphore的。所以，这个值至少是semaphore数量的两倍。
? sar -y: tty device activity
? sar -A: reports ALL data options
sar –y报告tty设备的活动。It reports on the input character rate (rawch/s), the input character rate processed by canon (canch/s), the output character rate (outch/s), the characters presented by mux (rcvin/s), and the number of output characters processed and passed on to the mux (xmtin/s).
sar –A报告所有数据，相当于把其他的所有选项都选上。
