中国IT动力,最新最全的IT技术教程
最新100篇 | 推荐100篇 | 专题100篇 | 排行榜 | 搜索 | 在线API文档
首 页 | 程序开发 | 操作系统 | 软件应用 | 图形图象 | 网络应用 | 精文荟萃 | 教育认证 | 硬件维护 | 未整理篇 | 站长教程
ASP JS PHP工程 ASP.NET 网站建设 UML J2EESUN .NET VC VB VFP 网络维护 数据库 DB2 SQL2000 Oracle Mysql
服务器 Win2000 Office C DreamWeaver FireWorks Flash PhotoShop 上网宝典 CorelDraw 协议大全 网络安全 微软认证
硬件维护  CPU  主板  硬盘  内存  显卡  显示器  键盘鼠标  声卡音箱  打印机  机箱电源  BIOS  网卡  C#  Java  Delphi  vs.net2005
  当前位置：> 程序开发 > 数据库开发 > 数据库综合
一次异常内存消耗问题的诊断及解决
作者:未知 时间:2005-07-27 23:40 出处:CSDN 责编:chinaitpower
              摘要：一次异常内存消耗问题的诊断及解决

 

 

 本文已经发表在ITPUB优化技术丛书，未经许可，不得转载。

1.   问题发现

一大早，接到通知说现网数据库（RAC中的一个节点）出现异常，现象是大量的业务拥堵，系统可用内存很低，经常徘徊在100m左右，随着业务高峰期的时间就要到了，眼看系统的内存已经处在极其危险的状态。

 

2.   解决过程

2.1. 环境介绍

硬件和软件环境：

HP 7410  ，16G内存，8个CPU，存储是HP XP128

OS版本，HPUX 11.11 + MC 11.15

2节点RAC，oracle版本9.2.0.4

2.2. 问题现象

首先看一下进程的内存情况（HPUX 11.11）：

 

oracle@db02:/oracle > vmstat 2 10

         procs           memory                   page                              faults       cpu

    r     b     w      avm    free   re   at    pi   po    fr   de    sr     in     sy    cs  us sy id

    8     5     0  2659897   54987  127   13     0    0     0    0    23  17401 114389  6145  21  6 73

    8     5     0  2659897   54365    4    0     4    0     0    0     0  16032 126259  7605  35  5 60

    8     5     0  2659897   54232    2    0     3    0     0    0     0  16043 139904  7705  38 11 51

    2     5     0  2664805   53921    0    0    32    0     0    0     0  16252 141213  7843  33  6 60

    2     5     0  2664805   56209    0    0    20    0     0    0     0  15828 136485  7592  30  6 65

    2     5     0  2664805   55701    0    0    56    0     0    0     0  16330 137069  7952  38  7 54

    2     5     0  2664805   55685    0    0    35    0     0    0     0  16819 141478  8098  32  6 62

    2     5     0  2664805   53749    0    0    22    0     0    0     0  16855 139303  8003  34  7 59

    7     1     0  2620255   51536  172    0    41    0     0    0     0  16521 136507  8093  44  6 50

    7     1     0  2620255   51323  109    0    28    0     0    0     0  17859 151458  8623  43  7 50

oracle@db02:/oracle >

      

我们知道，一般来说，系统的Page out(po)可以有一些，但如果Page in(pi)一般很高，并间歇性的还在逐渐上升，这就要引起注意。总得来说，正常系统的paging 可以有一些，但不能太多。

而这里，很明显，我们可以看见运行队列（r）很高，系统可用的空闲内存极少，并切伴随大量的page in，已经出现了明显的内存不足。同时我们也可以看到用户进程的CPU使用率（us）几乎没有异常，并且他们的cpu的使用率都在合理的范围内（抛除wait－io意味的CPU使用率）。

 

再使用top观察，是否有大量的极其耗费CPU的进程在操作：

oracle@db02:/oracle > top     

 

System: db02                                       Fri Mar  4 12:14:47 2005

Load averages: 0.56, 0.57, 0.58

966 processes: 951 sleeping, 15 running

Cpu states:

