DevOps知识中心
DevOps知识中心

掌握 OOM 策略：调整 systemd 对内存不足事件的响应

学习使用 systemd 控制 Linux 的内存不足 (OOM) killer 行为。本指南探讨 `OOMScoreAdjust` 和 `OOMPolicy` 指令，通过影响低内存条件下终止哪些进程来保护关键服务。掌握 systemd 的 OOM 调优，以增强系统稳定性和弹性。

44 浏览量

掌握 OOM 策略：调整 systemd 对内存不足事件的响应

Linux 系统设计得非常健壮，但在高负载或内存泄漏的情况下，它们偶尔会耗尽可用内存。当这种情况发生时，内核的内存不足（OOM）杀手会被调用来终止进程，释放内存并防止系统崩溃。然而，默认的 OOM 杀手行为可能并不总是最佳的，可能会导致关键服务的终止。Systemd 作为许多 Linux 发行版的现代 init 系统和管理器，提供了强大的工具来微调系统在内存耗尽时对进程的处理方式。

本文深入探讨了 systemd OOM（内存不足）策略的配置，特别关注 systemd 单元文件中的 OOMScoreAdjust 和 OOMPolicy 指令。通过理解和操作这些设置，您可以显著影响内核选择牺牲哪些进程，从而在低内存条件下保护您的关键应用程序并确保系统稳定性。

理解 Linux OOM 杀手

在深入了解 systemd 的配置之前，掌握 OOM 杀手的工作原理至关重要。当内核检测到无法释放更多内存来满足分配请求时，它会调用 OOM 杀手。该机制会扫描正在运行的进程，并为每个进程分配一个 oom_score，表示其“糟糕程度”或被终止的可能性。占用大量内存、运行时间长或 oom_score 较高的进程更有可能被终止。

oom_score 基于几个因素计算，包括内存使用量、进程优先级以及进程运行时间。然后，内核选择 oom_score 最高的进程进行终止，希望能回收足够的内存以维持系统运行。虽然有效，但这个过程是反应性的，有时可能导致非关键进程甚至重要进程被终止，如果它们的 oom_score 不慎过高。

Systemd 和 OOM 控制

Systemd 为管理单个服务的 OOM 行为提供了更精细的方法。您无需仅依赖内核的全局 OOM 分数，还可以影响 systemd 单元管理的进程的 oom_score，甚至为这些单元在 OOM 条件下的行为定义特定策略。

OOMScoreAdjust 指令

OOMScoreAdjust 指令在 systemd 单元文件中可用，它允许您直接影响该单元启动的进程的 oom_score。这是通过调整单元主进程的 /proc/[pid]/oom_score_adj 文件中的 oom_score_adj 值来实现的。

  • 值： OOMScoreAdjust 的范围是 -1000 到 1000。
  • -1000 的值使进程免疫 OOM 杀手。
  • 1000 的值使进程成为终止的首选候选。
  • 0 的值表示 oom_score_adj 未被修改，进程的 oom_score 由内核的默认逻辑决定。

工作原理： 当 systemd 启动一个服务时，它可以为相应的进程设置 oom_score_adj。较低的 oom_score_adj 值会降低进程的 oom_score，使其被终止的可能性降低。反之，较高的值会增加其 oom_score。

示例： 为了使关键数据库服务在 OOM 事件期间不太可能被终止，您可以将其添加到其 systemd 单元文件（例如 /etc/systemd/system/mydatabase.service）中：

[Service]
ExecStart=/usr/bin/my-database-server
OOMScoreAdjust=-500

在此示例中，OOMScoreAdjust=-500 显著降低了 my-database-server 进程的 oom_score，使其不太可能被 OOM 杀手选中。将 OOMScoreAdjust=-1000 将有效地保护它。

提示： 请极其谨慎地使用 OOMScoreAdjust=-1000。使进程完全免疫可能会导致系统不稳定，如果该进程存在内存泄漏，因为它永远不会被移除，可能会耗尽其他关键进程的资源。

OOMPolicy 指令

