【技术实操】银河高级服务器操作系统实例分享，达梦数据库服务器 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，需要继续分析。

继续查看 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 的原因，该值过下，意味着内存回收的时候，更多的回收的是小块内存，容易造成内存碎片化，内存碎片化也是造成上述问题的根本原因。

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 所杀死。