AIX主机性能评估.docx

AIX主机性能评估.docx

《AIX主机性能评估.docx》由会员分享，可在线阅读，更多相关《AIX主机性能评估.docx（45页珍藏版）》请在冰豆网上搜索。

AIX主机性能评估

AIX主机性能评估

这一篇可以作为我前面发的statspack解读的姊妹篇，再进一步说明如何来观察与数据库紧密联系的主机的性能。

对于AIX主机的性能评估，主要从下面的4个方面来逐一介绍：

CPU、MEMORY、IO系统和网络这4个方面来描述。

AIX5.3主机性能评估2

一、CPU性能评估2

1、vmstat2

2、sar3

3、iostat5

4、tprof6

5、ps8

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

7、小结10

二、Memory性能评估11

1、VMM的管理简介11

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

3、svmon命令14

4、内存的调整15

三、磁盘的IO性能评估16

1、iostat查看17

2、sar–d查看20

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

4、lslv–p评估物理布局22

5、使用vmstat命令评估调页空间的IO23

6、使用filemon命令监控系统IO24

7、监视磁盘IO的小结26

8、案例26

9、RAID10和RAID5的比较28

四、NETWORK性能评估31

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

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

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

4、netpmon34

5、其他一些常用的命令36

五、补充：

关于topas的使用说明36

六、主机日常检查脚本39

脚本中包括的内容包括：

主机的cpu，memory，io，network检查；ha检查，主机告警日志；数据库表空间，告警日志，job等的检查。

更新：

七、结合oracle的一个案例

第一部分目录

一、CPU性能评估1

1、vmstat1

2、sar3

3、iostat5

4、tprof5

5、ps7

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

7、小结9

1、vmstat

使用vmstat来进行性能评估，该命令可获得关于系统各种资源之间的相关性能的简要信息。

当然我们也主要用它来看CPU的一个负载情况。

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

$vmstat12

Systemconfigurationlcpu=16mem=23552MB

kthrmemorypagefaultscpu

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

rbavmfrerepipofrsrcyinsycsussyidwa

0030919882741152000000184926129490781883

00309198927411510000002527320136561152776

对上面的命令解释如下：

Kthr段显示内容

•r列表示可运行的内核线程平均数目，包括正在运行的线程和等待CPU的线程。

如果这个数字大于CPU的数目，则表明有线程需要等待CPU。

•b列表示处在非中断睡眠状态的进程数。

包括正在等待文件系统IO的线程，或由于内存装入控制而被挂起的线程。

Memory段显示内容

•avm列表示活动虚拟内存的页面数，每页一般4KB

•fre空闲的页面数，每页一般4KB

Page段显示内容

•re–该列无效

•pi从磁盘交换到内存的交换页（调页空间）数量，4KB页。

调页空间是驻留在硬盘上的虚拟内存的一部分。

当内存使用过量时，会将溢出的工作组页面存储到调页空间中（窃取页）。

当进程访问一个窃取页时，就产生了一个缺页故障，而这一页页必须从调页空间中读入到内存中。

•po从内存交换到磁盘的交换页数量，4KB页。

如果窃取的工作也在调页空间中不存在或者已经作了修改，则写入调页空间中。

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

•fr根据页面替换算法每秒释放的页数。

当VMM页面替换例程扫描页面帧表（PageFrameTable，PFT）时，它会根据一些条件选取需要窃取的页面以补充空闲列表。

该条件中包含工作页面和计算页面，释放的页面中，计算页面不产生IO，工作页面如果数据没有发生修改，也不需要写回磁盘，也不会产生IO。

•sr根据页面替换算法每秒所检查的页数。

sr值比fr值高的越多，说明替换算法要查找可以替换的页面就越困难。

•cy每秒页面替换代码扫描了PFT多少次。

因为增加空闲列表达到maxfree值，不一定需要完全扫描PFT表，而所有vmstat输出都为整数，所以通常cy列值为0。

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

•in在该时间间隔中观测到的每秒设备中断数。

•sy在该时间间隔中观测到的每秒系统调用次数。

•cs在该时间间隔中观测到的每秒钟上下文切换次数。

Cpu段显示内容

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

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

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

•wa列详细显示了有未决本地磁盘IO时CPU空闲的时间百分比。

