AIX5.3下oracle内存持续消耗不释放问题

unodba

手头维护的系统有个库运行在AIX5.3上，单机文件系统，oracle10.2.0.4发现内存被持续消耗不释放，感觉问题比较奇怪，特发来求助，第一次的帖子为http://t.askmaclean.com/thread-1898-1-1.html。
附件vg为几次的pg vg结果前后比较，使用的是官方的post_vg.sh脚本。
session为对应时间的session查询输出结果（select * from v$process p, v$session s where s.paddr=p.addr; ）。
awr为对应时间的awr日志。
nmon为两天的nmon监控输出文件。
增加vmo参数
希望大家多给意见，工作经验有限，自己处理不来。

增加了刘大提出的命令结果，svmon-G附件为执行的root和oracle的结果，oracle因为太多，远程传输最后的没有传输完全。
session为各命令执行结果。

xifenfei

vmo -a 参数？

unodba

xifenfei 发表于 2013-3-30 09:44
vmo -a 参数？

已添加vmo附件

unodba

xifenfei 发表于 2013-3-30 09:44
vmo -a 参数？

#
# vmo -a
        cpu_scale_memp = 8
data_stagger_interval = 161
                 defps = 1
   force_relalias_lite = 0
             framesets = 2
             htabscale = n/a
     kernel_heap_psize = 4096
          kernel_psize = 16777216
  large_page_heap_size = 0
          lgpg_regions = 0
             lgpg_size = 0
       low_ps_handling = 1
       lru_file_repage = 1
     lru_poll_interval = 10
             lrubucket = 131072
            maxclient% = 10
               maxfree = 1088
               maxperm = 570736
              maxperm% = 15
                maxpin = 3238960
               maxpin% = 80
       mbuf_heap_psize = 65536
       memory_affinity = 1
         memory_frames = 4014080
         memplace_data = 2
  memplace_mapped_file = 2
memplace_shm_anonymous = 2
    memplace_shm_named = 2
        memplace_stack = 2
         memplace_text = 2
memplace_unmapped_file = 2
              mempools = 2
               minfree = 960
               minperm = 190245
              minperm% = 5
             nokilluid = 0
               npskill = 32768
             npsrpgmax = 262144
             npsrpgmin = 196608
           npsscrubmax = 262144
           npsscrubmin = 196608
               npswarn = 131072
      num_spec_dataseg = 0
             numpsblks = 4194304
     page_steal_method = 0
          pagecoloring = n/a
       pinnable_frames = 3674709
  psm_timeout_interval = 20000
pta_balance_threshold = n/a
   relalias_percentage = 0
              rpgclean = 0
            rpgcontrol = 2
                 scrub = 0
            scrubclean = 0
soft_min_lgpgs_vmpool = 0
      spec_dataseg_int = 512
      strict_maxclient = 1
        strict_maxperm = 0
              v_pinshm = 0
  vm_modlist_threshold = -1
       vmm_fork_policy = 1
    vmm_mpsize_support = 1
    wlm_memlimit_nonpg = 1

unodba

SGA一些信息

1. Current total and average values of concurrent UGA memory usage:
   
2. 
   
3. 256873736 bytes (total) and ~435379 bytes (average), for ~590 sessions.
   
4. 
   
5. Current SGA structure sizings:
   
6. 
   
7. Total System Global Area 7381975040 bytes
   
8. Fixed Size                  2095448 bytes
   
9. Variable Size            4445963944 bytes
   
10. Database Buffers         2919235584 bytes
    
11. Redo Buffers               14680064 bytes
    
12. 
    
13. Some initialization parameter values at instance startup:
    
14. 
    
15. java_pool_size=0
    
16. large_pool_size=0
    
17. olap_page_pool_size=0
    
18. pga_aggregate_target=2455764992
    
19. sga_max_size=7381975040
    
20. sga_target=7381975040
    
21. shared_pool_size=0
    
22. sort_area_size=65536
    
23. streams_pool_size=0
    
24. 
    
25. Current Time: 2013.03.28-09:00:01

复制代码

1. Current total and average values of concurrent UGA memory usage:
   
2. 
   
3. 255400416 bytes (total) and ~440345 bytes (average), for ~580 sessions.
   
4. 
   
5. Current SGA structure sizings:
   
6. 
   
7. Total System Global Area 7381975040 bytes
   
8. Fixed Size                  2095448 bytes
   
