Ubuntu香港服务器如何配置Swap分区并优化OOM Killer策略？含验证与回滚步骤

在 Ubuntu 香港服务器上，建议先使用独立 Swap 文件建立可回收的内存缓冲，再根据业务服务的重要程度调整 OOM Killer 的选择倾向。Swap 能降低瞬时内存峰值导致系统立即触发 OOM 的概率，但不能替代物理内存；如果服务器持续发生高频换入换出，应优先处理进程内存增长、并发过高或服务容量限制问题。

适用于 Ubuntu 20.04、22.04、24.04 LTS 的常规部署场景。云服务器通常没有可直接拿来格式化的空闲磁盘分区，因此本文以 /swapfile 为主要方案，同时给出已有独立 Swap 分区时的配置方式。OOM 策略采用“Swap 缓冲 + vm.swappiness 控制 + 服务级 OOMScoreAdjust + 可选的 systemd-oomd”组合，最后通过命令和日志验证，出现异常时可以按步骤回滚。

一、准备条件与目标状态

1. 适用环境

香港服务器所在地区不会改变 Linux 内核对 Swap 和 OOM Killer 的工作方式。实际执行前仍需确认系统版本、根分区文件系统、剩余磁盘空间以及当前是否已经存在 Swap。

2. 检查系统现状

先执行以下命令。该步骤只读取状态，不会修改服务器配置。

sudo -v

. /etc/os-release
printf 'OS: %s %s\n' "$PRETTY_NAME" "$VERSION_ID"
printf 'Kernel: '
uname -r

printf '\nMemory:\n'
free -h

printf '\nSwap devices:\n'
swapon --show

printf '\nRoot filesystem:\n'
findmnt -no TARGET,FSTYPE,OPTIONS /

printf '\nDisk usage:\n'
df -h /

printf '\nExisting fstab swap entries:\n'
grep -nE '^[[:space:]]*[^#].*[[:space:]]swap[[:space:]]' /etc/fstab || true

printf '\nCgroup filesystem:\n'
stat -fc %T /sys/fs/cgroup

printf '\nCurrent swappiness:\n'
sysctl vm.swappiness

重点观察以下结果：

• swapon --show 没有输出，表示当前没有启用 Swap。
• findmnt 返回 ext4 或 xfs，可以继续使用常规 Swap 文件方案。
• df -h / 至少要有计划 Swap 大小之外的可用空间。
• stat -fc %T /sys/fs/cgroup 返回 cgroup2fs，后续才适合使用基于 cgroup v2 的 systemd-oomd 策略。
• 如果已经存在 /swapfile 或独立 Swap 分区，不要直接覆盖，应先确认当前用途。

3. 记录原始配置并备份

危险操作主要集中在修改 /etc/fstab、执行 mkswap、swapoff、删除 Swap 文件以及重启服务。先保存配置，便于失败时恢复。

sudo mkdir -p /root/swap-oom-backup

sudo cp -a /etc/fstab \
  "/root/swap-oom-backup/fstab.$(date +%F-%H%M%S)"

sudo cp -a /etc/sysctl.d \
  "/root/swap-oom-backup/sysctl.d.$(date +%F-%H%M%S)"

sudo systemctl is-enabled systemd-oomd 2>&1 | \
  sudo tee /root/swap-oom-backup/systemd-oomd-enabled.txt >/dev/null || true

sudo sysctl vm.swappiness | \
  sudo tee /root/swap-oom-backup/swappiness-before.txt

如果服务器正在运行数据库、缓存、编译任务或大批量导入任务，建议先避开业务高峰。创建 Swap 通常不会中断服务，但服务级 OOM 配置和 systemctl restart 可能引起进程重启。

二、确定 Swap 大小与部署方式

1. 参考容量

Swap 大小不应简单按“物理内存的固定倍数”计算。服务器不启用休眠功能时，Swap 的主要作用是应对短时内存峰值、回收长期不活跃页面以及为 OOM 处理争取时间。

例如，4 GiB 内存的 Ubuntu 香港服务器可以先配置约 4 GiB 的 Swap。这里的数值属于部署参考，不代表所有应用都适用。需要注意，Swap 位于磁盘上，访问延迟显著高于内存；过大的 Swap 不能把磁盘变成等效内存。

