aix系统性能管理及oracle案例分析

目录

AIX 5.3主机性能评估 .................................................................................................................... 1

一、CPU性能评估 ................................................................................................................. 2

1、vmstat ......................................................................................................................... 2 2、sar ............................................................................................................................... 3 3、iostat ........................................................................................................................... 5 4、tprof ............................................................................................................................ 5 5、ps ................................................................................................................................ 7 6、解决CPU占用的惩罚机制nice和renice ............................................................... 8 7、小结 ............................................................................................................................ 9 二、Memory性能评估 ........................................................................................................... 9

1、VMM的管理简介 ..................................................................................................... 9 2、使用vmstat确定内存的使用情况 .......................................................................... 12 3、svmon命令 .............................................................................................................. 12 4、内存的调整 .............................................................................................................. 13 三、磁盘的I/O性能评估 ..................................................................................................... 14

1、iostat查看 ................................................................................................................ 15 2、sar –d查看 ............................................................................................................... 17 3、使用lslv –l lvname来评估逻辑卷的碎片情况 ...................................................... 19 4、lslv –p 评估物理布局 ............................................................................................. 19 5、使用 vmstat 命令评估调页空间的 I/O ................................................................ 20 6、使用filemon命令监控系统I/O ............................................................................. 21 7、监视磁盘 I/O 的小结 ............................................................................................. 22 8、案例 .......................................................................................................................... 23 9、RAID10和RAID5的比较 ...................................................................................... 24 四、NETWORK性能评估 ................................................................................................... 26

1、ping命令查看网络的连通性 .................................................................................. 26 2、netstat –i检查网络的接口 ....................................................................................... 27 3、netstat –r检查主机的路由情况 .............................................................................. 27 4、netpmon .................................................................................................................... 29 5、其他一些常用的命令 .............................................................................................. 30 五、补充：关于topas的使用说明 ...................................................................................... 31 六、主机日常检查脚本 ........................................................................................................ 33

AIX 5.3主机性能评估

对于AIX主机的性能评估，我们从下面的4个方面来逐一介绍：CPU、MEMORY、I/O系统和网络这4个方面来描述。

一、CPU性能评估

首先，我们还是先来看一下CPU的性能评估。下面先主要介绍几个看CPU性能的命令。

1、vmstat

使用vmstat来进行性能评估，该命令可获得关于系统各种资源之间的相关性能的简要信息。当然我们也主要用它来看CPU的一个负载情况。

下面是我们调用vmstat命令的一个输出结果： $vmstat 1 2

System configuration: lcpu=16 mem=23552MB

kthr memory page faults cpu ----- ----------- ------------------------ ----------------- -----------

r b avm fre re pi po fr sr cy in sy cs us sy id wa 0 0 3091988 2741152 0 0 0 0 0 0 1849 26129 4907 8 1 88 3 0 0 3091989 2741151 0 0 0 0 0 0 2527 32013 6561 15 2 77 6 对上面的命令解释如下： Kthr段显示内容

? r列表示可运行的内核线程平均数目，包括正在运行的线程和等待 CPU 的线程。如果这个数字大于 CPU 的

数目，则表明有线程需要等待CPU。 ? b列表示处在非中断睡眠状态的进程数。包括正在等待文件系统 I/O 的线程，或由于内存装入控制而被挂起的

线程。

Memory段显示内容

? avm列表示活动虚拟内存的页面数，每页一般4KB ? fre空闲的页面数，每页一般4KB Page段显示内容

? re –该列无效

? pi 从磁盘交换到内存的交换页（调页空间）数量，4KB/页。调页空间是驻留在硬盘上的虚拟内存的一部分。

当内存使用过量时，会将溢出的工作组页面存储到调页空间中（窃取页）。当进程访问一个窃取页时，就产生了一个缺页故障，而这一页页必须从调页空间中读入到内存中。

? po 从内存交换到磁盘的交换页数量，4KB/页。如果窃取的工作也在调页空间中不存在或者已经作了修改，则

写入调页空间中。如果不被再次访问，它会留在调度空间中直到进程终止或者放弃空间。

? fr 根据页面替换算法每秒释放的页数。当VMM页面替换例程扫描页面帧表（Page Frame Table，PFT）时，它

会根据一些条件选取需要窃取的页面以补充空闲列表。该条件中包含工作页面和计算页面，释放的页面中，计算页面不产生I/O，工作页面如果数据没有发生修改，也不需要写回磁盘，也不会产生I/O。

? sr 根据页面替换算法每秒所检查的页数。sr值比fr值高的越多，说明替换算法要查找可以替换的页面就越困

难。

? cy 每秒页面替换代码扫描了PFT多少次。因为增加空闲列表达到maxfree值，不一定需要完全扫描PFT表，

而所有vmstat输出都为整数，所以通常cy列值为0。

Faults段显示内容（其实这段内容不需太多关注）

? in 在该时间间隔中观测到的每秒设备中断数。 ? sy 在该时间间隔中观测到的每秒系统调用次数。 ? cs 在该时间间隔中观测到的每秒钟上下文切换次数。 Cpu段显示内容

? us 列显示了用户模式所消耗的 CPU 时间。

? sy 列详细显示了 CPU 在系统模式所消耗的 CPU 时间。

? id 列显示了没有未决本地磁盘 I/O 时 CPU 空闲或等待时间的百分比。

? wa 列详细显示了有未决本地磁盘 I/O 时 CPU 空闲的时间百分比。wa 的值如果超过 25%,就表明磁盘子系

统可能没有被正确平衡，或者这也可能是磁盘工作负荷很重的结果。

如果在一个单用户系统中，us + sy时间不超过 90%，我们就不认为系统的CPU是受限制的。

如果在一个多用户系统中，us + sy时间超过 80%, 我们就认为系统的CPU是受限的。其中的进程将要花时间在运行队列中等待。响应时间和吞吐量会受损害。

检查cpu，我们主要关注报告中的4个cpu列和2个kthr（内核线程）列。 在上面的示例中，我们可以观察到以下几个主要的信息： CPU IDLE比较高，比较空闲；r列为0，表明线程不存在等待； WA值不高，说明I/O压力不大；

free值比较大，pi，po为0，表明内存非常富裕。空闲较多。

2、sar

第二个常用的是 sar命令，但是sar会增加系统的开销。当然有些情况下，我们使用sar比较方便。

sar的输出结果与前面的基本类似，这里不再作详细的介绍，关于命令的语法，也不再作详细的介绍，我们常用的命令格式： #sar 1 3

AIX jsdxh_db02 3 5 00C2C1EB4C00 10/24/07

System configuration: lcpu=16

17:52:26 %usr %sys %wio %idle physc 17:52:27 19 7 0 75 8.00 17:52:28 19 6 0 75 8.01 17:52:29 19 7 0 75 8.02

Average 19 7 0 75 8.01

在这里，sar命令输出的是一个整体的cpu使用情况的一个统计，统计分项目的内容也比较直观，通过名字就可以理解涵义。这里有一点比较方便的就是，在最后一行有一个汇总的average行，作为上述统计的一个平均。另外，补充说明一点的就是，一般来说，第一行统计信息包含了sar命令本身启动的cpu消耗，所以往往是偏高的，所以导致average值也往往是偏高一点的。当然，这不会对结果产生多大影响。

当我们有多个cpu的时候，而程序采用的是单线程，有时候会出现一种情况，我们检查发现，cpu总体的使用率不高，但是程序响应却比较慢。这里有可能就是单线程只使用了一个cpu，导致这个cpu100％占用，处理不过来，而其他的cpu却闲置。这时可以对cpu分开查询，统计每个cpu的使用情况。 #sar -P ALL 1 2

AIX jsdxh_db02 3 5 00C2C1EB4C00 10/24/07

System configuration: lcpu=16

18:03:30 cpu %usr %sys %wio %idle physc 18:03:31 0 0 69 0 31 0.00 1 50 50 0 0 1.00

2 0 0 0 100 0.52 3 0 0 0 100 0.48 4 0 1 0 99 0.54 5 0 0 0 100 0.46 6 0 0 0 100 0.53 7 0 0 0 100 0.47 8 0 0 0 100 0.53 9 0 0 0 100 0.47 10 0 2 0 98 0.54 11 0 0 0 100 0.46 12 11 58 0 31 0.00 13 100 0 0 0 1.00 14 0 0 0 100 0.53 15 0 0 0 100 0.47 - 19 7 0 75 8.01 18:03:32 0 0 71 0 29 0.00 1 50 50 0 0 1.00 2 0 0 0 100 0.52 3 0 0 0 100 0.48 4 0 1 0 99 0.54 5 0 0 0 100 0.47 6 0 0 0 100 0.52 7 0 0 0 100 0.47 8 0 0 0 100 0.53 9 0 0 0 100 0.47 10 0 2 0 98 0.54 11 0 0 0 100 0.46 12 39 41 0 20 0.00 13 100 0 0 0 1.00 14 0 0 0 100 0.52 15 0 0 0 100 0.47 - 19 7 0 75 7.98

Average 0 0 70 0 30 0.00 1 50 50 0 0 1.00 2 0 0 0 100 0.52 3 0 0 0 100 0.48 4 0 1 0 99 0.54 5 0 0 0 100 0.46 6 0 0 0 100 0.53 7 0 0 0 100 0.47 8 0 0 0 100 0.53 9 0 0 0 100 0.47 10 0 2 0 98 0.54 11 0 0 0 100 0.46 12 28 48 0 24 0.00 13 100 0 0 0 1.00 14 0 0 0 100 0.52 15 0 0 0 100 0.47 - 19 7 0 75 8.00

上面是分cpu统计的情况，结果应该也比较直观吧。

Sar还有其他一些比较特殊的使用方法，比如：

如果希望多个采样和多个报告，可为 sar 命令指定一个输出文件，这样就方便多了。将 sar 命令的标准输出数据定向到 /dev/null，并将 sar 命令作为后台进程运行。具体的命令格式为： sar -A -o /temp/sar_result.log 5 300 > /dev/null &

关于sar其他的一些使用方法，这里不再详述。

3、iostat

第三个可以用来使用的命令是iostat. $ iostat -t 2 4

tty: tin tout avg-cpu: % user % sys % idle % iowait

0.0 0.0 0.0 0.1 99.8 0.1 0.0 81.0 0.0 0.1 99.9 0.0 0.0 40.5 0.0 0.0 100.0 0.0 0.0 40.5 0.0 0.1 99.1 0.8 TTY 的两列信息（tin 和 tou）显示了由所有 TTY 设备读写的字符数

CPU 统计信息列（% user、% sys、% idle 和 % iowait）提供了 CPU 的使用情况。 注意：第一份报告为系统启动以来的一个累积值。

4、tprof

使用tprof命令用于统计每个进程的CPU使用情况 # tprof -x sleep 30

该命令的输出结果可查看 __prof.all文件。

此命令运行30秒钟，在当前目录下创建一个名为_prof.all 的文件。30秒钟内， CPU被调度次数约为3000次。__prof.all 文件中的字段Total 为此进程调度到的CPU次数。如果进程所对应的 Total字 段的值为1500，即表示该进程在3000次 CPU调度中占用了1500次，或理解为使用了一半的CPU时间。tprof的输出准确地显示出哪个进程在使用CPU 时间。

在我下面的这一份示例中，可以看到，大部分的cpu时间都是被wait所占用的。这里的wait实际上是idle进程，可以表明这个系统是一个完全空闲的系统。 $ more __prof.all

Process PID TID Total Kernel User Shared Other

======= === === ===== ====== ==== ====== ===== wait 40970 40971 2998 2998 0 0 0 wait 32776 32777 2994 2994 0 0 0 wait 24582 24583 2985 2985 0 0 0 wait 16388 16389 2980 2980 0 0 0 syncd 221254 155707 31 31 0 0 0 caiUxOs 524540 2294015 3 0 0 3 0 netm 73746 73747 1 1 0 0 0 hats_nim 1671242 1220665 1 0 0 1 0 snmpd64 598258 1245291 1 1 0 0 0 rpc.lockd 639212 1728679 1 1 0 0 0 tprof 704622 2277437 1 0 0 1 0 trclogio 360524 2408625 1 1 0 0 0 trace 1523820 2523145 1 0 0 1 0

clinfo 1958102 2760945 1 1 0 0 0 sh 1572938 2285709 1 1 0 0 0

======= === === ===== ====== ==== ====== ===== Total 12000 11994 0 6 0

Process FREQ Total Kernel User Shared Other

======= === ===== ====== ==== ====== ===== wait 4 11957 11957 0 0 0 syncd 1 31 31 0 0 0 caiUxOs 1 3 0 0 3 0 netm 1 1 1 0 0 0 hats_nim 1 1 0 0 1 0 snmpd64 1 1 1 0 0 0 rpc.lockd 1 1 1 0 0 0 tprof 1 1 0 0 1 0 trclogio 1 1 1 0 0 0 trace 1 1 0 0 1 0 clinfo 1 1 1 0 0 0 sh 1 1 1 0 0 0 ======= === ===== ====== ==== ====== ===== Total 15 12000 11994 0 6 0

在这里，对wait进程作一点补充说明。

在AIX 5L下，你用ps aux会发现有一些root的wait进程 #ps aux |head -20

