概述
ug 12 15:55:04 zw-db1 kernel:
Aug 12 15:55:04 zw-db1 kernel: Free pages: 13944kB (704kB HighMem)
Aug 12 15:55:04 zw-db1 kernel: Active:494884 inactive:7812 dirty:0 writeback:0 unstable:0 free:3486 slab:12664 mapped:491548 pagetables:511844
Aug 12 15:55:04 zw-db1 kernel: DMA free:12384kB min:16kB low:32kB high:48kB active:0kB inactive:0kB present:16384kB pages_scanned:2694 all_unreclaimable? yes
Aug 12 15:55:04 zw-db1 kernel: protections[]: 0 0 0
Aug 12 15:55:04 zw-db1 kernel: Normal free:856kB min:928kB low:1856kB high:2784kB active:268kB inactive:128kB present:901120kB pages_scanned:25707 all_unreclaimable? yes
Aug 12 15:55:04 zw-db1 kernel: protections[]: 0 0 0
Aug 12 15:55:04 zw-db1 kernel: HighMem free:704kB min:512kB low:1024kB high:1536kB active:1979268kB inactive:31120kB present:4325376kB pages_scanned:33 all_unreclaimable? no
Aug 12 15:55:04 zw-db1 kernel: protections[]: 0 0 0
Aug 12 15:55:04 zw-db1 kernel: DMA: 4*4kB 4*8kB 3*16kB 2*32kB 3*64kB 2*128kB 2*256kB 0*512kB 1*1024kB 1*2048kB 2*4096kB = 12384kB
Aug 12 15:55:04 zw-db1 kernel: Normal: 0*4kB 7*8kB 4*16kB 1*32kB 1*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 856kB
Aug 12 15:55:04 zw-db1 kernel: HighMem: 48*4kB 0*8kB 0*16kB 0*32kB 0*64kB 2*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 704kB
Aug 12 15:55:04 zw-db1 kernel: Swap cache: add 2595842, delete 2582907, find 1979373/2295790, race 2+2179
Aug 12 15:55:04 zw-db1 kernel: 0 bounce buffer pages
Aug 12 15:55:04 zw-db1 kernel: Free swap: 6359420kB
Aug 12 15:55:04 zw-db1 kernel: 1310720 pages of RAM
Aug 12 15:55:04 zw-db1 kernel: 819050 pages of HIGHMEM
Aug 12 15:55:04 zw-db1 kernel: 274055 reserved pages
Aug 12 15:55:04 zw-db1 kernel: 16929688 pages shared
Aug 12 15:55:04 zw-db1 kernel: 12863 pages swap cached
Aug 12 15:55:04 zw-db1 kernel:
Out of Memory: Killed process 19156 (oracle).
Aug 12 16:00:11 zw-db1 kernel:
Mem-info:
OOM是Out of Memory的简写,也就是内存不足。出现该问题的原因有很多,如程序内存泄漏等。内存泄漏问题可以通过定时地终止和重启有问题的程序来发现和解决。在Linux内核版本(比如2.6)中,有一种名为OOM(Out Of Memory )杀手的算法,它可以在必要时执行Kill而杀掉一些程序。
oom-killer只考虑lowmemory而不考虑highmemory,即便这个时候物理内存还有很多free或者cached或者buffer,只要swap不足,便会执行oom-killer。解决办法:
一、将oracle锁定在物理内中
SQL> show parameter sgaNAME TYPE VALUE
------------------------------------ ----------- ------------------------------
lock_sga boolean FALSE
pre_page_sga boolean FALSE
oracle实例启动时,会只载入各个内存区最小的大小。而其他SGA内存只作为虚拟内存分配,只有当进程touch到相应的页时,才会置换到物理内存中。但我们也许希望实例一启动后,所有SGA都分配到物理内存。这时就可以通过设置PRE_PAGE_SGA参数来达到目的了。
这个参数的默认值为FALSE,即不将全部SGA置入物理内存中。当设置为TRUE时,实例启动会将全部SGA置入物理内存中。它可以使实例启动达到它的最大性能状态,但是,启动时间也会更长(因为为了使所有SGA都置入物理内存中,oracle进程需要touch所有的SGA页)。 为了保证SGA都被锁定在物理内存中,而不必页入/页出,可以通过参数LOCK_SGA来控制。这个参数默认值为FALSE,当指定为TRUE时,可以将全部SGA都锁定在物理内存中。当然,有些系统不支持内存锁定,这个参数也就无效了。
二、解决oracle为什么不使用swap空间
简单怀疑swap空间会不会有什么问题?重建一些swap,权且试试看先移除原来的swap区 #swapoff /dev/sda3
创建/swap做为新的swap区,新swap分区的大小是物理内存的1.5倍,为了以后同样生效,编辑/etc/fstab文件。 #dd if=/dev/zero of=/swap bs=1024 count=$[1024 * 1024 * 物理内存*1.5]
#mkswap /swap
#swapon /swap
三、关闭oom-killer或者降低其出现的几率
echo 1 > /proc/sys/vm/panic_on_oom或者(推荐这个,一些提及oracle优化的文章中也推荐这个)
echo 1 > /proc/sys/vm/overcommit_memory
或者
echo 0 > /proc/sys/vm/overcommit_ratio
来关闭oom-killer,具体参考相关说明。
------------------------------------------------------------------------------------------
#echo 2>/proc/sys/vm/overcommit_memory
#echo 0>/proc/sys/vm/overcommit_ratio
-------------------------------------------------------------------------------------------
实际测试:
overcommit_memory ==2 ,物理内存使用完后,打开任意一个程序均显示“内存不足”;
overcommit_memory ==1,会从buffer中释放较多物理内存,适合大型科学应用软件,但oom-killer机制仍然起作用;
overcommit_memory ==0,系统默认设置,释放物理内存较少,使得oom-killer机制运作很明显。
最后
以上就是朴素月亮为你收集整理的当oracle遇上oom-killer的全部内容,希望文章能够帮你解决当oracle遇上oom-killer所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复