数据库

位置:IT落伍者 >> 数据库 >> 浏览文章

Oracle9i进程内存占用问题解决方法


发布日期:2023年07月14日
 
Oracle9i进程内存占用问题解决方法

发现Oracle公布了有关此问题的一些说明和部分解决方法大致的内容是AIX可以打个补丁来获得更好的效果而其他版本只能通过设置以下环境变量来减少消耗

AIXTHREAD_SCOPE=S;export AIXTHREAD_SCOPE

NUM_SPAREVP=; export NUM_SPAREVP(AIX

详细内容参考Metalink文档 Memory Consumption on AIX此文档是DEC创建的最近更新JAN

我们拿了一台新的M安装了AIX开始测试这一结果设置这些环境可以起一定的作用但没有明显效果

根据文档说明安装AIX APAR IY补丁执行如下步骤

从这里下在相关脚本

) save your current version of $ORACLE_HOME/oracle

) create a working directory $ORACLE_HOME/relink

) cd to $ORACLE_HOME/relink

) unzip the relinking package

) link $ORACLE_HOME/bin/oracle to /oracle

) run the script /genscript to generate some required files and scripts

) run /relinksh to generate the new oracle binary oraclenew$$

) copy oraclenew$$ to $ORACLE_HOME/bin/oracle and verify that the permissions match the original oracle binary

验证结果很明显内存占用改善了很多没有打补丁的一个空连接server进程占用最低都是M多而现在只有M多改善了%!

hawk> ps v (没打补丁的空连接)

PID TTY STAT TIME PGIN SIZE RSS LIM TSIZ TRS %CPU %MEM COMMAND

A : xx oracle

localhost> ps v (打过补丁的空连接)

PID TTY STAT TIME PGIN SIZE RSS LIM TSIZ TRS %CPU %MEM COMMAND

A : oracleor

虽然说这里ps v看到的结果不是很准确但是二者使用相同的标准计算并不影响对比结果而且和我们使用NMON的统计结果也是一致的

至此Oraclei在AIX上的内存占用问题算是基本解决了前后经历了快一年的时间这恐怕是我关注一个Oracle问题时间最久的一次理由很简单这是工作需要生产需要要知道这么随便一搞给我们剩下了很多麻烦之前为了允许更多的连接我们不得不将内存从G扩容到G现在一降下来可以为企业节省很多硬件投入毕竟这玩艺内存卖的还是挺贵的而这是无成本的

过去这段时间我工作的其中之一就是在为一个电信业务系统的升级做准备在两台IBM MCPU*G MEM AIX L)上对ORACLEI RAC做详细的测试工作开始的时候一切都很顺利但后来却遇到一个难题就是Oracle i的单个进程占用的内存过多

经过一段时间测试在先后解决了其它问题后最后的主要问题集中到了内存上ORACLEi在AIX L上每个进程都占用了很多内存一个空连接进程就会用到M多的内存而众所周知Oraclei的单个进程占用的内存一般是~M所以这就引起了我们的高度重视因为如果按此计算个连接什么事不做就要G内存了!而我们的实际应用连接数比这还要多

在出现问题之后我先后对ORACLE进行了不同方向的调整也问过了一些朋友以及IBM和ORACLE的技术支持 翻遍了国内外我所知道的论坛都没有看到任何有意思的消息更不要说解决方案了这让我开始怀疑是Oraclei的BUG果然在月底Oracle公布了这个BUG(我是在月底看到的因为月份的大部分时间在处理别的事)!造成这个问题是因为AIX上C的编译器问题使得本来可以共享的部分最后都没有共享造成每个进程都浪费了大约MB的内存详情参见本文最后BUG的描述

为了验证确实是AIX的问题我在另外一台HPUX B上进行了同样的测试结果显示Oraclei的单个进程仍然占用很多内存!经过分析发现这是由于两方面原因造成的

Oraclei的初始化参数CURSOR_SPACE_FOR_TIME从默认的FALSE改成了TRUE

HPUX上的Oraclei将虚拟内存数据页(virtual memory data pages)的默认值从原来的D(KB)改成了L(GB)

使用/usr/bin/chatr $ORACLE_HOME/bin/oracle查看oracle程序的内部属性 我们发现虚拟内存的text段从原来的M改成了M而DATA段从原来的M改成了L(最大可达到GB)经过测试验证 DATA段这个参数直接影响了Oraclei单个进程所占用的内存的大小 对于空连接来说MB是扩展的临界点因为空连接是扩不到MB(MB的下一个可设DATA段大小)

Oraclei和Oraclei虚拟内存默认值对比

i

shared library binding:

deferred

global hash table disabled shared vtable support disabled segments:

index type address flags size

text zrc M

data m M

executable from stack: D (default)kernel assisted branch prediction enabled lazy swap allocation for dynamic segments disabled

i

shared library binding:

deferred

global hash table disabled shared vtable support disabled segments:

index type address flags size

text zrc M

data m L (largest possible)executable from stack: D (default)kernel assisted branch prediction enabled lazy swap allocation for dynamic segments disabled

我们可以使用/usr/bin/chatr +pd newsize $ORACLE_HOME/bin/oracle来更改DATA段的可用内存大小对于text段的内存大小我们也可以使用chatr +pi来改但gototop并不建议你这样做因为text段是给命令用的

至此我就在想了自然在HPUX上是因为这个原因造成的那么在AIX上除了C编译器的原因之外是否也存在着同样的问题呢?到目前为止gototop还没有的等到任何可靠的消息来证明这一点但我猜想可能性很大

BUG:描述

//jpg>

问题陈述:

ORACLE ON AIX DOES NOT SHARE MANY CONST STRUCTS PER PROCESS MEMORY OVERHEAD

*** // : am ***

=========================

PROBLEM:

Clear description of the problem encountered:

Oracle on IBM AIX platforms (AIX L and ) use a large amount of memory per dedicated connection For Oracle on AIX L the memory required per idle Oracle process appears to be about Mb A significant portion of this is related to nonshared const structures (probably about Mb)

This bug is to track the issue of the nonshared const structures

上一篇:pl/sql查询字段为科学计数法

下一篇:性能陷阱:Oracle表连接中范围比较