2. 优先使用 Swap 文件

云服务器常见根分区已经完成分区，在线缩容或重新分区风险较高。只要根文件系统为 ext4 或 XFS，Swap 文件通常比重新调整磁盘分区更安全。

如果 findmnt -no FSTYPE / 返回 btrfs，不要直接套用下面的普通文件命令。Btrfs 对 Swap 文件的连续区块、写时复制和压缩属性有额外要求，建议使用云平台提供的独立块设备，或者先按照该系统版本的 Btrfs Swap 文件要求创建，避免得到无法启用的稀疏文件。

3. 创建并启用 4 GiB Swap 文件

下面示例创建一个约 4 GiB 的 /swapfile。如果需要其他大小，应同时调整 SWAP_SIZE；使用 dd 时还要同步调整块数量。

ROOT_FS=$(findmnt -no FSTYPE /)

case "$ROOT_FS" in
  ext4|xfs)
    echo "Root filesystem $ROOT_FS is suitable for the standard swapfile procedure."
    ;;
  *)
    echo "Unsupported root filesystem for this procedure: $ROOT_FS"
    exit 1
    ;;
esac

if [ -e /swapfile ]; then
  echo "/swapfile already exists. Stop and inspect it before continuing."
  exit 1
fi

sudo fallocate -l 4G /swapfile
sudo chown root:root /swapfile
sudo chmod 600 /swapfile

sudo mkswap /swapfile
sudo swapon /swapfile

sudo swapon --show
free -h

mkswap /swapfile 会把目标文件初始化为 Swap 区域。如果文件已存在，重新执行可能破坏其中的原有内容，因此前面的存在性检查不能省略。

如果 fallocate 创建的文件无法通过 swapon 检查，可以删除未启用的失败文件后，用连续写入方式重新创建。删除前必须确认该文件不是正在使用的 Swap。

sudo swapon --show

sudo rm -f /swapfile
sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 status=progress
sudo chown root:root /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

sudo swapon --show

上述 count=4096 对应约 4096 MiB，也就是常用的 4 GiB 示例。执行 rm 前要确认 swapon --show 中没有 /swapfile，不能删除正在使用的 Swap 文件。

4. 配置重启后自动启用

先检查 /etc/fstab 中是否已经有 /swapfile 条目，避免重复写入。

if ! grep -Eq '^[^#]*[[:space:]]+/swapfile[[:space:]]+swap[[:space:]]' /etc/fstab; then
  echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
else
  echo '/swapfile entry already exists in /etc/fstab'
fi

sudo findmnt --verify --verbose
grep -nE '^[[:space:]]*[^#].*[[:space:]]swap[[:space:]]' /etc/fstab

findmnt --verify 用于检查挂载配置格式。如果输出了原本就存在的其他挂载错误，应先区分这些错误是否由本次修改引起，不要在不了解影响范围的情况下执行批量修复。

不要为了测试而在生产环境直接执行 swapoff -a。当内存不足时，关闭全部 Swap 可能触发新的 OOM。持久化是否生效，可以在维护窗口重启后通过 swapon --show 验证。

三、已有独立 Swap 分区时的配置

如果服务器已经有未使用的独立分区，可以将它初始化为 Swap。该方式适用于确认分区没有文件系统、没有挂载点、没有业务数据的情况。

先查看设备信息：

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINTS,UUID
sudo blkid

假设经过人工确认，空闲设备为 /dev/vdb2。下面的 mkswap 会覆盖该分区上的原有签名和数据，设备名称必须替换为实际确认过的目标，不能照抄。

sudo umount /dev/vdb2 2>/dev/null || true
sudo mkswap /dev/vdb2
sudo swapon /dev/vdb2

sudo blkid -s UUID -o value /dev/vdb2
sudo swapon --show

取得 UUID 后，将类似下面的内容写入 /etc/fstab：

UUID=替换为实际UUID none swap sw 0 0

编辑前保留备份，并检查格式：

