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组进一步研究。