OOMPolicy 指令向 systemd 提供更具体的指示，说明如何处理给定单元的 OOM 情况。它规定了当系统遇到内存压力且单元进程被考虑终止时的行为。

  • 可能的值：
  • inherit (默认)：该单元继承其父 cgroup 的 OOM 策略。这是最常见的设置。
  • continue：进程不会被终止，系统会继续运行。如果根本问题未解决，这可能导致进一步的内存耗尽。
  • kill：进程被 OOM 杀手终止。
  • critical：将单元标记为关键。系统将在考虑终止此关键单元中的进程之前，尝试通过终止非关键进程来释放内存。
  • special：
    • special:container：当容器单元被标记为此策略时，如果发生 OOM 条件，整个容器将被终止。
    • special:stop：在发生 OOM 条件时，服务将被停止（而不是终止）。

示例： 将 Web 服务器指定为关键，确保首先终止其他非关键进程：

[Service]
ExecStart=/usr/bin/nginx
OOMPolicy=critical

示例： 而不是让服务被 OOM 杀手终止，而是以优雅的方式停止服务：

[Service]
ExecStart=/usr/local/bin/my-batch-job
OOMPolicy=special:stop

此配置将在内存压力很大时向 my-batch-job 进程发出干净关闭的信号，如果可能，允许它完成当前任务，而不是被突然终止。

警告： continue 策略应非常谨慎地使用。如果一个进程导致内存压力，并且允许其继续运行，它会加剧问题，可能导致系统完全冻结或无控制地崩溃。

实际应用和最佳实践

  1. 确定关键服务： 确定哪些服务对您的系统运行至关重要（例如，数据库、关键应用程序后端、核心网络服务）。这些是 OOM 策略调整的首选对象。
  2. 使用 OOMScoreAdjust 进行微调： 对于关键服务，使用 OOMScoreAdjust 来降低其 oom_score。从适中的值（例如 -200 到 -500）开始，并监控系统行为。仅在必要时增加调整，并始终注意使进程免疫的风险。
  3. 利用 OOMPolicy=critical： 对于绝对至关重要的服务，OOMPolicy=critical 是一个强大的选项。它告诉系统优先终止其他进程，然后再考虑您的关键服务。
  4. 考虑 OOMPolicy=special:stop 以实现优雅关闭： 如果一个服务可以安全地停止和重新启动，使用 special:stop 可以比立即终止实现更可控的关闭。
  5. 监控系统内存： 调整 OOM 策略是一种被动措施。最好的方法是主动监控系统内存使用情况，并解决内存耗尽的根本原因（例如，内存泄漏、RAM 不足、应用程序代码效率低下）。
  6. 彻底测试： 在对 OOM 策略进行任何更改并重新加载 systemd（sudo systemctl daemon-reload 和 sudo systemctl restart <service-name>）后，请务必在负载下彻底测试您的系统，以确保达到期望的行为并且没有产生意外后果。
  7. 记录更改： 记录对单元文件进行的所有 OOM 策略配置，包括每项更改的理由。

验证 OOM 调整

修改单元文件并重新加载 systemd（sudo systemctl daemon-reload 和 sudo systemctl restart <service-name>）后，您可以验证正在运行进程的 oom_score_adj。

首先，找到 systemd 单元管理的进程的 PID：

systemctl status <service-name>

在输出中查找 Main PID。

然后，检查该 PID 的 oom_score_adj 值：

cat /proc/<PID>/oom_score_adj

如果该值反映了您的 OOMScoreAdjust 设置，则表示您的配置已正确应用。

结论

Systemd 的 OOM 控制指令 OOMScoreAdjust 和 OOMPolicy 为管理员提供了管理内存稀缺期间系统行为的基本工具。通过仔细调整这些设置，您可以显著提高系统的弹性，确保即使在系统承受严重内存压力时，关键服务仍然可用。请记住，这些配置是更广泛的系统稳定性策略的一部分，而主动内存管理仍然是预防 OOM 事件的最有效方法。