AIX性能管理与监控指南

AIX性能管理与监控指南

1CPU监控1.1查看CPU消耗最高的进程以及其CPU占用情况1.2使用truss命令跟踪系统调用情况1.3使用procstack命令跟踪进程的执行栈信息1.4使用tprof命令观察系统整体CPU使用分解情况2内存监控2.1AIX内存分配回收策略介绍2.2内存分配观察示例—递增分配2.3内存分配观察示例—递减分配2.4观察系统中内存占用最高的进程（svmon方法）2.5观察系统中内存占用最高的进程（nmon方法）2.6寻找内存持续增长的进程2.7如何通过共享内存ID对应关联到该共享内存的进程2.8如何获取AIXKernel的内存使用率2.9如何判断系统是否存在内存不足3.

I/O监控3.1IO响应时间评估3.2通过nmon快速定位繁忙的磁盘

3.3通过sar/iostat命令监控繁忙磁盘3.4通过fcstat命令监控光纤卡3.5使用filemon监控IO读写情况4网络监控4.1监控网络速率4.2监控网络响应时间4.3监控网卡状态4.4监控网络连接状态4.5查看网络中数据包的重传率4.6通过netpmon监控网络读写情况5自动性能数据收集6perfpmr数据收集1CPU监控

本演示场景，主要是通过ncpu模拟应用对DLPAR分区的CPU加压；然后通过nmon观察消耗CPU最高的进程。

1.1查看CPU消耗最高的进程以及其CPU占用情况

登录AIX，运行nmon，输入“t”然后输入“2”:输出结果为占用CPU最高的各进程排序，可以看到CPU主要由rtsdb进程消耗。

1.2使用truss命令跟踪系统调用情况

如果nmon显示某些进程的系统CPU消耗很高，可以使用truss对特定进程进行跟踪分析。

跟踪共享库或者用户library调用。

示例：取得进程系统调用的统计情况，truss-c-p<pid>一段时间之后，然后Ctrl+C:

truss跟踪进程的执行，默认truss将跟踪到进程结束运行，可以Ctrl+C手工终止:

用-t选项根据具体的系统调用，如下：用-u跟踪共享库，例如libc.a:1.3使用procstack命令跟踪进程的执行栈信息

procstack可以提供类似dbx打印执行栈的功能，但不会阻塞应用执行。这可以用来辅助分析应用hang，或者锁冲突很高等等问题。

例如系统显示锁冲突很高，且主要系统CPU消耗在某进程，与此同时，如果多次procstack观察到该进程出现相同的锁调用模式，则这很可能就是触发问题的原因：1.4使用tprof命令观察系统整体CPU使用分解情况

运行tprof命令，其中-E参数指示tprof使用基于Power7PerformanceMonitorUnit(PMU)的采样方式生成剖析报告。相比默认的基于时钟的方式，基于PMU的采样方式可以提供更精确的剖析报告，尤其在某些kernel代码区域中断被关闭的情况下。-u表示userprofiling;

-s表示sharedlibraryprofiling;

-k表示kernelprofiling;

-e表示kernelextensionprofiling;

-j表示javaprofiling;

-l指示tprof报告显示函数名称时不进行截断，显示长名字;

-L用于指定应用程序的路径，例如本处rtsdb的路径为/tmp/nstress;

-t指示tprof报告按线程进行分解；-r指示生成的报告名称;

-x指示tprof运行的程序;

tprof的数据收集为该程序运行的整个生命周期;

Tip:有时tprof可能出现不显示函数名称而只看到函数地址的现象，这主要有如下几种原因：

1.未指定相关二进制程序或共享库路径，可以在tprof选项中加上：-S<应用程序所在路径:应用共享库路径>

2.二进制程序被strip过，去除了符号调试信息；建议检查去除编译脚本中的strip命令，或去除编译命令中的-s选项；或者直接按符号地址，通过dbx查询其对于函数名称：通过gencore生成相关进程的内存镜像文件，并通过dbx进行解析，如下：PS：直接通过dbx进入程序也可以直接查看函数地址，但如果需要同时查看相关数据结构的话，就需要gencore生成一份进程内存镜像了。

据此，可以看到CPU主要消耗在rtsdb进程上；而rtsdb进程的CPU消耗主要在User和Shared两部分，这两部分都对应CPU统计的usr%部分。

