一台数据库短时间hang住问题的解决(2010-09-27)

   数据库信息:
   db:10.2.0.4.0 - 64bi
   os:Red Hat Enterprise Linux AS release 4 (Nahant Update 7)

 

   7月15日开始连接这台数据库的应用监控连续报宕机错误,有当时连接到数据库的同事反应说当时系统反应极慢,所以感觉应该是数据库的问题,登录到数据库主机的时候,系统已经正常了,查看alert.log,并没有任何的异常信息,从sar历史,每10分钟的一个统计来看,刚才过去的10分钟确实是%user cpu比正常时段要高出许多,因为系统这个时候已经恢复了正常,也就没有必要做systemstate dump,hanganalyze了。

   立刻做了一个刚才5分钟内的ash报表,从报表来看:
   Average Active Sessions:  98.88
   Avg. Active Session per CPU:  6.18
   都比平时正常水平高出不少,
   Top User Events
   Event                      Event Class  % Activity Avg Active Sessions
   latch: library cache    Concurrency      52.94          52.35
   CPU + Wait for CPU   CPU                23.61          23.34
   latch: shared pool     Concurrency      7.29          7.21
  
   latch: library cache和latch: shared pool等待显著,尤其是latch: library cache显著,应该是分析上出现了问题.
   再往下看:
   Top SQL using literals部分居然是非空的.
   是如下这样的sql语句:
select *
  from (select dp.id dealerpriceid,
               nvl(c.regionid, 0) regionid,
               nvl(c.regionname, '') regionname,
               dp.productid productid,
               dp.productname productname,
               nvl(dp.price, 0) price,
               TO_CHAR(dp.updatedtime, 'YYYY-MM-DD') modifydate,
               NVL(dp.advert, '') productadvert,
               c.id companyid,
               c.name companyname,
               NVL(c.abbrname, '') companyabbrname,
               NVL(c.linkman, '') linkman,
               nvl(c.email, '') email,
               NVL(c.phone, '') phone,
               NVL(c.fax, '') fax,
               NVL(c.postcode, '') postcode,
               NVL(c.homepage, '') homepage,
               NVL(c.companyemail, '') companyemail,
               NVL(c.mobile, '') mobile,
               NVL(c.advert, '') companyadvert,
               getcompanyurl(c.id) companyurl,
               GetCompanyRankUrl(c.id) AS rankurl,
               nvl(c.type, 1) type,
               nvl(c.pageview, 0) pageview,
               getfirstcomqq(c.id, 1) qqcontents,
               getfirstcomqq(c.id, 2) taobaocontents,
               (to_char(sysdate, 'yyyy') - to_char(c.inputdate, 'yyyy')) + 1 as dealeryears,
               nvl(c.companyroleid, 1) companyroleid
          from recommenddealer rd, dealerprice dp, company c
         where dp.companyid = rd.companyid
           and dp.companyid = c.id
           and rd.type = :1
           and rd.status = 1
           and dp.status > 0
           and rd.catalogid in (288, 317)
           and dp.productid = :2
         order by dp.updatedtime desc, rd.priority desc, rd.id desc) a
 where rownum <= :3;

还有两条语句,也是类似的sql,并不是说开发人员没有使用绑定变量,大部分还是使用了绑定变量的,但就是in的部分使用了字面值.这样的语句在大量执行的时候便导致了大量的硬分析,耗费大量的CPU,而且硬分析时,需要持有shared pool latch和library cache latch,容易导致latch:library cache和latch:shared pool等待,为了得到这些latch,不断的spin,也加剧了CPU资源的消耗.

使用
select plan_hash_value,count(1) cnt from v$sql group by plan_hash_value having count(1)>=50 order by 2 desc;
至于具体的SQL语句:
select * from v$sql where plan_hash_value='1788691278';
发现除了ash报表中列出的3个sql语句外,还有1个也是in上使用字面值的sql.
而且每个plan_hash_value对应的sql语句数量都是几百,甚至有的达到了1000以上.

而且这些sql的执行频率还是比较高的,基本上都是每分钟八九十次左右.

Select version_count,sql_text,sql_fulltext,sql_id
from v$sqlarea
where version_count >= 50
order by version_count desc, hash_value;
没有发现版本很多的应用sql语句.

查看包含那个时间段的30分钟的awr报表,除了硬分析稍高外,也没有发现其它很异常的地方.

