AIX 性能管理与监控建议 运维进阶.docx

目录ICPU监控1.1 查看CPU消耗最高的进程以及其CPU占用情况1.2 使用truss命令跟踪系统调用情况13使用procstack命令跟踪进程的执行栈信息1.4 使用tprof命令观察系统整体CPU使用分解情况2内存监控2.1 AlX内存分配回收策略介绍2.2 内存分配观察示例一递增分配2.3 内存分配观察示例一递减分配2.4 观察系统中内存占用最高的进程（SVmon方法）2.5 观察系统中内存占用最高的进程（nmon方法）2.6 寻找内存持续增长的进程2.7 如何通过共享内存ID对应关联到该共享内存的进程2.8 如何获取AIXKernel的内存使用率2.9 如何判断系统是否存在内存不足3.1 /0监控3.110 响应时间评估3.111 nmon快速定位繁忙的磁盘3.112 sar/iostat命令监控繁忙磁盘3.113 fcstat命令监控光纤卡3.114 filemon监控IO读写情况4网络监控4.1 监控网络速率4.2 监控网络响应时间4.3 监控网卡状态4.4 监控网络连接状态4.5 查看网络中数据包的重传率4.6 通过netpmon监控网络读写情况5自动性能数据收集6perfpmr数据收集ICPU监控本演示场景，主要是通过ncpu模拟应用对DLPAR分区的CPU加压；然后通过nmon观察消耗CPU最高的进程。1.1 查看CPU消耗最高的进程以及其CPU占用情况登录AIX,运行nmon,输入“t”然后输入“2”：9.181.159.56-PuTTY-H回国卜topasnznon-4=Top-b-RAM-useHost=aixdexnolRefregh=2secs11:0417一Mode=2I=Baslc2-CPU3=Perf4=Slze5三I06=CmdsPIDTime<CPU-Total>Child<Delca>CommandStartTotalsUser+SystemTotalTotalUsr+Sys1743263400:02:28288:58288:58+0:000:0015.915.9+0.0XTSdb1762924000:02:28286:21(286:21+0:000:009.49.4+0.0ZXSdb1658060800:03:47289:54289:54+0:000:008.58.5+0.0rcsdb1644978400:03:47285:19(285:19+0:00)0:008.3(8.3+0.0rtsdb1638424600:03:47289:53289:5340:000:008.18.1÷0.0ZTSdb1756382600:02:28290:03(290:03+0:000:008.0(8.0+0.0rtsdb1677721800:03:27285:08285:08+0:000:007.8(7.8+0.0rtsdb1821908800:02:28289:10289zl0÷0:000:007.37.3+0.0rtsdb1651532600:03:47287:48(287:48+0:000:006.8(6.8+0.0rtsdb1730156600:03:09291:03(291:03+0:000:006.86.8+0.0ZXSdb1690829800:03:09287:13287:13+0:000:006.46.4+0.0rtsdb1795691400:03:27293:04293:04+0:000:006.1(6.1+0.0rrsdb629150200:02:28290:21290:21+0:000:005.75.7+0.0XTSdb1684276000:03:09286:15(286:15+0:000:005,45.4+0.0rtsdb1736719200:03:09288:42288:42+0:000:005.25.2+0.0IXSdb1671168400:03:27288:17288zl7÷0:000:005.15.1+0.0rtadb1769481600:03:09289:27(289:27+0:000:004.9(4.9+0.0rtsdb1782584600:03:09283:33(283z33÷0:000:004.94.9+0.0rzsdb1723601600:02:28288:33288z33÷0:000:004,44.4÷0.0rtsdbS输出结果为占用CPU最高的各进程排序，可以看到CPU主要由rtsdb进程消耗。1.2 使用truss命令跟踪系统调用情况如果nmon显示某些进程的系统CPU消耗很高，可以使用truss对特定进程进行跟踪分析。truss选项解释-p<pid>指定跟踪的进程：-c对进程的系统调用情况进行统计：-d显示时间戳：-f跟踪子进程：-I在输出中显示线程id；-t(!syscall指定跟踪的系统调用名；或者用“!”排除跟踪某些系统调用；-uILibraryName.:!FunctionName.跟踪共享库或者用户Iibrary调用。跟踪共享库或者用户Iibrary调用。示例：取得进程系统调用的统计情况，t11sscp<pid>一段时间之后，然后Ctrl+C:#truss-c-pCsyscalI6619376secondscallserrorskwrite.006munmap12.0681msync24.3681mmap.0079systotaIs：.002470usrtime：.00elapsed：.00truss跟踪进程的执行，默认truss将跟踪到进程结束运行，可以CtrHC手工终止：#truss-d-Otruss.Iog-I-p6619376C#moretruss,logMonOct1516:54:36201229294829：0.0000：nap(0x00000000.4194304,PRoLREADlPROTRITE.MAP_F1LEIMAP_VARIABLEMAP_SHARED,10.29360128)=0x3040000030933087：kwrite(1,"msyncintervw.,45)=4530933087：0.0007：munmap(0x30000000,4194304)=030933087：0.0014：mmap(0x00000000.4194304,PROT_READPROT_WRITE.MAP_F1LEIMAP_VARIABLEMAP_SHARED,8.20971520)=0x3000000029294829： 0.0062：30933087： 0.2532：29294829： 0.6684：30933087： 0.6693：29294829： 0.6699：msync(0x30400000.4194304,32)=0msync(0x30000000,4194304,32)=0munmap(0x30400000,4194304)=0munmap(0x30000000.4194304)=0mmap(0x00000000,4194304.PROLREADIPROLWRHE,MAP_FILEIMAP_VARIABLEMAP_SHARED.10.29360128)=0x300000030671061：0.6702：mmap(0x00000000,4194304,PROT.READPROT-WRITE.MAP_FILElMAP_VARlABLEiMAP.SHAR印.9.25165824)=0x3040000029294829：0.6751：msync(0x30000000,4194304,32)=030671061：0.7616：msync(0x30400000.4194304,32)=0用-t选项根据具体的系统调用，如下：#truss-tmap,msync,munmap-p6619376munmap(0x30400000,4194304)=0munmap(0x31400000,4194304)=0map(0x00000000,4194304,PROLREADlPROTIRITE,MAP_FILEMAP_VARIABLEMAP_SHARED,10.29360128)=0x30400000munmap(0x30800000,4194304)=0map(0x00000000,4194304.PROT_READ|PROT-WRITE.MAP_FILEMAP_VARIABLEMAP_SHARED.8.20971520)=0x30800000munmap(0x30C00000,4194304)=0mmap(0x00000000,4194304.PRoLREADlPROTJVRITE.MAP_FILEMAP_VARIABLEMAP_SHARED,6.12582912)=0x30C00000msync(0x30800000,4194304,32)=0用跟踪共享库，例如IibC.a:#truss-uIibc.a：*-p6619376kwrite(1,wmsyncintervw.46)=46->libc.a：gettimeofday(0×200dba98,0x0)->libc.a：gettimeofday(0x200f9a90,0x0)0. OOOOOO0. OOOOOO0. OOOOOO<-1ibe.a：gettimeofday()=0munmap(0x31400000,4194304)<-1ibe.a：gettimeofday()=0->libc.a：gettimeofday(0x200f9a98,0x0)<-1ibe.a：gettimeofday()=0mmap(0x00000000.4194304.PROT_READ|PROT_WRITE,MAP_FILEMAP_VAR1ABLEMAP_SHARED.10.29360128)=0x30000000mmap(0x00000000,4194304.PROLREADlPROLWRITE.MAP_FILEMAP_VARIABLEMAP_SHARED,9.25165824)=0x30400000->libc.a：gettimeofday(0x200bda98,0x0)->libc.a：gettimeofday(0x200f9a90,0x0)1.3 使用procstack命令跟踪进程的执行栈信息PrOCStaCk可以提供类似dbx打印执行栈的功能，但不会阻塞应用执行。这可以用来辅助分析应用hang,或者锁冲突很高等等问题。例如系统显示锁冲突很高，且主要系统CPU消耗在某进程，与此同时，如果多次procstack观察到该进程出现相同的锁调用模式，则这很可能就是触发问题的原因：#procstack2143029021430290：./testsOxdO513cfO_p_nsIeep(?,?)+0x10OxdOI207e4nsleep(?,?)+0xe40xd0257288sleep(?)+0x880x10001074sig_handIer_hup(int)(0x1f)÷0x14<signal>0xd05IbbfO_cond_wait_gIobaI(?,?,?)+0x4f0OxdO51c7b4_cond_wait(?.?.?)+0x340xd051d4dcPthread_cond_wait(?,?)+Ox19c0x10000878yaSemaphore：waitO(0x2ff22a38)+0x78Ox10000f60testSemaOO+0x600x10001024main(0x1.0x2ff22c24)+0x240x100001b8_start()+0×681.4 使用tprof命令观察系统整体CPU使用分解情况运行tprof命令，其中-E参数指示tprof使用基于PoWer7PerformanceMonitorUnit(PMU)的采样方式生成剖析报告。相比默认的基于时钟的方式，基于PMU的采样方式可以提供更精确的剖析报告，尤其在某些kernel代码区域中断被关闭的情况下。- u表示USerProfning;- s表示Sharedlibraryprofiling;- k表示kernelprofiling;- e表示kernelextensionprofiling;- j表示javaprofiling;指示tprof报告显示函数名称时不进行截断，显示长名字；-L用于制定应用程序的路径，例如本处rtsdb的路径为tmpnstress;- t指示tprof报告按线程进行分解；- r指示生成的报告名称；- X指示tprof运行的程序;tprof的数据收集为该程序运行的整个生命周期；Tip:有.时tprof可能出现不显示函数名称而只看到函数地址的现象,这主要有如下几种原因：1 .未指定相关二进制程序或共享库路径，可以在tprof选项中加上：-S<应用程序所在路径:应用共享库路径2 .二进制程序被StriP过，去除了符号调试信息；建议检查去除编译脚本中的StriP命令，或去除编译痛令中的-S选项；或者直接按符号地址，通过dbx查询其对于函数名称：通过gencore生成相关进程的内存镜像文件，并通过dbx进行解析，如下：# gencore<pid>core.01# dbx<programfilenamewithfullpath>.core.01(db×)0×10000980i0x10000980(testfunc+0×20)4bfffff4b0×10000974(testfunc+0xl4)(dbx)OX100OO97"i0xl974(testfunc+0xl4)80610040Iwzr3,0x40(rl)(db×)0xl0097i0xl00978(testfunc+0xl8)38630laddir3,0xl(r3)(db×)quitPS：直接通过dbx进入程序也可以直接查看函数地址，但如果需要同时查看相关数据结构的话，就需要gencore生成一份进程内存镜像了。aixdemol:/tmp#tprof-L/tmp/nstress-uskejlt-rdemo01-×sleep15SunMar2418:00:182013System:AIX7.1Node:ai×demolMachine:00F74EA04C00StartingCommandsleep15stoppingtracecollection.Generatingdemo01.prof<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<ProcessFreqTotalKernelUserSharedOtherJava./rtsdbwaitvmmdusrsbinslp-srvregusrbintprofusrbinsleep2460.830.0017.1143.720.000.00838.7538.750.000.000.000.0010.370.370.0.000.000.10.020.020.000.0.000.10.020.010.000.010.0.0010.010.010.000.000.0.00Total36100.0039.1617.1143.730.000.00据此，可以看到CPU主要消耗在rtsdb进程上；而rtsdb进程的CPU消耗主要在USer和Shared两部分，这两部分都对应CPU统计的usr%部分。对tprof报告的输出部分进一步追踪可以看到，USER部分CPU主要消耗在ncpu.c的work函数：Total%ForAllProcesses(USER)=17.11UserProcess17.11.rtsdbProfile:.rtsdbTotal%ForAIIProcesses(.rtsdb)=17.11Subroutine% Source12.73 ncpu.c4.00 ncpu.c0.33 glink.s0.05 glink.s.work.engine.random.gettimeofday而SHARED部分CPU主要消耗在Iibc库的除法调用(divu64)函数:Total%ForAllProcesses(SH-LIBs)=43.73SharedObject43.720.01usrliblibc.a(shr.o)usrliblibc.a(shr-64.oProfile:usrliblibc.ashr.oTotal%ForAllProcesses(usrliblibc.ashr.o)=43.72Subroutine%Source._divu6427.83divu64.s.time_base_to_time6.92.,/././././././src/bos/usr/ccs/lib/libc/POWER/time_base_to_time.c.random-r3.48.,/././././././src/bos/usr/ccs/lib/libc/random.c.read_real_time2.64read_real_time.s.gettimeofday1.72././././././.srcbosusr/ccs/lib/libc/gettimeofday.c.random1.12.,/././././././src/bos/usr/ccs/lib/libc/random.c至此，我们就可以得到CPU占用率优化的方向，重点分析上述几个CPU占用率高的函数调用及其来源。注意一般而言，上述部分可能存在对应关系，例如很可能是USER部分的work函数调用了SHARED部分的_divu64函数。2内存监控2.1 AlX内存分配回收策略介绍AIX系统为每个业务进程维护一个独立的空闲内存列表；同时采取相应的策略，使得对于该进程的内存申请/释放尽量在此空闲列表中进行。这样可以提高分配效率，不需要每次内存分配都经过系统内核。进程退出后，系统会回收该进程占用的全部内存。详情参考：注：选择不同的分配策略时,对空闲内存空间的管理策略会有所差异。例如默认的管理结构是CarteSian树；而采用WatSon分配算法时，使用的管理结构是红黑树。2.2 内存分配观察示例一递增分配进程的详细内存分配情况可以使用svmon来观察，参考如下示例。需要注意，为方便SVmon观察，示例代码需要在ma11oc之后调用memset进行初始化；因为操作系统实际上并不会立即对已申请但尚未访问到的内容分配实际存储空间，而是推迟到第一次访问时才会实际分配一这即是缺页机制的工作原理。如下是一个申请空间递增的应用，分配/释放大小为2MB->4MB->8MB->16MB,则通过各阶段的svmon可以看到，内存页面会持续增长，从2MB一直增加到16MB(注意不是2MB+4MB+.+16MB=30MB)0ManoC分配2MB,未初始化时：rootanzga:/#svmonnrP909436PidCommandInusePinPgspVirtual64-bitMthrd16MB909436testm165848841727YNNVsidEsidTypeDescriptionPSizeInusePinPgspVirtual2cba711worktextdataBSSheapAddrRange:0.512s2002839b2ffffffffworkapplicationstacks2002AddrRange:65534.65535AddrRange:65534.65535AddressRange为0512页，即代表512X4096=2MB虚拟地址空间。VirtUaI取值为2,表示该空间尚未实际分配。初始化后：2cba711worktextdataBSSheapS51300513AddrRange:0.512VirtUal取值为513,表明虚存空间已经实际分配。释放之前申请的2MB,重新申请4MB并初始化后：AddrRange:O.10241024×4096=4MB,此前释放的512页虚拟地址空间被重复利用。释放之前申请的4MB,重新申请8MB并初始化后：AddrRange:0.2048此前释放的1024页虚拟地址空间被重复利用。释放之前申请的8MB,重新申请16MB并初始化后：2cba711worktextdataBSSheaps4097004097AddrRange:0.40962.3 内存分配观察示例一递减分配如示例，如果是一个申请空间递减的应用，分配/释放大小为16MB->8MB->4MB->2MB,通过各阶段的svmon(svmon-nrP<pid>)可以看到，内存页面始终维持在16MBoMalk)C分配16MB,未初始化时：VsidEsidTypeDescriptionPSizeInusePinPgspVirtualbl41411worktextdataBSSheaps2002AddrRange:0.40962cba7ffffffffworkapplicationstackAddressRange为04096页，即代表4096X4096=16MB虚拟地址空间。InuseZVirtual取值为2,表示该空间尚未实际分配。初始化后：VsidEsidTypeDescriptionPSizeInusePinPgspVirtualbl41411worktextdataBSSheaps4097004097AddrRange:0.4096Virtual=4097页,虚拟内存已经实际分配。释放之前申请的16MB,重新申请8MB并初始化后：b!41411worktextdataBSSheaps4097004097AddrRange:0.4096释放之前申请的8MB,重新申请4MB并初始化后：bl41411worktextdataBSSheaps4097004097AddrRange:0.4096释放之前申请的4MB,重新申请2MB并初始化后：bl41411worktextdataBSSheaps4097004097AddrRange:0.4096可以看到SVmOn输出结果没有变化；原因是虽然应用调用了free释放了16MB内存，但系统的处理策略是将该内存置于进程自身的空间块树中管理。下一个8MB分配，实际上是直接从进程已有的16MB空闲块中获取的。但对系统而言，进程管理的空闲块树也对应为该进程的内存消耗，所以其内存占用没有变化。测试代码：!include<stdio.h>include<stdlib.h>!include<errno.h>intmain(intargc,char*argv)(char*p;intsize-1024*4096;intindicator;if(argc=2)size三atoi(argvl)*4096;%d MB, press entern,z size/ (1024*1024);p=(char*)malloc(size);printf("sizeofmaHoc=getchar();memset(p,0,size);getchar();while(p!=NULL)(free(p);size2;/如果用递增，则size*2;p三(char*)malloc(size);memset(p,0,size);if(p=NULL)(printf("errorencountered,mallocreturnNULL,error=%dn,zerrno);else(printf("sizeofmalloc=%dMB,pressentern",size/(1024*1024);2.4 观察系统中内存占用最高的进程(SVmOn方法)后台运行3个nmem64进程：./nmem64-m2048-s3000-z80&按进程使用的虚拟内存进行排序，显不占用最高的前三项：显示虚拟内存占用最高的3个进程的详细的内存段分布信息，如下：可以看到，消耗最多虚拟内存的段都是nmem64进程的数据段。#svmon-P-t3-Osegment=on-OSortentity=VirtuaI-Otimestamp=onUnit:pageTimestamp:06:10:57PidCommandInusePin6094858nmem6427156110992PgspVirtual0271538VsidEsidTypeDescriptionPSizeInusePinPgspVirtualc915c912worktextdataBSSheapsm655360065536bal63a13worktextdataBSShe叩sm655360065536890a8911worktextdataBSSheapsm655360065536c9164914worktextdataBSSheapsm5827600582762020workkernelsegmentm74668407469d001d900000worksharedlibrarytextm139001395059ffffffdworksharedlibrarysm21730021739flf90020014worksharedlibraryS19700197acl42cf00000002workprocessprivatem53058616069001000aworksharedlibrarydataSm200020f3f39fffffffclntUSLAtextdevhd2:8193S150-dOOOd9ffffffeworksharedlibrarysm120012ffl67f10clnttextdataBSSheap,/dev/hdl:12299S8CI-cfl44f80020014workUSLAheapsm5005fcO6fc8fffffffworkprivateloaddataS5005871687ffffffffworkapplicationstacksm1001ccl5cc19worktextdataBSSheapSm1001c70bc7fffffffaworkapplicationstacksm0000fcl47cfffffff3workapplicationstacksm0000c616c6fffffff2workapplicationstacksm0000ecl5ecfffffff5workapplicationstacksm0000cO15cOfffffff4workapplicationstacksm0000bel5befffffff9workapplicationstacksm00008c0d8cfffffffbworkapplicationstacksm0000fll6flfffffff8workapplicationstacksm0000ebl5ebffffffflworkapplicationstacksm0000a715a716worktextdataBSSheapsm00009al71a17worktextdataBSSheapsm0000961716fffffffworkapplicationstacksm00008al60afffffffeworkapplicationstacksm0000e515e5fffffffcworkapplicationstacksm0000e7166715worktextdataBSSheapsm0000f2167218worktextdataBSSheapsm0000f415f4fffffff6workapplicationstacksm0000841704fffffffdworkapplicationstacksm0000821702fffffff7workapplicationstacksm0000PidCommandInusePin4194650nmem6424693310992PgspVirtual0246910VsidEsidTypeDescriptionPSizeInusePinPgspVirtuaIfcl5fc13worktextdataBSSheapsm655360065536adl62d12worktextdataBSSheapSm655360065536cbl64b11worktextdataBSSheapsm655360065536f915f914worktextdataBSSheapsm336480033648200020workkernelsegmentm74668,07469d001d90000000worksharedlibrarytextm13900139500059ffffffdworksharedlibrarysm21730021739f001f920014worksharedlibraryS19700197adl6adf00000002workprocessprivatem5305d216529l(XX)aworksharedlibrarydatasm200020f300f39fffffffclntUSLAtext,/dev/hd2:8193S150-dd9ffffffeworksharedlibrarysm120012ffl67f10clnttextdataBSSheap,S8C)-devhdl:12299b2163280020014workUSLAheapsm5005d814d88fffffffworkprivateloaddataS5005ccl64cffffffffworkapplicationstacksm1001a9142919worktextdataBSSheapSm1001f916f918worktextdataBSSheapSm0000fal67afffffff4workapplicationstacksm0000cal6cafffffffcworkapplicationstackSm0000e21662fffffff9workapplicationstacksm0000c416c4fffffff2workapplicationstackSm0000bal5bafffffffeworkapplicationstacksm0000e5166515worktextdataBSSheapsm0000bll5blffffffflworkapplicationstacksm0000dal6dafffffff6workapplicationstacksm0000b316b3fffffffworkapplicationstacksm0000cbl6cb17worktextdataBSSheapSm0000d21