AIX系统资源性能监控与分析兼工作总结.doc

AIX系统资源性能监控与分析 -兼底层性能测试工作的总结 张煜刚 前言： 在综合监控入围测试中，规范要求底层性能基于AIX环境达到入库1000/s的高性能，在此背景下，基于MQ消息传输和数据库入库效率进行性能监控和调优。性能监控包括底层c应用和java应用各个模块的性能测试及监控，并从常见的性能指标点查找和定位性能问题。在本文中就借鉴本次测试的环境和数据进行总结，并按照测试中遇到的具体细节，来介绍常用命令在不同场景下的监控效果，诸如vmstat、iostat、nmon和svmon等。一、测试环境熟悉通常aix会使用lsconf或lsdev命令来系统地列出所有资源配置，但实际工作中为了更直观，常用配置都会先看cpu、内存、交换空间和硬盘等信息，所以推荐使用以下脚本可以很方便地获取出对应数据（以103为例）-很简单地了解到CPU有3.5G，内存有30G，交换空间有30G左右。lsconf | awk $1 /System/ | $2 /Clock/ |$1 /CPU/ | $1 /LPAR/ | $1 /Memory/ | $2 /Paging/ print $0 注意，如果env中环境变量LANG为中文zh_CN，该脚本无效。但是直接使用lsconf也可以快速查找到所需的指标。1.CPU在测试之前为了确定测试环境的cpu，也可以使用nmon查看CPU主频（GHZ）和其分布格局。通常AIX系统会使用双核cpu，在nmon下首页即可显示cpu的基本配置。（nmon是基于topas的交互式工具，功能强大，可以跟踪监控，生成整体资源的性能报告，详情参考nmon说明。但本文很多应用基于交互式命令下的实时展现） 以103为例，该机器cpu有8个（是八个内核，不是八个cpu，查询cpu个数可以使用lsconf |grep Number），主频为3503MHz。同时nmon交互界面中输入C，即可显示每个cpu的实际使用率（u代表usr，s代表sys），非常直观显示当前cpu的整体负荷。2.内存操作系统内存严格分类有四种，寄存器register、高速缓存cache、物理内存RAM和交换空间swap。数据传输和查询速率会依次降低，所以任何系统都是尽量将最常用的数据保存在最高层的内存中，而出现问题最多的也就是最底层的RAM或swap,如果RAM空间不足，进程运行中会调用页面映射地址，从而导致大量cpu时间处于等待swap返回数据的状态，并且io会升高。针对内存另一个常用的概念是虚拟内存，虚拟内存属于逻辑层面的概念，在unix系统监控中常把RAM和SWAP空间统称为虚拟内存，但是针对进程占用的虚拟内存VSZ推荐学习系统原理，交换空间或虚拟内存都是基于页面交换或地址映射。首先可以查询内存的配置，以103为例，使用lsdev命令查询可以发现有内存和LR二级缓存两种，而swap是基于硬盘的空间分配的，使用lsps -a命令即可查询swap空间使用的硬盘和对应空间大小。如果查询当前swap空间使用情况，使用lsps -s即可 在性能测试中如果要查询当前swap和内存的使用情况，建议使用nmon工具，在命令行输入nmon打开交互界面后，使用m快捷键即可查询其中Physical是物理内存RAM，而交换空间swap就是PageSpace。在AIX下，内存管理通常优先使用RAM，在进程不常用达到一定阈值后，相关内存页面才会转移到swap空间中，所以页面交换就会对此进行统计。所以，换种说法，在AIX系统中，会出现RAM使用到90%而swap空余很多的情况，这也是正常的。另外需要注意下方的Min/Maxfree参数，该值表示当RAM剩余内存少于Maxfree值时（1088），就会开启vmm机制。而如果内存持续占用到剩余内存小于Minfree值时（最小空闲页链表尺寸）。系统就会偷页以填充页链表，保证有足够的内存页面。此类代价会出现CPU飙升并且有较高swap的IO使用。而且对于RAM中文件缓存空间的设置也有参数指定，下方的Maxperm参数指定了文件页面可以占用内存的上限，因为文件页面不主动释放，所以很容易造成内存的文件页面过高的占用，导致其他的应用内存使用紧张。3.硬盘 在确定测试环境的同时还要预估测试各个环节日志对应的硬盘空间，这个使用df或du命令就能简单查询出来。不在此赘述。但是要注意，在默认df命令下，数据按照512k作为一个block来统计，可以使用df -g命令获取按GB为单位列举的数据。 如果在nmon中使用d关键字，会打开在当前环境下对应硬盘的具体io操作，其中R代表读的速率，W代表写的速率和比值。4.网络首先判断所需要的环境拓扑，是否MQ服务器在本机上，是否数据库在本机上，然后确定所需网络的配置，如果MQ和数据库都在本机上运行，网络流量几乎无法使用，如果使用nmon交互式窗口，使用n即可查询配置，以及当前的流量信息。由上图可见，网络适配器有en0,en1,et1,lo0四种，前两者是1000M网卡，et1是1000M802.3无线网卡，最后lo0默认为本机。二、性能测试分析思路1.CPU性能CPU性能现象直观明了，容易监控，但是分析并定位到具体进程有些难。尤其是深入到进程运行的线程分析需要研发协助。所以需要分两部分说明1）首先是系统资源整体CPU性能监控。监控cpu可以使用即时工具观察，也可以在稳定性测试中使用诸如vmstat 10vmstatdate +%m%d%H%M.log命令后台执行来保存数据，但是该命令无法标注时间，所以推荐使用sar u 10 600sardate +%m%d%H%M.log来单独保存CPU信息。在即时监控中都默认开启vmstat和iostat，对其中CPU的参数重点关注cpu部分的usr、sys、idl和wait。如果想要直观查询各个cpu的状态，使用nmon工具下键入c即可。 使用vmstat w可以很清晰的区分不同列的范围，针对CPU主要有us、sy、id、wa，分别代表用户进程、系统进程、idle和wating状态的cpu。有的vmstat命令会加入ec和pc，其中ec是在运行共享处理器的系统上，您正使用的分配 CPU 时间多少的一个指标通常和us+sy相当，pc是消耗的共享处理器资源的百分比。其中usr比值是部署应用的实际占用，与sys相比 有较高比值，如果sys在系统忙时占用比重与usr相当甚至较高，则说明系统硬件支持能力达到瓶颈。 在cpu异常的时候还需要关注kthr下r和b，分别是当前处于运行状态和block的进程数量，idle小于15%-20%，cpu已经达到高负荷运转，此时如果进程中b的数值继续升高，说明cpu分配进程会出现等待超时，从而性能低下，此时就需要增加cpu的资源，或减少应用的并发数量。此外在使用iostat时，会在偏重硬盘活动监控的同时也会统计cpu信息 如图，在avg-cpu后续的参数与vmstat的usr、sys、idle、wait、pc和ec等指标保持一致（实践证明使用truss跟踪分析两者的命令执行都会调用内核ptx_get_cpuinfo和ptx_get_sysinfo接口返回cpu数据，故数值是一致的。） 如果在CPU升高的同时发现iostat下硬盘的tm_act比值也很高，即物理磁盘处于活动状态非常频繁，由此引起的CPU瓶颈就需要结合硬盘监控继续分析。2）其次是具体进程的CPU性能监控 如果确定系统运行期间CPU达到高负荷，性能出现瓶颈，就需要继续分析是哪个应用引起的CPU高。但是在离线的情况下，AIX不像solaris使用prstat P那样可以监控进程的性能，只能使用topas或nmon命令（nmon实际就是基于topas和top工具，但功能更强大），所以目前都是即时状态下确定有问题的资源（或者使用secureCRT工具的记录回话功能来抓屏保存，这样就能保存线程性能的历时数据）。如果出现cpu飙升，（通常会vmstat离线统计的趋势图观察到一个尖峰），当出现cpu峰值的时候，查询是否有其他异常情况，如出现底层c应用出现coredump、队列积压太大后启动硬盘io操作也会导致cpu升高，或jvm出现内存溢出的heapdump甚至死循环造成的javacore。这些都是常见导致cpu飙升的问题。但是现象之外更需要数据支持。所以在实时监控时，需要使用ps aux 或nmon下的T方式查看使用cpu最高的进程。Nmon工具下top-process有强大的分析工具，默认是基础信息主要关注PID、CPU（此处cpu是基于单核cpu的使用百分比进行的，在此状态下无sys进程的显示，故与ps的数据有差异）、Size、Char和Command，而且还在此交互窗口下通过输入1,2,3,4,5,6支持显示cpu，内存io等详情。在ps 命令下可以使用aux参数获取性能信息，除了PID外，CPU和MEM都是按照系统整体资源进行计算的百分比。而且该命令如果使用得当，可以针对PID进程号进行后台记录。当然两种方式查询不一样，ps aux会针对当前系统下所有cpu总量进行统计，所以通常显示都个位数内，而nmon下T方式（top排行），显示的各个进程所占据的单核cpu，所以显示可能超出200%，这些数据都需要结合实际环境去理解，但是相同命令得出的结果还是具有可比性，所以查看cpu最高的几个应用都是一致的。 如果确定是什么应用的cpu最高之后，就可以使用更深一步的命令来追踪。这就是接下来要讲的。3）具体进程的性能监控 a）Java应用 如果确定CPU占用最高的是java，（通常情况下也都是java应用占CPU最高）。针对java应用推荐使用jcosole或jvisualvm工具监控，该工具在AIX的64位jdk下可以获取真实的jvm占用cpu数据和GC的cpu数据。值得一提是此工具也是监控java应用内存溢出的重要工具。如下图示，即为jvisualvm工具监控效果（JDK1.6上都会自带此工具，但默认监视下只能保存最近一小时的数据），其中CPU明确显示出进程使用的趋势和gc进程的趋势，而堆内存显示在当前heap空间下实际占用的内存大小，通常情况下会伴随GC机制稳定在一个范围内。而jconsole由于JDK版本问题，在AIX上运行的java无法监控到CPU，但是针对heap的监控可以保持最长1年的数据，该日志在7*24小时中还是很有效果的。 但是以上工具都需要jmx协议支持，所以在确定监控对象后，在unix上启动java应用时，应该在其java执行参数中输入： -Dcom.sun.management.jmxremote.port=8699 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false其中port=8699就是监控当前的端口，可自行设置，在设置成功并启动java应用后（注意：必须启动java应用后才能正常获取端口并监控）。打开工具，在连接在新建连接中或远程机器的jmx连接请求中输入 03:8699，即可打开java的远程监控。在此工具下分析java应用cpu占用较高的原因需要从线程入手，此时就需要研发协助分析，是哪些线程持续运行，或持续阻塞状态。同样，对抽样器的CPU时间也需要监控，并判断是什么方法导致问题。 此后就由研发协助确定具体的问题。b）C应用 如果是C应用或perl应用，推荐使用tprof命令，该命令使用trace机制获取一定时间片内的周期。并列举出当前时间片内所有线程占用的cpu。针对C推荐使用tprof -usekj -x sleep 10 ，会在当前目录下生成f文件，保存10s内的数据。 首先会显示系统当前所有进程的CPU占用，主要关注Total，Kernel，User以及wait进程的整体占用。从kernel和user上可以查询出该进程使用系统资源和业务逻辑的比例，此处如果Sys%的比例和往常相比占有率偏高，如是可能是应用问题。在此prof文件中继续查找相关进程，针对C应用的不同子线程（或指针地址），使用cpu的数据都可以呈现，此后定位就需要研发使用源代码查询了。 同理，该tprof工具也能获取java应用的线程数据，但需要研发协助分析。优化建议-1.减少所有循环中异常的判断和变量的设置。2.减少不必要的数组排序，这对cpu消耗较大，尤其是从数据库返回的数据排序。2.内存性能 在CPU监控的同时，系统内存也是重要的性能数据，因为任何大数据量的压力测试下，每个应用都会使用不同的方式占用内存空间，在正常性能下，内存会保持一个稳定的范围，如果出现内存异常飙升，或持续上涨而导致内存不足，性能测试甚至压力测试的结果都会失败。 通常监控需要在启动测试对象前标记内存状况，启动应用后，查看日志到加载所有类和数据库连接都建立完毕后，再查看内存的剩余空间，然后执行压力测试后再监控内存，如果内存稳定在一个范围内，表示性能基本正常，如果长时间下内存不再释放，说明性能测试的内存有问题。 但是这个思路需要稳定性测试及长时间监控支持。同样针对内存需要按步骤来确定1）首先是系统资源整体内存监控 使用vmstat监控memory参数，通过历史数据查询free的变换趋势，注意其中free数据为4kb单位的block数，avm是正在使用的活动虚拟内存量（4kb的block页面数量）。由上文提到的内存分析中，在nmon中可以实时查看内存变化，并且监控max/minfree参数确定是否启动交换。仅仅监控的剩余空间还不能发现问题，我们可以使用svmon命令进一步深入，但是该命令是基于页面统计的，首先使用svmon G查询整个系统中实内存和调页空间的使用的统计信息。 如上所示，memory是RAM内存，pg space属于交换空间，在inuse中显示已占用的页面，free是剩余的页面数，此数值与vmstat基本一致。但是需要注意的是pin数值，字面是钉在内存的页面数，实际上是RAM中不能被VMM机制调用到的页面数，该值表示系统进程使用的状况。当然只是确定剩余内存被占用多少，是否始终占用还不够，还需要定位是哪些应用占用内存较多，而这部分就需要进程PS命令去概览。2）查询定位进程的内存使用 使用ps 命令监控系统进程，除了上方提供的aux参数外，还可以使用gv参数，如ps gv | head -n 1; ps gv | egrep -v RSS | sort +6b -7 -n -r 执行后，会针对所有进程的RSS进行逆序排序这里值得注意的参数有：RSS 常驻内存，即每个进程用于文本和数据段的RAM量，单位KB，。%MEM-进程使用内存的百分比，即RSS的实际量 / RAM 总量；TRS 用于进程文本段的RAM量（单位为 KB）；SIZE 为此进程（文本和数据）分配的分页空间的实际大小。确定出使用最大内存的进程后，就可以使用svmon对以上内存进行单独查询，例如41549952，是java应用，我们可以使用svmon P 41549952命令查询该进程使用的具体内存（注意此时命令执行必须使用root用户）。 实例检查进程是否有内存泄露： 输入命令:svmon P 进程ID，然后记录“Work process private”项对应的值 等待一段时间，重复运行刚才的命令:svmon P 进程ID，对照“Work process private”项对应的值有没比以前增长很多，如有可能会有泄露问题但是由于系统各项服务都有默认进程，这些真正长时间占用的内存的进程用户无法监控到的，使用ps kfl可以查询到相关信息，并在svmon中做进一步分析此外，针对java应用的内存使用，由于jvm的机制，在aix下会占用一定的内存作为jvm固定空间，所以建议使用jconsole和jvisualvm工具监控，相关操作参见性能监控的Java应用部分。 针对oracle数据库的进程，基于oracle内存分配机制，也是默认占用10G左右空间作为其分配空间，所以oracle的进程使用需要其他工具监控，这里不做赘述。 3.硬盘IO通常性能测试中，伴随内存吃紧，交换页面频率上升，硬盘IO的问题会显得更加重要，常见的IO操作都在大数据量消息传输导致日志记录频繁、队列堵塞导致文件从缓存拷贝到硬盘还有数据库大批量查询等场景时会出现。所以需要从不同方式监控和区别对待，而且很多情况下两者会同时出现，故需要区别对待。1）与交换空间有关的IO监控 在硬盘整体IO出现升高的情况下，还需要区分情况确定是什么目录或硬盘设备引起的，如果是/opt等常见目录，就和日志记录有关系，如果是在vmstat下监控到page参数有明显压力，就说明处于频繁换页中。 注意监控Page的数据，包括以下参数。pi列表示每秒钟从Paging Space置换到内存的页数。通常情况下，调页空间是驻留在磁盘上的虚拟内存的一部分。当内存过量使用时，它用作溢出。调页空间由用于存储从实内存中窃取到的工作组页面的逻辑卷组成。当进程访问一个窃取页时，产生了一个缺页故障，这一页必须从调页空间读入内存。po列表示每秒钟从内存置换到Paging Space的页数。无论什么时候窃取工作存储器的一页，如果它仍未驻留在调页空间中或已被修改，那它会被写入调页空间。如果不被再次访问，它会留在页面调度设备中直到进程终止或放弃空间。如果包含在出故障页面中的后续地址引用导致缺页故障，那么这些页面将会由系统个别调进。当一个进程正常终止，任何分配给该进程的调页空间将被释放。如果这两列持续大于零，则系统的性能瓶颈很可能是内存。fr列表示每秒钟页面置换算法释放的页数。它使用一些条件选取要窃取的页面以插入到可用内存帧的空闲列表中。sr列表示每秒钟页面置换算法检查的页数。页面替换算法在可以窃取足够的页面以满足页面替换线程的需要之前可能不得不扫描许多页面帧。cy 列表示每秒页面替换代码扫描了 PFT 多少次。我们可以看到，上面输出中I/O等待时间和等待队列都很大。从中可以推断，系统I/O大部分为内存和Paging Space的交换。当然以上数据只能获取到目前整体系统的资源，还无法定位是什么应用引起的操作导致，可以使用nmon命令下t关键字查询（选择5=I/O），查询其中Paging参数中io和other较高的应用，以此确定是否其内存出现不足。 同样在确定pid后可以是用svmon P查询定位进程的内存地址。2）与文件系统有关的IO监控通常文件系统的io监控需要定位到什么目录或硬盘下读写异常，使用iostat f 1命令即可，（注意，若iostat后不加上间隔周期的参数，命令只返回当前系统开机后整体周期io的平均值。）通常iostat可以使用管道方式保存监控结果到文件中，然后根据目录关键字进程统计。 由于目录都处于同一硬盘上，故tm_act无数据，整体硬盘的活动频率在70%以上时就说明当前io很严重了，其中最频繁的目录操作可以查询吞吐量tps分析，读入写出速率都能即时监控。 所有参数主要关注：% tm_act-表示物理磁盘处于活动状态的时间百分比（驱动器的带宽使用率），驱动器在数据传送和处理命令时是活动的，例如寻道至新的位置。“磁盘活动时间”百分比正比于资源争用，反比于性能。当磁盘使用率增加时，性能就下降并且响应时间就增加。Kbps 表示以 KB 每秒为单位的传输（读或写）到驱动器的数据量。tps 表示每秒钟输出到物理磁盘的传输次数。一次传输就是一个对物理磁盘的 I/O 请求。多个逻辑请求可被并为对磁盘的一个单一 IO 请求。传输具有不确定的大小。Kb_read 读取的 KB 总数。Kb_wrtn 写入的 KB 总数。 当定位到进程应用的方法还是和nmon相同，查询其中的Char参数即可。由此判断哪些应用使用的io最高，然后判断是否有报错信息导致大量日志引起io升高。 此外，在文件监控中还推荐使用filemon命令，该命令可以监控一定周期内所有文件的I/O状况。在当前目录下使用filemon o ./filemon.out O All启动监控后，使用trastop来结束监控，并打开生成的filemon.out文件即可分析。 首先是最活跃的文件列表，有打开和读写记录，及保存的位置节点，相关数据需要研发协助分析。 还有活跃的卷，物理空间和逻辑磁盘的列表，后续还可以分析哪些进程引起的读写较多，此时也能对照进程监控结果分析。4.网络由于本次测试中MQ传输消息是使用binding方式，无需监控network流量，故对此未有数据，但是需要简单说明一下。Netstat命令是非常常用的网络监控命令，可以使用netstat i 1生成离线的流量监控数据，并查询趋势来确定网络流量是否持续运行在最高位，（注意第一行数据是开机后到目前为止所有总数，统计前需要注意数据的单位是包pactets，不能简单转换成以kb为单位的流量。） 或者更直观的使用nmon 工具查询当前的信息，注意的参数主要有Recv和Trans，因为这些数据是以kb为单位的，方便比较。三、其他性能测试环节1.MQ队列的监控 由于底层应用的测试需要发送大量xml消息做压力，并在各个模块接收发送队列中排查传输效率的瓶颈，因此需要针对MQ的各个队列进行监控，类似于在runmqsc下执行dis ql（*.Q） curdepth通过获取到的当前队列深度来发送和接收的差异。 而且可以基于此机制针对不同队列管理器的不同队列分别监控。相关shell可以参考如下脚本。while truedoecho date +%Y-%m-%d %H:%M:%Secho DIS QL(AMT.Q) CURDEPTH|runmqsc RUWEI_QM|grep CURDEPTH(sleep 1done 但是监控的场景通常需要区分，因为在监控单独模块和整体模块测试中，使用积压消息的方式和持续加压的方式是有不同的，目前经验来看，积压消息的压力在理论上是最大压力，可以获取性能基准进行比较，但是在所有基准确定后推荐使用持续发送消息的压力来模拟真实场景。 1）单独模块收发速率的测试和监控 如果单独测试某个模块的接收速率，可以先将其接收队列消息积满，启动应用后，监控队列深度减少的趋势，即可得出该模块的接收速率。如果单独测试某个模块的发送速率，可以上一操作的同时监控该模块的发送队列，根据队列深度增长的趋势，得出该模块的发送速率。通常发送速率会小于接受速率。 2）整体所有模块队列的监控 在整体情况下监控，就需要确定哪一个队列深度是积压最快的，也就是木桶的短板，在接收队列出现堆积的情况下，该模块是否CPU和内存正常，就需要结合其进程进行查询比较了。 注：在监控队列时推荐监控队列消息转移到硬盘后的I/O和相关队列的文件大小，针对/var/mqm/qmgrs/RU_WEI/queues目录下会创建各个队列的文件保存堆积时的数据，此时使用du sm * 即可查询不同队列的大小（MB） 此外在/var/mqm/qmgrs/RU_WEI/errors目录下执行tail f AMQERR01.LOG，可以针对MQ队列的问题及时发现并定位。2.入库速率的监控针对业务场景常常有消息入库的性能测试，需要研发在入库操作中提前定义一个insert_time字段，保存入库时的当前时间。在所有测试数据发送入库并结束后，使用以下sql执行Select distinct(insert_time),count(*) from TABLE group by insert_time来确定每个入库周期的记录数，从而获取到入库的速率。注：在监控入库操作时建议做数据库性能监控，确定数据库系统服务的瓶颈。3.java应用OOM的分析在性能测试中也会发现java应用的执行目录下出现类似heapdump开头的文件，这个是aix专用JDK的heap包，使用特殊的压缩算法。如CPU章节中对java应用的描述，需要添加-Dcom.sun.management.jmxremote.port=8699 -Dcom.sun.management.jmx