• 【技术实操】银河高级服务器操作系统实例分享，达梦数据库服务器 oom 问题分析

    1. 服务器环境以及配置

    【 机型】

    处理器： HUAWEIKunpeng 920 5220

    内存： 400518528 kB

    主板型号： Chaoqiang K620 series

    整机类型/架构： ARM

    BIOS 版本： KL4.41.028.TF.220224.R

    固件版本： KL4.41.028.TF.220224.R

    系统硬盘： 1 disks, totaling 4470 GiB (4.37 TiB)

    网卡： mlx5_core

    【 内核版本】

    4.19.90-23.26.v2101ky10.aarch64

    【 OS 镜像版本】

    Kylin-Server-10-SP1-Release-Build20-20210518

    【 第三方软件】

    达梦数据库

    2. 问题现象描述

    用户反馈 OA 系统服务器在 2024-3-4 凌晨左右出现 oom。

    3. 问题分析

    从客户的监控平台来看，在3月4日凌晨4点的时候， 内存急剧下降， 并且内存下降的时候， 内存使用率只有 40%多， 如图 1。

    图 1

    查看 messages 中对应时间点的日志， 可以看到任务 3c458aeac30 在申请 order=3也就是申请连续 2^3 个 pagesize（ 2^3*64k=512K） 的内存的时候失败了。 由于3c458aeac30 在申请内存的时候没有指定 nodemask， 所以默认从 Normal 区域申请内存， 向 DMA 或者 DMA32 借位的话也是从 Normal 往下借位。

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123150] Job:3c458aeac30

    invoked oom-killer: gfp_mask=0x6040c0(GFP_KERNEL|__GFP_COMP),

    nodemask=(null), order=3, oom_score_adj=0

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123156] Job:3c458aeac30

    cpuset=/ mems_allowed=0

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123164] CPU: 23 PID:

    2579635 Comm: Job:3c458aeac30 Kdump: loaded Not tainted

    4.19.90-23.26.v2101.ky10.aarch64 #1

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123165] Hardware name:

    THTF Chaoqiang K620-M1/BC82AMDDIA, BIOS KL4.41.028.TF.220224.R

    02/24/2022

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123166] Call trace:

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123174]

    dump_backtrace+0x0/0x170

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123175]

    show_stack+0x24/0x30

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123179]

    dump_stack+0xa4/0xe8

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123185]

    dump_header+0x6c/0x240

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123187]

    oom_kill_process+0x334/0x370

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123189]

    out_of_memory+0xe4/0x4f0

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123191]

    __alloc_pages_nodemask+0xcf0/0xd70

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123196]

    alloc_pages_current+0x88/0xf0

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123200]

    kmalloc_order_trace+0x38/0x100

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123202]

    __kmalloc+0x274/0x290

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123206]

    ksys_getdents64+0x9c/0x348

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123207]

    __arm64_sys_getdents64+0x28/0x38

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123214]

    el0_svc_common+0x78/0x130

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123216]

    el0_svc_handler+0x38/0x78

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123219]

    el0_svc+0x8/0x1b0

    后续 mem 信息如下， 可以看到 inactive_file 比较多， 并且空闲内存 free 也有 8262个 pagesize， 也就是 528M 左右， 从这里看， 说明触发 oom 的时候， 服务器存在很多cache 并且有一部分 free 的空闲内存， 但是为什么会触发 oom， 需要继续分析。

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123220] Mem-Info:

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123228] active_anon:335474

    inactive_anon:15962 isolated_anon:0#012 active_file:123475 inactive_file:448986

    isolated_file:0#012 unevictable:448 dirty:24 writeback:0 unstable:0#012

    slab_reclaimable:3906 slab_unreclaimable:28995#012 mapped:2154 shmem:50577

    pagetables:324 bounce:0#012 free:8262 free_pcp:39 free_cma:0

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123232] Node 0

    active_anon:21470336kB inactive_anon:1021568kB active_file:7902400kB

    inactive_file:28735104kB unevictable:28672kB isolated(anon):0kB

    isolated(file):0kB mapped:137856kB dirty:1536kB writeback:0kB

    shmem:3236928kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB

    writeback_tmp:0kB unstable:0kB all_unreclaimable? no

    继续查看 meminfo 的日志打印， 可以看到 Normal 区的 order >= 3 阶的内存已经用完， 并且 Normal 区的 free 空闲内存大于 high 水位， 不会进行回收， 从 Normal区来看， 程序申请不到 order=3 阶的内存属于正常现象， 也从侧面反应了该服务器存在一定程度上的内存碎片化。

    从 DMA32 区来看， 空闲内存 free > min + reserved*pagesiz（ 285952kB > 704kB +3893*64kB ） ， 看似能向 DMA32 借用内存， 但是我们注意到 DMA32 中， 大于等于 3阶的内存都有 H 标记， 也就是 migratetype 为“H” ， 即 MIGRATE_HIGHATOMIC，而进程申请内存的时候指定的内存标志位为gfp_mask=0x6040c0(GFP_KERNEL|__GFP_COMP) ， 其中GFP_KERNEL=(__GFP_RECLAIM | __GFP_IO | __GFP_FS)， 这便使得该次内存申请其默认申请migratetype 为“E” （ 即 MIGRATE_RECLAIMABLE） 的内存， 而无法申请 migratetype都为“H” 的内存页。

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123235] Node 0 DMA32

    free:285952kB min:704kB low:2112kB high:3520kB active_anon:432320kB

    inactive_anon:18816kB active_file:138368kB inactive_file:548672kB

    unevictable:0kB writepending:0kB present:2096960kB managed:1497920kB

    mlocked:0kB kernel_stack:3520kB pagetables:128kB bounce:0kB free_pcp:0kB

    local_pcp:0kB free_cma:0kB

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123238] lowmem_reserve[]:

    0 3893 3893

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123241] Node 0 Normal

    free:242816kB min:31488kB low:95232kB high:158976kB

    active_anon:21039424kB inactive_anon:1002752kB active_file:7764032kB

    inactive_file:28187008kB unevictable:28672kB writepending:1536kB

    present:65011712kB managed:63802624kB mlocked:28672kB

    kernel_stack:24128kB pagetables:20608kB bounce:0kB free_pcp:2496kB

    local_pcp:0kB free_cma:0kB

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123244] lowmem_reserve[]:

    0 0 0

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123245] Node 0 DMA32:

    621*64kB (UMH) 148*128kB (UMH) 37*256kB (UH) 66*512kB (H) 49*1024kB (H)

    34*2048kB (H) 6*4096kB (H) 3*8192kB (H) 1*16384kB (H) 0*32768kB 0*65536kB

    0*131072kB 0*262144kB 0*524288kB = 287296kB

    Mar 4 04:00:01 BJZJXCOA-DB01 kernel: [39236047.123252] Node 0 Normal:

    2630*64kB (U) 560*128kB (U) 37*256kB (U) 0*512kB 0*1024kB 0*2048kB

    0*4096kB 0*8192kB 0*16384kB 0*32768kB 0*65536kB 0*131072kB 0*262144kB

    0*524288kB = 249472kB

    查看内核启动参数， 可以看到没有开启 thp， 所以 min_free_kbytes 默认只初始化一次， 这也是现场 min_free_kbytes 为 32312kB 的原因， 该值过下， 意味着内存回收的时候， 更多的回收的是小块内存， 容易造成内存碎片化， 内存碎片化也是造成上述问题的根本原因。

    BOOT_IMAGE=/vmlinuz-4.19.90-23.26.v2101.ky10.aarch64

    root=/dev/mapper/klas-root ro crashkernel=1024M,high rd.lvm.lv=klas/root

    rd.lvm.lv=klas/swap video=VGA-1:640x480-32@60me rhgb quiet

    smmu.bypassdev=0x1000:0x17 smmu.bypassdev=0x1000:0x15 video=efifb:off

    video=VGA-1:640x480-32@60me numa=off transparent_hugepage=never

    4. 问题分析结果

    综上所述， 本次触发 OOM 的原因是系统内存回收水位线较小、 内存碎片化， 空闲内存高于内存回收水位但无法提供进程申请的较大阶数的连续内存页。 内存回收水位较低的原因是系统手动关闭了 THP， 导致 min_free_kbytes 只进行一次初始化， 只能达到 32312kB。

    由于关闭 THP 是为了保证业务应用性能， 我们只能通过其他方法来改善这个情况。首先是可以手动修改 min_free_kbytes 参数的大小， 避免单次初始化的上限干扰。

    其次还可以修改 watermark_scale_factor 的值， 调大 min、 low、 high 三条内存回收水位线的差距， 使得系统在空闲内存不足时更早、 更多地进行内存回收。

    之后对于内存碎片化的情况， 如果业务应用是会频繁生成、 读取小文件， 产生大量零散 cahce， 我们建议可以在业务空闲时手动释放、 规整内存。

    最后对于 OOM 杀死达梦数据库的情况， 除了上述优化内存回收、 规整内存的方法， 我们还可以通过设置应用 oom_score_adj 为-1000 的方式， 禁止 OOM 进程杀死对应应用。

    5. 后续计划与建议

    ￮手动调整 min_free_kbytes 参数的大小（ 建议）

    打开 sysctl.conf 配置文件： vim /etc/sysctl.conf， 在其中手动添加 vm.min_free_kbytes= 653005（ 该值单位为 KB， 推荐设置为总内存大小的 0.5%-1%） ， 完成修改后生效配置： sysctl -p

    查询参数看是否修改完成： cat /proc/sys/vm/min_free_kbytes 或 sysctl -a |grep

    min_free_kbytes

    ￮内存规整（ 暂不建议， 后续还有问题可以调整）

    对于内存碎片化的情况， 如果系统内存高碎片化情况较为频繁， 条件允许的情况下， 我们建议在业务空闲时手动进行异步内存规整。 直接用 root 用户执行 echo 1 >/proc/sys/vm/compact_memory 即可， 若服务器业务较为规律， 可以挑选一天中的业务空闲时间直接写入定时任务执行。

    ￮调整 min、 low、 high 间距（ 暂不建议， 后续还有问题可以调整）

    如果想将更多的内存留给用户态应用使用， 还可以修改 watermark_scale_factor 的值来调大 min、 low、 high 三条内存回收水位线的差距， 这个这次不建议调整。

    ￮进程防杀死（ 暂不建议， 后续还有问题可以调整）

    手动修改应用进程oom_score_adj 为 -1000，通过修改进程oom用户打分oom_score_adj 为-1000 的方式， 我们可以使得该进程不会被 oom 所杀死。

  • 相关阅读:
    JAVA电费管理系统计算机毕业设计Mybatis+系统+数据库+调试部署
    【小笔记】为什么语义相似度要用余弦相似度而不用欧式距离？
    springboot中注解介绍
    点云重建方法汇总一（PCL-CGAL）
    网格布局之网格线编号定位
    这几个拍图读字软件你见过吗？附赠使用方法
    【DELL】戴尔笔记本PE下没有硬盘解决方法
    天天用defineEmits宏函数，竟然不知道编译后是vue2的选项式API？
    【面试现场】为什么 MySQL 数据库要用B+树存储索引？
    蓝桥杯实战应用【算法代码篇】-如何找数组中唯一成对的那个数（附Java和C++代码）
  • 原文地址：https://blog.csdn.net/2301_77223451/article/details/139268863