USER PID %CPU %MEM SZ RSS TTY STAT STIME TIME COMMAND oracle 266354 5.7 0.0 50136 27524 - A 15:40:35 0:32 oracleora92 (LOC root 17214 3.1 0.0 40 40 - A Jul 04 24793:53 wait root 16946 3.1 0.0 40 40 - A Jul 04 24633:59 wait root 16678 3.1 0.0 40 40 - A Jul 04 24600:21 wait root 53274 3.1 0.0 40 40 - A Jul 04 24397:54 wait root 286 3.1 0.0 40 40 - A Jul 04 24371:55 wait root 8196 3.0 0.0 40 40 - A Jul 04 24312:40 wait root 822 3.0 0.0 40 40 - A Jul 04 24303:36 wait root 554 3.0 0.0 40 40 - A Jul 04 24261:50 wait root 20776 2.7 0.0 40 40 - A Jul 04 21502:46 wait root 57372 2.7 0.0 40 40 - A Jul 04 21439:31 wait root 49176 2.7 0.0 40 40 - A Jul 04 21423:47 wait root 21044 2.7 0.0 40 40 - A Jul 04 21398:24 wait root 12848 2.7 0.0 40 40 - A Jul 04 21357:07 wait root 21312 2.7 0.0 40 40 - A Jul 04 21324:26 wait root 12580 2.7 0.0 40 40 - A Jul 04 21293:06 wait root 13116 2.7 0.0 40 40 - A Jul 04 21195:47 wait

oracle 344612 0.3 0.0 57588 34976 - A Jul 04 2663:08 ora_j000_ora92 oracle 430408 0.3 0.0 55908 33296 - A Jul 04 2220:57 ora_j001_ora92

wait就是CPU空闲的时候运行的空闲进程，AIX4上叫kproc。所以这个进程占用越大，表示机器越空闲。Wait进程的数量是由机器上的逻辑CPU的个数决定的，有几个逻辑CPU，就有几个wait进程.

5、ps

这个命令使用本身也比较复杂，在这里只介绍如何查看cpu占用最高的进程。使用举例如下： #ps aux | head -25

USER PID %CPU %MEM SZ RSS TTY STAT STIME TIME COMMAND root 17214 3.1 0.0 40 40 - A Jul 04 25578:42 wait root 16946 3.1 0.0 40 40 - A Jul 04 25415:54 wait root 16678 3.1 0.0 40 40 - A Jul 04 25377:03 wait root 53274 3.1 0.0 40 40 - A Jul 04 25170:12 wait root 286 3.1 0.0 40 40 - A Jul 04 25144:00 wait root 8196 3.0 0.0 40 40 - A Jul 04 25082:32 wait root 822 3.0 0.0 40 40 - A Jul 04 25072:25 wait root 554 3.0 0.0 40 40 - A Jul 04 25034:14 wait root 20776 2.7 0.0 40 40 - A Jul 04 22181:27 wait root 57372 2.7 0.0 40 40 - A Jul 04 22118:00 wait root 49176 2.7 0.0 40 40 - A Jul 04 22102:02 wait root 21044 2.7 0.0 40 40 - A Jul 04 22077:18 wait root 12848 2.7 0.0 40 40 - A Jul 04 22036:44 wait root 21312 2.7 0.0 40 40 - A Jul 04 21998:53 wait root 12580 2.7 0.0 40 40 - A Jul 04 21967:17 wait root 13116 2.7 0.0 40 40 - A Jul 04 21865:51 wait

oracle 344612 0.3 0.0 56372 33852 - A Jul 04 2707:30 ora_j000_ora92 oracle 430408 0.3 0.0 55916 33396 - A Jul 04 2266:20 ora_j001_ora92 oracle 365092 0.2 0.0 56184 33664 - A Jul 04 1765:58 ora_j002_ora92 oracle 442430 0.2 0.0 56092 33572 - A Jul 04 1426:40 ora_j003_ora92 oracle 385606 0.1 0.0 55984 33464 - A Jul 05 1159:17 ora_j004_ora92 oracle 413856 0.1 0.0 50520 28000 - A Jul 23 543:31 oracleora92 (LOC oracle 143668 0.1 0.0 50528 28008 - A Jul 13 833:21 oracleora92 (LOC oracle 369230 0.1 0.0 56600 34080 - A Jul 05 806:36 ora_j005_ora92

在这个输出结果中，排在前面的是16个root用户的wait进程，这其实是CPU空闲的时候运行的空闲进程，之前已作说明。

所以CPU最高的几个进程其实是下面的ORACLE用户的ora_j00*进程，这是ORACLE的job进程。在这里，这些进程的开销很小。如果ORACLE的进程开销比较大，我们可以用如下的方法来查询具体的进程在干什么事情，例如我们要查询进程ora_j000_ora92，PID=344612，可以使用下面的方法： $su – oracle

SQL>sqlplus “/as sysdba”

SQL>oradebug setospid 344612

SQL>oradebug event 10046 trace name context forever, level 8

SQL>oradebug tracefile_name –这个命令我们获得输出文件的绝对路径和文件名 SQL>oradebug event 10046 trace name context off

$tkprof /opt/oracle/app/oracle/admin/ora92/bdump/ora92_j000_344612.trc tracepid.txt $more tracepid.txt

在tracepid.txt中，我们就可以看到这个进程中具体运行的语句、过程等，以及所有的SQL的cpu消耗、物理读、逻辑读、执行计划等信息。

另外，我们也可以执行下面的语句查看进程具体运行的SQL语句的文本： SELECT /*+ ORDERED */ sql_text FROM v$sqltext a WHERE (a.hash_value, a.address) IN (

SELECT DECODE (sql_hash_value,0, prev_hash_value,sql_hash_value), DECODE (sql_hash_value,0, prev_sql_addr, sql_address) FROM v$session b

WHERE b.paddr = (SELECT addr

FROM v$process c

WHERE c.spid = '&pid')) ORDER BY piece ASC

6、解决CPU占用的惩罚机制nice和renice

指定和修改命令的优先级。

系统中运行的每个进程都有一个优先级，我们可以用ps命令看到，这个优先级为PRI，PRI的值越小，优先级越高，能占用更多的CPU时间片。系统默认的PRI为60，我们可以通过nice命令和renice命令来改变一个进程的优先级，从而控制进程对CPU时间片的占用。

任何一个用户都可以使用nice命令来使他的进程以低于系统默认的pri运行。但是只有root用户才可以使进程以高于默认的pri运行。

我们先来看一下nice命令的使用方法： #nice –n -5 vmstat 2 10 >vmstat.out # ps -el

F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 200001 A 0 704738 1523728 0 55 15 aee1400 544 f100009e63c23e30 pts/1 0:00 vmstat

指定程序以nice值-5开始运行。程序开始后，nice的值为15，PRI的值为55。

nice命令可以指定的范围为-20 (最高优先级)到 20 (最低优先级)。在AIX5.3中，默认的nice为20。 # vmstat 2 10 >vmstat.out # ps -el

F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD

200001 A 0 704740 1523728 0 60 20 32ec6400 472 f100009e63c23e30 pts/1 0:00 vmstat64 可以看到默认的情况下，系统使用的nice=20，pri=60 。

实际上，在使用nice指定的时候，我们也可以使用超出闭区间[-20,20]的值，比如： nice –n -33 vmstat 2 10 >vmstat.out # ps -el

F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD

200001 A 0 319652 1523728 0 40 0 82ef0400 544 f100009e63c23e30 pts/1 0:00 vmstat64 上例中，我们指定的nice小于-20，得到最高的优先级（pri=40）。反之，如果我们指定nice的值超过20，比如nice=21，我们将得到最低的优先级值pri=100。

renice不能在具有固定优先级的进程上使用。非root用户可以在一个或多个运行进程的nice值上加一个指定的值，但不能从中减去指定的值。也就是只能降低进程的优先级，而不能增加优先级。 renice -n -10 pidnumber ，将指定的进程nice值减小10。 renice -n +5 pidnumber ，将指定的进程nice值增加5。

根据nice值的不同取值，这里renice的值可以取值的范围是闭区间[-40,40 ]。为什么取值范围是这个呢？我们可以这样来理解，通过ps –l命令，我们可以看到NI的取值范围是闭区间[0,40]，我们使用renice需要改变的也就是整个值，考虑两个极端的情况，假如现在为0，我们要把它改到40，就必须得renice –n 40，如果现在是40，我们要把它改为0，则renice的值就得是-40了。

当然，跟nice一样，在这里renice的值在命中使用的时候也可以超出这个闭区间，不会报错，但有效的结果只落在这个闭区间内。

# ps l 1630282

FSUID PID PPID C PRI NI ADDR SZ RSS WCHAN TTY TIME CMD 200001 A 0 1630282 680062 0 100 40 413e8400 472 484 EVENT pts/1 0:00 v # renice -n -30 1630282 # ps l 1630282

FSUID PID PPID C PRI NI ADDR SZ RSS WCHAN TTY TIME CMD 200001 A 0 1630282 680062 0 50 10 413e8400 472 484 EVENT pts/1 0:00 v

我们可以总结一下，pri值的取值公式大概如下：

优先级值（PRI）= 基本优先级（60）＋nice损失 ＋ 基于最近CPU使用情况的CPU损失 总的来说nice值越小，进程的优先级越高，能分配到更多的cpu时间片。反之，也成立。

7、小结

对于系统cpu的监控，建议： 1）使用vmstat进行分析

2）sar –P ALL 1 10 分析，多个cpu间的负载是否平衡 3）ps aux 查看

4）tprof查看更详细的信息

二、Memory性能评估 1、VMM的管理简介

首先，还是简单讲解一下内存以及的VMM的一点工作原理。

内存和交换空间一般都是用页面来进行分配和管理的。在内存中存在两种类型的页面：计算页面（一般为可执行文件段中的页面）和文件页面（存储的数据文件的页面）。当我们执行程序或者读入数据的时候，内存中的页面就逐渐被占用。当空闲的内存只剩maxfree的时候，vmm的调页就被唤醒，通过调页算法，将内存中的页面转移到交换空间中。一直到空闲内存达到maxfree，才停止调页。

在这里，我们涉及到两个参数：

1) Minfree：最小空闲页链表尺寸。一旦低于该值，系统偷页以填充页链表，保证有足够的内存页面。偷页就是将不

常用的页面替换出去。

2) Maxfree：最大空闲页链表尺寸。一旦高于该值，系统停止偷页。 如果发现空闲列表不足，可以用下面的方法增加minfree参数 #vmo -o minfree=1000 -o maxfree=1008 Setting maxfree to 1008 Setting minfree to 1000

#vmo –o minfree=1000 –o maxfree=1008 –P # -P参数使修改永久生效 一般情况下，minfree和maxfree通过下面的公式得到： maxfree=minmum(memory/128,128) ,minfree=maxfree-8

注意：在AIX 5.2之前的版本请使用/usr/samples/kernel/vmtune命令。 #/usr/samples/kernel/vmtune –f 1000 –F 1008

另外，关于内存的使用，我们还有两个经常碰到的参数需要关注：

Minperm：用户I/O文件访问的最小缓冲区页数 Maxperm：用户I/O文件访问的最大缓冲区页数

Minperm和maxperm这两个参数的默认值分别为20％和80％。在这里主要与性能相关的是maxperm参数。maxperm参数指定了文件页面可以占用内存的上限，因为文件页面不主动释放，所以很容易造成内存的文件页面过高的占用，导致其他的应用内存使用紧张。调整参数值的方法如下： #vmo -o maxperm%=80 -o minperm%=20 Setting minperm% to 20 Setting maxperm% to 80

在AIX 5.2之前的版本请使用/usr/samples/kernel/vmtune命令。

#/usr/samples/kernel/vmtune -p 20–P 80 将min和max的值分别设置为20％和80％。

查看当前的参数设置方法如下： 1）vmo –a 显示当前所有的参数设置

在AIX 5.2之前的版本请使用 # /usr/samples/kernel/vmtune 显示当前所有的参数设置 #vmo -a

cpu_scale_memp = 8 data_stagger_interval = 161 defps = 1 force_relalias_lite = 0 framesets = 2 htabscale = n/a kernel_heap_psize = 4096 large_page_heap_size = 0 lgpg_regions = 0 lgpg_size = 0 low_ps_handling = 1 lru_file_repage = 1 lru_poll_interval = 10

lrubucket = 131072 maxclient% = 80 maxfree = 1088

maxperm = 4587812 maxperm% = 80 maxpin = 4881650 maxpin% = 80 mbuf_heap_psize = 4096 memory_affinity = 1

memory_frames = 6029312 memplace_data = 2 memplace_mapped_file = 2 memplace_shm_anonymous = 2 memplace_shm_named = 2 memplace_stack = 2 memplace_text = 2 memplace_unmapped_file = 2 mempools = 4 minfree = 960

minperm = 1146952 minperm% = 20 nokilluid = 0

npskill = 49152 npsrpgmax = 393216 npsrpgmin = 294912 npsscrubmax = 393216 npsscrubmin = 294912 npswarn = 196608 num_spec_dataseg = 0

numpsblks = 6291456 page_steal_method = 0 pagecoloring = n/a

pinnable_frames = 5601758 pta_balance_threshold = n/a relalias_percentage = 0 rpgclean = 0 rpgcontrol = 2 scrub = 0 scrubclean = 0 soft_min_lgpgs_vmpool = 0 spec_dataseg_int = 512 strict_maxclient = 1 strict_maxperm = 0 v_pinshm = 0 vm_modlist_threshold = -1 vmm_fork_policy = 1 vmm_mpsize_support = 1 2）vmstat -v # vmstat -v

6029312 memory pages 5734766 lruable pages 2801540 free pages 4 memory pools 406918 pinned pages

80.0 maxpin percentage 20.0 minperm percentage 80.0 maxperm percentage 2.3 numperm percentage 135417 file pages

0.0 compressed percentage 0 compressed pages 0.0 numclient percentage 80.0 maxclient percentage 0 client pages

0 remote pageouts scheduled

312417 pending disk I/Os blocked with no pbuf 0 paging space I/Os blocked with no psbuf 2878 filesystem I/Os blocked with no fsbuf

0 client filesystem I/Os blocked with no fsbuf

0 external pager filesystem I/Os blocked with no fsbuf

显示minperm和maxperm和numperm的值。numperm值给出的是内存中文件页数。 系统调页的规则：

1) 如果numperm>maxperm，则只调出文件页面。