这几条sql语句极可能是导致系统短时间hang住的原因所在,那就改呗:
比如说上面的语句改成下面这样:
select *
  from (select /*+ ordered index(rd (companyid)) use_nl(rd list_catalogid)*/dp.id dealerpriceid,
               nvl(c.regionid, 0) regionid,
               nvl(c.regionname, '') regionname,
               dp.productid productid,
               dp.productname productname,
               nvl(dp.price, 0) price,
               TO_CHAR(dp.updatedtime, 'YYYY-MM-DD') modifydate,
               NVL(dp.advert, '') productadvert,
               c.id companyid,
               c.name companyname,
               NVL(c.abbrname, '') companyabbrname,
               NVL(c.linkman, '') linkman,
               nvl(c.email, '') email,
               NVL(c.phone, '') phone,
               NVL(c.fax, '') fax,
               NVL(c.postcode, '') postcode,
               NVL(c.homepage, '') homepage,
               NVL(c.companyemail, '') companyemail,
               NVL(c.mobile, '') mobile,
               NVL(c.advert, '') companyadvert,
               getcompanyurl(c.id) companyurl,
               GetCompanyRankUrl(c.id) AS rankurl,
               nvl(c.type, 1) type,
               nvl(c.pageview, 0) pageview,
               getfirstcomqq(c.id, 1) qqcontents,
               getfirstcomqq(c.id, 2) taobaocontents,
               (to_char(sysdate, 'yyyy') - to_char(c.inputdate, 'yyyy')) + 1 as dealeryears,
               nvl(c.companyroleid, 1) companyroleid
          from dealerprice dp,recommenddealer rd,
               (select /*+ cardinality(1)*/column_value catalogid from table(seperate_numstr(:1))) list_catalogid,
               company c
         where dp.companyid = rd.companyid
           and dp.companyid = c.id
           and rd.type = :2
           and rd.status = 1
           and dp.status > 0
           and rd.catalogid =list_catalogid.catalogid
           and dp.productid = :3
         order by dp.updatedtime desc, rd.priority desc, rd.id desc) a
 where rownum <= :4;

 

CREATE OR REPLACE TYPE t_numtable IS TABLE OF number;

CREATE OR REPLACE FUNCTION seperate_numstr(p_str IN VARCHAR2) RETURN t_numtable
IS
   l_str   LONG DEFAULT p_str||',';
   l_n     NUMBER;
   l_data  t_numtable:=t_numtable();
BEGIN
   LOOP
      l_n:=InStr(l_str,',');
      EXIT WHEN (Nvl(l_n,0)=0);
      if(LTrim(RTrim(SubStr(l_str,1,l_n-1))) is not null) then
         l_data.extend();
         l_data(l_data.count):=To_Number(LTrim(RTrim(SubStr(l_str,1,l_n-1))));
      end if;
      l_str:=SubStr(l_str,l_n+1);
   END LOOP;
   RETURN l_data;
exception
   when others then
       l_data.delete();
       RETURN l_data;
END;

将其它几个sql也按照这样修改之后,把它们交给了开发人员,开发人员很快对应用做了修改,并重启了应用服务器.
但开发人员反应,这些sql其实并不是最近才新添上去的,其实很早的时候就使用这些sql了.
这个也不是太好说,可能很早的时候就部署上去了,但可能就没怎么被调用过,而最近被频繁的调用才显露出问题来着,这个也是可能的,毕竟互联网用户的行为是不好确定的.

在这次之后,
nohup /home/oracle/osw/startOSW.sh 30 120
开启了osw监控,30秒捕抓一次os性能统计信息,便于再发生类似的问题的时候,从os上得到更多的信息.

这样处理之后,系统便再也没有出现短时间hang住的问题,一直到了8月11号.

**********************************

从8月11号下午6点多开始,这台数据库断续的会在短时间内hang住没有任何的响应,但几分钟后,这种现象又自动消失.不定的时间后又表现出这样的hang住的现象.12号凌晨3点开始执行的过程,原本一个小时就执行完的,但这次直到中午都没有执行完.

从db的awr报表看,表现出大量的latch: library cache和cursor: pin S wait on X, latch: shared pool等待,而尤以latch: library cache为著。
因为之前出现过in使用字面值的问题,所以再次出现这种现象的时候,怀疑是老的问题又出现了,但无论是ash报表还是相关视图,都没有发现显著的使用字面值的问题,应该不是那个问题导致的.