sudo cp -a /etc/fstab \
  "/root/swap-oom-backup/fstab-partition.$(date +%F-%H%M%S)"

sudoedit /etc/fstab
sudo findmnt --verify --verbose

如果该分区原本承载业务数据，不能执行 mkswap。云服务器无法确认空闲分区时，应回到 Swap 文件方案。

四、调整 Swap 使用倾向

1. 设置 vm.swappiness

vm.swappiness 控制内核在回收文件缓存和换出匿名内存之间的倾向，取值并不代表“使用了百分之多少 Swap”。将它设为 0 也不等于完全禁止 Swap。

常见应用服务器可以从 10 或 20 开始观察：

• Web、API、普通后台服务：可从 10～20 开始。
• 内存敏感型服务：可从 1～10 开始，但不能因此忽略内存峰值。
• 需要大量缓存的服务：不宜直接套用低值，应结合 vmstat 和应用指标判断。
• 如果服务器频繁发生 Swap 输入输出，降低该值通常不能解决根因，只能改变触发时机。

创建独立配置文件，避免直接改动发行版默认文件：

sudo tee /etc/sysctl.d/99-swap-oom.conf >/dev/null <<'EOF'
# General-purpose Ubuntu server baseline.
# Adjust after observing the actual workload.
vm.swappiness = 10
EOF

sudo sysctl --load=/etc/sysctl.d/99-swap-oom.conf
sysctl vm.swappiness

不要在没有明确容量模型的情况下同时修改 vm.overcommit_memory、vm.overcommit_ratio 或 vm.panic_on_oom。这些参数会影响内存承诺、分配失败和系统故障行为，错误配置可能导致应用在尚有空闲内存时就分配失败，或让故障更难定位。

2. 判断是否出现 Swap 抖动

使用以下命令观察 5 秒左右：

vmstat 1 5

重点看 si 和 so：

• si 表示从 Swap 读入内存的速率。
• so 表示从内存写入 Swap 的速率。
• 长时间持续有较大的 si/so，通常意味着内存压力已经影响到响应延迟。
• 偶发的小量换入换出不一定是故障，内核可能只是回收长期不活跃页面。

如果持续抖动，应先查看占用内存的进程和服务，再考虑提高物理内存、降低并发或设置服务级内存上限。不要只通过关闭 Swap 来隐藏问题。

五、优化 OOM Killer 策略

1. 理解两类 OOM 处理机制

Linux 内核 OOM Killer 在内存和可回收资源不足、进程无法满足分配请求时选择进程。oom_score_adj 会影响选择倾向：

• -1000 表示极强保护，不建议对普通业务进程使用。
• 负值表示降低被内核 OOM Killer 选中的概率。
• 0 是常见默认值。
• 正值表示更容易成为回收目标。
• 该参数不是内存上限，也不能阻止服务自身持续增长。

systemd-oomd 是基于 systemd 和 cgroup 的用户态内存压力处理机制。它可以在系统完全耗尽内存之前，根据 PSI 内存压力和 Swap 使用情况终止某个服务组。它并非所有 Ubuntu 安装都默认启用，而且依赖 cgroup v2，因此必须先检查环境。

2. 为关键服务设置保护倾向

假设关键业务服务名为 myapp.service，服务名必须替换为实际名称，可通过以下命令查询：

systemctl list-units --type=service --state=running

为关键服务创建 drop-in 配置：

sudo systemctl edit myapp.service

写入以下内容：

[Service]
OOMScoreAdjust=-300

保存后执行：

sudo systemctl daemon-reload
sudo systemctl restart myapp.service

systemctl restart 会导致该服务短暂中断，涉及有状态服务时应先确认业务连接、数据落盘和维护窗口。OOMScoreAdjust=-300 只是降低该服务被内核选择的概率，不代表服务一定不会被终止。不要把所有服务都设置为负值，否则内核可能只能选择更不应该被杀的进程。

如果某个后台任务、批处理或可横向拉起的 Worker 更适合优先退出，可以为它设置正值：

sudo systemctl edit worker.service

[Service]
OOMScoreAdjust=300

这样做的前提是该任务具备失败重试、断点续跑或重新拉起能力。