对tprof报告的输出部分进一步追踪可以看到，USER部分CPU主要消耗在ncpu.c的work函数：而SHARED部分CPU主要消耗在libc库的除法调用(divu64)函数：至此，我们就可以得到CPU占用率优化的方向，重点分析上述几个CPU占用率高的函数调用及其来源。注意一般而言，上述部分可能存在对应关系，例如很可能是USER部分的work函数调用了SHARED部分的__divu64函数。2内存监控

2.1AIX内存分配回收策略介绍

AIX系统为每个业务进程维护一个独立的空闲内存列表；同时采取相应的策略，使得对于该进程的内存申请/释放尽量在此空闲列表中进行。这样可以提高分配效率，不需要每次内存分配都经过系统内核。进程退出后，系统会回收该进程占用的全部内存。详情参考：/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.genprogc/doc/genprogc/sys_mem_alloc.htm

注：选择不同的分配策略时,对空闲内存空间的管理策略会有所差异。例如默认的管理结构是cartesian树；而采用watson分配算法时，使用的管理结构是红黑树。

2.2内存分配观察示例—递增分配

进程的详细内存分配情况可以使用svmon来观察，参考如下示例。需要注意，为方便svmon观察，示例代码需要在malloc之后调用memset进行初始化；因为操作系统实际上并不会立即对已申请但尚未访问到的内容分配实际存储空间，而是推迟到第一次访问时才会实际分配---这即是缺页机制的工作原理。

如下是一个申请空间递增的应用，分配/释放大小为2MB->4MB->8MB->16MB,则通过各阶段的svmon可以看到，内存页面会持续增长，从2MB一直增加到16MB（注意不是2MB+4MB+..+16MB=30MB）。

Malloc分配2MB，未初始化时：AddrRange:65534..65535AddressRange为0～512页，即代表512×4096=2MB虚拟地址空间。Virtual取值为2，表示该空间尚未实际分配。

初始化后：Virtual取值为513，表明虚存空间已经实际分配。

释放之前申请的2MB，重新申请4MB并初始化后：AddrRange:0..10241024×4096=4MB，此前释放的512页虚拟地址空间被重复利用。

释放之前申请的4MB，重新申请8MB并初始化后：AddrRange:0..2048此前释放的1024页虚拟地址空间被重复利用。

释放之前申请的8MB，重新申请16MB并初始化后：2.3内存分配观察示例—递减分配

如示例，如果是一个申请空间递减的应用，分配/释放大小为16MB->8MB->4MB->2MB,通过各阶段的svmon（svmon-nrP<pid>）可以看到，内存页面始终维持在16MB。

Malloc分配16MB，未初始化时：AddressRange为0～4096页，即代表4096×4096=16MB虚拟地址空间。Inuse/Virtual取值为2，表示该空间尚未实际分配。

初始化后：Virtual=4097页,虚拟内存已经实际分配。

释放之前申请的16MB，重新申请8MB并初始化后：释放之前申请的8MB，重新申请4MB并初始化后：释放之前申请的4MB，重新申请2MB并初始化后：可以看到svmon输出结果没有变化；原因是虽然应用调用了free释放了16MB内存，但系统的处理策略是将该内存置于进程自身的空间块树中管理。下一个8MB分配，实际上是直接从进程已有的16MB空闲块中获取的。但对系统而言，进程管理的空闲块树也对应为该进程的内存消耗，所以其内存占用没有变化。

测试代码：2.4观察系统中内存占用最高的进程（svmon方法）

后台运行3个nmem64进程：./nmem64-m2048-s3000-z80&

按进程使用的虚拟内存进行排序，显示占用最高的前三项：显示虚拟内存占用最高的3个进程的详细的内存段分布信息，如下：可以看到，消耗最多虚拟内存的段都是nmem64进程的数据段。2.5观察系统中内存占用最高的进程（nmon方法）

登录AIX，运行nmon，输入“t”然后输入“4”:

输出结果为按内存使用由高到低的进程排序。

2.6寻找内存持续增长的进程