CPU   LOAD   USER   NICE    SYS   IDLE  BLOCK  SWAIT   INTR   SSYS

 0    0.65  30.0%   0.0%   5.7%  64.3%   0.0%   0.0%   0.0%   0.0%

 1    0.77  95.7%   0.0%   1.0%   3.4%   0.0%   0.0%   0.0%   0.0%

 2    0.64  24.9%   0.0%  11.6%  63.5%   0.0%   0.0%   0.0%   0.0%

 3    0.40  36.5%   0.0%   7.3%  56.2%   0.0%   0.0%   0.0%   0.0%

 4    0.59  27.2%   0.0%   7.7%  65.1%   0.0%   0.0%   0.0%   0.0%

 5    0.54  26.4%   0.0%   7.3%  66.3%   0.0%   0.0%   0.0%   0.0%

 6    0.60  17.8%   0.0%  11.4%  70.8%   0.0%   0.0%   0.0%   0.0%

 7    0.29  36.3%   0.0%   3.6%  60.2%   0.0%   0.0%   0.0%   0.0%

---   ----  -----  -----  -----  -----  -----  -----  -----  -----

avg   0.56  36.9%   0.0%   6.9%  56.2%   0.0%   0.0%   0.0%   0.0%

 

Memory: 14829952K (8998976K) real, 20328344K (10419100K) virtual, 227036K free  Page# 1/35

 

CPU TTY  PID USERNAME PRI NI   SIZE    RES STATE    TIME %WCPU  %CPU COMMAND

 7   ?  8946 oracle   241 20  7328M  2148K run     13:56 99.14 98.97 ora_j002_cmc2

 4   ? 11551 oracle   241 20  7344M 14384K run    148:31 22.84 22.80 oraclecmc2  

 0   ? 22315 oracle   221 20  7358M  5668K run    294:01 18.22 18.19 ora_lms0_cmc2

 3   ? 22317 oracle   154 20  7358M  5668K sleep  307:13 17.89 17.86 ora_lms1_cmc2  

 1   ?  9108 oracle   241 20  7328M  2820K run      0:06 17.31 17.28 oraclecmc2  

 0   ?  9106 oracle   154 20  7328M  2928K sleep    0:22 10.87 10.85 oraclecmc2

 1   ?  7044 oracle   154 20  7333M  5720K sleep    0:45  7.25  7.24 oraclecmc2

 2   ? 11591 oracle   154 20  7328M   864K sleep  183:59  7.25  7.24 oraclecmc2

 4   ?  7235 root     152 20 43172K  7236K run      4:03  7.04  7.02 nco_m_ssmagent

 6   ? 11687 oracle   156 20  7328M   852K sleep   86:09  6.27  6.26 oraclecmc2

 4   ?  3650 oracle   154 20  7328M   816K sleep    7:11  5.54  5.53 oraclecmc2  

 0   ? 11384 oracle   154 20  7328M   844K sleep   79:19  5.47  5.46 oraclecmc2

 5   ?  8772 oracle   154 20  7328M  2420K sleep    1:00  5.02  5.01 oraclecmc2  

 3   ? 10083 oracle   154 20  7328M  1052K sleep   71:55  5.00  4.99 oraclecmc2  

 3   ? 22335 oracle   156 20  7335M  2604K sleep   67:37  4.94  4.94 ora_lgwr_cmc2

 2   ?  8836 root     -16 10 39044K 18820K run      0:36  3.02  3.01 midaemon

 4   ?  3225 oracle   154 20  7328M   844K sleep    3:55  2.95  2.95 oraclecmc2  

 6   ? 22339 oracle   148 20  7328M  1560K sleep   47:11  2.60  2.60 ora_smon_cmc2

 6   ?     0 root     127 20    32K     0K sleep   48:24  2.34  2.34 swapper

 2   ?  5115 oracle   154 20  7332M  2072K sleep    4:06  1.73  1.72 oraclecmc2  

 2   ?  7607 oracle   154 20  7353M  1548K sleep    1:39  1.67  1.67 oraclecmc2  

 4   ? 22313 oracle   154 20  7334M  3992K sleep   22:38  1.65  1.65 ora_lmd0_cmc2  

 3   ?  4824 oracle   154 20  7332M  3160K sleep    3:12  1.53  1.53 oraclecmc2  

 3   ?  4896 oracle   154 20  7332M  3168K sleep    4:05  1.50  1.50 oraclecmc2

 1   ?  9697 oracle   154 20  7332M  3460K sleep    4:06  1.50  1.50 oraclecmc2

 5   ?  9733 oracle   154 20  7332M  2672K sleep    4:25  1.39  1.39 oraclecmc2

 4   ? 11487 oracle   154 20  7328M  1064K sleep    9:46  1.34  1.34 oraclecmc2