3. 对内存预算明确的服务设置上限

如果已经通过监控得出服务正常峰值和异常峰值，可以使用 cgroup 限制服务：

[Service]
OOMScoreAdjust=-300
MemoryHigh=1800M
MemoryMax=2200M

其中：

• MemoryHigh 是内存压力控制线，超过后会增加回收压力，不等于立即杀进程。
• MemoryMax 是硬上限，服务达到该上限后，可能触发该 cgroup 内部的内存回收或 OOM。
• 1800M 和 2200M 只是示例，必须根据服务实际峰值、线程数、缓存和启动开销调整。
• 不应把 MemoryMax 设置得低于服务正常启动和稳定运行所需的内存。

设置后应用配置并重启服务：

sudo systemctl daemon-reload
sudo systemctl restart myapp.service

如果服务由多个进程组成，cgroup 限制通常比单独修改某个 PID 的 oom_score_adj 更容易管理。不要只依据主进程的 RSS 设置上限，还要考虑子进程、文件缓存以及运行时堆内存。

4. 条件允许时使用 systemd-oomd

先确认服务、版本和 cgroup 环境：

systemctl list-unit-files systemd-oomd.service
systemctl is-active systemd-oomd || true
systemd-analyze --version
stat -fc %T /sys/fs/cgroup

如果系统存在 systemd-oomd.service，且 cgroup 类型为 cgroup2fs，可以先启动服务：

sudo systemctl enable --now systemd-oomd
sudo systemctl is-active systemd-oomd

如果系统没有该服务，先查询软件包，不要直接假设所有 Ubuntu 版本都能安装同一版本：

apt-cache policy systemd-oomd

如果候选版本存在，可以在维护窗口安装：

sudo apt-get update
sudo apt-get install -y systemd-oomd
sudo systemctl enable --now systemd-oomd

对可退出的 Worker，可以使用 systemd 的 cgroup 内存压力策略：

sudo systemctl edit worker.service

[Service]
OOMScoreAdjust=300
ManagedOOMMemoryPressure=kill
ManagedOOMMemoryPressureLimit=60%
ManagedOOMSwap=kill

保存后：

sudo systemctl daemon-reload
sudo systemctl restart worker.service

这组配置表示：当 Worker 所在 cgroup 出现持续内存压力或 Swap 使用达到处理条件时，允许 systemd-oomd 将该服务组作为回收对象。它适合可重试、可重建的工作进程，不适合直接套在唯一的数据库、核心控制面或没有数据恢复机制的服务上。

如果执行 systemctl daemon-reload 或启动服务时出现 Unknown lvalue、Invalid argument 等错误，通常说明当前 systemd 版本不支持该配置项。应删除不支持的 ManagedOOM... 行，仅保留兼容的 OOMScoreAdjust，不要强行启用未知参数。

六、上线后的验证方法

1. 验证 Swap 是否正常

printf 'Enabled swap:\n'
sudo swapon --show --bytes

printf '\nMemory summary:\n'
free -h

printf '\nKernel swap entries:\n'
cat /proc/swaps

printf '\nPersistent fstab entry:\n'
grep -nE '^[[:space:]]*[^#].*[[:space:]]swap[[:space:]]' /etc/fstab

成功状态通常包括：

• swapon --show 能看到 /swapfile 或目标分区。
• free -h 的 Swap 总量与配置大小接近。
• /etc/fstab 中只有一条有效的对应记录。
• 文件权限为 600：

stat -c '%A %U:%G %n' /swapfile

预期类似：

-rw------- root:root /swapfile

2. 验证内核 OOM 日志

不要通过人为耗尽生产环境内存来测试 OOM。先查看已有启动周期内是否发生过 OOM：

sudo journalctl -k -b --no-pager | \
  grep -Ei 'out of memory|oom-killer|killed process|memory cgroup out of memory' || true

也可以查看最近的内核日志：

sudo dmesg -T | \
  grep -Ei 'out of memory|oom-killer|killed process|memory cgroup' || true

如果日志出现 Killed process，需要结合 PID、进程名、cgroup 和发生时间判断是全局 OOM 还是某个服务达到了 MemoryMax。没有 OOM 日志不代表没有内存压力，Swap 抖动和服务超时可能早于 OOM 发生。