可以使用psvg记录当前系统中各进程的内存消耗情况，然后通过比较多次psvg的结果来判断是否存在一些进程有持续的内存增长。说明：进程存在持续内存增长并不一定意味着出现了内存泄漏。由于AIX内存分配采用了访问时分配的策略，进程申请大量内存时系统并不会第一时间分配内存，而是在进程使用过程中实际访问时才进行分配。由于这种分配策略，进程在启动初期可能存在内存持续增长的可能（例如数据库缓存需要一定时间才能完全填充）；但其增长曲线应该是收敛到具体值的。

测试脚本如下：2.7如何通过共享内存ID对应关联到该共享内存的进程

在AIX系统层面，只要给定共享内存id，就可以获取attach该共享内存的进程列表，方法如下：

可以根据其共享段SID，获得相应的关联进程pid，如下。注意ipcs上看NATTACH=53，即有53个进程attach到该共享内存，因此svmon结果中，进程列表部分对应列出了53个进程pid。根据相应的pid可以获取进程的具体信息：2.8如何获取AIXKernel的内存使用率

kernel大部分内存占用采用跟普通进程一样的内存段方式组织，比如kernelheap(这部分内存消耗包含文件系统的元数据、内核扩展、第三方驱动等等),网络buffer，磁盘管理LVMbuffer占用，以及一些RAS特性的buffer占用，例如light-weightmemorytracebuffers,componenttracebuffers等等。这部分都可以通过svmon-Ss查询出（注意这条命令阻塞时间较长）。少部分采用非段方式组织的主要是AIX内存管理的元数据如页表之类。

可以通过perfpmr.sh-xmemdetails.sh获取kernel内存占用的整体情况，内存分布将输出在中。

也可以通过如下方法直接观察AIXKernel内存使用情况：1.观察AIX内存使用的命令(基于kdb，建议仅在测试环境验证)

2.建议从我们目前实验的几个系统看，超过100G的大分区，一般内核的内存占用实际都在5%以下。如果客户环境中采用了较多第三方驱动或组件，比例可能偏高一些，建议搭建环境验证一下。

此外，如果系统中存在超大的JFS2文件系统，包含大量的巨型文件（比如单个文件数十、数百GB），或者有数以十万、百万计的小文件；则可能观察到较高的JFS2元数据缓存占用，或者inode缓存占用。这部分内存消耗也会计入AIXkernel，可以通过cat/proc/sys/fs/jfs2/memory_usage观察到:

另，文件系统的元数据缓存和inode缓存可以通过如下ioo参数控制

这两个参数是比例系数，设置为400时(AIX6.1默认值)，元数据和inode缓存最多能占据系统内存的16%左右。一般而言，如果分区内存不大或者元数据相关操作不多，使用默认值（AIX7.1为200）通常是可行的。但如果分区内存足够大（比如100GB以上），元数据操作较多（可以通过观察上面的命令输出确认），则可以考虑将这两个参数设置为100，可以使得元数据和inode缓存最多占用系统内存的比例下调至4%左右。

2.9如何判断系统是否存在内存不足

预期的内存需求是virtual页面数加上文件页面数（包括pers和clnt），如果这两者之和大于实际配置的内存页面数，即可认为存在内存不足，如下示例：

3I/O监控

3.1IO响应时间评估

什么样的IO响应时间是合理的？如下是一些经验规则的总结：对于使用机械硬盘、且未配置存储同步镜像的磁阵，评估随机IO响应时间的经验规则配置同步镜像时，评估随机IO响应时间的经验规则如果使用SSD存储对于顺序IO而言，不需要担心IO服务时间，更应该关注吞吐率；

3.2通过nmon快速定位繁忙的磁盘

进入nmon报告的DISKBUSY页面，观察WAvg的取值。如果WAvg在90%以上，则可能存在磁盘热点，需要重点监控相关的磁盘。注意：Avg显示的平均值是全监控过程的平均（包括磁盘完全idle的时段）；而WAvg则是显示在监控时段且磁盘繁忙时的平均；由于nmon数据采集周期往往远远长于业务峰值时间，因此WAvg一般比Avg更有意义。如下：

3.3通过sar/iostat命令监控繁忙磁盘