只能接着分析问题了.
从OS上看,hang住的这段时间表现为大量的换页操作,system cpu偏高.
06:20:02 PM       all     26.71      0.00     31.70      7.81     33.79
06:20:02 PM       CPU   %user     %nice   %system   %iowait     %idle
06:33:23 PM       all     26.43      0.00     31.90      7.01     34.66
06:40:01 PM       all      8.23      0.00     21.02      9.98     60.76
06:50:01 PM       all      9.69      0.00      1.47      8.45     80.39
07:00:02 PM       all     19.69      0.00      3.08      8.99     68.24
07:10:02 PM       all     15.04      0.00      3.77      9.58     71.61
07:20:02 PM       all     13.63      0.00      3.16      7.95     75.26
07:30:01 PM       all      7.87      0.00     43.69      7.72     40.72

06:20:02 PM    399.35    334.03
06:20:02 PM  pswpin/s pswpout/s
06:33:23 PM    318.69    190.82
06:40:01 PM    806.72   1259.11
06:50:01 PM    537.68    255.16
07:00:02 PM    535.01    270.41
07:10:02 PM    434.94    349.09
07:20:02 PM    364.92    244.34
07:30:01 PM    736.53    821.42

而osw报表中,本来是30秒钟抓取一次的,但生生的缺失了两三分钟的数据.其实也好理解,那段时间存在了大量的换页操作,而换页的优先级又高于普通用户操作(包括数据库操作,osw脚本的执行),所以数据库操作没有了响应,osw脚本的动作在那段时间里也没有执行.

从缺失数据前后的数据来看,在前后的top中都出现了kswapd0进程,这个也反应出换页频繁的问题来.
但前后的meminfo来看,MemFree:不是太少,也不是太多,缺失数据之前是五六百M,之后迅速回升到1g以上.
我估计缺失数据的时间段内的free内存可能极少
并且交换分区使用的也偏高一些,2G左右.

所以感觉和linux虚拟内存机制有关,文件系统缓存占用着大量的物理内存,当系统负载上来的时候,oracle就需要更多的内存,释放这些文件系统缓存占用的内存就产生了换页.而系统换页的优先级很高,导致数据库的操作得不到时间片,这样就表现为数据库hang住了.

主机是16G的内存,为了让os尽快的释放文件系统占用的物理内存,尽量不要使用交换分区,做出了如下的调整.

vi /etc/sysctl.conf
添加如下的数据行
vm.swappiness=40
vm.vfs_cache_pressure=200
vm.min_free_kbytes=80000

sysctl -p

但第二天还是出现了短时间hang住的现象,并且我每次登陆的时候,系统都已经恢复正常了,想做个systemstate dump,hanganalyze都没用.
从os的统计信息看,还是空闲内存不多,交换分区使用偏大,换页频繁,system cpu偏高.
感觉这些vm核心参数的调整似乎根本就不起作用的.

既然从os调整不了,接着看db方面能不能做什么调整吧!
hang住的这几个时间段,无论是极短时间内的ash报表还是更长时间端的awr报表,都表现出latch: library cache和latch: shared pool等待显著.

其实当时促使我还是从db的等待事件去调整,一个原因是vm的参数调整不起作用,另外一个很重要的原因也在于当时一些片面的理解:当时我只意识到latch的争用会导致spin,会导致空耗CPU,会导致CPU资源出现瓶颈.却没有意识到这两者其实是相互作用的,latch争用会导致cpu资源出现瓶颈,同样的cpu出现瓶颈的时候,也会加剧latch的争用。

因为当时我只意识到latch的争用会导致spin,会导致空耗CPU,会导致CPU资源出现瓶颈.既然数据库等待事件来看,主要表现为latch: library cache和latch: shared pool等待,而且显著,虽然说我也知道这些latch争用导致的应该是user cpu高,而不应该是system cpu高吧,但我还是决定从解决这两个latch争用去入手.

查看出现问题时间段的数据库awr报表,latch: library cache和latch: shared pool等待显著,miss,sleeps很大:

Latch Name Get Requests Pct Get Miss Avg Slps /Miss Wait Time (s) NoWait Requests Pct NoWait Miss
library cache  4,681,222  7.51          0.83          90494           74,798  29.71
shared pool  1,739,642  8.99          0.59          16417           0  