oracle@db02:/oracle >

 

 

2.3. 对比分析

这里可以清楚的看到空闲内存只有200M，并且几乎每个进程伴随都有很高的wait－io。于是想到对比以前的系统性能记录：

oracle@db02:/oracle > sar -u 2 10

 

HP-UX db02 B.11.11 U 9000/800    02/08/05

 

18:32:24    %usr    %sys    %wio   %idle

18:32:26      34       5      19      43

18:32:28      39       7      18      37

18:32:30      37       6      15      42

18:32:32      31       5      12      51

18:32:34      29       4       9      57

18:32:36      28       4      10      57

18:32:38      31       4      14      52

18:32:40      35       5      12      48

18:32:42      39       3      10      49

18:32:44      42       5      16      37

 

Average       35       5      14      47

oracle@db02:/oracle >

 

使用sar –u 命令我们看到，那时的系统状态是非常良好的，CPU的idel平均值（%idle）在47％，而系统的wait io（%wio）的平均值在14％，这是一个比较理想的状态。

 

再来看系统正常时候的内存使用情况：

oracle@db02:/oracle > vmstat 2 10

         procs           memory                   page                              faults       cpu

    r     b     w      avm    free   re   at    pi   po    fr   de    sr     in     sy    cs  us sy id

    5     2     0   930013  1008560  127    9     0    0     0    0     0  17382 114792  6110  21  6 73

    6     2     0   988914  1007728  208   40     0    0     0    0     0  15703 128093  7582  47  7 46

    6     2     0   988914  1007665  203   50     0    0     0    0     0  15603 127244  7496  42  6 52

    6     2     0   988914  1007664  213   63     0    0     0    0     0  15444 126853  7647  48  6 45

    6     2     0   988914  1007552  136   40     0    0     0    0     0  15592 133625  7417  39  4 56

    6     2     0   988914  1007265  163   54     0    0     0    0     0  15733 140186  7161  40  5 54

    4     1     0  1004118  1007248  104   34     0    0     0    0     0  15356 137336  6836  44  5 51

    4     1     0  1004118  1006640  130   46     1    0     0    0     0  15461 138396  6926  38  5 57

    4     1     0  1004118  1006641  163   59     1    0     0    0     0  16366 148071  7617  42  6 51

    4     1     0  1004118  1006640  104   37     1    0     0    0     0  15761 136805  7334  40  4 55

oracle@db02:/oracle >

 

 

 

我们看到，虽然也存在有一些等待队列，但是系统的可用内存在4G左右（free*page size=1008560*4096=4131061760 byte）。系统的几乎没有page in。

 

情急之下，请业务人员停掉一个应用，以便系统稳定在free memory在200M左右，然后开始进一步定位问题的原因。

 

现在，检查一下当前的oracle进程数目，是否由于今天的业务太多，或者连接的用户太多造成的压力呢？

 

oracle@db02:/oracle > ps -ef | grep oracle| wc -l

842

oracle@db02:/oracle >

 

这个数值和平时相比，是一个非常正常的值，系统曾经在并发连接数目达到1200以上仍然正常工作，因此排除了业务过量导致系统资源不足的可能性。

 

现在需要尽快找到入手的线索，既然内存不足，存在大量的page in操作，那么看一下交换分区的使用状态：

oracle@db02:/oracle > swapinfo

             Kb      Kb      Kb   PCT  START/      Kb

TYPE      AVAIL    USED    FREE  USED   LIMIT RESERVE  PRI  NAME

dev     32768000 4058864 28709136   12%       0       -    1  /dev/vg00/lvol2

reserve       - 15057520 -15057520

memory  12954600 1303496 11651104   10%

oracle@db02:/oracle >

 

 

