如何解决out of memory ,并自动杀ORACLE进程?谢谢

发布于 2022-10-01 20:14:08 字数 11180 浏览 11 评论 0

大家好,我有一台HP 3000 服务器,redhat 7.1+ apahce + oracle 8.1.7 ,作为 WWW及ORACLE SERVER服务器。
内存1G,swap 2G  . 近来,该机器发生了几次ORACLE 进程死掉,而其它服务进程还可以正常运行的情况。我查
看系统信息,发现SWAP空间被大量消耗,我将ORACLE 服务器停止,该SWAP空间还是有1994200K被消耗掉了。
  :( 如下所示:

10:09am  up 299 days, 15:09,  4 users,  load average: 1.32, 1.69, 1.57
151 processes: 148 sleeping, 3 running, 0 zombie, 0 stopped
CPU states: 27.5% user, 72.4% system,  0.0% nice,  0.0% idle
Mem:  1028800K av,  785580K used,  243220K free,       0K shrd,   47728K buff
Swap: 2048248K av, 1994200K used,   54048K free                  578468K cached

我的内存信息:
Memory: 1028176k/1048512k available (1365k kernel code, 19944k reserved, 92k data, 236k init, 131008k highmem)

同时,用dmesge 命令可以看到很多这样的信息:应该是将ORACEL进程杀死前的信息

__alloc_pages: 0-order allocation failed.
__alloc_pages: 0-order allocation failed.
__alloc_pages: 0-order allocation failed.
__alloc_pages: 0-order allocation failed.
__alloc_pages: 0-order allocation failed.
__alloc_pages: 0-order allocation failed.
TCP: Treason uncloaked! Peer 218.20.159.235:44299/8080 shrinks window 4116856850:4116860990. Repaired.
TCP: Treason uncloaked! Peer 218.13.66.216:39666/8080 shrinks window 635871618:635879898. Repaired.
__alloc_pages: 0-order allocation failed.
__alloc_pages: 0-order allocation failed.
__alloc_pages: 0-order allocation failed.
__alloc_pages: 0-order allocation failed.
__alloc_pages: 0-order allocation failed.
Out of Memory: Killed process 31879 (oracle).
Out of Memory: Killed process 32186 (oracle).
Out of Memory: Killed process 17043 (oracle).
Out of Memory: Killed process 26442 (oracle).
Out of Memory: Killed process 17359 (oracle).
Out of Memory: Killed process 17449 (oracle).
Out of Memory: Killed process 17432 (oracle).
Out of Memory: Killed process 17489 (oracle).
Out of Memory: Killed process 17504 (oracle).

在messages 中也有报错:
kernel: Out of Memory: Killed process 20814 (oracle).

数据库信息:

SQL>; select 100*sum(gets - getmisses - usage - fixed)/sum(gets) 行缓冲区命中率 from v$rowcache;

行缓冲区命中率
--------------
      93.42071

SQL>; select 100*sum(pins-reloads)/sum(pins) 库缓冲区命中率 from v$librarycache;
库缓冲区命中率
--------------
    99.9075358

SQL>; select 100*(1-(select value from v$sysstat where name = 'physical reads')/((select value from v$sysstat where name = 'db block gets')+(select value from v$sysstat where name = 'consistent gets'))) 高速缓冲区命中率 from dual;
高速缓冲区命中率
----------------
      99.7720807

SQL>;  column name format a25;
SQL>; select * from v$sgastat;

POOL                   NAME                           BYTES
---------------------- ------------------------- ----------
                       fixed_sga                      73888
                       db_block_buffers           314572800
                       log_buffer                   1048576
shared pool            free memory                206076448
shared pool            miscellaneous                 442528
shared pool            PL/SQL MPCODE                  92572
shared pool            KQLS heap                     201768
shared pool            branches                       45120
shared pool            ktlbk state objects            80036
shared pool            table definiti                   320
shared pool            KGK heap                        4228

POOL                   NAME                           BYTES
---------------------- ------------------------- ----------
shared pool            latch nowait fails or sle      37632
shared pool            db_files                       72496
shared pool            db_handles                     75000
shared pool            sessions                      366520
shared pool            trigger inform                   404
shared pool            State objects                 194024
shared pool            KGFF heap                       8404
shared pool            character set object           67664
shared pool            SYSTEM PARAMETERS              63328
shared pool            long op statistics array       74800
shared pool            fixed allocation callback        320

POOL                   NAME                           BYTES
---------------------- ------------------------- ----------
shared pool            enqueue_resources              69696
shared pool            PL/SQL DIANA                  368428
shared pool            DML locks                      89760
shared pool            dictionary cache              205196
shared pool            PLS non-lib hp                  2096
shared pool            table columns                  17172
shared pool            character set memory          136812
shared pool            message pool freequeue        116176
shared pool            library cache                 937428
shared pool            db_block_buffers             5222400
shared pool            sql area                      944784

POOL                   NAME                           BYTES
---------------------- ------------------------- ----------
shared pool            db_block_hash_buckets         745480
shared pool            processes                     119400
shared pool            log_buffer                     32768
shared pool            transactions                  166804
shared pool            event statistics per sess     590240
large pool             free memory                  6144000
java pool              free memory                 20971520

40 rows selected.

我将/proc/sys/kernel/shmall 的值2097152,改为4294967295 了, 情况依然不变。

我想请问几个问题:
1,如何查看操作系统中SWAP空间被谁占用了?
2,看情况可能是ORACLE无法获得所需的内存,但为何我将ORACLE停掉,SWAP空间利用情况依然没有改变呢?
3,我的ORACLE是否需要进行参数调整呢?
4,谁可以帮我分析一下这个奇怪现象是这么回事么?非常感谢。。。

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文