systemd服务OOM触发失败：配置后未生效问题咨询

操作背景与现象 #

尝试触发systemd服务的OOM机制但失败，操作流程如下：

1. 编译了一个分30次申请内存的二进制程序（每次100M，总计3G），放置于/opt/test路径；
2. 创建systemd服务文件，设置1G内存限制与OOMPolicy=kill，服务文件内容：

[Unit]
Description=ttt
After=network.target

[Service]
Type=simple
ExecStart=/opt/test

MemoryMax=1G
OOMPolicy=kill

3. 启动服务后，程序未被OOM杀死，出现矛盾现象：
   • systemctl status显示已配置1G内存限制，但进程实际内存占用仅656.0K：

   # sudo systemctl status ttt.service
   ● ttt.service - ttt
        Loaded: loaded (/usr/lib/systemd/system/ttt.service; static)
        Active: active (running) since Tue 2024-12-10 07:56:42 UTC; 15min ago
      Main PID: 360604 (test)
         Tasks: 1 (limit: 8757)
        Memory: 656.0K (max: 1.0G available: 1023.3M peak: 876.0K)
           CPU: 8ms
        CGroup: /system.slice/ttt.service
                └─360604 /opt/test
   

   • ps -aux显示进程虚拟内存占用3G：

   # ps -aux | grep test
   root      360604  0.0  0.0 3074372 1280 ?        Ss   07:56   0:00 /opt/test
   

   • dmesg -w未捕获到任何OOM相关日志

可能的原因及解决方法 #

1. 程序仅申请虚拟内存，未实际占用物理内存 #

Linux默认采用惰性内存分配：调用malloc等函数时，内核仅分配虚拟地址空间，不会立即分配物理内存。只有当程序向申请的内存区域写入数据时，才会触发物理内存的实际分配。

• 解决：修改程序逻辑，在每次申请内存后用memset等方式填充内存块，确保物理内存被实际占用。

2. systemd内存限制的统计逻辑差异 #

MemoryMax限制的是进程实际占用的物理内存（RSS），而ps输出的3074372是虚拟内存大小（VSZ）。从systemctl status的输出看，进程实际RSS仅656.0K，远未达到1G阈值，因此不会触发OOM。

• 验证：用pmap -x <PID>查看进程内存细分，确认RSS（Resident Set Size）的真实大小。

3. OOMPolicy的生效前提 #

OOMPolicy=kill仅在cgroup内部触发OOM时生效，即进程实际占用的物理内存超过MemoryMax限制时才会执行。若进程未触碰到cgroup的内存阈值，该策略不会起作用。

4. 补充更严格的内存限制参数 #

可添加以下参数强化内存约束：

• MemoryHigh=800M：当内存占用超过该值时，systemd会主动限制进程的内存分配，提前触发内存管控
• MemorySwapMax=0：禁止进程使用交换分区，避免内存溢出到swap而绕过物理内存限制

5. 验证cgroup内存限制是否正确加载 #

检查进程所在cgroup的内存限制配置：

cat /sys/fs/cgroup/system.slice/ttt.service/memory.max

若输出不是1073741824（1G对应的字节数），说明服务配置未正确加载，执行以下命令重启生效：

sudo systemctl daemon-reload
sudo systemctl restart ttt.service

内容的提问来源于stack exchange，提问作者Guanghan