我们看见，一个正常的系统，交换分区的使用应该在5％以内，这里交换区使用率已经达到了12％，远远超过这个一般HP系统的常规值。

 

 

2.4. 假设和分析

联系所有上面的现象，我们已经基本可以断定，系统今天的现象绝对不是由于某些单纯的用户进程引起的，应该有几种可能：

1，Oracle 的SGA设置不合理

2，Oracle 的 PGA使用有异常

3，有可能某些僵死的进程不能正常释放内存

4，有某些认为的操作造成了内存泄漏

5，遇到了HP 或者Oracle某些bug

 

我们逐步检查上述原因，继续寻找线索。首先，考虑到既然操作系统上连接的Oracle用户进程数目正常，会不会oracle的SGA设置不合理呢？

SQL> show sga

 

Total System Global Area 7391385520 bytes

Fixed Size                   747440 bytes

Variable Size            3070230528 bytes

Database Buffers         4294967296 bytes

Redo Buffers               25440256 bytes

SQL>

 

使用show sga可以清楚的看见，Oracle的SGA区仅仅的占用了物理内存7.3G左右，其中，Data buffer 使用了4G。对于这是一个有着16G物理内存的HP 7410来说，专门的作为Oracle 数据库服务器，并且没有任何的用户应用跑在上面，那么这个设置显然没有什么异常（在正常情况下，我们甚至曾经预计将再将1G到2G的系统空闲内存的分给Oracle的Data buffer来是用的）。

 

       排除了SGA设置过大的可能性，接下来看看，用户进程的时候是否有什么异常现象？这里我新建立一个连接，在不作任何操作的情况下，看看一个空的连接对系统PGA的使用情况，以观察是否有系统的bug导致的每个Oracle用户进程过渡消耗内存的可能性：

SQL> select distinct sid from v$mystat;     

 

       SID

----------

       206

 

Elapsed: 00:00:00.01

SQL> l

  1  select b.PGA_USED_MEM PGA_USED_MEM, b.PGA_ALLOC_MEM PGA_ALLOC_MEM,

  2  b.PGA_FREEABLE_MEM PGA_FREEABLE_MEM,b.PGA_MAX_MEM PGA_MAX_MEM

  3  from v$session a, v$process b

  4* where a.PADDR=b.ADDR and a.sid ='&sid'

SQL> /

Enter value for sid: 206

old   4: where a.PADDR=b.ADDR and a.sid ='&sid'

new   4: where a.PADDR=b.ADDR and a.sid ='206'

 

PGA_USED_MEM PGA_ALLOC_MEM PGA_FREEABLE_MEM PGA_MAX_MEM

------------ ------------- ---------------- -----------

      330201        612345                0    11884537

Elapsed: 00:00:00.02

 

 

很明显，一个空的进程只需要300k的内存，这是非常正常的状态。现在再观察，系统总的PGA的使用情况，看看有什么发现：

   

SQL> select sum(PGA_USED_MEM) from v$process;

 

SUM(PGA_USED_MEM)

-----------------

        561546135

 

Elapsed: 00:00:00.08

SQL>

SQL> select sum(PGA_USED_MEM) from v$process;

 

SUM(PGA_USED_MEM)

-----------------

        409176749

 

Elapsed: 00:00:00.00

SQL>

   

    这里，我们观察到，系统总的PGA的使用基本上稳定在400M到700M之间（系统设置的PGA的最大值是1G），与往常相比也是一个非常合理的状态。

 

 

2.5. 找到根源

到这里，我们可以作个简单的加减法计算，总的物理内存16G，减去Oracle SGA 占用的7.3G，再减去PGA占用的400M到700M（每时每刻根据使用情况在变话，最大为1G），再减去系统使用的和系统上显示的空闲内存，还应该有至少6个多G的内存去了哪里？

这台主机只用于数据库服务器，因此没有跑任何应用的情况下，因此不存在某些应用服务异常而占用过量共享内存段导致的内存不足（这样的案例是存在的），那么我在这里做过大胆的假设，应该是有某些异常的进程，异常的使用了将近6个多G的共享内存段，如果可以找到哪个共享内存段被谁异常使用，应该就可以找到上述种种问题的答案。

 

按照这个假设，我们使用ipcs观察共享内存段的使用情况