3. 验证服务级 OOM 配置

systemctl show myapp.service \
  -p MainPID \
  -p ControlGroup \
  -p OOMScoreAdjust \
  -p MemoryHigh \
  -p MemoryMax \
  -p ManagedOOMMemoryPressure \
  -p ManagedOOMMemoryPressureLimit \
  -p ManagedOOMSwap

取得主进程 PID 后检查实际值：

PID=$(systemctl show -p MainPID --value myapp.service)

if [ "$PID" -gt 0 ] && [ -r "/proc/$PID/oom_score_adj" ]; then
  printf 'PID: %s\n' "$PID"
  printf 'oom_score_adj: '
  cat "/proc/$PID/oom_score_adj"
  printf 'oom_score: '
  cat "/proc/$PID/oom_score"
else
  echo "The service does not currently have a readable main PID."
fi

如果使用 cgroup v2，还可以查看该服务的内存事件：

CGROUP=$(systemctl show -p ControlGroup --value myapp.service)

if [ -n "$CGROUP" ] && [ -f "/sys/fs/cgroup${CGROUP}/memory.events" ]; then
  sudo cat "/sys/fs/cgroup${CGROUP}/memory.events"
else
  echo "The service cgroup memory.events file is unavailable."
fi

memory.events 中常见字段包括：

• high：超过 MemoryHigh 的次数。
• max：触及 MemoryMax 的次数。
• oom：cgroup 内出现内存分配失败。
• oom_kill：cgroup 内发生进程终止。

4. 验证 systemd-oomd 行为

sudo systemctl status systemd-oomd --no-pager
sudo journalctl -u systemd-oomd -b --no-pager

部分系统提供 oomctl，可用于查看被 systemd-oomd 观察的 cgroup：

command -v oomctl >/dev/null && sudo oomctl dump || true

如果 systemd-oomd 日志没有内容，不应直接判定配置无效。只有在服务被纳入对应 cgroup、内存压力达到条件并且策略允许终止时，才会出现相关动作日志。

七、常见失败处理

1. swapon 报 Invalid argument

常见原因包括：

• Swap 文件是稀疏文件或存在不适合的文件系统特性。
• 文件权限不是 600。
• 文件没有经过 mkswap 初始化。
• Btrfs 未按要求创建 Swap 文件。
• 目标文件正在被其他方式使用。

按低风险顺序检查：

ls -lh /swapfile
stat -c '%A %U:%G %n' /swapfile
sudo filefrag -v /swapfile 2>/dev/null || true
sudo swapon --show
findmnt -no FSTYPE /

对于 ext4 或 XFS，可以确认没有启用后删除失败文件，再使用连续写入方式重新创建。对于 Btrfs，不要重复尝试普通 fallocate 方案，应改用独立 Swap 分区或符合该文件系统要求的方式。

2. 重启后 Swap 没有自动启用

检查 fstab 是否重复、路径是否正确：

grep -n '/swapfile' /etc/fstab
sudo findmnt --verify --verbose
sudo swapon --all --verbose
sudo swapon --show

如果 swapon --all 报错，先备份并编辑对应行，不要直接删除整个 /etc/fstab。修正后再次执行 swapon --all --verbose。如果服务器已经因为错误的 fstab 进入救援模式，应在控制台中恢复备份文件，再处理 Swap 条目。

3. Swap 使用率高且服务变慢

执行：

free -h
vmstat 1 5
ps -eo pid,ppid,comm,%mem,rss --sort=-rss | head -n 15

如果 si/so 持续升高，说明磁盘 Swap 已成为性能瓶颈。此时应检查：

• 是否有进程持续增长。
• 是否存在并发突然升高。
• MemoryMax 是否设置过低。
• 物理内存是否长期不足。
• 是否需要拆分 Worker 或限制单个任务规模。

不建议通过 swapoff -a 作为临时“优化”。如果当前内存不足，关闭 Swap 可能马上触发全局 OOM。

4. 服务启动失败或频繁被终止

先查看服务日志：

