数据库oracle实际使用的内存---AIX产生大量的swap反思

最新推荐文章于 2023-09-21 16:36:24 发布

转载最新推荐文章于 2023-09-21 16:36:24 发布 · 902 阅读

ORACLE数据库故障处理分析专栏收录该内容

24 篇文章

订阅专栏

本文揭示了一个Oracle数据库实例因内存配置不当导致系统频繁使用swap的问题。原本配置给Oracle的100GB内存中，PGA和SGA的实际使用量分别达到36GB和90GB，总计126GB，超出分配，耗尽了系统内存，迫使操作系统启动swap机制。通过查询发现，一个高频率运行的复杂查询消耗了大量PGA资源，平均每分钟200次调用，每次查询占用约1GB PGA空间，最终导致内存不足。解决此问题需调整PGA配置并优化查询。

来看看oracle实际使用的内存：

select sum（pga_alloc_mem）/1024/1024/1024 Alloc from v$process ; +
select sum(value)/1024/1024/1024 as b  from v$sga  + 进程本身消耗的内存。

操作系统频繁使用swap，原因基本是系统内存不够用了。从数据库的内存配置来看，128G总内存，配置给ORACLE 100g ，留给操作系统约30G，讲道理，应该是够用的了。

来看看oracle实际使用的内存：

select sum（pga_alloc_mem）/1024/1024/1024 Gb_Alloc from v$process ;
36.3
select sum(value)/1024/1024/1024 as Gb  from v$sga ;
90

看出问题来了，实际使用内存数量为：90+ 36 = 126G，已经耗干了操作系统的所有内存，不使用swap才怪呢。很容易看出，问题的关键在于PGA这里，pga_aggregate_target 配置为10G，但是实际使用了36G，这是有可能的，pga_aggregate_target配置的值是个软限制，实际使用pga的使用是可以超过这个限制的。oracle会根据这个配置去限定每个服务进程使用的pga使用上限。假设在某一时段，有大量的进程都需要排序操作、大表hash join等等，从而从PGA里分走的都是一个上限值，那么就会发生上面的这种情况。

故障很容易定位到源头。应用系统有一个很频繁的查询，大概一分钟会被查询200次左右，该查询的逻辑相当的复杂，不过之前优化过，整体的开销已经不高了。昨晚因为一个需求，对查询做了一点点改动，仅仅是局部测试后就丢上生产了，结果在实际生产中，每一次查询都会有十几个大表进行hash连接。想一想，一分钟200次的查询，每次查询计算过会分走约1G的PGA空间，可想而知，结果会怎么样。

PS：应用配置了连接池，限制活动的连接数量为50个，因此PGA的消耗36G，数据基本吻合上面的估算了