9. Variable Size            4445963944 bytes
   
10. Database Buffers         2919235584 bytes
    
11. Redo Buffers               14680064 bytes
    
12. 
    
13. Some initialization parameter values at instance startup:
    
14. 
    
15. java_pool_size=0
    
16. large_pool_size=0
    
17. olap_page_pool_size=0
    
18. pga_aggregate_target=2455764992
    
19. sga_max_size=7381975040
    
20. sga_target=7381975040
    
21. shared_pool_size=0
    
22. sort_area_size=65536
    
23. streams_pool_size=0
    
24. 
    
25. Current Time: 2013.03.28-15:00:01
    

复制代码

1. Current total and average values of concurrent UGA memory usage:
   
2. 
   
3. 248788232 bytes (total) and ~444264 bytes (average), for ~560 sessions.
   
4. 
   
5. Current SGA structure sizings:
   
6. 
   
7. Total System Global Area 7381975040 bytes
   
8. Fixed Size                  2095448 bytes
   
9. Variable Size            4445963944 bytes
   
10. Database Buffers         2919235584 bytes
    
11. Redo Buffers               14680064 bytes
    
12. 
    
13. Some initialization parameter values at instance startup:
    
14. 
    
15. java_pool_size=0
    
16. large_pool_size=0
    
17. olap_page_pool_size=0
    
18. pga_aggregate_target=2455764992
    
19. sga_max_size=7381975040
    
20. sga_target=7381975040
    
21. shared_pool_size=0
    
22. sort_area_size=65536
    
23. streams_pool_size=0
    
24. 
    
25. Current Time: 2013.03.29-09:00:02
    

复制代码

unodba

top信息因为昨天机器内存耗尽，重启了，没有。

低调小马哥

是不是内存泄漏的bug啊，11.2.0.1的orarootagent进程中aix上就有缓慢内存泄漏的bug，建议到mos上查查

xifenfei

maxclient% = 10
maxperm% = 15
这样的配置很不常见？一般都一样大小

3.6+7+2+2=14.6 ，剩余给系统的只有1G多了，出现换页频繁我个人感觉正常

处理建议：
1.增加物理内存
2. 减小sga和session数

unodba

xifenfei 发表于 2013-3-30 10:34
maxclient% = 10
maxperm% = 15
这样的配置很不常见？一般都一样大小

1. # /usr/sbin/vmo -a
   
2.         cpu_scale_memp = 8
   
3. data_stagger_interval = 161
   
4.                  defps = 1
   
5.    force_relalias_lite = 0
   
6.              framesets = 2
   
7.              htabscale = n/a
   
8.      kernel_heap_psize = 4096
   
9.           kernel_psize = 16777216
   
10.   large_page_heap_size = 0
    
11.           lgpg_regions = 0
    
12.              lgpg_size = 0
    
13.        low_ps_handling = 1
    
14.        lru_file_repage = 1
    
15.      lru_poll_interval = 10
    
16.              lrubucket = 131072
    
17.             maxclient% = 80
    
18.                maxfree = 1088
    
19.                maxperm = 3043929
    
20.               maxperm% = 80
    
21.                 maxpin = 3238957
    
22.                maxpin% = 80
    
23.        mbuf_heap_psize = 65536
    
24.        memory_affinity = 1
    
25.          memory_frames = 4014080
    
26.          memplace_data = 2
    
27.   memplace_mapped_file = 2
    
28. memplace_shm_anonymous = 2
    
29.     memplace_shm_named = 2
    
30.         memplace_stack = 2
    
31.          memplace_text = 2
    
32. memplace_unmapped_file = 2
    
33.               mempools = 2
    
34.                minfree = 960
    
35.                minperm = 760982
    
36.               minperm% = 20
    
37.              nokilluid = 0
    
38.                npskill = 32768
    
39.              npsrpgmax = 262144
    
40.              npsrpgmin = 196608
    
41.            npsscrubmax = 262144
    
42.            npsscrubmin = 196608
    
43.                npswarn = 131072
    
44.       num_spec_dataseg = 0
    
45.              numpsblks = 4194304
    
46.      page_steal_method = 0
    
47.           pagecoloring = n/a
    
48.        pinnable_frames = 3656054
    
49.   psm_timeout_interval = 20000
    
50. pta_balance_threshold = n/a
    
51.    relalias_percentage = 0
    