而这些sleeps中,又都是些sleep4的:
Latch Name Get Requests Misses         Sleeps       Spin Gets  Sleep1 Sleep2 Sleep3
library cache  4,681,222  351,789  292,430  71,994   0  0  0
shared pool  1,739,642  156,332  92,977          67,941   0  0  0

说明library cache latch争用显著.

但其实shared pool设置并不小,在问题时段还是有不小的空闲的:
Shared Pool Statistics      Begin  End
Memory Usage %:             86.92  86.81   

Pool    Name         Begin MB End MB  % Diff
shared  free memory  345.34          348.32   0.86
可以看到问题时段,共享池使用85%左右,有300多M的空闲空间,也就是说并不是shared pool设置的问题.

虽说
Library Cache Activity

Namespace Get Requests Pct Miss Pin Requests Pct Miss       Reloads Invali-dations
INDEX          25          40.00          70          21.43         5  0
SQL AREA  376,535  10.98          5,985,703  1.18         3,033  157
这两个子池的丢失率有些偏高,但对比了5个相同时段表现出性能问题前后的awr报表,发现出问题之前这些子池的丢失率更高:

Namespace Get Requests Pct Miss Pin Requests Pct Miss       Reloads Invali-dations
INDEX          31          61.29          74          25.68         0  0
SQL AREA  529,103  21.89          6,125,568  4.00         28,538  790
所以这也应该不是导致问题的原因.

对比出现问题前后这5个相同时段的数据库awr报表,表现出一个相同的地方,就是:
出现问题后,数据库的会话数量比之前平均多了50～80.
也就是说应该是因为数据库负载增高导致了这个问题,最近业务上有什么变化?
连接到这个数据库的应用很多,虽然说已经通过一个逻辑从库分担了一部分负载,但连到这个主库上的应用还是不少.
在出现问题前的一个最大的应用变化就是:
一个应用新增了一台应用服务器,两台应用服务器做了负载均衡,所以导致数据库负载增大了,所以也最终触发了这样的问题.

数据库负载增大,意味着更多的软分析(因为应用基本上都使用了绑定变量,不存在硬分析的显著提高),而共享池配置是不存在问题的,所以感觉是负载增大,导致library cache闩锁的访问过于频繁,导致闩锁数量不足,从而导致了这个问题,所以想着看是不是可以加大library cache子latch的数量来解决这个问题:
现在的数量:
sys> select count(1) from v$latch_children where name='library cache';

  COUNT(1)
----------
        17
而这个数量是由cpu_count决定的,一般来说就是大于cpu_count的最小质数,而
sys> show parameter cpu_count

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
cpu_count                            integer     16

它确实反映了正确的主机配置.
17之后的质数就是19,但我感觉这样增加,增加量偏小了,再下面就是23,31了,如果是31,增加的就太大了,太大了也不好,否则oracle也不会有默认值了,所以就想增大到23,所以决定增加cpu_count到20.
sys> alter system set cpu_count=20 scope=spfile;

System altered.

同时因为library cache子lath数量增多,必然导致共享池并发操作的增加,可能引起共享池使用率的提升,而现在在平时系统的CPU使用并不高,所以也同时加大了shared_pool_size,加大了500M

之后在凌晨重启数据库.重启之后:

SQL> show parameter cpu_count
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
cpu_count                            integer     20
 
SQL> select count(1) from v$latch_children where name='library cache';
 
  COUNT(1)
----------
        23

修改参数,重启数据库之后,系统正常的运行了10天,也没有出现短时间hang住的现象。之前在这次出现这个问题之后,是每天都要hang住至少一次的.似乎是解决问题了.

可26号,我在查看这台主机的os信息的时候,发现在昨天晚上和今天凌晨的时候,又出现了system cpu偏高的现象,所以我怀疑可能那个问题又出现了.
查看邮件,发现了应用宕机的邮件,让开发人员查看应用服务器日志,出现了
Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool error Timeout waiting for idle object
应该是当时数据库又hang住了,应用连不上了.
虽然说不是白天工作时间吧,但我感觉如果不解决的话,迟早工作时间也会hang住的,
果然,27号上班时间数据库又短时间hang住了.

