zoukankan      html  css  js  c++  java

  • oracle 12c RAC其中一节点内存率异常高

    一、概述

    • 环境：suse+12c rac环境，配置：16C48G

    • 问题：suse+12c rac环境，其中rac一节点异常使用率很高，将近占100%，而同样的负载，另一节点内利用率才70%。 

    二、诊断过程

    2.1、oracle配置查看(SGA+PGA)

    1、查看SGA的使用

     

    SQL> show parameter sga;
​
NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
allow_group_access_to_sga            boolean                FALSE
lock_sga                             boolean                FALSE
pre_page_sga                         boolean                TRUE
sga_max_size                         big integer            20G
sga_min_size                         big integer            0
sga_target                           big integer            20G
unified_audit_sga_queue_size         integer                1048576

    　　

    2、查看PGA

    • 查看pga参数

    SQL> show parameter pga
​
NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
pga_aggregate_limit                  big integer            7500M
pga_aggregate_target                 big integer            3217M

    • 查看pga的实际使用情况

    SQL> select sum(PGA_MAX_MEM)/1024/1024 "MB" from v$session a,v$process b where a.PADDR=b.ADDR;
​
        MB
----------
1214.61253

    通过上述查询如知，实际pga的使用才占1.2G。SGA(20G)+PGA(1.2G)=21.2G，而系统却占用了48G，继续跟踪其他剩余内存的去向。

    • 查看pga历史使用最大值（PGA最大使用将近3G）

    SQL>  select name,value/1024/1024/1024 "GB" from  dba_hist_pgastat where name like '%maximum PGA allocated%' order by GB desc;
​
NAME                                                                                                                                     GB
-------------------------------------------------------------------------------------------------------------------------------- ----------
maximum PGA allocated                                                                                                             2.9895134
maximum PGA allocated                                                                                                             2.9895134
maximum PGA allocated                                                                                                             2.9895134
maximum PGA allocated                                                                                                             2.9895134
maximum PGA allocated                                                                                                             2.9895134
maximum PGA allocated                                                                                                             2.9895134
maximum PGA allocated                                                                                                             2.9895134
maximum PGA allocated                                                                                                             2.9895134
maximum PGA allocated                                                                                                             2.9895134
maximum PGA allocated                                                                                                             2.9895134
maximum PGA allocated                                                                                                             2.9895134
maximum PGA allocated                                                                                                             2.9895134
maximum PGA allocated                                                                                                             2.9895134
maximum PGA allocated                                                                                                             2.9895134
maximum PGA allocated                                                                                                             2.9895134
maximum PGA allocated                                                                                                             2.9895134
                                                                                    

    2.2 系统方面

    1、查看共享内存段的使用情况

    • 查看ipcs共享内存段的使用情况，具体如下没有发现异常。

    prd-mes-wdb02:~ # ipcs -mb
​
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x6c0144b7 0          zabbix     600        949056     12                      
0x00000000 2654209    grid       600        4096       0                       
0x00000000 2686978    grid       600        4096       0                       
0xc5a94c0c 2719747    grid       600        24576      39                      
0x00000000 5701636    oracle     600        15712256   340                     
0x00000000 5734405    oracle     600        16844324864 170                     
0x00000000 5767174    oracle     600        4563402752 170                     
0x00000000 5799943    oracle     600        51396608   170                     
0x81d24290 5832712    oracle     600        28672      170

    通过查询没有发现共享内存段状态为D - Delete，这在通常情况下是正常的。

    说明：

    如果发现共享内存段状态为D - Delete，那通常是不正常的，在这是一个Oracle用户占用的共享内存段，由于状态为D的共享内存段本身就是没有正常使用的内存段，所以满以为使用ipcrm -m id删除这个共享内存段，应该就可以解决问题，但是，当时上述做法的结果是系统报告找不到找个ID。

    [localhost]#ipcrm -m 13893637

    现在我们使用shminfo要使用root权限，查看一下当前到底哪个进程在使用找个共享内存段：

    [localhost]#shminfo -s 13893637

    2、查看/proc/meminfo

    通过查看发现PageTables只使用了500M左右，基本排除PageTables引起的问题。PageTables是内存表，是不共享的，在内存很大的情况下，如果很大process访问内存的话，就会每个process都copy一份PageTables，最终导致大量内存自耗的情况。

    [prd-mes-wdb02@/home/oracle]$cat /proc/meminfo 