2) 如果numperm

3) 如果minperm

如果系统在向调页空间调出页面，可能使因为内存中的文件页数低于maxperm，从而也调出了部分的计算页面以达到maxfree的要求。在这种情况下，可以考虑把maxperm降低到低于numperm的某个值，从而阻止计算页面的调出。在5.2 ML4以后的版本中，为了防止计算页面被调出，可以采用另外一个方法，就是设置参数lru_file_repage=0。将该参数设为0，则告诉vmm在进行页面替换的时候，优先替换文件页面。 maxclient通常应该设置为一个小于或者等于maxperm的值。

增强JFS文件系统为它的缓冲区高速缓存使用客户机文件，这不受maxperm和minperm的影响。为了在限制增强JFS文件系统使用高速缓存，可以指定maxclient的值，避免在它进行页面替换的时候，替换其他类型的页。

2、使用vmstat确定内存的使用情况

主要检查vmstat输出的 memory和pages列和faults列。详细的说明见前一节cpu评估说明。

3、svmon命令

# svmon -G -i 2 2

size inuse free pin virtual

memory 2097136 236845 1860291 152150 194943 pg space 1048576 960

work pers clnt lpage pin 151904 246 0 0 in use 194960 41885 0 0

size inuse free pin virtual

memory 2097136 236853 1860283 152150 194947 pg space 1048576 960

work pers clnt lpage pin 151904 246 0 0 in use 194964 41889 0 0

memory段

? size 物理内存总页数。4KB/页

? inuse 物理内存中正在使用的内存页面数。包含活动进程和已经终止的进程的持久文件页面。 ? free 空闲列表中的页面数量

? pin 锁定在内存中的页面数量（锁定的意思就是不能被替换出去） ? virtual pg space段

? size 调页空间总大小

? inuse 已经分配页的总数，也就是已经使用的调页空间页数 pin段

? work 物理内存中的工作页面数 ? pers 物理内存中的持久页面数

? clnt 物理内存中的客户机页面数（客户机页面就是一个远程文件页面）

inuse段

? work 物理内存中的工作页面数 ? pers 物理内存中的持久页面数

? clnt 物理内存中的客户机页面数（客户机页面就是一个远程文件页面）

3、ps命令显示当前运行的进程状态信息。

运行下列命令，显示内存占用前10位的进程。 # ps gv |sort +6b -nr |head -10

2490538 - A 191:56 0 11840 32748 xx 45762 20924 0.1 0.0 ora_j00 2039970 - A 592:59 11 11728 32648 xx 45762 20924 0.3 0.0 ora_j00 2588922 - A 1118:31 22 11712 32632 xx 45762 20924 0.6 0.0 ora_j0 2523168 - A 305:01 1 11688 32608 xx 45762 20924 0.2 0.0 ora_j00 2474214 - A 0:01 0 11588 32512 xx 45762 20924 0.1 0.0 ora_j00 2007282 - A 0:01 0 10384 31308 xx 45762 20924 0.0 0.0 ora_j00 508120 - A 32:58 662 9344 27164 xx 45762 20924 0.0 0.0 ora_dbw 1351908 - A 0:02 1 5668 26560 xx 45762 20924 0.0 0.0 oracleo 3801250 - A 203:22 0 5648 26556 xx 45762 20924 0.1 0.0 oracleo 3915976 - A 0:00 0 5664 26556 xx 45762 20924 0.0 0.0 oracleo

如果是oracle的一些进程占用了过度的内存，我们也可以通过前面类似的进程处理方法来分析。

4、内存的调整

具体调整需要结合系统运行的应用程序对症下药，如调整minperm/maxperm将改变内存与PAGING SPACE之间的交换算法，调整minpgahead/maxpgahead将改变内存块请求机制，调整minfree/maxfree将改变内存紧张时的内存清理刷新机制，等等。如果数据库使用裸设备，并且没有太多其他的应用，因为裸设备不需要文件系统的缓存，所以可以降低minperm，maxperm，maxclient的默认值，降低操作系统对内存的不必要的占用。 案例：

计费数据库数据库响应变慢，内存16G，裸设备，却存在很多的PI,PO情况。 在检查与内存相关的系统参数，发现如下问题：

minperm% = 20， maxperm% = 80， maxclient% = 80

说明：以上三个参数为系统缺省配置，其表示，使用文件系统时，最多可使用80% * 16G=10.8G，用于缓存所访问的文件。

结论：由于以上参数采用系统缺省配置，文件系统缓存最大可以达到10.8G,在执行大量的文件cp操作后，系统的可用内存量迅速下降，在其后的计费过程中，由于大量page in/page out操作引起系统严重性能瓶颈。

优化：

将maxperm% = 30 ，maxclient% = 30 #vmo –o maxperm%=30 –P #vmo –o maxclient%=30 –P 5.2以前版本

/usr/samples/kernel/vmtune –p 20 –P 30 /usr/samples/kernel/vmtune –t 30

三、磁盘的I/O性能评估

对磁盘IO的性能考虑：

1) 将频繁访问的文件系统和裸设备应尽可能放置在不同的磁盘上。

2) 在建立逻辑卷时尽可能使用mklv的命令开关给不同的文件系统和裸设备赋予不同的内策略。

3) 使用磁盘设备驱动适配器的功能属性构建合适的RAID方式,以获得更高的数据安全性和存取性能。一般考虑采用

RAID5或者RAID10方式，对于写要求比较高的系统，一般建议采用RAID10方式;关于RAID10 与RAID 5的比较，可以见piner的文章，作为补充我会在后面贴出。

4) 尽可能利用内存读写带宽远比直接磁盘I/O操作性能优越的特点,使频繁访问的文件或数据置于内存中进行操作处

理;

在这里，顺带提一下裸设备以及文件系统的对比。 裸设备的优点：

1) 由于旁路了文件系统缓冲器而进行直接读写，从而具有更好的性能。对硬盘的直接读写就意味着取消了硬盘与文

件系统的同步需求。这一点对于纯OLTP系统非常有用，因为在这种系统中，读写的随机性非常大以至于一旦数据被读写之后，它们在今后较长的一段时间内不会得到再次使用。除了OLTP，raw设备还能够从以下几个方面改善DSS应用程序的性能：

排序：对于DSS环境中大量存在的排序需求，raw设备所提供的直接写功能也非常有用，因为对临时表空间的写动作速度更快。

序列化访问：raw设备非常适合于序列化I/O动作。同样地，DSS中常见的序列化I/O（表/索引的完全扫描）使得raw设备更加适用于这种应用程序。

2) 直接读写，不需要经过OS级的缓存。节约了内存资源，在一定程度上避免了内存的争用。 3) 避免了操作系统的cache预读功能，减少了I/O。

4) 采用裸设备避免了文件系统的开销。比如维护I-node，空闲块等。

裸设备的缺点：

1、裸设备的空间大小管理不灵活。在放置裸设备的时候，需要预先规划好裸设备上的空间使用。还应当保留一部分裸设备以应付突发情况。这也是对空间的浪费。

2、很多备份工具软件对裸设备的支持不足，导致备份等的操作和方法比较原始、麻烦。

接下来，对于磁盘I/O的性能性能评估的方法。

1、iostat查看

#iostat 1 3

System configuration: lcpu=16 drives=11 paths=4 vdisks=0

tty: tin tout avg-cpu: % user % sys % idle % iowait

0.0 59.7 30.4 17.0 25.6 27.1

Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk1 1.0 4.0 1.0 0 4 hdisk0 0.0 4.0 1.0 0 4 hdisk2 0.0 0.0 0.0 0 0 hdisk3 0.0 0.0 0.0 0 0 dac0 0.0 14477.7 1513.4 3072 11469 dac0-utm 0.0 0.0 0.0 0 0 dac1 0.0 0.0 0.0 0 0 dac1-utm 0.0 0.0 0.0 0 0 hdisk4 74.7 4968.3 440.1 1728 3262 hdisk5 99.6 9508.4 1073.3 1344 8206 cd0 0.0 0.0 0.0 0 0

tty: tin tout avg-cpu: % user % sys % idle % iowait

0.0 904.0 29.3 10.6 28.9 31.1

Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk1 0.0 0.0 0.0 0 0 hdisk0 0.0 0.0 0.0 0 0 hdisk2 0.0 0.0 0.0 0 0 hdisk3 0.0 0.0 0.0 0 0 dac0 0.0 5956.0 492.0 1832 4124 dac0-utm 0.0 0.0 0.0 0 0 dac1 0.0 0.0 0.0 0 0 dac1-utm 0.0 0.0 0.0 0 0

hdisk4 49.0 2840.0 221.0 512 2328 hdisk5 100.0 3116.0 271.0 1320 1796 cd0 0.0 0.0 0.0 0 0

tty: tin tout avg-cpu: % user % sys % idle % iowait

0.0 898.2 41.6 8.9 21.2 28.3

Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk1 0.0 0.0 0.0 0 0 hdisk0 0.0 0.0 0.0 0 0 hdisk2 0.0 0.0 0.0 0 0 hdisk3 0.0 0.0 0.0 0 0 dac0 0.0 25695.7 2306.8 2344 23432 dac0-utm 0.0 0.0 0.0 0 0 dac1 0.0 0.0 0.0 0 0 dac1-utm 0.0 0.0 0.0 0 0 hdisk4 67.8 7908.3 542.3 712 7221 hdisk5 99.7 17787.4 1764.5 1632 16211 cd0 0.0 0.0 0.0 0 0 注意：第一个报告代表自系统启动以来所有的活动。 下面对输出的结果说明如下：

? tty TTY 的两列信息（tin 和 tou）显示了由所有 TTY 设备读写的字符数。

? avg-cpu CPU 统计信息列（% user、% sys、% idle 和 % iowait）提供了 CPU 的使用故障。如果 iostat 命令表

明 CPU 受限的情况不存在，并且 % iowait 时间大于 20%，则可能出现 I/O 或磁盘受限情况。这一情况可能在缺少实内存的情况下由过多调页产生。也有可能是由于不平衡的磁盘负载、碎片数据或应用模式而产生。 ? % tm_act 指示物理磁盘活动所占总时间的百分比（磁盘的带宽利用率），或者换句话说，磁盘请求的总时间未达到。

驱动器在数据传送和处理命令时是活动的，例如寻道至新的位置。“磁盘活动时间”百分比正比于资源争用，反比于性能。当磁盘使用率增加时，性能就下降并且响应时间就增加。一般来说，当利用率超过 70% 时，进程将等待的时间会比完成 I/O 所必需的时间更长，因为大多数 UNIX 进程在等待它们的 I/O 请求完成时会阻塞（或休眠）。查找相对空闲驱动器来说繁忙的驱动器。把数据从繁忙的驱动器中移到空闲驱动器里可以帮助减轻磁盘的瓶颈。在磁盘中调入调出页面会使 I/O 负载增加。

? Kbps指示了每秒钟多少 KB 的数据被传送（读或写）。这是在系统报告时间间隔内 Kb_read 加上 Kb_wrtn 的总

和并除以的这段时间间隔的总数的结果。

? tps 指示了每秒钟物理磁盘传送的次数。一次传送是设备驱动程序级别到物理磁盘的一次 I/O 处理请求。多重逻

辑请求可以组合成单一的磁盘 I/O 请求。传送的大小是不确定的。

? Kb_read报告了在测量间隔中总的从物理卷中读取的数据量（以 KB 为单位）。 ? Kb_wrtn显示了在测量间隔中总的写入物理卷中的数据量（以 KB 为单位）。

我们也可以针对适配器作性能评估。想知道某个适配器是否饱和，使用 iostat 命令并且把所有连接到这个适配器上的磁盘的 Kbps 数量加起来。为了获得最大的聚集性能，总的传送率（Kbps）必须在磁盘适配器的吞吐量之下。在大多数情况下，使用 70% 的吞吐量，-a 或 -A 选项会显示这些信息。 #iostat -a 1 1

System configuration: lcpu=16 drives=11 paths=4 vdisks=0

tty: tin tout avg-cpu: % user % sys % idle % iowait

0.0 59.8 20.8 7.8 34.9 36.5

Adapter: Kbps tps Kb_read Kb_wrtn sisscsia2 0.0 0.0 0 0

Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk1 0.0 0.0 0.0 0 0 hdisk0 0.0 0.0 0.0 0 0

Adapter: Kbps tps Kb_read Kb_wrtn sisscsia4 0.0 0.0 0 0

Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk2 0.0 0.0 0.0 0 0 hdisk3 0.0 0.0 0.0 0 0

Adapter: Kbps tps Kb_read Kb_wrtn fcs0 12614.7 1338.0 2160 10502

Disks: % tm_act Kbps tps Kb_read Kb_wrtn dac0 0.0 12615.7 1338.0 2160 10503 hdisk4 59.8 4255.0 405.5 752 3519 hdisk5 99.6 8359.7 932.5 1408 6983

Adapter: Kbps tps Kb_read Kb_wrtn vsa0 0.0 0.0 0 0

Disks: % tm_act Kbps tps Kb_read Kb_wrtn dac0-utm 0.0 0.0 0.0 0 0 dac1-utm 0.0 0.0 0.0 0 0

Adapter: Kbps tps Kb_read Kb_wrtn fcs2 0.0 0.0 0 0

Disks: % tm_act Kbps tps Kb_read Kb_wrtn dac1 0.0 0.0 0.0 0 0

Adapter: Kbps tps Kb_read Kb_wrtn ide0 0.0 0.0 0 0

Disks: % tm_act Kbps tps Kb_read Kb_wrtn cd0 0.0 0.0 0.0 0 0

2、sar –d查看

#sar -d 1 2

AIX jsdxh_db01 3 5 00C2C1BB4C00 10/24/07

System configuration: lcpu=16 drives=11

21:05:38 device %busy avque r+w/s Kbs/s avwait avserv

