关键业务进程应设oom_score_adj为-1000以确保oom时永不被杀；systemd服务可通过oomscoreadjust=-1000长期配置；辅以cgroup内存限制、earlyoom前置干预及合理内核参数调优，实现双层防护。

生产环境的关键业务进程（如数据库、API网关、消息队列）必须避免被OOM Killer误杀。核心思路不是“阻止OOM发生”，而是确保关键进程在内存紧张时拥有最高生存优先级，同时降低非关键进程的干扰权重。

设置关键进程的oom_score_adj为-1000

这是最直接有效的保护手段。值为-1000表示该进程在OOM事件中永不被选中终止，内核会跳过它进行评分和杀戮。

• 对已运行的进程：获取PID后立即生效
  echo -1000 | sudo tee /proc/<pid>/oom_score_adj</pid>
• 对systemd服务（推荐长期使用）：
  执行sudo systemctl edit <service-name></service-name>，添加以下内容：
  

  [Service]<br>OOMScoreAdjust=-1000

  
  然后重载并重启：sudo systemctl daemon-reload && sudo systemctl restart <service-name></service-name>
• 常见服务建议值：
  • MySQL / PostgreSQL：-500 至 -800（保留一定弹性，避免极端场景下系统完全不可控）
  • sshd / systemd-journald：-1000（保障运维通道和日志基础能力）
  • Nginx / Envoy：-300（高可用网关需强保护，但不宜全设-1000）

限制非关键进程的内存使用范围

防止某个临时任务或监控脚本突发占用大量内存，拖垮整个节点。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 通过cgroup v2限制用户或进程组内存上限（适用于容器或独立服务）：
  

  sudo mkdir -p /sys/fs/cgroup/low-priority<br>echo "max 512M" | sudo tee /sys/fs/cgroup/low-priority/memory.max<br>echo <pid> | sudo tee /sys/fs/cgroup/low-priority/cgroup.procs</pid>

• 对cron任务或后台脚本，启动前加ulimit -v 2097152（限制虚拟内存2GB），避免malloc无节制增长
• Java应用务必设置-Xmx且不超过物理内存的70%，并启用-XX:+UseContainerSupport（K8s环境）

调整系统级OOM行为策略

让OOM Killer更可控，而非依赖默认随机性。

• 确认vm.panic_on_oom=0（默认值），确保触发的是进程终止而非整机panic
• 将vm.oom_kill_allocating_task=0（默认），使内核按综合得分选进程，而非简单杀当前申请者——这对数据库事务类场景更公平
• 谨慎启用vm.overcommit_memory=2（配合vm.overcommit_ratio），可显著降低虚假OOM概率，尤其适合内存敏感型服务

补充防护：部署earlyoom作为前置防线

Linux原生OOM Killer是“最后一搏”，而earlyoom可在内存真正耗尽前主动干预，给关键进程留出缓冲时间。

• 安装后配置为仅在可用内存≤8%时发送SIGTERM（可优雅关闭），≤4%时才发SIGKILL
• 用--avoid排除关键进程名（如mysqld|redis-server|etcd），用--prefer标记易牺牲进程（如python3|node）
• 搭配systemctl restart earlyoom并设为开机自启，形成双层防护