可以通过sar–d或iostat–D监控繁忙磁盘，如下，其中响应时间以毫秒为单位。一般如果读平均响应时间超过15ms，写平均响应时间超过2.5ms，需要重点关注。排队时间和sqfull取值如果长期不为空，则需要判断是否队列深度设置太小(queue_depth)。说明：为方便脚本分析，一般建议在设置-D选项同时，加上-l（小写的L）和-T选项。这样对应每个hdisk的输出将在同一行显示。

3.4通过fcstat命令监控光纤卡

通过fcstat可以观察光纤卡的支持速率和运行速率，例如：#fcstatfcs0|grep-ispeed

PortSpeed(supported):8

GBIT

PortSpeed(running):

8GBIT

如果运行的速率低于实际支持的速率，则需要检查交换机与主机的链路状态是否正常。

如果显示如下两个指标持续增长(注意取值肯定是非零值，重点在于增长速度)，则需要相应的调整光纤卡的max_xfer_size和num_cmd_elems:

或使用fcstat–D判断，num_cmd_elems的取值应该大于或等于<highwatermarkofactivecommands>+<highwatermarkofpendingcommands>。比如如下例子中，可以设置num_cmd_elems为180+91=271.3.5使用filemon监控IO读写情况

可以用filemon监控lf（文件系统），lv（逻辑卷），pv（物理卷），vmm（虚拟内存管理）层面的信息，如下：#filemon-T1000000-u-Olf,lv,pv,detailed-ofmon.out

#sleep5

#trcstop

生成的filemon报告输出在fmon.out里面。

注意：如果报告中出现xxxeventslost，则说明出现了tracebuffer溢出，可以适当增加tracebuffer（由-T指定），或者缩短监控周期（从filemon到trcstop的间隔）。

3.4阅读filemon报告

可以通过filemon报告得到最忙的文件、逻辑卷以及物理卷信息，如下：也可以从filemon的Detailedreport中获得不同文件、逻辑卷、物理卷的读写情况以及响应时间：其中seeks的百分比实际上预示了IO的模式，如果seeks比例接近100%，则说明IO是随机型的。反之，如果seeks接近0，则说明IO是顺序的。

4网络监控

4.1监控网络速率

可以使用entstat–dentX命令监控网络速率，以及收发包情况，例如如下场景：#entstat-dent0|grep-ispeed

MediaSpeedSelected:Autonegotiate

MediaSpeedRunning:100Mbps,FullDuplex

External-Network-Switch(ENS)PortSpeed:100Mbps,FullDuplex

显示的网络运行速率为100Mbps；如果实际测试中网络带宽超过12.5MBps，则说明网络可能是性能瓶颈。

4.2监控网络响应时间

ping命令主要用来检查网络的连通性。从ping的结果，可以检查网络的质量、丢包率等。Ping响应的time值，可以用来判断两台主机直接的网络传送延时情况，在局域网服务器之间（大多数为万兆卡光纤连接），time值应该低于1ms.如下提供了一个脚本用于评估两台主机之间的网络延迟：

4.3监控网卡状态

同时entstat–d命令也可以监控到etherchannel网卡的流量分布状态（例如收发包以及收发带宽分布情况），以及802.3ad链路的聚合状态，例如，如下示例显示了一个802.3ad聚合成功的网卡状态：4.4监控网络连接状态

netstat是用来对网络运行进行统计观察的最常用的一个工具。netstat有很多参数，主要用的的有-in/-an/等等。使用-in选项时，需要关注Ierrs和Oerrs两栏。Ierrs表示接收失败的总包数，Oerrs表示发送失败的总包数。检查Ierrs/Ipkts超过1%时，或者Oerrs/Opkts超过1%时，此时可能要检查一下网络是否存在不稳定的情况。使用-an选项时，注意Recv-Q、Send-Q和state这三栏。Recv-Q表示接收网卡队列的排队情况，Send-Q表示网卡发送队列的排队情况。state表示网络连接的状态，一般为LISTEN或者ESTABLISH。当连接长时间处于LAST_ACK、FIN_WAIT之类的状态时，说明相关的TCP连接状态比较差，如果该TCP连接是应用程序所使用，那么需要引起注意。

4.5查看网络中数据包的重传率

netstat-s提供了TCP的相关统计数据，包括重传统计。TCP重传会触发拥塞避免算法，造成网络带宽不能得到有效利用，从而使得性能出现明显下降。尤其是retransmittimeouts，默认设置下，这类重传超时往往需要1.5