sudo systemctl status myapp.service --no-pager
sudo journalctl -u myapp.service -b --no-pager -n 200
sudo journalctl -k -b --no-pager | \
  grep -Ei 'oom|out of memory|memory cgroup' || true

如果日志表明触及 MemoryMax，应根据稳定运行峰值重新计算上限，而不是无条件删除限制。如果是 systemd-oomd 主动终止，应检查该服务是否真的允许被回收；核心服务应去掉 ManagedOOMMemoryPressure=kill 和 ManagedOOMSwap=kill，并保留合理的 OOMScoreAdjust。

八、失败回滚步骤

1. 回滚服务级 OOM 配置

首先删除对应服务的 drop-in：

sudo systemctl revert myapp.service
sudo systemctl daemon-reload
sudo systemctl restart myapp.service

systemctl revert 会删除通过 systemctl edit 创建的本地覆盖配置。执行前应确认该服务没有需要保留的其他本地 drop-in。如果只想删除本次配置，应先查看：

systemctl cat myapp.service

对于 Worker 服务也采用同样方式：

sudo systemctl revert worker.service
sudo systemctl daemon-reload
sudo systemctl restart worker.service

2. 回滚 systemd-oomd

如果本次才安装并启用了 systemd-oomd，可以停止并取消开机启动：

sudo systemctl disable --now systemd-oomd

如果它原本就是系统既有配置，不应直接禁用。应参考备份文件：

cat /root/swap-oom-backup/systemd-oomd-enabled.txt

如果只是回滚某个服务的 ManagedOOM... 设置，优先使用 systemctl revert，不必关闭整个 systemd-oomd。

3. 回滚 vm.swappiness

删除本次创建的配置文件，然后恢复记录的原值。假设备份文件中记录的是原始值：

cat /root/swap-oom-backup/swappiness-before.txt

先读取其中的数值，再执行类似命令：

sudo rm -f /etc/sysctl.d/99-swap-oom.conf
sudo sysctl --system

如果希望立即恢复记录值，可执行：

sudo sysctl -w vm.swappiness=原来的数值

sysctl --system 会重新加载多个系统配置文件。如果其他管理员在同一时间修改过 sysctl，应先审阅输出和备份，不要盲目覆盖。

4. 回滚 Swap 文件

只有在确认系统有足够可用内存、Swap 不再承载页面时，才能关闭并删除 Swap 文件：

free -h
sudo swapon --show

确认可执行后，编辑 /etc/fstab 删除或注释本次添加的行，再执行：

sudo swapoff /swapfile
sudo rm -f /swapfile

sudo findmnt --verify --verbose
sudo swapon --show

如果 swapoff /swapfile 因内存不足失败，不要强制删除文件。可以先扩大物理内存、停止非关键任务或临时增加另一块 Swap，待页面迁移完成后再回滚。

独立 Swap 分区的回滚方式类似，但只能关闭并移除 fstab 中的对应 UUID 行：

sudo swapoff /dev/vdb2

回滚时不要执行 mkfs、fdisk 或分区删除操作。Swap 分区停用后是否恢复为其他用途，应由后续磁盘规划单独处理。

上线前验收清单

• [ ] Ubuntu 版本、根文件系统和剩余磁盘空间已确认。
• [ ] /etc/fstab 和 sysctl 配置已完成备份。
• [ ] Swap 文件或独立分区已通过 swapon --show 验证。
• [ ] Swap 权限为 root:root 且文件权限为 600。
• [ ] /etc/fstab 中没有重复 Swap 条目。
• [ ] vm.swappiness 已设置为与业务负载匹配的值。
• [ ] 关键服务和可回收 Worker 已分别设置 OOM 优先级。
• [ ] MemoryHigh、MemoryMax 仅用于已经掌握内存峰值的服务。
• [ ] systemd-oomd 仅在服务存在、cgroup v2 可用且策略经过确认时启用。
• [ ] 已通过 systemctl show、/proc/PID/oom_score_adj 和日志完成验证。
• [ ] 未在生产环境通过人为耗尽内存测试 OOM。
• [ ] 已记录服务级配置、Swap 路径和回滚命令，便于后续维护。