52.               rpgclean = 0
    
53.             rpgcontrol = 2
    
54.                  scrub = 0
    
55.             scrubclean = 0
    
56. soft_min_lgpgs_vmpool = 0
    
57.       spec_dataseg_int = 512
    
58.       strict_maxclient = 1
    
59.         strict_maxperm = 0
    
60.               v_pinshm = 0
    
61.   vm_modlist_threshold = -1
    
62.        vmm_fork_policy = 1
    
63.     vmm_mpsize_support = 1
    
64.     wlm_memlimit_nonpg = 1

复制代码

这个是调整以前的参数，当时这样的参数系统也是挂掉了，后来调整的10，15.

Maclean Liu(刘相兵

这上上下下也太享受了

Maclean Liu(刘相兵

%comp
76.6
76.4
76.4
76.4
76.4
76.4
76.4
76.4
76.4
76.4
76.4
79.2
79.2
81.9
81.9
81.9
81.9
81.9
81.9
81.9
81.9
81.9
81.9
81.9
81.9
81.9
81.9
81.9
81.9
81.9
81.9
84.8
84.8
87.5
87.5
87.5
87.6
87.6
87.6
87.6
86.5
84.7
82.8
82

一直变化的主要是comp% 计算内存

Maclean Liu(刘相兵

Event        Waits        Time(s)        Avg Wait(ms)        % Total Call Time        Wait Class
CPU time                  34,508                  41.9         
cursor: pin S wait on X         2,891,345         29,172         10         35.5        Concurrency
kksfbc child completion         76,309         3,762         49         4.6        Other
log file sync         1,437,291         1,764         1         2.1        Commit
buffer busy waits         378,238         1,421         4         1.7        Concurrency


解析很严重 这会导致PGA内存的分配

Maclean Liu(刘相兵

svmon -U grid
svmon -G


svmon -Put 10
svmon -Sut 10

svmon -P $(ps -elf | egrep "ora_smon_${ORACLE_SID}" | grep -v egrep | awk '{print $4}') | grep shmat
svmon -O unit=MB

ls -al $ORACLE_HOME/bin/oracle >> /tmp/support.txt
whoami >> /tmp/support.txt
ulimit -a >> /tmp/support.txt
svmon -O unit=MB >> /tmp/support.txt
/usr/sbin/lsps -a >> /tmp/support.txt
/usr/sbin/lsattr -HE -l sys0 -a realmem >> /tmp/support.txt
ipcs -m >> /tmp/support.txt

select name, value/1024/1024 as Mbytes from v$pgastat
where name in (‘maximum PGA allocated’,'aggregate PGA target parameter’,'aggregate PGA auto target’);

select sum(value)/1024/1024 as Mbytes from v$sga;
select current_size/1024/1024 Mbytes from V$SGA_DYNAMIC_FREE_MEMORY;
ipcs -mb

查一下 把输出的结果 上传

Maclean Liu(刘相兵

另一个问题是：

cursor_sharing        =======>>>>SIMILAR

Stone

xifenfei 发表于 2013-3-30 10:34
maxclient% = 10
maxperm% = 15
这样的配置很不常见？一般都一样大小

同意@xifenfei的看法，感觉sessions设置到3305有点儿过高啦，而且从贴出的sessions数量监控来看，即使最高的也没有超过1000。那么sessions过高，肯定会消耗过多的memory,那么内存消耗完，也就属于正常现象啦。另外加上Soft Parse%过低，Hard Parse过高，所以也导致了过量的内存消耗。

系统物理内存16G，按照目前的sessions和hard parse情况，从目前的advisory数据来看，buffer pool分配2.7G太少，应该到5.4G。Shard Pool大小4G感觉还不够，应该到6G多。所以SGA的advisory应该到12G多，所以目前的SGA_TARGET只有7G多还是小啦。当然这是根据目前的不合理设置估计出来的，调整这些不合理的参数，减少硬解析乃当务之急，应该可以大大减小内存的使用。

纯属个人意见，仅供参考 :)

unodba

Maclean Liu(刘相兵 发表于 2013-3-30 17:13
另一个问题是：

cursor_sharing        =======>>>>SIMILAR

上周五将参数进行了一下调整，      
   1、修改参数cursor_sharing
              alter system set cursor_sharing='EXACT';
         2、修改参数sga_target
              alter system set db_cache_size=2000M;
              alter system set shared_pool_size=4900M;
              alter system set java_pool_size=50M;
              alter system set large_pool_size=40M;
              alter system set sga_target=0 scope=spfile;
周六把maxclient%=15，调整成与maxperm一样了。

输出结果执行太多了，放在附件了

unodba

Stone 发表于 2013-3-31 00:42
同意@xifenfei的看法，感觉sessions设置到3305有点儿过高啦，而且从贴出的sessions数量监控来看，即使最 ...

谢谢建议，session是设置的太高了，后面改下来，这个参数当时没有考虑太多

Stone

unodba 发表于 2013-3-31 13:16
谢谢建议，session是设置的太高了，后面改下来，这个参数当时没有考虑太多 ...

不客气。建议在调整后，及时监控主要性能数据，做下业务正常高峰时段的AWR报告，上传。然后大家再一起分析下调整后的运行状况，方便总结调整的效果。

Good luck

hzhg

Maclean Liu(刘相兵 发表于 2013-3-30 17:10
Event        Waits        Time(s)        Avg Wait(ms)        % Total Call Time        Wait Class
CPU time                  34,508                  41.9         
cursor: p ...

解析不是SGA里的么，怎么会pga分配呢？

hzhg

Stone 发表于 2013-3-31 00:42
同意@xifenfei的看法，感觉sessions设置到3305有点儿过高啦，而且从贴出的sessions数量监控来看，即使最 ...

弱弱的问一句，session设置过大，但是没有使用难道也会分配pga么？

Maclean Liu(刘相兵

hzhg 发表于 2013-3-31 15:01
解析不是SGA里的么，怎么会pga分配呢？

硬解析时 需要pga分配内存才能做的， 好比是 我这个人 写了一本书， 写的时候是 我这个人花时间花空间，写好了 我共享出来 放到共享池里， 共享池当然也要花空间。 但写书的时候是 我在花时间和空间啊，而往往这个空间还比后面的大。

Stone

hzhg 发表于 2013-3-31 15:03
弱弱的问一句，session设置过大，但是没有使用难道也会分配pga么？

@hzhg，谢谢你的问题，问的很好。

我查了下，可以参考下AskTom的问答，非常好：
http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:670546500346748368

根据Tom的回答，我的理解是，没有使用的话，pga应该影响不大。但是过大的sessions设置对SGA是有影响的。

特别是对于这个系统来说，CPU只有8个，设置的processes 3000, sessions达到3305，那么就肯定不合适啦。(Sessions = Processes*1.1 + 5 = 3000*1.1 + 5 = 3305) Processes参数设置好了，Sessions数了就定了，Sessions是一个Derived parameter。

setting processes too high will use a little extra SGA memory for some structures that are allocated based on processes and may make some lookups take a little longer (lookups in SGA structures) but would not generally have a noticeable impact. It would be noticeable if something caused many processes to spawn however ;)

So what happens if I set processes to, for example 2000 but only 500 are needed?  Or sessions to
1000 when only 200 are needed?

Many thanks in advance!


Followup   January 13, 2011 - 10am UTC:

you will consume more SGA resources as that parameter is used to size many data structures.

Look at your machine, if you have say an 8 cpu machine and you have processes set to more than 200 or so - you have set it too high. Your 8 cpu machine cannot possibly do 2000 processes. You need to get your connection pool(s) under control or start employing shared server.

@unodba,
另外是否有可能应用使用了连接池pool, 连接池的Size设置过大，造成过多的Inative sessions在DB里面，而这些Sessions应该是会消耗PGA的。

可以参考Tom关于processes的设置：

think about how many processes you'll have -

the Oracle backgrounds (give them 15)              15

plus your user sessions
(number of shared servers/dedicated servers)    1000

number of job processes/aq processes
you want to permit                                                    10

parallel execution servers if applicable.                      0
                                                                                  ========
                                                                                      1025

欢迎讨论 :)

hzhg

Stone 发表于 2013-3-31 16:08
@hzhg，谢谢你的问题，问的很好。

我查了下，可以参考下AskTom的问答，非常好：

照tom的说法，过大的process却是对sga有一点影响，但是不会有明显的影响：but would not generally have a noticeable impact
如果设置了过大的连接池，这些连接都是常连接，肯定会占用pga的。

zhoumange

感觉是session数太多了，10g一个session在 操作系统 的 额外开销接近20M。建议先将SGA减小到4G