一次增加内存引发的血案 (由pre_page_sga引发的)

一次增加内存引发的血案 (由pre_page_sga引发的)

把我在itpub上的帖子抄过来..警示自己.

http://www.itpub.net/thread-1318170-1-1.html

昨天对一台服务器增加内存 顺带插一块HBA卡,装HBA卡的驱动...win 2003 64bit ,ora 版本10.2.0.4.0 ,机器IBM 3850 M2 7233 
原本8G,加完后16G, 
把sga_max_size ,sga_target改好,启动数据库,把应用也启动, 
接着奇异的事就来了~ 随着前台的应用的增长 反应速度越来越慢, 并且速度是慢在连接数据库的那一会儿 
(我们是短连接,断开式连接,无共享池,专用模式) 
....接着应用的压力达到正常水平后,数据库基本没法使用了.. 
这时 tnsping ,返回至基本在500~1000ms左 右,慢得离谱,正常值应该在10~100ms. 

(但是在应用服务器上ping 数据库服务器, -t -l 60000的包,返回时间<15ms ) 

我手工SQLplus连接数据库,连接的那一会确实非常慢,5~10秒不等, 连上了后面查询数据速度不慢,均正常. 
这点可以从AWR报告里看出. 

接着折腾了1小时,还临时换了个2万元的交换机过来...(这里折腾了一会, ping 大包,返回时间已经可以<1ms,但是无奈tnsping仍然很慢). 

诊断无果,最后把内存,HBA卡拔了...结果就恢复正常了.. 
大伙有无遇过类似这样的事..? 

后来想起,我当时应该弄个trace的,诶,过于着急,当时是生产机,对停机时间有严格要求... 

 

QUOTE:原帖由 lfree 于 2010-6-25 15:51 发表
应许是你根本没有加到内存，使用swap做内存。 
这一点 我还是能确认的,因为我改了sga_max_size, 和target, 并且启起来了(原本sga是4G左右,改后是9G), 也相应把虚拟内存加到8G了,
最后,即使我把sga_max_size, 和target 调整回原来的4G, 问题仍然是存在的,我用了pre_sga,由于是windows无法用lock sga
但是如果想确认 DB是否一直在用虚拟内存, 当时如果能记起用perfmon来看就好了 
T.T 无奈时间紧迫...

 

/****************************************************************************************************/ 
                                     第二次编辑的分割线 
/****************************************************************************************************/ 
枯荣长老 21:29:59 
On a sensibly configured system you would not expect paging to be 
  a problem. There have been several performance problems in the 
  past related to setting this parameter to TRUE. If you experience 
  delays connecting to Oracle and this parameter is set to TRUE 
  then it may be worth checking performance with it set to FALSE. 
  This is more likely to be a problem with large SGAs. 

枯荣长老 21:31:15 

PRE_PAGE_SGA can increase the process startup duration, because every process that starts must access every page in the SGA. The cost of this strategy is fixed; however, you might simply determine that 20,000 pages must be touched every time a process starts. This approach can be useful with some applications, but not with all applications. Overhead can be significant if your system frequently creates and destroys processes by, for example, continually logging on and logging off. 

pre_page_sga 为true时, 每个进程创建的时候都会去touch一遍sga里的page, 当sga越大的时候,这个touch所消耗的时间就越长,
特别是在断开式连接,短连接的Application上, 将会消耗很多资源.

 

枯荣长老的提示一针见血, 之后 set pre_page_size =false 后, 就恢复正常了, tnsping 的返回值在10~20ms之间.

之前之所以没有问题,估计是因为4G的SGA 配合上 pre_page_sga=true 再加上我们应用上的并发压力, 并没有突破这个性能slow的临界点(我猜测并发如果再大一些的话,应该也会突破这个点),其实隐患一直都存在了,这个pre_page_sga=true就一直用到最近, 结果那天一加内存 ,变成了9G的SGA, 估计touch 4G的SGA和9G的SGA差别很大 ,问题就立马暴露出来了.

 

本问题结束,希望以后类似的血案不再发生....

 

去年急忙上系统时,临时啃了啃文档,调了些参数就上线了 ,由于当时是第一次接触oracle ,对参数理解不够充分 埋下了隐患..

反省 反省, 还是需要多看文档,多总结 ..