hp开启异步IO后仿佛没生效

按理说,在正常情况下,hp主机开启了异步IO之后,主机的wio会有较大幅度的下降,在我们的系统中,wio一般会下降到10%以下。但是最近遇到的情况就非常奇怪,开启异步IO之后,观察wio却仍然很高,在30%~50%,业务忙时cpu idle在个位数。仿佛和没开wio一样。

检查的时候发现,相关参数都是配置正确的,主机和数据库的异步IO参数均已经配置好,通过fuser /dev/async也能看到有进程被放入到异步IO的队列中,但是队列中的进程数很少。比如800多个数据库进程,队列中大约只有200个左右。

由于判断不了是什么原因造成这样的问题,之前又有一个省遇到类似的问题,后来第二天什么参数都没调整,但是恰好需要更换主机内存,主机换了内存被重启之后,问题就解决了。于是对于该问题,申请了一个晚上试图重启主机,看问题能否修复。可以重启之后,问题依旧存在,重启之后异步IO无法启用,$ORACLE_HOME/rdbms/admin下很多trc文件,/dev/async中看不到任何队列。看来还是mlock的权限问题,手工setprivgrp之后,trc文件不再产生,但是/dev/async中仅很少队列,和白天业务高峰期看到的情况类似。

由于数据库主机的hp service guard双机架构,我们尝试切换到db02,系统反映就很正常,/dev/async中的进程队列马上出来,而且很多。这是怎么回事,两边的配置都是一样,难道是db01上的/etc/privgroup文件中含什么看不到的字符?尝试将db02上的文件rcp到db01,然后重启主机后,数据库在db01上启动。故障依旧。

在进一步的观察中发现,重启主机后,/dev/async都没有队列产生,只有手工setprivgrp之后才会产生队列,但是队列数较少。而在db02上,由于主机操作人员之前就执行了setprivgrp,且db02一直没有重启过,所以切换到db02就正常。而且,在db02上观察/dev/async的进程:

我们看到数据库的dbwr的进程28480和28482是在 /dev/async进程队列里面的。

而之前的db01上:

我们在/dev/async中是没看到dbwr的进程的。

于是,我判断:

于是在db01上手工setprivgrp之后,请主机工程师帮忙在db01上通过mc重启数据库。

真的印证了我的判断,dbwr进入了/dev/async异步io的队列,进程数大大增加,和数据库中的session数接近,$ORACLE_HOME/rdbms/log中没再产生trc文件。重启应用后,异步IO的队列数有800多个:

白天业务高峰观察wio情况:

看到异步io已经明显生效,wio几乎在5%以下。

至于/etc/privgroup文件不能随机启动,需要手工setprivgrp的问题,后续交给SA组进一步研究。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据