其实这段时间在看书的时候,也正好纠正了我之前的片面的看法:
latch争用会导致cpu资源出现瓶颈,不仅仅是这样,同样的,cpu出现瓶颈的时候,也会加剧latch的争用。

这个数据库问题的本质问题在于os的vm机制,文件系统缓存占用了大量的物理内存,而数据库的sga,pga并不是完全在物理内存里的,这样数据库负载猛的上来的时候,sga,pga需要更多的加载到物理内存里,而物理内存是不足的,这时候这些文件系统缓存就要被交换出去,sga,pga被交换进来,这样就占用了大量的system cpu,而系统换页的优先级很高,导致数据库的操作得不到时间片,这样就表现为数据库hang住了.user cpu不足激化了相应的latch争用,从数据库端来看,表现为latch的争用.但从因果关系来看,应该是user cpu不足导致了latch争用,而不是相反.我原来认为是latch的争用导致了cpu的不足,但如果是那样的话,占用的应该是user cpu,不应该是system cpu的,但从os来看,数据库hang住的时候,表现出的是system cpu高,而不是user cpu高.这是我一直想不明白的.现在看来应该是我把因果关系倒置了.我增加cpu_count,相应的增加library cache latch,只是缓解了数据库hang住的问题的出现,而不是从根本上解决了这个问题.

从根本上来说,还是要减小文件系统缓存占用的物理内存的百分比,但as4好像不提供这样的功能.

现在从free -m来看,used-buffers/cache才2G左右,而sga_target=10000m,所以说sga并没有完全放入物理内存,这样数据库负载猛的上来的时候,sga,pga需要更多的加载到物理内存里,而物理内存是不足的,这时候这些文件系统缓存就要被交换出去,sga,pga被交换进来,这样就占用了大量的system cpu。如果能够把sga固定到内存里就可以减少这些页被交换进来的需要,在很大程度上缓解这个问题.
另外就是文件系统缓存的问题,数据库有自己的cache,这样文件系统缓存对于这个纯数据库服务器来说基本上是没有意义的,也正是因为文件系统缓存导致空闲的物理内存不多,导致了数据库的问题,虽说linux 上不存在像aix上maxperm%这样的内核参数来调整文件系统缓存占用的最大的内存百分比(我原来认为vm.pagecache是类似的功能控制,但后来发现我错了,这个内核参数不是干这个的,当然我现在也不知道它到底是干什么的).但我可以控制db在读写数据文件的时候使用直接IO,绕过文件系统缓存,因为这是一台纯数据库服务器,不存在其他应用,文件的读写操作都是数据库的读写操作,文件系统缓存也绝大部分是因为数据库读写操作造成的,如果数据库读写文件使用直接IO,绕过文件系统缓存的话,就可以解决这个问题.

于是做出了如下的调整:
vi /etc/sysctl.conf
添加
vm.nr_hugepages=5003
vm.hugetlb_shm_group=501

vi /etc/security/limits.conf
添加
oracle           soft    memlock        10246144
oracle           hard    memlock        10246144

其中Hugepagesize:     2048 kB

10246144=5003*2048

vm.nr_hugepages的设置可以使用下面的脚本:
保证所有使用hugepages的程序(oracle实例,asm实例)都稳定的运行了一段时间,然后运行下面的脚本:

vi hugepages_settings.sh

#!/bin/bash
#
# hugepages_settings.sh
#
# Linux bash script to compute values for the
# recommended HugePages/HugeTLB configuration
#
# Note: This script does calculation for all shared memory
# segments available when the script is run, no matter it
# is an Oracle RDBMS shared memory segment or not.
# Check for the kernel version
KERN=`uname -r | awk -F. '{ printf("%d.%d/n",$1,$2); }'`
# Find out the HugePage size
HPG_SZ=`grep Hugepagesize /proc/meminfo | awk {'print $2'}`
# Start from 1 pages to be on the safe side and guarantee 1 free HugePage
NUM_PG=1
# Cumulative number of pages required to handle the running shared memory segments
for SEG_BYTES in `ipcs -m | awk {'print $5'} | grep "[0-9][0-9]*"`
do
   MIN_PG=`echo "$SEG_BYTES/($HPG_SZ*1024)" | bc -q`
   if [ $MIN_PG -gt 0 ]; then
      NUM_PG=`echo "$NUM_PG+$MIN_PG+1"|bc -q`
   fi