21:05:39 hdisk1 0 0.0 0 0 0.0 0.0 hdisk0 0 0.0 0 0 0.0 0.0 hdisk2 0 0.0 0 0 0.0 0.0 hdisk3 0 0.0 0 0 0.0 0.0 dac0 0 0.0 2051 20360 20.1 5.7 dac0-utm 0 0.0 0 0 0.0 0.0 dac1 0 0.0 0 0 0.0 0.0 dac1-utm 0 0.0 0 0 0.0 0.0 hdisk4 80 0.0 514 6137 1.2 5.3 hdisk5 100 2.6 1536 14223 26.4 5.9 cd0 0 0.0 0 0 0.0 0.0

21:05:40 hdisk1 0 0.0 0 0 0.0 0.0 hdisk0 0 0.0 0 0 0.0 0.0 hdisk2 0 0.0 0 0 0.0 0.0 hdisk3 0 0.0 0 0 0.0 0.0 dac0 0 0.0 1100 9835 34.0 11.8 dac0-utm 0 0.0 0 0 0.0 0.0 dac1 0 0.0 0 0 0.0 0.0 dac1-utm 0 0.0 0 0 0.0 0.0 hdisk4 84 0.1 270 2763 7.7 14.2 hdisk5 100 3.2 830 7072 42.6 11.0 cd0 0 0.0 0 0 0.0 0.0

Average hdisk1 0 0.0 0 0 0.0 0.0 hdisk0 0 0.0 0 0 0.0 0.0 hdisk2 0 0.0 0 0 0.0 0.0 hdisk3 0 0.0 0 0 0.0 0.0 dac0 0 0.0 1575 15097 27.1 8.7 dac0-utm 0 0.0 0 0 0.0 0.0 dac1 0 0.0 0 0 0.0 0.0 dac1-utm 0 0.0 0 0 0.0 0.0 hdisk4 82 0.1 392 4450 4.5 9.7 hdisk5 100 2.9 1183 10647 34.5 8.4 cd0 0 0.0 0 0 0.0 0.0 输出结果说明：

? device 设备的类型

? %busy 报告设备忙于执行传输请求所用的时间 ? avque 该段时间内未完成的请求的平均值。 ? r+w/s 进车设备的读/写传送次数。 ? blks/s 以512字节为单元的传送数 ? avwait 不执行，总是设置为 0.0 ? avserv 不执行，总是设置为 0.0

3、使用lslv –l lvname来评估逻辑卷的碎片情况

# lslv -l hd2 hd2:/usr

PV COPIES IN BAND DISTRIBUTION hdisk0 114:000:000 22% 000:042:026:000:046 输出字段说明： ? PV 物理卷名称

? Copies三个字段分别代表

在物理卷上至少包含一个物理分区（没有副本）的逻辑分区的数量 在物理卷上至少包含两个物理分区（一个副本）的逻辑分区的数量 在物理卷上至少包含三个物理分区（两个副本）的逻辑分区的数量 ? In band center分配策略占用的百分比。

? Distribution 分配在物理卷每个区域内：物理卷的外部边缘、外部中间、中间、中心和内部边缘的物理分区的数

目

对于该例中的结果说明如下：

copies显示逻辑卷hd2只复制了一份。IN BAND显示了内策略是如何遵循的。这个百分比越高，分配效率就越好。在这个示例中，有总共114个逻辑分区（LP），42个位于中部，26个位于中心，还有46个位于内边缘。in band占用22％（26/（42＋26＋46））。DISTRIBUTION显示物理分区的具体的内策略部署，格式如下：

outer-edge : outer-middle : center : inner-middle : inner-edge

关于物理卷内分配策略说明：

指定物理卷上选择物理分区时使用何种策略。五种常用的策略时边缘、内层边缘、中部、内层中部和中心。鉴于磁盘的读取方式，数据写入磁盘中心部分的寻道时间比写入外部边缘的寻道时间短。

4、lslv –p 评估物理布局

可以使用lslv –p hdiskN来查看在物理磁盘上的数据存储分布情况，同时也可以看到使用该内策略的逻辑卷以及挂载的文件系统。 #lspv -p hdisk3 hdisk3:

PP RANGE STATE REGION LV NAME TYPE MOUNT POINT 1-30 free outer edge

31-110 used outer edge ocsapplv jfs /ocsapp 111-206 used outer middle paging00 paging N/A

207-219 free outer middle 220-328 free center 329-437 free inner middle 438-546 free inner edge

5、使用 vmstat 命令评估调页空间的 I/O

# vmstat -s

43665986 total address trans. faults 30613 page ins 2956863 page outs

0 paging space page ins 0 paging space page outs 0 total reclaims

26027126 zero filled pages faults

16710 executable filled pages faults 0 pages examined by clock 0 revolutions of the clock hand 0 pages freed by the clock 5333765 backtracks 0 lock misses 0 free frame waits 0 extend XPT waits 21434 pending I/O waits 2937501 start I/Os 2937501 iodones

2723836378 cpu context switches 2176961335 device interrupts 0 software interrupts 0 traps 25243857756 syscalls 以下的“前和后”vmstat -s 的报告显示了调页活动的累计情况。请记住是 paging space page ins 和 paging space page outs 代表了真实的调页空间 I/O。这个（未限定）的 page ins 和 page outs 报告了总的由调页机制执行的 I/O，即调页空间 I/O 和普通文件 I/O。该报告已经经过编辑并且删除了和本讨论无关的信息。

# vmstat -s # before # vmstat -s # after

6602 page ins 7022 page ins 3948 page outs 4146 page outs 544 paging space page ins 689 paging space page ins 1923 paging space page outs 2032 paging space page outs 0 total reclaims 0 total reclaims

事实上在编译时产生比调页空间 page-outs 更多的 page-ins 意味着系统性能已被降至颠簸的边缘。有些页面正在重新分配空间，因为在它们完成调度前其帧已被其他所用。

6、使用filemon命令监控系统I/O

filemon 命令监控文件系统和 I/O系统事件的跟踪，并且报告一个周期内的文件和 I/O 的访问性能。监视文件系统的性能，并且报告代表逻辑文件、虚拟内存段、逻辑卷和物理卷的 I/O 活动。 语法：

filemon [ -d ] [ -i Trace_File -n Gennames_File] [ -o File] [ -O Levels] [ -P ] [ -T n] [ -u ] [ -v ]

例如：

# filemon -o fm.out -O all ; sleep 30 ; trcstop

Enter the \

[filemon: Reporting started] nlist failed. # more fm.out

Wed Oct 24 21:23:56 2007

System: AIX oracle1 Node: 5 Machine: 0058D25D4C00

Cpu utilization: 4.7%

Most Active Files

------------------------------------------------------------------------

#MBs #opns #rds #wrs file volume:inode ------------------------------------------------------------------------

0.2 1 51 0 unix /dev/hd2:30816 0.0 5 10 0 ksh.cat /dev/hd2:109023 0.0 1 2 0 cmdtrace.cat /dev/hd2:108887 0.0 1 2 0 hosts /dev/hd4:24621 0.0 1 1 0 vmstat.cat /dev/hd2:109265 输出结果保存在fm.out 中。输出字段说明如下： 最活跃的文件

? #MBs 此文件在测量间隔时间内的传送量（以 MBs 为单位）。各行按照此字段降序排列。 ? #opns 在测量周期内的文件的打开次数。 ? #rds 文件读取调用的次数 ? #wrs 文件写入调用的次数

? file 文件名称（文件路径全称在详细报告中）。

? volume:inode 文件驻留的逻辑卷和在相连文件系统总的 i-node 数目。此字段可以被用来把文件和在详细的 VM

段报告中显示的其相应的永久段关联起来。此字段对在执行过程中创建和删除的临时文件可以为空。

最活跃的段

? #MBs 此段在测量间隔时间内的传送量（以 MBs 为单位）。各行按照此字段降序排列。 ? #rpgs 从磁盘读入段中大小为 4-KB 的页面数

? #wpgs 从段中写入磁盘大小为 4-KB 的页面数（page out） ? #segid 内存段的 VMM 标识

? segtype段的类型：工作段、永久段（本地文件）、客户机段（远程文件）、页表段、系统段或者包含文件系统数据

的指定永久段。

? volume:inode 对永久段来说，包含相关文件的逻辑卷名称和文件的 i-node 数目。此字段可以被用来把段和在详细

的文件状态报告中显示的其相应的文件关联起来。对非永久段来说，此字段为空。

最活跃的逻辑卷

? util 逻辑卷使用率。

? #rblk 从逻辑卷读取的大小为 512 字节的块数。 ? #wblk 写入逻辑卷大小为 512 字节的块数。 ? KB/s 每秒钟平均传送速率，单位 KB。 ? volume 逻辑卷名称。

? description 文件系统安装点或是逻辑卷类型（paging, jfslog, boot, or sysdump）。例如，逻辑卷 /dev/hd2 是 /usr类

型；/dev/hd6 是 paging 类型以及 /dev/hd8 是 jfslog 类型。有时也可能出现被压缩的这个字眼。这意味着所有的数据在被写入磁盘前都会以 Lempel-Zev（LZ）压缩技术自动压缩，在从磁盘读取时则自动解压缩。

最活跃的物理卷

? util 物理卷使用率。

注:逻辑卷 I/O 请求在物理卷 I/O 请求前后启动。总的逻辑卷使用率将会看起来比总的物理卷使用率高。使用率用百分比表示，0.10 是指 10% 的物理卷在测量时间间隔内繁忙。 ? #rblk 从物理卷读取的大小为 512 字节的块数。 ? #wblk 写入物理卷大小为 512 字节的块数。 ? KB/s 每秒钟平均传送速率，单位 KB。 ? volume 物理卷名称。

? description 有关物理卷类型的简单描述，例如, SCSI 多媒体 CD-ROM 驱动器或 16位 SCSI 磁盘驱动器。

文件系统的安装点(mount point)及文件的i节点(inode)可与命令ncheck一起使用，来找出相对应的文件。

7、监视磁盘 I/O 的小结

一般来说，高的 % iowait 表明系统存在一个应用程序问题、缺少内存问题或低效的 I/O 子系统配置。例如，应用程序的问题可能是由于许多 I/O 请求，而不是处理许多数据。理解 I/O 瓶颈并且要清楚解决瓶颈问题的关键在于提高 I/O 子系统的效率。磁盘的灵敏度可以以几种方式出现，并具有不同的解决方法。一些典型的解决方案可能包括： ? 限制在特定的物理磁盘上活动逻辑卷和文件系统的数目。该方法是为了在所有的物理磁盘驱动器中平衡文件 I/O。 ? 在多个物理磁盘间展开逻辑卷。该方法在当有一些不同的文件被存取时特别有用。

? 为一个卷组创建多个 Journaled 文件系统（JFS）日志并且把它们分配到特定的文件系统中（最好在快速写高速缓

存驱动器中）。这对应用程序创建、删除或者修改大量文件特别是临时文件来说十分有益。

? 如果 iostat 命令的输出结果表明您的负载的 I/O 活动没有被均衡地分配到系统磁盘驱动器中，并且一个或多个磁

盘驱动器的使用率经常在 70-80 之间或更高，您就得考虑重组文件系统，例如备份和恢复文件系统以便减少碎片。碎片将引起驱动器过多地搜索并且可能产生大部分响应时间过长。

? 如果很大，I/O 增强的后台作业将涉及和相应时间交互，您可能希望激活I/O 调步。

? 如果有迹象表明一小部分文件被一次又一次地读取，您可以考虑附加的实存是否允许那些文件更加有效地缓存。 ? 如果负载的存取模式是随机占主导地位，您可能要考虑增加磁盘并把按那些随机存取的文件分布到更多的磁盘中。 ? 如果负载的存取模式是顺序占主导地位并且涉及多个磁盘驱动器，您可能要考虑增加一个或多个磁盘适配器。您

也可以适当地考虑构建一个条带状逻辑卷来适应大型并且性能关键的顺序文件。 ? 使用快速写高速缓存设备。 ? 使用异步 I/O。

8、案例

说明：这个案例不是我的，不记得在哪里找的： # sar 1 5

01:24:21 %usr %sys %wio %idle 01:24:51 46 5 28 21 01:25:21 46 5 29 20 01:25:51 47 5 30 20 01:26:21 44 5 29 22 01:26:51 45 5 28 22

Average 46 5 29 21

在CPU资源尚未耗尽的情况下,有近1/3的CPU时间在等待磁盘I/O,可以肯定系统资源调度中I/O存在瓶颈;进而监控I/O使用情况: # iostat –d hdisk3 1 10

Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk3 52.1 1086.9 262.6 1025224 1967060 hdisk3 93.0 4704.0 1121.0 636 4068 hdisk3 98.0 1236.0 294.0 400 836 hdisk3 92.0 1556.0 386.0 780 776 hdisk3 81.0 760.0 178.0 696 64 hdisk3 89.0 1032.0 252.0 824 208 hdisk3 92.0 1376.0 329.0 708 668 hdisk3 99.0 1888.0 457.0 292 1596 hdisk3 98.0 1436.0 356.0 660 776 hdisk3 94.0 1624.0 403.0 852 772 hdisk3 99.0 2412.0 589.0 724 1688

可以发现hdisk3平均访问率非常高,几乎在90%以上,但从数据传输量来看其真正的数据量并不大,约为1500Kbps,而且读写均衡,说明运行的应用程序的对磁盘访问有小数据量频繁存取的特点(其实即为电信应用中话务呼叫的应用特点);这里可以肯定的是系统整体性能的瓶颈在于hdisk3的过度访问. 更进一步分析,使用系统监控命令filemon 或 lvmstat可以获得以下信息:

#filemon –o filemon.out; sleep 30; trcstop #vi filemon.out(部分截取)