wa的值如果超过25%,就表明磁盘子系统可能没有被正确平衡，或者这也可能是磁盘工作负荷很重的结果。

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

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

其中的进程将要花时间在运行队列中等待。

响应时间和吞吐量会受损害。

检查cpu，我们主要关注报告中的4个cpu列和2个kthr（内核线程）列。

在上面的示例中，我们可以观察到以下几个主要的信息：

CPUIDLE比较高，比较空闲；r列为0，表明线程不存在等待；

WA值不高，说明IO压力不大；

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

空闲较多。

2、sar

第二个常用的是sar命令，但是sar会增加系统的开销。

当然有些情况下，我们使用sar比较方便。

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

#sar13

AIXjsdxh_db023500C2C1EB4C00102407

Systemconfigurationlcpu=16

175226%usr%sys%wio%idlephysc

1752271970758.00

1752281960758.01

1752291970758.02

Average1970758.01

在这里，sar命令输出的是一个整体的cpu使用情况的一个统计，统计分项目的内容也比较直观，通过名字就可以理解涵义。

这里有一点比较方便的就是，在最后一行有一个汇总的average行，作为上述统计的一个平均。

另外，补充说明一点的就是，一般来说，第一行统计信息包含了sar命令本身启动的cpu消耗，所以往往是偏高的，所以导致average值也往往是偏高一点的。

当然，这不会对结果产生多大影响。

当我们有多个cpu的时候，而程序采用的是单线程，有时候会出现一种情况，我们检查发现，cpu总体的使用率不高，但是程序响应却比较慢。

这里有可能就是单线程只使用了一个cpu，导致这个cpu100％占用，处理不过来，而其他的cpu却闲置。

这时可以对cpu分开查询，统计每个cpu的使用情况。

#sar-PALL12

AIXjsdxh_db023500C2C1EB4C00102407

Systemconfigurationlcpu=16

180330cpu%usr%sys%wio%idlephysc

18033100690310.00

15050001.00

20001000.52

30001000.48

4010990.54

50001000.46

60001000.53

70001000.47

80001000.53

90001000.47

10020980.54

110001000.46

1211580310.00

131000001.00

140001000.53

150001000.47

-1970758.01

18033200710290.00

15050001.00

20001000.52

30001000.48

4010990.54

50001000.47

60001000.52

70001000.47

80001000.53

90001000.47

10020980.54

110001000.46

1239410200.00

131000001.00

140001000.52

150001000.47

-1970757.98

Average00700300.00

15050001.00

20001000.52

30001000.48

4010990.54

50001000.46

60001000.53

70001000.47

80001000.53

90001000.47

10020980.54

110001000.46

1228480240.00

131000001.00

140001000.52

150001000.47

-1970758.00

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

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

如果希望多个采样和多个报告，可为sar命令指定一个输出文件，这样就方便多了。

将sar命令的标准输出数据定向到devnull，并将sar命令作为后台进程运行。

具体的命令格式为：

sar-A-otempsar_result.log5300devnull&

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

3、iostat

第三个可以用来使用的命令是iostat.

$iostat-t24

ttytintoutavg-cpu%user%sys%idle%iowait

0.00.00.00.199.80.1

0.081.00.00.199.90.0

0.040.50.00.0100.00.0

0.040.50.00.199.10.8

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

CPU统计信息列（%user、%sys、%idle和%iowait）提供了CPU的使用情况。

注意：

第一份报告为系统启动以来的一个累积值。

4、tprof

使用tprof命令用于统计每个进程的CPU使用情况

#tprof-xsleep30

该命令的输出结果可查看__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

ProcessPIDTIDTotalKernelUserSharedOther

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

wait409704097129982998000

wait327763277729942994000

wait245822458329852985000

wait163881638929802980000

syncd2212541557073131000

caiUxOs524540229401530030

netm737467374711000

hats_nim1671242122066510010

snmpd64598258124529111000

rpc.lockd639212172867911000

tprof704622227743710010

trclogio360524240862511000

trace1523820252314510010

clinfo1958102276094511000

sh1572938228570911000

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

Total1200011994060

ProcessFREQTotalKernelUserSharedOther

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

wait41195711957000

syncd13131000

