AIX 53主机性能评估-结合案例分析.doc

AIX 5.3主机性能评估-结合案例分析案例 在这个案例中，主要重点就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/TTYThu Oct 25 13:58:32 2007 Interval: 2 Cswitch Readch Syscall WritechKernel | | Reads RawinUser | | Writes TtyoutWait | | Forks IgetsIdle | | Execs Namei Runqueue DirblkNetwork KBPS I-Pack O-Pack KB-In KB-Out WaitqueuePAGING MEMORY Faults Real,MB Steals % CompDisk Busy% KBPS TPS KB-Read KB-Writ PgspIn % Noncomp PgspOut % Client PageIn PageOut PAGING SPACE Sios Size,MB % Used NFS (calls/sec) % FreeServerV2 ClientV2 Press: ServerV3 h for help ClientV3 q to quit2、安装nmon_aix53（操作系统为5.3），结果nmon_aix53运行也报错。#./nmon_aix53ERROR: Assert Failure in file=nmon11.c in function=main at line=3239ERROR: Reason=NULL pointerERROR: Expression=q-procs = MALLOC(sizeof(struct procentry64 ) * n )ERROR: errno=12ERROR: errno means : Not enough space3、检查进程情况#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 DESCRIPTIONA63BEB70 1025140007 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATEDA63BEB70 1025133007 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATEDA63BEB70 1025130007 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATEDA63BEB70 1025123007 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATEDA63BEB70 1025120007 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATED在这里，可以看到频繁的这个报错。基本每隔半个小时报错一次。再检查详细的错误。可以定位到原来是由于一个网管监控软件造成的这个错误。基本也可以判断，由于整个软件的不当的fork调用，导致了数量惊人的孤儿进程。现在孤儿进程的问题基本确定了，但是这个孤儿进程到目前为止，对系统造成的影响有多大？网上搜了一把，孤儿进程一般不占用内存，不占用空间，只不过是在进程列表中占了一个位置，所以并不会对系统性能产生太严重的影响。当然，如果任期发展，有可能就会使主机hang住。在这里，网管系统是以root用户运行的，进程数的限制非常大。所以，这里孤儿进程应该只是一个安全隐患，并不是对当前性能造成影响的原因。4、检查cpu的使用情况，#vmstat 1 10 System configuration: lcpu=16 mem=23552MBkthr 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 38Cpu的使用率基本在65左右，wa基本在35到40，io等待比较严重。5、再继续检查一下磁盘的IO情况#iostat 1 2System configuration: lcpu=16 drives=11 paths=4 vdisks=0tty: tin tout avg-cpu: % user % sys % idle % iowait 0.0 60.0 26.6 9.6 38.4 25.4Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk1 37.0 350.0 70.0 0 350hdisk0 31.0 354.0 70.0 0 354hdisk2 0.0 0.0 0.0 0 0hdisk3 0.0 0.0 0.0 0 0dac0 0.0 9780.0 1199.0 2000 7780dac0-utm 0.0 0.0 0.0 0 0dac1 0.0 0.0 0.0 0 0dac1-utm 0.0 0.0 0.0 0 0hdisk4 49.0 3141.0 389.0 520 2621hdisk5 99.0 6639.0 810.0 1480 5159cd0 0.0 0.0 0.0 0 0tty: 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_wrtnhdisk1 0.0 0.0 0.0 0 0hdisk0 0.0 0.0 0.0 0 0hdisk2 0.0 0.0 0.0 0 0hdisk3 0.0 0.0 0.0 0 0dac0 0.0 13080.0 1497.0 1616 11464dac0-utm 0.0 0.0 0.0 0 0dac1 0.0 0.0 0.0 0 0dac1-utm 0.0 0.0 0.0 0 0hdisk4 63.0 3866.0 405.0 296 3570hdisk5 100.0 9214.0 1092.0 1320 7894cd0 0.0 0.0 0.0 0 0在上面的两份报告中，可以发现，系统对磁盘的负载不均。Hdisk5基本上长期维持在100，而hdisk4则基本上维持在50左右。再检查这两个hdisk的详细情况：#lspv hdisk5PHYSICAL VOLUME: hdisk5 VOLUME GROUP: oravg PV IDENTIFIER: 00c2c1eb0bcfbdd4 VG IDENTIFIER 00c2c1eb00004c0000000110153a551dPV STATE: active STALE PARTITIONS: 0 ALLOCATABLE: yesPP SIZE: 64 megabyte(s) LOGICAL VOLUMES: 120TOTAL PPs: 8718 (557952 megabytes) VG DESCRIPTORS: 1FREE PPs: 1206 (77184 megabytes) HOT SPARE: noUSED PPs: 7512 (480768 megabytes) MAX REQUEST: 1 megabyteFREE DISTRIBUTION: 00.00.00.00.1206 USED DISTRIBUTION: 1744.1744.1743.1743.538 #lspv hdisk4PHYSICAL VOLUME: hdisk4 VOLUME GROUP: oravgPV IDENTIFIER: 00c2c1eb0bcfb8b3 VG IDENTIFIER 00c2c1eb00004c0000000110153a551dPV STATE: active STALE PARTITIONS: 0 ALLOCATABLE: yesPP SIZE: 64 megabyte(s) LOGICAL VOLUMES: 128TOTAL PPs: 6538 (418432 megabytes) VG DESCRIPTORS: 2FREE PPs: 100 (6400 megabytes) HOT SPARE: noUSED PPs: 6438 (412032 megabytes) MAX REQUEST: 1 megabyteFREE DISTRIBUTION: USED DISTRIBUTION: 1308.1308.1307.1307.1208 6、检查一下内存，#lsps -aPage Space Physical Volume Volume Group Size %Used Active Auto Typepaging00 hdisk2 rootvg 12288MB 1 yes yes lvhd6 hdisk0 rootvg 12288MB 1 yes yes lv#svmon -G -i 1 5 size inuse free pin virtualmemory 6029312 3780159 2249153 446200 3535574pg space 6291456 17540 work pers clntpin 445938 262 0in use 3535574 244585 0 size inuse free pin virtualmemory 6029312 3780168 2249144 446205 3535578pg 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%) / 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_redo15SQL !$ lslv -l lv_redo13lv_redo13:N/APV COPIES IN BAND DISTRIBUTION hdisk4 008:000:000 0% 000:000:000:000:008 $ lslv -l lv_redo16lv_redo16:N/APV COPIES IN BAND DISTRIBUTION hdisk5 008:000:000 0% 000:000:008:000:000 $ lslv -l lv_redo11lv_redo11:N/APV COPIES IN BAND DISTRIBUTION hdisk4 008:000:000 0% 008:000:000:000:000 $ lslv -l lv_redo14lv_redo14:N/APV COPIES IN BAND DISTRIBUTION hdisk5 008:000:000 0% 008:000:000:000:000 $ lslv -l lv_redo12lv_redo12:N/APV COPIES IN BAND DISTRIBUTION hdisk4 008:000:000 0% 000:000:000:000:008 $ lslv -l lv_redo15lv_redo15:N/APV 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 4053432766Module: Das.exeBEGIN 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 1594289970Module: Das.exeSELECT MAX(T.ACTIVE_FLAG), MAX(T.SECOND_NO) FROM T_MC_MCN_USERINFO T WHERE T.USER_NO = :B1 AND T.PARTCOL_USERNO = SUBSTR(:B1 , - 3, 2) AND ROWNUM ordered by IOs (Reads + Writes) descTablespace- 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.8TBS_MCN_LOG_IDX 101,915 56 74.3 1.0 416,523 231 34,705 2.8TBS_MCN_MAIN_IDX 110,871 61 43.9 1.0 200,902 111 15,797 1.4TBS_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 POINTlv_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 POINTlv_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,578Hdisk5：261,996Hdisk5的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_data09750,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_data092IXDBA.NET社区论坛 22,352 12 145.5 1.0 2,375 1 1 70.0TBS_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,valuefrom v$segment_statistics where statistic_name=physical reads and owner=MCNSorder by value desc ;OBJECT_NAMETABLESPACE_NAMEVALUEPK_MC_MCN_USERINFOTBS_MCN_MAIN_IDX66970541T_MC_SM