util #rblk #wblk KB/s volume description ------------------------------------------------------------------------ 1.00 91080 108112 1561.1 /dev/workdbslv1 raw 0.00 0 4072 31.9 /dev/logiclogdbslv raw 0.00 8 4384 34.4 /dev/tcom_filelv /tcom_file 0.00 0 120 0.9 /dev/hd4 / 0.00 0 144 1.1 /dev/hd2 /usr 0.00 0 88 0.7 /dev/loglv01 jfslog 0.00 0 272 2.1 /dev/tcomlv /tcom 0.00 0 32 0.3 /dev/hd8 jfslog 0.00 0 104 0.8 /dev/loglv00 jfslog 0.00 0 8 0.1 /dev/hd3 /tmp

Most Active Physical Volumes

------------------------------------------------------------------------

util #rblk #wblk KB/s volume description

------------------------------------------------------------------------

0.91 91088 116672 1628.2 /dev/hdisk3 SSA Logical Disk Drive 0.00 0 304 2.4 /dev/hdisk0 N/A

0.00 0 360 2.8 /dev/hdisk4 SSA Logical Disk Drive

hdisk3的过分繁忙是由于其中的用于放置数据库表的/dev/workdbslv1裸设备过度繁忙造成的,至此我们可以通过调整裸设备的放置策略和数据库配置参数获得更好的I/O性能: 1.建立workdbslv1时裸设备时使用如下命令调整:

# mklv -y workdbslv1 -t raw –a’c’ datavg 128 hdisk3 hdisk4

hdisk3和hdisk4为属于同一个卷组的两个7133RAID逻辑盘。指定内分配策略。

9、RAID10和RAID5的比较

这篇是piner写的，我稍微增加了点点内容。 为了方便对比，这里拿同样多驱动器的磁盘来做对比，RAID5选择3D+1P的RAID方案，RAID10选择2D+2D的RAID方案，如图：

1、安全性方面的比较

其实在安全性方面，勿须质疑，肯定是RAID10的安全性高于RAID5。我们也可以从简单的分析来得出。当盘1损坏时，对于RAID10，只有当盘1对应的镜象盘损坏，才导致RAID失效。但是对于RAID5，剩下的3块盘中，任何一块盘故障，都将导致RAID失效。

在恢复的时候，RAID10恢复的速度也快于RAID5。

2、空间利用率的比较

RAID10的利用率是50%，RAID5的利用率是75%。硬盘数量越多，RAID5的空间利用率越高。

3、读写性能方面的比较

主要分析分析如下三个过程：读，连续写，离散写。

在介绍这三个过程之前，先介绍一个特别重要的概念：cache。

cache已经是整个存储的核心所在，就是中低端存储，也有很大的cache存在，包括最简单的raid卡，一般都包含有几十，甚至几百兆的raid cache。

cache的主要作用是什么呢？体现在读与写两个不同的方面，如果作为写，一般存储阵列只要求写到cache就算完成了写操作，所以，阵列的写是非常快速的，在写cache的数据积累到一定程度，阵列才把数据刷到磁盘，可以实现批量的写入，至于cache数据的保护，一般都依赖于镜相与电池（或者是UPS）。

cache的读一样不可忽视，因为如果读能在cache中命中的话，将减少磁盘的寻道，因为磁盘从寻道开始到找到数据，一般都在6ms以上，而这个时间，对于那些密集型io的应用可能不是太理想。但是，如果cache能命中，一般响应时间则可以在1ms以内。两者应该相差3个数量级（1000倍）。

1）读操作方面的性能差异

RAID10可供读取有效数据的磁盘个数为4，RAID5可供读取有效数据的磁盘个数也为4个（校验信息分布在所有的盘

上），所以两者的读的性能应该是基本一致的。

2）连续写方面的性能差异

在连续写操作过程，如果有写cache存在，并且算法没有问题的话，RAID5比RAID10甚至会更好一些，虽然也许并没有太大的差别。（这里要假定存储有一定大小足够的写cache，而且计算校验的cpu不会出现瓶颈）。

因为这个时候的RAID校验是在cache中完成，如4块盘的RAID5，可以先在内存中计算好校验，同时写入3个数据+1个校验。而RAID10只能同时写入2个数据+2个镜相。

如上图所示，4块盘的RAID5可以在同时间写入1、2、3到cache，并且在cache计算好校验之后，这里假定是6，同时把三个数据写到磁盘。而4块盘的RAID10不管cache是否存在，写的时候，都是同时写2个数据与2个镜相。 根据前面对缓存原理的介绍，写cache是可以缓存写操作的，等到缓存写数据积累到一定时期再写到磁盘。但是，写到磁盘阵列的过程是迟早也要发生的，所以RAID5与RAID10在连续写的情况下，从缓存到磁盘的写操作速度会有较小的区别。不过，如果不是连续性的强连续写，只要不达到磁盘的写极限，差别并不是太大。

3）离散写方面的性能差异

例如oracle 数据库每次写一个数据块的数据，如8K；由于每次写入的量不是很大，而且写入的次数非常频繁，因此联机日志看起来会像是连续写。但是因为不保证能够添满RAID5的一个条带，比如32K（保证每张盘都能写入），所以很多时候更加偏向于离散写入（写入到已存在数据的条带中）。

我们从上图看一下离散写的时候，RAID5与RAID10工作方式有什么不同。如上图：我们假定要把一个数字2变成数字4，那么对于RAID5，实际发生了4次io：先读出2与校验6，可能发生读命中然后在cache中计算新的校验写入新的数字4与新的校验8。

如上图我们可以看到：对于RAID10，同样的单个操作，最终RAID10只需要2个io，而RAID5需要4个io. 这里我忽略了RAID5在那两个读操作的时候，可能会发生读命中操作的情况。也就是说，如果需要读取的数据已经在cache中，可能是不需要4个io的。这也证明了cache对RAID5 的重要性，不仅仅是计算校验需要，而且对性能的提升尤为重要。 当然，并不是说cache对RAID10就不重要了，因为写缓冲，读命中等，都是提高速度的关键所在，只不过RAID10对cache的依赖性没有RAID5那么明显而已。

4）磁盘的IOPS对比

假定一个case，业务的iops是10000，读cache命中率是30%，读iops为60%，写iops为40%，磁盘个数为120，那么分别计算在raid5与raid10的情况下，每个磁盘的iops为多少。 raid5:

单块盘的iops = (10000*(1-0.3)*0.6 + 4 * (10000*0.4))/120 = (4200 + 16000)/120 = 168

这里的10000*(1-0.3)*0.6表示是读的iops，比例是0.6，除掉cache命中，实际只有4200个iops。

4 * (10000*0.4) 表示写的iops，因为每一个写，在raid5中，实际发生了4个io，所以写的iops为16000个 为了考虑raid5在写操作的时候，那2个读操作也可能发生命中，所以更精确的计算为： 单块盘的iops = (10000*(1-0.3)*0.6 + 2 * (10000*0.4)*(1-0.3) + 2 * (10000*0.4))/120 = (4200 + 5600 + 8000)/120 = 148

计算出来单个盘的iops为148个，基本达到磁盘极限 raid10 单块盘的iops = (10000*(1-0.3)*0.6 + 2 * (10000*0.4))/120 = (4200 + 8000)/120 = 102

可以看到，因为raid10对于一个写操作，只发生2次io，所以，同样的压力，同样的磁盘，每个盘的iops只有102个，还远远低于磁盘的极限iops。

4、小结

所以要求较高的空间利用率，对安全性要求不是特别高、大文件存储的系统采用RAID5比较好。 相反，安全性要求很高，不计成本，小数据量频繁写入的系统采用RAID10的方式比较好。

四、NETWORK性能评估

网络的性能可以通过以下一些方法进行监控和优化：

1、ping命令查看网络的连通性

如果一旦发现网络发现问题，我们最常规的使用方法就是使用ping命令来检查网络的连通情况。

# ping 10.33.102.107

PING 10.33.102.107: (10.33.102.107): 56 data bytes

64 bytes from 10.33.102.107: icmp_seq=0 ttl=255 time=4 ms 64 bytes from 10.33.102.107: icmp_seq=1 ttl=255 time=0 ms 64 bytes from 10.33.102.107: icmp_seq=2 ttl=255 time=0 ms 64 bytes from 10.33.102.107: icmp_seq=3 ttl=255 time=0 ms 64 bytes from 10.33.102.107: icmp_seq=4 ttl=255 time=0 ms 64 bytes from 10.33.102.107: icmp_seq=5 ttl=255 time=0 ms 64 bytes from 10.33.102.107: icmp_seq=6 ttl=255 time=0 ms 64 bytes from 10.33.102.107: icmp_seq=7 ttl=255 time=0 ms ^C

----10.33.102.107 PING Statistics----

8 packets transmitted, 8 packets received, 0% packet loss

上面的结果中，最后一行是一个总结，0% packet loss可以检查网络的质量，丢包率。从time=0 ms，我们也可以来判断这两台主机之间网络传送的延时情况。

2、netstat –i检查网络的接口

这个命令可以用来检查网络的接口情况。 #netstat -i

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll en0 1500 link#2 0.d.60.b.98.e2 5022475 0 4643590 0 0 en0 1500 10.33.102.9 oracle1_boot 5022475 0 4643590 0 0 en2 1500 link#3 0.d.60.b.96.78 4925323 0 4515364 0 0 en2 1500 192.100.10 oracle1_stb 4925323 0 4515364 0 0 en3 1500 link#4 0.2.55.cf.4d.b9 0 0 7 0 0 en3 1500 10.0.2 oracle1 0 0 7 0 0 lo0 16896 link#1 4789337 0 4791656 0 0 lo0 16896 127 loopback 4789337 0 4791656 0 0 lo0 16896 ::1 4789337 0 4791656 0 0 对于上述的输出结果，说明如下： ? name 接口名称

? Mtu 最大传输单元，单位字节 ? Ipkts 接收到的信息包总数量

? Ierrs 接收失败的包总数，比如，畸形的信息包、校验和错误或是设备驱动程序中的缓冲空间不足。 ? Opkts 发送的信息包总数量

? Oerrs 发送失败的包总数，比如，主机连接错误或者适配器输出队列超限。 ? Coll 检测到包冲突的次数

如果Ierrs/ Ipkts超过1％，就需要通过netstat –m来检查存储器的内存使用情况。 如果Oerrs/ Opkts超过1％，就需要为这个接口增加发送队列的大小（xmt_que_size），xmt_que_size的值可以通过下面的命令来检查： #lsattr –El adapter

如果Coll/Opkts超过10％，则网络的使用率比较高，有必要重新组合或是分区，使用netstat –v或者 enstat 命令可以确定冲突的比率。

3、netstat –r检查主机的路由情况

Netstat –r可以用来检查主机的路由情况。在这里，default表示的是默认路由。在很多网络不通的时候，我们可以首先检查路由表的情况，如果路由表不存在太多的问题，可以再使用traceroute命令来检查包的传送路径，从而定位网络问题。 #netstat -r Routing tables

Destination Gateway Flags Refs Use If Exp Groups

Route Tree for Protocol Family 2 (Internet):

default 10.33.102.97 UG 316 597250728 en7 - - 10.33.102.96 jsdxh_db_svc UHSb 0 0 en7 - - => 10.33.102.96/28 jsdxh_db_svc U 195 2288404800 en7 - - jsdxh_db_svc loopback UGHS 0 635942 lo0 - - 10.33.102.111 jsdxh_db_svc UHSb 0 261 en7 - - 127/8 loopback U 44 8771083 lo0 - - 192.168.0.0 jsdxh_db01_stby UHSb 0 0 en9 - - => 192.168.0/28 jsdxh_db01_stby U 2 3781828 en9 - - jsdxh_db01_stby loopback UGHS 0 2463802 lo0 - - 192.168.0.15 jsdxh_db01_stby UHSb 0 272 en9 - -

Route Tree for Protocol Family 24 (Internet v6):

::1 ::1 UH 0 48 lo0 - -

关于输出结果的一点说明：

Destination：表示路由的目的地。Default则表示该条路由位默认路由。在有些系统上，则使用0.0.0.0来表示默认路由。 Gateway：网关

Flag：flag的字段值比较多，不一一说明。这里的U表示up。G表示路由至网关。H表示路由至主机而不是网络。S表示手工添加。b表示该路由为广播地址。

Refs：给出当前活动使用的路由数目。面向连接协议在连接持续时间内保留单独的路由，而无连接协议在发送给同一目标时获取路由。

Use：提供使用该路由发送的信息包数目的计数。

If：表示本路由利用的网络接口。其中lo0表示回环地址。En7表示以太网口7。 Exp：该字段无效。 Group：该字段无效。

下面是给出的一个traceroute示例： # traceroute 10.33.102.107

trying to get source for 10.33.102.107 source should be 10.33.102.105

traceroute to 10.33.102.107 (10.33.102.107) from 10.33.102.105 (10.33.102.105), 30 hops max outgoing MTU = 1500

1 oracle_svc (10.33.102.107) 1 ms 0 ms 0 ms

Netstat命令的其他用法，简单介绍。

Netstat –t命令可以用来检查外部链接的情况，在这里可以看到链路所使用协议，以及端口情况。 # netstat -ta |grep –v loopback | more

Active Internet connections (including servers)

Proto Recv-Q Send-Q Local Address Foreign Address (state)

tcp4 0 0 *.daytime *.* LISTEN tcp 0 0 *.ftp *.* LISTEN tcp 0 0 *.telnet *.* LISTEN tcp4 0 0 *.smtp *.* LISTEN tcp4 0 0 *.time *.* LISTEN tcp4 0 0 *.sunrpc *.* LISTEN tcp4 0 0 *.smux *.* LISTEN tcp 0 0 *.exec *.* LISTEN tcp 0 0 *.login *.* LISTEN tcp 0 0 *.shell *.* LISTEN