done
# Finish with results
case $KERN in
   '2.4') HUGETLB_POOL=`echo "$NUM_PG*$HPG_SZ/1024" | bc -q`;
          echo "Recommended setting: vm.hugetlb_pool = $HUGETLB_POOL" ;;
   '2.6') echo "Recommended setting: vm.nr_hugepages = $NUM_PG" ;;
    *) echo "Unrecognized kernel version $KERN. Exiting." ;;
esac
# End

chmod +x hugepages_settings.sh

./hugepages_settings.sh
Recommended setting: vm.nr_hugepages = 5003

如果没有使用asm的话,其实就是sga_max_size(注意是sga_max_size,不是sga_target)对应的hugepage页数.

vm.hugetlb_shm_group=`id -g oracle`  只有oracle的主用户组的用户可以使用hugepages,一般来说这里应该是dba组的id

alter system set filesystemio_options=directio scope=spfile;
因为使用的是文件系统,所以只使用了直接IO。

重启主机,重启数据库之后:
more /proc/meminfo
HugePages_Total:  5003
HugePages_Free:      2
Hugepagesize:     2048 kB

free -m
             total       used       free     shared    buffers     cached
Mem:         16043      15893        150          0         24       4186
-/+ buffers/cache:      11682       4361
Swap:        31996          0      31996

sga完全固定到物理内存里了.没有使用交换分区.

 

(
其实这里重启主机的操作也不是必需的,也可以不重启主机,在关闭数据库实例之后这样操作
echo 3 > /proc/sys/vm/drop_caches
sysctl -p
more /proc/sys/vm/nr_hugepages
重复上面三条指令,直到最后一个命令显示的是你sysctl.conf中设置的nr_hugepages的值.
然后echo 0 > /proc/sys/vm/drop_caches
最后再重启数据库实例就可以了
) 

这次调整也过去快一个月了,也再没有出现短时间hang的现象.基本上没有换页现象.出现极少量的换页也是因为逻辑备份完之后,tar,scp到别的服务器的时候使用了大量的物理内存导致的极少量的换页.(其实也可以通过在别的服务器上来完成这个数据库的逻辑备份来避免这个问题的)交换分区几乎没有使用过,最多使用也就是12M.应该来说,这个问题算是彻底的解决了.

简单的总结一下:
1.不要孤立的只从数据库等待事件的角度去查看解决数据库性能问题,也要结合其它信息比如说操作系统,存储信息等来看.
比如说这里如果只是从等待事件的角度去解决latch:library cache,latch:shared pool这两个latch的争用的话,也许永远都解决不了这个问题.

也就是说需要了解这只是症状,还是问题的根源.摘录<<expert oracle practices>>第3章中的一段话:Symptom or problem? Sometimes the main symptom is actually a side effect of the real problem. For example, in one case cache buffers chains latch contention increased CPU utilization to 100 percent, which resulted in library cache latch wait times increasing to the point that they were the top wait event. Although the symptom pointed to a library cache problem, it was actually the result of cache buffers chains latch contention, which itself was induced by inefficient SQL.就我这里的问题而言,数据库端这两个latch的争用只是症状,而不是问题的根源,问题的根源是原来的数据库配置下,文件系统缓存占用了大量的物理内存,在系统负载急剧上升时换页操作导致的user cpu资源不足.

2.很多事物之间的影响是双向的,是相互作用的。
比如说这里的问题:latch的争用会导致spin,导致空耗CPU,会加剧CPU的开销,从而导致CPU资源出现瓶颈.
但反向的作用也是存在的,CPU资源出现瓶颈(对于这个案例而言就是user cpu资源不足),也会加剧latch的争用.
in使用字面值导致CPU出现瓶颈属于前者的影响,而换页的影响属于后者.

3.就是数据库安装配置时的规范化
如果说in使用字面值的问题还是应用的问题的话,那么其实后面的问题就是数据库配置的问题带来的结果了.
sga固定到物理内存里是建议的,使用文件系统的数据库使用直接IO也是建议的,而这个数据库却都没有采用,最终导致了这个问题.而我也是通过使用这样的建议配置来解决这个性能问题的.

 

补记:从8月底做出最后的调整到11月1日这个数据库迁移到另一台主机上,这段时间数据库一直很稳定,再也没有出现过短时间hang住的现象