MemTotal:       49460972 kB
MemFree:         1824472 kB
MemAvailable:     534148 kB
Buffers:           60776 kB
Cached:         21593536 kB  --21G(包括SGA)
SwapCached:        76884 kB
Active:         43152452 kB
Inactive:        2742528 kB
Active(anon):   42709652 kB
Inactive(anon):  2542128 kB
Active(file):     442800 kB
Inactive(file):   200400 kB
Unevictable:      387576 kB
Mlocked:          387576 kB
SwapTotal:      31456252 kB
SwapFree:       28926564 kB
Dirty:               452 kB
Writeback:             0 kB
AnonPages:      24575348 kB
Mapped:         19555580 kB
Shmem:          20876148 kB
Slab:             388704 kB
SReclaimable:     313392 kB
SUnreclaim:        75312 kB
KernelStack:       15392 kB
PageTables:       484012 kB  --480MB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    56186736 kB
Committed_AS:   50301640 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:    27434816 kB
DirectMap2M:    22896640 kB
DirectMap1G:     2097152 kB
​

    image-20210604102030236

    3、查看进程使用内存情况

    25节点：
prd-mes-wdb02@/home/grid]$ps aux |grep -E "asm_dia0"
grid     20131  0.0  0.0  10528  1556 pts/0    S+   18:07   0:00 grep --color=auto -E asm_dia0
grid     24447  1.8 45.5 25553460 22523896 ?   Ss   May07 724:37 asm_dia0_+ASM2
     

    image-20210604103719812

    通过上述查看asm_dia0使用内存45%，22G!!!，它是罪魁祸首！

    参数说明：

    • USER 进程的属主；

    • PID 进程的ID；

    • PPID 父进程；

    • %CPU 进程占用的CPU百分比；

    • %MEM 占用内存的百分比；

    • NI 进程的NICE值，数值大，表示较少占用CPU时间；

    • VSZ 进程使用的虚拟內存量（KB）；

    • RSS 该进程占用的固定內存量（KB）（驻留中页的数量）；

    • TTY 该进程在那个终端上运行（登陆者的终端位置）;

    • 若为pts/0等，则表示由网络连接主机进程

    • WCHAN 当前进程是否正在進行，若为-表示正在進行；

    • START 该进程被启动时间；

    • TIME 该进程实际使用CPU运行的时间；

    • COMMAND 命令的名称和参数；

    • STAT状态位

      • D 无法中断的休眠状态（通常 IO 的进程）；

      • R 正在运行可中在队列中可过行的；

      • S 处于休眠状态；

      • T 停止或被追踪；

      • W 进入内存交换 （从内核2.6开始无效）；

      • X 死掉的进程 （基本很少見）；

      • Z 僵尸进程；

      • < 优先级高的进程

      • N 优先级较低的进程

      • L 有些页被锁进内存；

      • s 进程的领导者（在它之下有子进程）；

      • l 多进程的（使用 CLONE_THREAD, 类似 NPTL pthreads）；

    • 位于后台的进程组；

    三、解决方案

    查看MOS，会导致ASM dia0进程会导致很高的内存消耗。是oracle的一个bug。Asm_dia0进程是一个诊断进程，负责检测Oracle数据库中的挂起(hang)和死锁的处理。MOS上给出的解决方案有2个，一个是打patch，另外一个是在非高峰期时定期的杀dia0进程。基于目前的系统压力状况，我们决定先杀掉进程，然后和应用部门确定停机时间，打数据库的补丁。

    四、参考资料

    1、系统内存耗尽的案例分析

    https://www.cnblogs.com/DataArt/p/10018877.html)

    2、Asm_dia0 进程占用用大量内存处理

    http://blog.itpub.net/22213086/viewspace-1571185

    喜欢请赞赏一下啦^_^

    微信赞赏

    支付宝赞赏
  • 相关阅读:
    java 动态规划算法求解最长公共子串
    Dos 连接远程DB2数据库及其常用操作
    Nio 读取UTF-8文件出现中文乱码
    maven配置 lucene ikanayzer
    简单的生产消费者模型
    解决当前项目遇到多叉树的情况第二版
    解决当前项目遇到多叉树的情况
    关于windowSoftInputMode
    Android中悬浮小窗播放视频的实现方案
    Android基础之Activity篇-启动模式探索(Cover Android Develop Guide)
  • 原文地址：https://www.cnblogs.com/lkj371/p/14858242.html
Copyright © 2011-2022 走看看