tcp4 0 0 *.rmc *.* LISTEN tcp4 0 0 jsdxh_db_svc.ncube-lm 10.37.131.7.iad1 ESTABLISHED tcp4 0 13 jsdxh_db_svc.ncube-lm 10.33.102.104.nicelink ESTABLISHED tcp4 0 0 jsdxh_db_svc.ncube-lm 10.33.102.104.cnrproto ESTABLISHED tcp4 0 0 jsdxh_db_svc.ncube-lm 10.33.102.104.lmsocial ESTABLISHED tcp4 0 0 jsdxh_db_svc.ncube-lm 10.34.131.74.prolink ESTABLISHED tcp4 0 0 jsdxh_db_svc.ncube-lm 10.33.102.104.icp ESTABLISHED tcp4 0 0 jsdxh_db_svc.ncube-lm 10.33.102.104.1124 ESTABLISHED tcp4 0 0 jsdxh_db_svc.ncube-lm 10.33.102.104.1125 ESTABLISHED tcp4 0 0 jsdxh_db_svc.ncube-lm 10.33.102.104.1126 ESTABLISHED tcp4 0 0 jsdxh_db_svc.ncube-lm 10.33.102.104.1127 ESTABLISHED

4、netpmon

netpmon命令用于监控与网络有关的I/0及CPU的使用情况。

以root 身份运行下面的命令，可以找出进程使用的CPU时间，以及其中与网络有关的代码使用的CPU时间： # netpmon -o /tmp/netpmon.out -O cpu -v; sleep 30; trcstop

此命令运行30 秒钟，并在/tmp目录下生成文件 netpmon.out。其中字段 CPU Time 为进程使用CPU

的时间总值，CPU%对应其百分比，Network CPU% 为进程中与网络有关的代码所占用的CPU百分比。如下所示： TIME: 30.002476450 TRACE OFF

# more /tmp/netpmon.out Wed Aug 15 16:15:15 2007

System: AIX oracle2 Node: 5 Machine: 005073CD4C00

trace -a -T 256000 -o - -j 000,000,001,002,003,005,006,106,10C,139,134,135,100,200,102,103,101,104,465,467,46A,

00A,256,255,262,26A,26B,32D,32E,2A7,2A8,351,352,320,321,30A,30B,330,331,334,335,2C3,2C4,2A4,2A5,2E6,2E7,2DA,2DB

,2EA,2EB,252,216,211

TIME: 0.000000000 TRACE ON pid 1662992 tid 0x2a8015 TIME: 30.002476450 TRACE OFF Hook counts

----------------------------- TrcOn: 1 TrcOff: 1 TrcHdr: 4 TrcTWrap: 187 Dispatch: 26204 Idle: 46017 Fork: 1 Exec: 1 Exit: 8 Flih: 25479 Resume: 82837 Slih: 10655 SlihRet: 10655 SVCEnter: 321792

SVCReturn: 321731 Createthread: 1 TrcUtil: 1001 IfEn: 9257 Socket: 113004

968836 hooks processed (incl. 1194 utility) 30.002 secs in measured interval

========================================================================

Process CPU Usage Statistics: -----------------------------

Network Process PID CPU Time CPU % CPU % ----------------------------------------------------------

oracle 1745142 1.1525 0.960 0.000

UNKNOWN 2113548 0.6105 0.509 0.000 oracle 1196136 0.5308 0.442 0.009 oracle 843984 0.3940 0.328 0.007 oracle 1548420 0.3821 0.318 0.006 oracle 1171498 0.3382 0.282 0.006 oracle 1302590 0.3291 0.274 0.005 oracle 974996 0.3278 0.273 0.005 oracle 1507490 0.3224 0.269 0.005 oracle 1253426 0.3046 0.254 0.005 oracle 892972 0.2259 0.188 0.004 oracle 1327172 0.2098 0.175 0.003 oracle 1204434 0.1992 0.166 0.003 oracle 925944 0.1913 0.159 0.003 oracle 2023594 0.1903 0.159 0.003 oracle 483440 0.1849 0.154 0.003 oracle 458788 0.1749 0.146 0.003 oracle 1859812 0.1743 0.145 0.003 oracle 721084 0.1666 0.139 0.003 …

5、其他一些常用的命令

Arp Route Ifconfig

Nslookup等等。

这些命令，在这里不再一一介绍，有兴趣的可以查看相关资料。

五、补充：关于topas的使用说明

topas命令用于监控各种系统资源，如CPU的使用情况，CPU事件和队列，内存和换页空间的使用，磁盘性能，网络性能以及NFS统计等。它还会报告指派给不同WLM类的进程对系统资源的消耗情况。它还能报告系统中最热门的进程和工作量管理器（WLM）的热门类。有关WLM类信息只有在WLM激活时才会显示。topas命令将热门进程定义为那些使用大量CPU时间的进程。topas命令没有作日志的选项，所有信息都是实时的。

topas命令利用System Performance Measurement Interface（SPMI）API获得有关信息。正是因为通过SPMI API，使系统开销保持在最小程度。topas命令使用perfstat库调用访问perfstat内核扩展。

topas命令提供了实时的对系统处理器的状态监视。它将显示系统中CPU最“敏感”的任务列表。该命令可以按CPU使用。内存使用和执行时间对任务进行排序；而且该命令的很多特性都可以通过交互式命令或者在个人定制文件中进行设定。

下面是该命令的语法格式：

topas [-d number-of-monitored-hot-disks][-h] [-i monitoring-interval_in_seconds]

[-n number-of-monitored-hot-network-interfaces] [-p number-of-monitored-hot-processes] [-w number-of-monitored-hot-WLM classes] [-c number-of-monitored-hot-CPUs] [-P|-W]

-d 指定要受监视的磁盘数目。缺省2个磁盘，在屏幕显示空间足够的情况下，全部显示。 -i 以秒为单位设置监视的时间间隔。缺省2秒。

? d 指定每两次屏幕信息刷新之间的时间间隔。当然用户可以使用s交互命令来改变之。 ? q 该选项将使top没有任何延迟的进行刷新。如果调用程序有超级用户权限，那么top将以尽可能高的优先级运行。 ? S 指定累计模式。

? s 使top命令在安全模式中运行。这将去除交互命令所带来的潜在危险。 ? i 使top不显示任何闲置或者僵死进程。 ? c 显示整个命令行而不只是显示命令名。

top命令显示的项目很多，默认值是每5秒更新一次，当然这是可以设置的。显示的各项目为：

uptime 该项显示的是系统启动时间、已经运行的时间和三个平均负载值（最近1秒，5秒，15秒的负载值）。 processes 自最近一次刷新以来的运行进程总数。当然这些进程被分为正在运行的，休眠的，停止的等很多种类。进程和状态显示可以通过交互命令t来实现。

CPU states 显示用户模式，系统模式，优先级进程（只有优先级为负的列入考虑）和闲置等各种情况所占用CPU时间的百分比。优先级进程所消耗的时间也被列入到用户和系统的时间中，所以总的百分比将大于100％。 PID（Process ID）：进程标示号。 USER：进程所有者的用户名。 PR：进程的优先级别。 NI：进程的优先级别数值。

VIRT：进程占用的虚拟内存值。 RES：进程占用的物理内存值。 SHR：进程使用的共享内存值。

S：进程的状态，其中S表示休眠，R表示正在运行，Z表示僵死状态，N表示该进程优先值是负数。

Mem 内存使用情况统计，其中包括总的可用内存，空闲内存，已用内存，共享内存和缓存所占内存的情况。 Swap 交换空间统计，其中包括总的交换空间，可用交换空间，已用交换空间。 PID 每个进程的ID。

PPID 每个进程的父进程ID。 UID 每个进程所有者的UID 。 USER 每个进程所有者的用户名。 PRI 每个进程的优先级别。 NI 该进程的优先级值。

SIZE 该进程的代码大小加上数据大小再加上堆栈空间大小的总数。单位是KB。 TSIZE 该进程的代码大小。对于内核进程这是一个很奇怪的值。 DSIZE 数据和堆栈的大小。 TRS 文本驻留大小。

D 被标记为“不干净”的页项目。

LIB 使用的库页的大小。对于ELF进程没有作用。 RES 该进程占用的物理内存的总数量，单位是KB。 SHARE 该进程使用共享内存的数量。

STAT 该进程的状态。其中S代表休眠状态；D代表不可中断的休眠状态；R代表运行状态；Z代表僵死状态；T代表停止或跟踪状态。

TIME 该进程自启动以来所占用的总CPU时间。如果进入的是累计模式，那么该时间还包括这个进程子进程所占用的时间。且标题会变成CTIME。

％CPU 该进程自最近一次刷新以来所占用的CPU时间和总时间的百分比。 ％MEM 该进程占用的物理内存占总内存的百分比。

COMMAND 该进程的命令名称，如果一行显示不下，则会进行截取。内存中的进程会有一个完整的命令行。 下面介绍在top命令执行过程中可以使用的一些交互命令。从使用角度来看，熟练的掌握这些命令比掌握选项还重要一些。这些命令都是单字母的，如果在命令行选项中使用了s选项，则可能其中一些命令会被屏蔽掉。 $#@60;空格立即刷新显示。 Ctrl+L 擦除并且重写屏幕。

h或者? 显示帮助画面，给出一些简短的命令总结说明。

k 终止一个进程。系统将提示用户输入需要终止的进程PID，以及需要发送给该进程什么样的信号。一般的终止

进程可以使用15信号；如果不能正常结束那就使用信号9强制结束该进程。默认值是信号15。在安全模式中此命令被屏蔽。

i 忽略闲置和僵死进程。这是一个开关式命令。 q 退出程序。

r 重新安排一个进程的优先级别。 S 切换到累计模式。

s 改变两次刷新之间的延迟时间。系统将提示用户输入新的时间，单位为s。如果有小数，就换算成m s。输入0值则系统将不断刷新，默认值是5 s。需要注意的是如果设置太小的时间，很可能会引起不断刷新，从而根本来不及看清显示的情况，而且系统负载也会大大增加。 f或者F 从当前显示中添加或者删除项目。 o或者O 改变显示项目的顺序。

l 切换显示平均负载和启动时间信息。 m 切换显示内存信息。

t 切换显示进程和CPU状态信息。 c 切换显示命令名称和完整命令行。 M 根据驻留内存大小进行排序。

P 根据CPU使用百分比大小进行排序。 T 根据时间/累计时间进行排序。

W 将当前设置写入~/.toprc文件中。这是写top配置文件的推荐方法。

六、主机日常检查脚本

#!/bin/sh #

# 首先载入配置文件，如果配置文件不存在，则报错退出 #

SOURCE=$HOME/config/config check_source() {

if [ -r $SOURCE ]; then . $SOURCE else

echo \ exit 1 fi } #

# 定义报表头 #

