本文共 4249 字,大约阅读时间需要 14 分钟。
首先我维护的系统的结构是,RP8420主机,SAN存储网络,XP12000高端阵列
最近DBA反映数据库写日志的进程有很多在等待,于是在数据库主机侧执行sar -u 1 10命令,输出如下:
08:51:00 %usr %sys %wio %idle
08:51:01 35 4 56 5
08:51:02 37 7 50 6
08:51:03 36 4 56 4
08:51:04 34 4 59 3
08:51:05 37 3 56 4
08:51:06 51 4 43 2
08:51:07 62 6 31 1
08:51:08 58 6 34 2
08:51:09 62 7 31 0
08:51:10 48 4 46 1
Average 46 5 46 3
发现CPU的WIO有些高,很多CPU的处理时间都耗费在了等待IO上,于是又执行sar -d 1 10命令,输出如下:
08:51:37 device %busy avque r+w/s blks/s avwait avserv
Average c2t6d0 95.20 2.24 244 3211 6.56 15.41
Average c0t6d0 74.67 2.35 216 3053 6.16 15.26
Average c10t0d0 73.67 0.50 337 8105 0.03 5.74
Average c10t0d1 30.33 0.50 141 3467 0.00 4.17
Average c10t0d2 63.76 0.50 310 7378 0.00 4.53
Average c10t0d4 65.17 0.50 316 7135 0.00 4.21
Average c10t0d5 41.44 0.51 177 4053 0.08 5.97
Average c10t0d6 67.77 0.50 325 7707 0.00 4.49
Average c10t0d7 47.25 0.50 191 4464 0.00 5.41
Average c10t1d0 21.32 0.50 126 2016 0.00 1.84
Average c10t1d1 18.72 0.50 125 1997 0.00 1.60
Average c10t1d2 19.82 0.50 125 2000 0.00 1.75
Average c10t1d3 30.03 0.50 125 2007 0.00 2.66
Average c10t1d4 21.12 0.50 127 2026 0.00 1.83
Average c10t1d5 20.72 0.50 127 2024 0.00 1.75
Average c10t1d6 23.12 0.50 123 1973 0.00 2.11
Average c10t1d7 18.82 0.50 126 2008 0.00 1.62
Average c16t0d1 166.47 5.50 273 6365 0.00 2.11
Average c16t0d2 28.83 0.50 89 2183 0.07 10.96
Average c16t0d3 44.14 0.50 209 5175 0.00 6.60
Average c16t0d5 42.74 0.51 251 5547 0.16 3.97
Average c16t0d6 17.52 0.50 81 1829 0.00 4.47
Average c16t0d7 44.14 0.50 207 5135 0.00 5.38
Average c6t0d1 85.59 4.71 89 9242 41.79 68.74
Average c16t0d4 14.01 0.50 91 1963 0.00 2.55
Average c16t0d0 21.42 0.50 63 1376 0.00 8.50
Average c10t0d3 39.44 0.50 191 4438 0.00 4.29
此时发现对列的等待时间绝大多数都在0.50左右,不是很高,数据量也不大,平均服务时间大多数也都保持在10ms以下
通过阵列的监控,看到writepending大约在25%左右,感觉并不像是出现了IO瓶颈,可是为什么CPU的WIO会那么高?
想请教一下高手,在我这个系统里,WIO很高,你们认为IO是瓶颈吗?sar -u 与sar -d 看到的为什么得出的结论不一样,我应该倾向于哪个?非常感谢!
从数据上看是wio是比较高,最近做了什么改动么?
你的c0t6d0和c2t6d0也有些忙,内存用光了吗?
这是vmstat 1 5的输出
procs memory page faults cpu
r b w avm free re at pi po fr de sr in sy cs us sy id
3 5 0 1223501 2442289 961 40 128 0 0 0 0 8863 56387 3795 12 5 83
3 5 0 1223501 2440711 131 18 9 0 0 0 0 9996 56752 3575 19 4 77
5 4 0 1162290 2438178 105 14 8 0 0 0 0 10283 69205 3851 20 5 75
5 4 0 1162290 2439762 84 11 6 0 0 0 0 10180 66452 3790 11 4 85
5 4 0 1162290 2442610 68 8 4 0 0 0 0 10266 63163 3800 8 4 88
内存我通过glance看过了,还剩余8G,应该是够了
回复 #1 bug1981 的帖子 wio高可能跟你usr多有关。硬盘IO只有下面4个有点忙,其他都正常
Average c2t6d0 95.20 2.24 244 3211 6.56 15.41
Average c0t6d0 74.67 2.35 216 3053 6.16 15.26
Average c16t0d1 166.47 5.50 273 6365 0.00 2.11
Average c6t0d1 85.59 4.71 89 9242 41.79 68.74
把oracle的参数贴出来:
show parameter sga;
show parameter pga_;
show parameter log;
也许是你的log buffer的大小不合理,调大点试试看?
问问应用最近是否有变动?
[[i] 本帖最后由 czyf2001 于 2008-3-6 17:43 编辑 [/i]]
c2t6d0 和c0t6d0 都应该是本地根盘吧 如果是vg00的话,注意下是不是盘有问题了
c2t6d0 和c0t6d0 的确都是根盘,不过检查发现,根盘没有问题。
现在很疑惑的地方是,wio很高,数据库写日志觉得慢,但是我看盘的运行情况好像IO瓶颈并不是很突出,难道说可能有别的什么原因?或者说可能是并发业务量确实太大了?
看看oracle的设置.应用的影响很大.不要老集中在system上面。
[quote]原帖由 [i]bug1981[/i] 于 2008-3-5 14:19 发表 [url=http://bbs.chinaunix.net/redirect.php?goto=findpost&pid=8041668&ptid=1060899][img]http://bbs.chinaunix.net/images/common/back.gif[/img][/url]
这是vmstat 1 5的输出
procs memory page faults cpu
r b w avm free re at pi po fr de sr ... [/quote]
这里看你CPU idle很高啊,找个忙的时候做,不然反映不了问题,pi po不算高
用oracle用户执行sqlplus " / as sysdba"
select name,bytes from v$datafile;
SELECT a.group#, a.member, b.bytes FROM v$logfile a, v$log b WHERE a.group# = b.group#;
select * from v$controlfile;
搞不好有人用OEM给数据文件加到/下的某个地方了.
[quote]原帖由 [i]netzh[/i] 于 2008-3-7 16:58 发表 [url=http://bbs.chinaunix.net/redirect.php?goto=findpost&pid=8052194&ptid=1060899][img]http://bbs.chinaunix.net/images/common/back.gif[/img][/url]
这里看你CPU idle很高啊,找个忙的时候做,不然反映不了问题,pi po不算高
用oracle用户执行sqlplus " / as sysdba"
select name,bytes from v$datafile;
SELECT a.group#, a.member, b.bytes FRO ... [/quote]
强烈同意,本地IO量非常高,有可能是把数据文件加到/下了,是不是加数据文件的时候多出了空格之类的东东。
从vmstatus看你的物理内存不够了,po =pageout 所以有内存和disk之间的换页操作,建议加内存看看。应该就是这个原因
I/O量大,需要从系统的负载和数据库的sp一起分析。可以在系统运行缓慢时把sar 和oracle的sp 一起贴出来看看
转载地址:http://gjgxi.baihongyu.com/