caiUxOs130030

netm111000

hats_nim110010

snmpd64111000

rpc.lockd111000

tprof110010

trclogio111000

trace110010

clinfo111000

sh111000

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

Total151200011994060

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

在AIX5L下，你用psaux会发现有一些root的wait进程

#psauxhead-20

USERPID%CPU%MEMSZRSSTTYSTATSTIMETIMECOMMAND

oracle2663545.70.05013627524-A154035032oracleora92（LOC

root172143.10.04040-AJul042479353wait

root169463.10.04040-AJul042463359wait

root166783.10.04040-AJul042460021wait

root532743.10.04040-AJul042439754wait

root2863.10.04040-AJul042437155wait

root81963.00.04040-AJul042431240wait

root8223.00.04040-AJul042430336wait

root5543.00.04040-AJul042426150wait

root207762.70.04040-AJul042150246wait

root573722.70.04040-AJul042143931wait

root491762.70.04040-AJul042142347wait

root210442.70.04040-AJul042139824wait

root128482.70.04040-AJul042135707wait

root213122.70.04040-AJul042132426wait

root125802.70.04040-AJul042129306wait

root131162.70.04040-AJul042119547wait

oracle3446120.30.05758834976-AJul04266308ora_j000_ora92

oracle4304080.30.05590833296-AJul04222057ora_j001_ora92

wait就是CPU空闲的时候运行的空闲进程，AIX4上叫kproc。

所以这个进程占用越大，表示机器越空闲。

Wait进程的数量是由机器上的逻辑CPU的个数决定的，有几个逻辑CPU，就有几个wait进程.

5、ps

这个命令使用本身也比较复杂，在这里只介绍如何查看cpu占用最高的进程。

使用举例如下：

#psauxhead-25

USERPID%CPU%MEMSZRSSTTYSTATSTIMETIMECOMMAND

root172143.10.04040-AJul042557842wait

root169463.10.04040-AJul042541554wait

root166783.10.04040-AJul042537703wait

root532743.10.04040-AJul042517012wait

root2863.10.04040-AJul042514400wait

root81963.00.04040-AJul042508232wait

root8223.00.04040-AJul042507225wait

root5543.00.04040-AJul042503414wait

root207762.70.04040-AJul042218127wait

root573722.70.04040-AJul042211800wait

root491762.70.04040-AJul042210202wait

root210442.70.04040-AJul042207718wait

root128482.70.04040-AJul042203644wait

root213122.70.04040-AJul042199853wait

root125802.70.04040-AJul042196717wait

root131162.70.04040-AJul042186551wait

oracle3446120.30.05637233852-AJul04270730ora_j000_ora92

oracle4304080.30.05591633396-AJul04226620ora_j001_ora92

oracle3650920.20.05618433664-AJul04176558ora_j002_ora92

oracle4424300.20.05609233572-AJul04142640ora_j003_ora92

oracle3856060.10.05598433464-AJul05115917ora_j004_ora92

oracle4138560.10.05052028000-AJul2354331oracleora92（LOC

oracle1436680.10.05052828008-AJul1383321oracleora92（LOC

oracle3692300.10.05660034080-AJul0580636ora_j005_ora92

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

所以CPU最高的几个进程其实是下面的ORACLE用户的ora_j00进程，这是ORACLE的job进程。

在这里，这些进程的开销很小。

如果ORACLE的进程开销比较大，我们可以用如下的方法来查询具体的进程在干什么事情，例如我们要查询进程ora_j000_ora92，PID=344612，可以使用下面的方法：

$su–oracle

SQLsqlplus“assysdba”

SQLoradebugsetospid344612

SQLoradebugevent10046tracenamecontextforever,level8

SQLoradebugtracefile_name–这个命令我们获得输出文件的绝对路径和文件名

SQLoradebugevent10046tracenamecontextoff

$tkprofoptoracleapporacleadminora92bdumpora92_j000_344612.trctracepid.txt

$moretracepid.txt

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

另外，我们也可以执行下面的语句查看进程具体运行的SQL语句的文本：

SELECT+ORDEREDsql_textFROMv$sqltexta

WHERE（a.hash_value,a.address）IN（

SELECTDECODE（sql_hash_value,0,prev_hash_value,