report_header() {

HOSTIP=$(ifconfig -a | sed -n '2p' |awk '{print $2}')

HOSTNAME=$(hostname)

USER=`who am i | cut -d \cat<

Hostname: $HOSTNAME User: $USER

SYSTEM CHECK REPORT =================== ! } #

# 定义日志文件存放的目录和日志文件名，将当前用户目录设置为LOG_PATH #

LOG_PATH=$(echo $HOME)

LOG_FILE=$LOG_PATH/log`date +%Y%m%d%H%M%S` #

# 备份历史文件 #

cd $LOG_PATH test -f log2007* if [ \

mv $LOG_PATH/log2007* $LOG_PATH/niyl/ >/dev/null 2>&1 else : fi

#define temp directory ,if not exist,create temp directory first. TEMP_PATH=$LOG_PATH/temp if [ -d $TEMP_PATH ];then fi #

# 载入环境设置 #

check_source #

# 输出报表头信息 #

report_header >>$LOG_FILE

# 检查 CPU的使用情况，这里使用vmstat命令

echo \

:

mkdir $TEMP_PATH else

Server: $HOSTIP

Time: $(date +%Y'-'%m'-'%d' '%H':'%M':'%S)

vmstat 1 10 | awk '{print $0;if($1 ~ /^[0-9].*/) (totalcpu+=$16);(avecpu=100-totalcpu/10)}; END {print \of

cpu is :\

cat $TEMP_PATH/cpu_info >>$LOG_FILE

cpu_used_pct=`cat $TEMP_PATH/cpu_info | grep \if [ \

echo \负载超过阀值设置，请检查系统!!\else fi #

# 内存使用监控，包括交换区的使用情况监控 ÷ # echo >>$LOG_FILE echo >>$LOG_FILE

echo \check memory useage *****************************************\cat $TEMP_PATH/cpu_info | awk '{print $0;if($1 ~ /^[0-9].*/) (totalpi+=$6)(totalpo+=$7)};\\

END {if(totalpi<10 && totalpo<10) print \负载正常!!\负载异常，请检

查系统!!\ #

# 检查磁盘空间. ÷ #

echo >>$LOG_FILE echo >>$LOG_FILE

echo \df -k >>$LOG_FILE

df -k |grep -v proc |grep -v Filesystem |awk '{x=1*$4}{print $1\

cat $TEMP_PATH/disk_info | grep -v '^#' | while read line do

item1=$(echo $line | awk -F ',' '{print $1}') item2=$(echo $line | awk -F ',' '{print $2}') item3=$(echo $line | awk -F ',' '{print $3}')

item4=$(echo $line | awk -F ',' '{print $4}' |awk -F '%' '{print $1}') item5=$(echo $line | awk -F ',' '{print $5}') item6=$(echo $line | awk -F ',' '{print $6}') item7=$(echo $line | awk -F ',' '{print $7}') if [ \

echo \磁盘$item7\\t剩余空间不足，请处理!!\else

echo \磁盘空间$item7\\t\\t使用正常!!\fi done

echo \负载正常!!\

#

# 检查磁盘的io进行监控，iostat #

echo >>$LOG_FILE echo >>$LOG_FILE

echo \iostat 1 3 >>$LOG_FILE #

# 对网络流量进行监控，在这里可以作一个主机列表，对每个主机ping检查网络是否连通。 #

echo >>$LOG_FILE echo >>$LOG_FILE

echo \netstat -i >>$LOG_FILE #

# 检查主机的告警日志 #

echo >>$LOG_FILE echo >>$LOG_FILE

echo \errpt | head -10 >>$LOG_FILE

day=`date +%D |awk -F \errpt | awk '{print $2}' | grep ^$day if [ $? -eq 0 ] ; then

echo \

report.\else

echo >>$LOG_FILE

echo \fi #

# 检查HA的运行是否正常 #

echo >>$LOG_FILE echo >>$LOG_FILE

echo \/usr/es/sbin/cluster/clstat -o > $TEMP_PATH/ha_info lssrc -g cluster >> $TEMP_PATH/ha_info cat $TEMP_PATH/ha_info >>$LOG_FILE echo >>$LOG_FILE

cat $TEMP_PATH/ha_info| grep \do

node=$(echo $line | awk '{print $1}')\echo $line |grep UP$ >/dev/null if [ \

echo \

echo \

else

>>$LOG_FILE fi done #

# 检查数据库主要的6个进程是否正常. # echo >>$LOG_FILE echo >>$LOG_FILE

echo \check oracle process *****************************************\ps -ef | grep ora_ | grep -v grep | awk -F '-' '{print $2}' | awk '{print $2}' >/$TEMP_PATH/ora_process_info ps -ef | grep ora_ | grep -v grep >>$LOG_FILE

# background process ckpt

if [ `grep ora_ckpt_ora92 $TEMP_PATH/ora_process_info` ]; then COUNT=1 else

echo \fi

# background process dbwr

if [ `grep ora_dbw0_ora92 $TEMP_PATH/ora_process_info` ]; then COUNT=$((COUNT+1)) else

echo \fi

# background process reco

if [ `grep ora_reco_ora92 $TEMP_PATH/ora_process_info` ]; then COUNT=$((COUNT+1)) else

echo \fi

# background process lgwr

if [ `grep ora_lgwr_ora92 $TEMP_PATH/ora_process_info` ]; then COUNT=$((COUNT+1)) else

echo \fi

# background process pmon

if [ `grep ora_pmon_ora92 $TEMP_PATH/ora_process_info` ]; then

COUNT=$((COUNT+1)) else

echo \fi

# background process smon

if [ `grep ora_smon_ora92 $TEMP_PATH/ora_process_info` ]; then COUNT=$((COUNT+1)) else

echo \fi

if [ \ echo >>$LOG_FILE

echo \else : fi #

# Check the oracle tablespace. #

echo >>$LOG_FILE echo >>$LOG_FILE echo

\

check

oracle

*****************************************\

#su - oracle -c sqlplus dxh/dxh < /home/guest/dxhwh/niyl/tablespace_query.sql >>$LOG_FILE sqlplus -s xxx/xxx < $TEMP_PATH/ts_info set pagesize 100 set linesize 100 col status for a10

col tablespace_name for a20 col contents for a10 col \col used for a15 col pct for a10

select d.status, d.tablespace_name,

TO_CHAR(NVL(a.bytes / 1024 /1024, 0),'99G999G990') \

TO_CHAR(NVL(a.bytes - NVL(f.bytes, 0),0)/1024/1024, '99G999G990D00') used, TO_CHAR(NVL((a.bytes - NVL(f.bytes, 0)) / a.bytes * 100, 0), '990D00')||'%' pct FROM sys.dba_tablespaces d,

(select tablespace_name, sum(bytes) bytes from dba_data_files group by tablespace_name) a, (select tablespace_name, sum(bytes) bytes from dba_free_space group by tablespace_name) f WHERE d.tablespace_name = a.tablespace_name(+) AND d.tablespace_name = f.tablespace_name(+) order by tablespace_name ; exit !EOF

tablespace

cat $TEMP_PATH/ts_info>>$LOG_FILE

cat $TEMP_PATH/ts_info |grep ONLINE |awk '{print $2\do

ts_name=$(echo $line |awk -F ':' '{print $1}') ts_total=$(echo $line |awk -F ':' '{print $2}') ts_used=$(echo $line |awk -F ':' '{print $3}')

ts_used_pct=$(echo $line |awk -F ':' '{print $4}' |awk -F '%' '{print $1}'|awk -F '.' '{print $1}') if [ \ fi done #

# Check the oracle Job. #

echo >>$LOG_FILE echo >>$LOG_FILE

echo \sqlplus -s xxx/xxx <> $LOG_FILE col job for 999 col last_date for a20 col next_date for a20 col what for a40 set linesize 120

select job,what,

to_char(last_date,'yyyy-mm-dd hh24:mi:ss') last_date, to_char(next_date,'yyyy-mm-dd hh24:mi:ss') next_date, failures from dba_jobs order by job; !!ET

sqlplus -s xxx/xxx < $TEMP_PATH/job_info col flag for a5 col rou for 99999

select 'XXX' flag,job,failures,broken,round(next_date-sysdate,2)*100 rou from dba_jobs order by job; !EOF

cat $TEMP_PATH/job_info |grep XXX |awk '{print $2,$3,$4,$5}' |while read line do

jobnum=`echo $line | awk '{print $1}'` failure=`echo $line | awk '{print $2}'` broken=`echo $line | awk '{print $3}'` round=`echo $line | awk '{print $4}'`

if [ \

if [ \

echo \`date +%Y'-'%m'-'%d' '%H':'%M':'%S`,表空间$ts_name 的剩余空间紧张,请尽快清理表空间!\echo \else

fi

fi

echo \

echo \

else

else

if [ \ fi

echo \

echo \else

done #

# Check oracle alert log. #

echo >>$LOG_FILE echo >>$LOG_FILE echo

\

check

oracle

alert

log

*****************************************\

tail -300 $ORACLE_BASE/admin/ora92/bdump/alert_ora92.log | grep -v Thread | \\ grep -v Current | grep -v \

七、案例

在这个案例中，主要重点就io这一块作分析。对于其他的，在这里就不作讨论。 应用环境：

两台P570作HA（Rotating方式），AIX 5.3 安装oracle 9206，磁阵DS4300，14块盘，6块作raid10为hdisk4，另外8块盘作raid10为hdisk5 两台P630作HA（Rotating方式），AIX 5.1 安装oracle 9206，磁阵7133 两个数据库各分担一定的功能。P570压力比较大。

性能问题：

最近，P570数据库上的数据库性能急剧下降，报表统计跑将近24个小时才能完成，严重影响白天正常的业务，给主机带来比较大的性能负担。

检查过程(主要在P570上操作)：

1、使用topas查看一下操作系统的load情况。结果没想到topas无法运行了，得到的结果如下，根本无法刷新数据。 Topas Monitor for host: jsdxh_db01 EVENTS/QUEUES FILE/TTY Thu Oct 25 13:58:32 2007 Interval: 2 Cswitch Readch Syscall Writech

Kernel | | Reads Rawin User | | Writes Ttyout Wait | | Forks Igets Idle | | Execs Namei Runqueue Dirblk Network KBPS I-Pack O-Pack KB-In KB-Out Waitqueue

PAGING MEMORY Faults Real,MB Steals % Comp Disk Busy% KBPS TPS KB-Read KB-Writ PgspIn % Noncomp PgspOut % Client PageIn

PageOut PAGING SPACE Sios Size,MB % Used NFS (calls/sec) % Free ServerV2

ClientV2 Press:

ServerV3 \ ClientV3 \2、安装nmon_aix53（操作系统为5.3），结果nmon_aix53运行也报错。 #./nmon_aix53

ERROR: Assert Failure in file=\ERROR: Reason=NULL pointer

ERROR: Expression=[[q->procs = MALLOC(sizeof(struct procentry64 ) * n )]] ERROR: errno=12

ERROR: errno means : Not enough space 3、检查进程情况

#ps -ef | wc -l

9947

竟然总共已经产生了9000多个进程。在这众多的进程中可以发现有很多的defunct进程。 #ps -ef |grep defunct | wc -l

9331

##ps -ef | grep defunct | more

root 159952 1 0 0:00 root 172052 1 0 0:00 root 225294 1 1 0:00 root 262236 1 0 0:00 root 290902 1 0 0:00

在网上随便查一下defunct，就可以知道，这是孤儿进程。已经找不到父进程，所以把init（PID 1）作为他的父进程。上面的结果中就是PPID=1。孤儿进程无法用kill -9 来清除，即使是root用户也不行，只能重启。这些孤儿进程一般情况下都是由于不当的fork ()/execve()造成的。

继续检查系统，不知道这么多的孤儿进程是哪个产生的。看一下主机系统的报错情况。 #errpt |more

IDENTIFIER TIMESTAMP T C RESOURCE_NAME DESCRIPTION

A63BEB70 1025140007 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATED A63BEB70 1025133007 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATED A63BEB70 1025130007 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATED A63BEB70 1025123007 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATED

A63BEB70 1025120007 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATED

在这里，可以看到频繁的这个报错。基本每隔半个小时报错一次。再检查详细的错误。可以定位到原来是由于一个网管监控软件造成的这个错误。基本也可以判断，由于整个软件的不当的fork调用，导致了数量惊人的孤儿进程。

现在孤儿进程的问题基本确定了，但是这个孤儿进程到目前为止，对系统造成的影响有多大？网上搜了一把，孤儿进程一般不占用内存，不占用空间，只不过是在进程列表中占了一个位置，所以并不会对系统性能产生太严重的影响。当然，如果任期发展，有可能就会使主机hang住。在这里，网管系统是以root用户运行的，进程数的限制非常大。所以，这里孤儿进程应该只是一个安全隐患，并不是对当前性能造成影响的原因。

4、检查cpu的使用情况， #vmstat 1 10

System configuration: lcpu=16 mem=23552MB

kthr memory page faults cpu ----- ----------- ------------------------ ------------ ----------- r b avm fre re pi po fr sr cy in sy cs us sy id wa

4 0 3533226 2251446 0 0 0 0 0 0 3167 323907 7321 22 9 32 37 1 0 3533229 2251443 0 0 0 0 0 0 1863 313913 4784 18 8 40 34 2 0 3533229 2251443 0 0 0 0 0 0 3004 319720 6939 19 9 35 38 Cpu的使用率基本在65％左右，wa基本在35％到40％，io等待比较严重。 5、再继续检查一下磁盘的IO情况 #iostat 1 2

System configuration: lcpu=16 drives=11 paths=4 vdisks=0

tty: tin tout avg-cpu: % user % sys % idle % iowait 0.0 60.0 26.6 9.6 38.4 25.4 Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk1 37.0 350.0 70.0 0 350 hdisk0 31.0 354.0 70.0 0 354 hdisk2 0.0 0.0 0.0 0 0 hdisk3 0.0 0.0 0.0 0 0 dac0 0.0 9780.0 1199.0 2000 7780 dac0-utm 0.0 0.0 0.0 0 0 dac1 0.0 0.0 0.0 0 0 dac1-utm 0.0 0.0 0.0 0 0 hdisk4 49.0 3141.0 389.0 520 2621 hdisk5 99.0 6639.0 810.0 1480 5159 cd0 0.0 0.0 0.0 0 0

tty: tin tout avg-cpu: % user % sys % idle % iowait 0.0 902.0 30.2 8.4 38.9 22.5 Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk1 0.0 0.0 0.0 0 0 hdisk0 0.0 0.0 0.0 0 0 hdisk2 0.0 0.0 0.0 0 0 hdisk3 0.0 0.0 0.0 0 0 dac0 0.0 13080.0 1497.0 1616 11464 dac0-utm 0.0 0.0 0.0 0 0 dac1 0.0 0.0 0.0 0 0 dac1-utm 0.0 0.0 0.0 0 0 hdisk4 63.0 3866.0 405.0 296 3570 hdisk5 100.0 9214.0 1092.0 1320 7894

cd0 0.0 0.0 0.0 0 0

在上面的两份报告中，可以发现，系统对磁盘的负载不均。Hdisk5基本上长期维持在100％，而hdisk4则基本上维持在50％左右。再检查这两个hdisk的详细情况： #lspv hdisk5

PHYSICAL VOLUME: hdisk5 VOLUME GROUP: oravg

PV IDENTIFIER: 00c2c1eb0bcfbdd4 VG IDENTIFIER 00c2c1eb00004c0000000110153a551d PV STATE: active STALE PARTITIONS: 0 ALLOCATABLE: yes PP SIZE: 64 megabyte(s) LOGICAL VOLUMES: 120 TOTAL PPs: 8718 (557952 megabytes) VG DESCRIPTORS: 1 FREE PPs: 1206 (77184 megabytes) HOT SPARE: no

USED PPs: 7512 (480768 megabytes) MAX REQUEST: 1 megabyte FREE DISTRIBUTION: 00..00..00..00..1206 USED DISTRIBUTION: 1744..1744..1743..1743..538

#lspv hdisk4

PHYSICAL VOLUME: hdisk4 VOLUME GROUP: oravg

PV IDENTIFIER: 00c2c1eb0bcfb8b3 VG IDENTIFIER 00c2c1eb00004c0000000110153a551d PV STATE: active STALE PARTITIONS: 0 ALLOCATABLE: yes PP SIZE: 64 megabyte(s) LOGICAL VOLUMES: 128 TOTAL PPs: 6538 (418432 megabytes) VG DESCRIPTORS: 2 FREE PPs: 100 (6400 megabytes) HOT SPARE: no

USED PPs: 6438 (412032 megabytes) MAX REQUEST: 1 megabyte FREE DISTRIBUTION: 00..00..00..00..100 USED DISTRIBUTION: 1308..1308..1307..1307..1208

6、检查一下内存， #lsps -a

Page Space Physical Volume Volume Group Size %Used Active Auto Type paging00 hdisk2 rootvg 12288MB 1 yes yes lv hd6 hdisk0 rootvg 12288MB 1 yes yes lv #svmon -G -i 1 5

size inuse free pin virtual memory 6029312 3780159 2249153 446200 3535574 pg space 6291456 17540

work pers clnt pin 445938 262 0 in use 3535574 244585 0

size inuse free pin virtual memory 6029312 3780168 2249144 446205 3535578 pg space 6291456 17540

这台机器内存比较大，24G物理内存，从这里看，free的空间也挺多，交换区也基本没怎么使用，在这里内存肯定不会造成问题。

查看一下参数设置情况： #vmo -a | grep perm

maxperm = 4587812 maxperm% = 80

minperm = 1146952

minperm% = 20 #vmo -a | grep client

maxclient% = 80

这里，两套系统都使用的是裸设备，这几个参数完全没必要设这么高，这会造成系统的内存争用。P570内存比较大，这种情况还没多大影响，但是在P630上，就可以看到已经比较危险了。下面是nmon输出的一个内存统计结果，可以看到物理内存已经被消耗殆尽，交换也已经使用了62.6％的空间了。但实际上这个数据库是比较空闲的，cpu使用率不超过10％，io的量基本为0，内存的消耗实际上就是被maxperm给吃了，被文件页面的缓存给占用了。这个系统就必需要调整maxperm和minperm的值，否则如果业务繁忙起来，将导致oracle和操作系统的内存争用，影响性能。

Memory

Physical PageSpace | pages/sec In Out | FileSystemCache % Used 99.4% 62.6% | to Paging Space 0.0 0.0 | Process & 13.3% % Free 0.6% 37.4% | to File System 0.0 14.2 | System 86.1% MB Used 8141.4MB 2563.9MB | Page Scans 0.0 | MB Free 50.6MB 1532.1MB | Page Cycles 0.0 | Free 0.6% Total(MB) 8191.9MB 4096.0MB | Page Steals 0.0 | ------ | Page Faults 18.9 | Total 100.0% ------------------------------------------------------------ | Min/Maxperm 1540MB( 19%) 6162MB( 75%) <--% of RAM | Min/Maxfree 120 128 Total Virtual 12.0GB | Pinned 7.1%

7、顺带再检查一下，网络基本没什么问题。 #netstat -i

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll

en7 1500 link#2 0.14.5e.c5.5d.2e 3133315897 0 2978410586 4 0 en7 1500 10.33.102.9 jsdxh_db_svc 3133315897 0 2978410586 4 0 en9 1500 link#3 0.14.5e.c5.64.b8 16814726 0 3897247 3 0 en9 1500 192.168.0 jsdxh_db01_stby 16814726 0 3897247 3 0 lo0 16896 link#1 13949555 0 13969868 0 0 lo0 16896 127 loopback 13949555 0 13969868 0 0 lo0 16896 ::1 13949555 0 13969868 0 0

从上面对数据库主机的操作系统层面的情况检查来看，大致可以判断造成问题主要应该是在io上面。尤其是hdisk5，hdisk5的io负担过重，可以考虑与分担一部分的量到hdisk4上，以平衡磁盘io，减少io等待。下面对数据库部分的分析也主要在io这一块，其他方面在这里就不作分析了。

下面对数据库部分的分析思路大致如下：找到读写最频繁读写的lv（有可能是表，索引或者其他的），分布其流量。

下面再对数据库来作分析。 1、检查了一下alert日志。

$ tail -100 alert_ora92.log |more Thu Oct 25 17:43:29 2007

Thread 1 advanced to log sequence 68444

Current log# 3 seq# 68444 mem# 0: /dev/rlv_redo13 Current log# 3 seq# 68444 mem# 1: /dev/rlv_redo16 Thu Oct 25 17:47:26 2007

Thread 1 advanced to log sequence 68445

Current log# 4 seq# 68445 mem# 0: /dev/rlv_redo11 Current log# 4 seq# 68445 mem# 1: /dev/rlv_redo14 Thu Oct 25 17:51:16 2007

Thread 1 advanced to log sequence 68446

Current log# 5 seq# 68446 mem# 0: /dev/rlv_redo12 Current log# 5 seq# 68446 mem# 1: /dev/rlv_redo15

从日志中看，redo切换的频率相当高，基本上是4分钟不到，就会作一次日志的切换操作。Redo是3个组，每组2个member，每个member 500M。

2、statspack

Top 5 Timed Events

~~~~~~~~~~~~~~~~~~ % Total Event Waits Time (s) Ela Time -------------------------------------------- ------------ ----------- -------- log file sync 483,667 84,354 64.69 db file sequential read 469,344 35,231 27.02 enqueue 82,536 5,747 4.41 CPU time 2,150 1.65 db file parallel write 11,919 1,245 .96

从top 5事件看，

日志的写入速度太慢。这需要对应用作调整，将频繁commit的改为批量提交。但是在这里我想可能更大的原因是磁盘io的原因。检查一下相关的日志文件，以及相关redo的lv情况： SQL> /

GROUP# STATUS TYPE MEMBER

---------- ------- ------- ------------------------------ 3 ONLINE /dev/rlv_redo13 3 ONLINE /dev/rlv_redo16 4 ONLINE /dev/rlv_redo11 4 ONLINE /dev/rlv_redo14 5 ONLINE /dev/rlv_redo12 5 ONLINE /dev/rlv_redo15 SQL> !

$ lslv -l lv_redo13 lv_redo13:N/A

PV COPIES IN BAND DISTRIBUTION

hdisk4 008:000:000 0% 000:000:000:000:008 $ lslv -l lv_redo16 lv_redo16:N/A

PV COPIES IN BAND DISTRIBUTION

hdisk5 008:000:000 0% 000:000:008:000:000 $ lslv -l lv_redo11 lv_redo11:N/A

PV COPIES IN BAND DISTRIBUTION

hdisk4 008:000:000 0% 008:000:000:000:000 $ lslv -l lv_redo14 lv_redo14:N/A

PV COPIES IN BAND DISTRIBUTION

hdisk5 008:000:000 0% 008:000:000:000:000 $ lslv -l lv_redo12 lv_redo12:N/A

PV COPIES IN BAND DISTRIBUTION

hdisk4 008:000:000 0% 000:000:000:000:008

$ lslv -l lv_redo15 lv_redo15:N/A

PV COPIES IN BAND DISTRIBUTION

hdisk5 008:000:000 0% 008:000:000:000:000

在这里，每个组中的两个member一个在hdisk4，一个在hdisk5，分布在磁盘的边缘。可以考虑改变一下内策略，将redo分布调整到磁盘的中间位置。因为本身是raid10的方式，或者干脆不要两个member，只使用其中的一个member，这个有可能带来其他的问题，如果非不得已，不考虑这种方法。

另外一个等待事件，顺序读。这个事件一般是由于不当的选择索引或者表的连接。但在这里，我想可能并不是这个原因，而主要还是磁盘繁重的io造成的。看一下物理读排序的SQL语句：

SQL ordered by Reads for DB: ORA92 Instance: ora92 Snaps: 47 -48 -> End Disk Reads Threshold: 1000

CPU Elapsd

Physical Reads Executions Reads per Exec %Total Time (s) Time (s) Hash Value --------------- ------------ -------------- ------ -------- --------- ---------- 170,449 206,955 0.8 33.1 279.55 20719.02 4053432766 Module: Das.exe

BEGIN p_mc_sce_addsms(:p0,:p1,:p2,:p3,:p4,:p5,:p6,:p7,:p8); END ;

142,856 233,890 0.6 27.8 74.05 9616.88 1594289970 Module: Das.exe

SELECT MAX(T.ACTIVE_FLAG), MAX(T.SECOND_NO) FROM T_MC_MCN_USERIN FO T WHERE T.USER_NO = :B1 AND T.PARTCOL_USERNO = SUBSTR(:B1 , -

3, 2) AND ROWNUM <= 1

我想，在这里我们对比cpu time和Elapsd time就可以发现，这里I/O等待的情况非常严重。当然，也可以进一步检查过程内语句的执行计划情况，看是否合理。在这里，还是来关注io的情况。

在表空间的io统计中，比较繁忙的表空间是： ->ordered by IOs (Reads + Writes) desc Tablespace

------------------------------

Av Av Av Av Buffer Av Buf Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms) -------------- ------- ------ ------- ------------ -------- ---------- ------ TBS_MCN_HIS_IDX

109,393 61 94.2 1.0 421,033 233 8,004 1.8 TBS_MCN_LOG_IDX

101,915 56 74.3 1.0 416,523 231 34,705 2.8 TBS_MCN_MAIN_IDX

110,871 61 43.9 1.0 200,902 111 15,797 1.4 TBS_MCN_MAIN_DAT

108,012 60 79.2 1.2 68,267 38 9,668 0.9

在看file io之前，先看一下hdisk4和hdisk5的各自拥有的lv情况。 #lspv -l hdisk4

hdisk4: LV NAME LPs PPs DISTRIBUTION MOUNT POINT lv_data052 64 64 00..00..64..00..00 N/A lv_data009 64 64 00..64..00..00..00 N/A lv_data053 64 64 00..00..64..00..00 N/A ?

#lspv -l hdisk5

hdisk5: LV NAME LPs PPs DISTRIBUTION MOUNT POINT lv_data143 64 64 00..00..64..00..00 N/A lv_data100 64 64 00..64..00..00..00 N/A lv_data244 64 64 00..00..00..00..64 N/A lv_data142 64 64 00..00..64..00..00 N/A lv_data099 64 64 00..64..00..00..00 N/A ?

通过观察，可以分布的大致情况是，080以上的lv基本在hdisk5中，080以下lv基本都在hdisk4中。现在再对比一下file io的统计：

根据file io的统计，去计算一下，在hdisk4和hdisk5中的物理读的数量差不多是 Hdisk4：132,578 Hdisk5：261,996

Hdisk5的io量差不多就是hdisk4的两倍。这和前面iostat的统计的结果也基本差不多。 下面几个是file io统计中最繁忙的几个lv。 TBS_MCN_LOG_IDX /dev/rlv_data096

50,938 28 74.8 1.0 209,422 116 17,496 2.6 /dev/rlv_data097

50,977 28 73.7 1.0 207,101 115 17,209 3.0

TBS_MCN_MAIN_DAT /dev/rlv_data009

15,625 9 20.6 1.0 985 1 0 /dev/rlv_data010

33,026 18 18.0 1.5 26,717 15 9,658 0.7 /dev/rlv_data091

37,009 21 118.5 1.2 38,190 21 9 107.8 /dev/rlv_data092

22,352 12 145.5 1.0 2,375 1 1 70.0

TBS_MCN_MAIN_IDX /dev/rlv_data018

26,666 15 17.6 1.0 35,333 20 4,023 1.8 /dev/rlv_data019

26,661 15 17.3 1.0 35,216 20 3,368 0.9 /dev/rlv_data020

30,600 17 17.1 1.0 93,095 52 4,274 1.1 /dev/rlv_data093

26,944 15 126.8 1.0 37,258 21 4,132 1.8

再来统计一下，表的读写情况。

select object_name,tablespace_name,value

from v$segment_statistics where statistic_name='physical reads' and owner='MCNS' order by value desc ;

OBJECT_NAME

PK_MC_MCN_USERINFO T_MC_SMS_SMSNOTI

IX_MC_SMS_SMSNOTI_SMID

IX_MC_SMS_SMSNOTI_CREATETIME PK_MC_SMS_SMSNOTI

IX_MC_SMS_SMSNOTI_SERIALID TABLESPACE_NAME TBS_MCN_MAIN_IDX TBS_MCN_LOG_DAT TBS_MCN_LOG_IDX TBS_MCN_LOG_IDX TBS_MCN_LOG_IDX TBS_MCN_LOG_IDX VALUE 66970541 51920167 29194969 28041895 26514549 25635735

PK_MC_MCN_REC IX_MCN_REC_TIME

T_MC_SMS_SMSNOTIHIS

IX_MC_SMS_SMSNOTI_STATUS IX_RECVSMLOGHIS_ORGADDR IX_MC_SMS_SMSNOTI_GETFLAG T_MC_SMS_SMSNOTIHIS T_MC_SMS_SMSNOTIHIS T_MC_SMS_SMSNOTIHIS T_MC_SMS_SMSNOTIHIS T_MC_SMS_SMSNOTIHIS T_MC_SMS_SMSNOTIHIS T_MC_SMS_SMSNOTIHIS T_MC_SMS_SMSNOTIHIS T_MC_SMS_SMSNOTIHIS T_MC_SMS_SMSNOTIHIS

TBS_MCN_MAIN_IDX 17623694 TBS_MCN_MAIN_IDX 13969248 TBS_MCN_HIS_DAT 4455853 TBS_MCN_LOG_IDX 4432880 SERVICE_HIST_IDX 4187067 TBS_MCN_LOG_IDX 3812548 TBS_MCN_HIS_DAT 3758602 TBS_MCN_HIS_DAT 3632276 TBS_MCN_HIS_DAT 3585179 TBS_MCN_HIS_DAT 3561865 TBS_MCN_HIS_DAT 3509901 TBS_MCN_HIS_DAT 3495163 TBS_MCN_HIS_DAT 3480248 TBS_MCN_HIS_DAT 3473926 TBS_MCN_HIS_DAT 3463826 TBS_MCN_HIS_DAT 3431232

通过上面的file io以及表的统计，再结合实际的业务情况，可以明确，这里最繁忙的是表空间TBS_MCN_LOG_DAT

中的表T_MC_SMS_SMSNOTI以及其上位于表空间TBS_MCN_LOG_IDX中的索引。并且，这两部分全部集中

再hdisk5上，所以后面的平衡io的优化操作就是将该表以及索引部分分布到hdisk4上。

本文来源：https://www.bwwdw.com/article/u4kw.html