4.3内存
杭州社保系统分析方案
部分内存可以通过系统的重新启动释放出来。
16
1009080706050403020100500045004000350030002500200015001000500010012014020 09:034060800 09:03 09:03 09:04 09:05 09:06 09:07 09:08 09:09 09:10 09:11 09:12 09:13 09:14 09:14 09:15 09:16 09:17 09:18 09:19 09:20 09:21 09:22 09:23 09:24 09:25 09:25 09:26 09:27 09:28 09:29 09:30 09:31 09:32 09:33 09:04 09:05 09:06 09:07 09:08 09:09 09:10 09:11 09:12 09:13 09:14 09:14 09:15 09:16 09:17 09:18 09:19 09:20 09:21 09:22 09:23 09:24 09:25 09:25 09:26 09:27 09:28 09:29 09:30 09:31 09:32 09:04 09:05 09:06 09:07 09:08 09:09 09:10 09:11 09:12 09:13 09:14 09:14 09:15pgsinProcess% 09:16 09:17 09:18pgsoutFScache% 09:19Real free(MB) 09:20Memory p690a_db 2009-4-13Memory Use p690a_db 2009-4-13 09:21System% 09:22Paging p690a_db (pgspace) 2009-4-13 09:23 09:24 09:25 09:25 09:26 09:27 09:28 09:29 09:30 09:31 09:32 09:33 09:33 在监控的这段时间，系统的空闲内存维持在3G左右，其中，FSCache用了大约20%左右，所以，该
1020304050607004.4网络
3000200010000-1000-2000-3000-4000-5000-6000-7000 09:03 09:04 09:05 09:06 09:07 09:08 09:09 09:10 09:11 09:12 09:13 09:14 09:14Total-Read 09:15 09:16 09:17 09:18 09:19 09:20 09:21 09:22 09:23 09:24 09:25 09:25 09:26 09:27 09:28 09:29 09:30 09:31 09:32 09:33Page scan:free ratio p690a_db 2009-4-13简单的调高Oracle的SGA及PGA的参数，这样可能会造成更为严重的IO问题。
Network I/O p690a_db (KB/s) - 2009-4-13Total-Write (-ve) 09:03 09:04 09:05 09:06 09:07 09:08 09:08 09:09 09:10 09:11 09:12 09:13 09:13 09:14 09:15 09:16 09:17 09:18 09:18 09:19 09:20 09:21 09:22 09:23 09:23 09:24 09:25 09:26 09:27 09:28 09:28 09:29 09:30 09:31 09:32 09:33 但是，系统出现pgsout和页扫描，所以，系统的内存内存有一些不足。所以，根据这个来看我们不能
17
杭州社保系统分析方案
4.5内核运行队列
Processes p690a_db 2009-4-13RunQueue706050403020100 09:03 09:04 09:05 09:06 09:07 09:08 09:08 09:09 09:10 09:11 09:12 09:13 09:13 09:14 09:15 09:16 09:17 09:18 09:18 09:19 09:20 09:21 09:22 09:23 09:23 09:24 09:25 09:26 09:27 09:28 09:28 09:29 09:30 09:31 09:32 09:33Swap-in RunQueue表示在内核队列中运行的任务的数量，如果该值超过CPU的总的个数，就是说明CPU存在一定的瓶颈。
p690a_db/tmp/nmon#vmstat 1 10
System Configuration: lcpu=12 mem=24576MB
kthr memory page faults cpu ----- ----------- ------------------------ ------------ ----------- r b avm fre re pi po fr sr cy in sy cs us sy id wa 4 10 4802254 519347 0 0 3 119 169 0 2113 25005 5354 13 3 66 18 3 8 4802297 519303 0 2 0 7740 46034 0 7958 49701 15185 29 6 19 46 4 13 4803779 517953 0 3 25 8234 76412 0 8700 87489 18464 43 6 15 36 9 7 4807333 514916 0 4 374 11035 112609 0 8994 100553 17601 42 11 13 34 7 16 4806543 515634 0 1 49 10214 78141 0 9250 122369 19126 53 12 5 30 10 25 4806503 515670 0 2 107 10232 36819 0 8748 114125 17864 52 10 7 31 4 10 4806595 515577 0 0 0 6754 31079 0 7947 78967 16092 27 12 16 45 3 12 4801393 520770 0 2 30 9515 32673 0 9642 78943 19240 40 9 15 35 7 7 4801451 520715 0 2 0 7298 29081 0 8685 99123 18057 39 8 17 36 6 11 4803615 518546 0 0 0 9400 37142 0 8806 84989 17677 48 7 9 36
以上，是vmstat的采样数据，r代表上图中的runqueue，b代表的是被IO中断的的情况，所以，从这两个数据来看：
1．
cpu消耗比较高，有时会成为系统的瓶颈，但是，该问题，不能单纯的看，导致CPU高的主要问题是由于IO缓慢导致的。所以，我们首要任务就是定位和优化系统中消耗CPU及IO的业务sql。
18
第5章 Oracle Statspack监控
5.1事务的回滚率比较高
Rollback per transaction %: 30.01，该值正常在10%左右，而该系统的回退率竟然达到了30%以
上，由于系统回滚需要消耗大量的资源，所以，应该尽量降低系统的回滚率。经过和开发人员咨询，由于业务大量使用基于事务的临时表，所以，导致业务回滚比较高，所以，导致消耗大量的CPU及临时表空间及回滚段。建议优化临时表的写法或是避免使用。
5.2Sql语句硬解析
Execute to Parse %: 39.07
Parse CPU to Parse Elapsd %: 88.28 % SQL with executions>1: 45.96 60.18
系统的存在大量的sql语句的没有变量邦定，可以考虑调整参数cursor_sharing=similar
5.3Oracle等待事件问题
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total Event Waits Time (s) Ela Time -------------------------------------------- ------------ ----------- --------
CPU time 35,303 41.07 db file sequential read 12,143,210 28,605 33.28 log file sync 89,414 7,527 8.76 enqueue 2,610 6,619 7.70 db file scattered read 1,161,950 1,930 2.25
db file sequential read,该事件主要是由于DB文件连续读取。通常显示单个块的读取(通常指索引读取)，表示的是读进磁盘的block被放在连续的内存块中。事实上大部分基本代表着单个block的读入，可以说象征着 IO 或者说通过索引读入的比较多。这种等待的数目很多时，可能显示表的连接顺序不佳，或者不加选择地进行索引。由于我们的优化器采用的是：optimizer_mode=choose，所以，在具
有表和索引具有分析数据的时候他使用的是基于CBO，否则采用RBO，而我们由于系统目前没有及时作统计分析采用导致SQL的执行计划异常，导致该走全表扫描的走的是索引。
19
杭州社保系统分析方案 第6章索引检查
系统针对hzsimis用户的2323个索引进行监控，通过一个业务周期的监控，我们发现有1462个索引没有使用到，建议在经过两个业务周期监控通过开发人员的判断，对该部分索引进行删除。监控明细monitor index.xls。
同时，对hzsimis表的索引建立情况进行了分析，主要问题表现在个别表建立大量的索引，这样会大大降低系统的执行效率。
表名称 AA28 LDFB_PB03_FIRST AC13_GT LC20 NZJZ_GRJFQKNEW AB07 TEMP_GRJFQK1 LDFB_PB03 LC01 MC01 IC01 FYYLB AC22 AC32 KC46_SW AC37 NZJZ_AC01 KC66 AC35 AC19 LC20_BACK PSIGN LC40 LDFB_PB01 LC30_BACK AC06 PB35 AA93 LDFB_PB02_FIRST LDFB_PB02_FIRST_GT LDFB_PB01_FIRST LDFB_PB01_FIRST_GT LDFB_PB02 AC10_GT 20
5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 索引个数 AC10 IC15 KC02 AC13_TEMP TEMP_GRJFQK TEMP_JFCX TEMP_GRJFQK_DZD NZJZ_GRJFQK NZJS_AC10 NZJS_AC10_HIS STATIC_AC13TX IC10 NZJS_AC01 NZJS_AC13 GFYLYLB AC13 AC14 AB08_DSTZ NZJS_AB01 IC14 AB08 LDFB_PB101 AB08_DSBAK LDFB_PB103 LDFB_PB102 KC21 TEMP_AC13 KC22 AB10 AB08_BS_051223 AB15 KC69 AC13_LC KC09 表名称 6 6 6 6 6 6 6 6 6 6 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 8 8 8 8 8 8 8 8 9 索引个数