AWS企业号高限额 EC2 实例 Swap 交换内存配置失效导致应用程序频繁 Crash 排查

← 返回列表

这个问题我见过很多次，表面上是“Swap 没生效”，实际往往是三类原因叠在一起：系统层没有真正启用、实例重启后配置丢了、应用本身已经被 OOM/容器限制打死。如果你现在看到的是“服务时不时崩、重启后短暂恢复、压力一上来又挂”，先别急着改大实例，先把问题拆开看。

先判断：到底是 Swap 失效，还是应用根本没资格吃到 Swap

很多人只看过一次 free -h，发现有 Swap，就以为没事了。真正排查时，先看这三项：

free -h：看 Swap 总量和是否已经被打满。
swapon --show：确认系统当前挂载的交换区。
dmesg -T | grep -i oom：看是不是 OOM Killer 直接把进程杀了。

如果日志里已经出现 OOM 记录，说明不是“应用自己崩”，而是内存不够被系统清掉了。这个时候即使有 Swap，也可能只是延迟崩溃，不代表问题解决。

EC2 上 Swap 失效，最常见的 4 个原因

现象	常见原因	你该怎么处理
重启后 Swap 消失	`/etc/fstab` 没写、写错路径、创建的是临时盘	检查启动挂载项，确认是 EBS 持久盘
系统显示有 Swap，但应用还是崩	容器内存限制、JVM Xmx 过大、进程峰值瞬间冲高	查容器限制和应用启动参数，不只看宿主机
Swap 已经满了	实例内存太小，Swap 只是在硬扛	升级实例规格，别继续加大 Swap
创建了 Swap 文件但没生效	权限不对、没有 `mkswap`、没执行 `swapon`	逐条核对命令，别只执行到一半

我在 EC2 上最常用的排查顺序

先查是否真的被 OOM：dmesg -T | grep -i oom。
查 Swap 是否在运行：swapon --show。
AWS企业号高限额 查是否开机自动挂载：cat /etc/fstab。
查磁盘空间够不够：df -h。
如果是 Docker / ECS / K8s，再查容器限制：docker stats、Pod limit、cgroup 配置。

很多“Swap 配好了还崩”的案例，最后发现是 容器内存限制只有 512MB，但宿主机有 8GB Swap。容器看到的不是宿主机全部资源，Swap 对它几乎没帮助。

如果你要重新配置 Swap，建议这样做

适合临时缓冲、低成本救急的做法是用 Swap 文件，而不是先急着换实例。

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap defaults 0 0' | sudo tee -a /etc/fstab

如果是小规格 EC2，比如 1GB、2GB 内存的实例，我一般只建议先配 2GB~4GB Swap。原因很简单：Swap 不是 RAM，I/O 延迟会明显上升。你把 Swap 开到 16GB，看起来“稳定”了，实际应用可能只是从“立刻崩”变成“卡死后再崩”。

什么时候该继续修 Swap，什么时候该直接加实例

场景	建议	原因
偶发峰值，峰值持续几分钟	保留 2GB~4GB Swap	成本低，能扛突发
Java / PHP / 编译任务经常顶满内存	优先加内存规格	Swap 只能缓冲，不能解决持续高压
容器频繁重启	查 limit，再调内存上限	宿主机 Swap 不等于容器可用内存
数据库、缓存类服务	不要指望 Swap 兜底	延迟抖动会更明显

成本怎么选：加 Swap 还是升级 EC2

如果只是为了防止偶发 Crash，Swap 的月成本通常很低，尤其是用一块小的 EBS 盘来放交换文件时，费用远低于直接升级实例。但这笔钱省不省，要看你的业务类型。

加 Swap：适合“低频峰值、可以接受变慢”的场景，月成本低，但性能波动大。
升实例：适合“持续高内存占用”的场景，成本更高，但稳定性明显更好。

我通常给客户的建议是：如果内存使用长期超过 70%，而且高峰会顶到 90% 以上，不要把希望压在 Swap 上。Swap 只是止血，不是治本。

账号、实名认证、充值续费这些事，很多人会卡在排查前面

如果你是新开 AWS 账号，或者账号不是你自己长期在用，先确认下面几件事，不然你连 Swap 都来不及配，实例就先因为账单或风控停了。

支付方式：AWS 常见是国际信用卡/借记卡，能不能扣款成功比“卡种名字”更重要。
账单地址：有些账号失败不是技术问题，而是账单信息和支付卡信息不一致。
风控审核：新账号、频繁换卡、短时间大量开机、跨区域登录，容易触发核验。
续费方式：AWS 默认是按账单自动扣费，不是“先充值再用”的模式，别按国内云的习惯去理解。

AWS企业号高限额 如果你是企业账号，建议把 Root 账号只留给付款和安全设置，日常操作用 IAM 用户。很多因为误操作导致实例中断、快照删除、参数改坏的问题，其实不是云故障，而是权限没分开。

常见失败原因：不是 Swap 写错，就是启动方式不对

创建了 Swap 文件，但忘了写 /etc/fstab，一重启就丢。
Swap 放在临时盘上，实例 stop/start 后文件没了。
Java 服务 -Xmx 设得太大，留给系统和缓存的内存太少。
Docker 容器 limit 太低，宿主机再大也没用。
只看“有 Swap”，没看“Swap 是否已经被用光”。

我会怎么给客户做决策

如果是线上服务，优先级通常是：

先确认是不是 OOM、容器限制、参数配置问题。
小规模加 2GB~4GB Swap 作为缓冲。
观察 24~72 小时的内存曲线。
如果仍然频繁顶满，直接升级实例，不再和 Swap 较劲。

这类问题最怕的就是“看到能跑就不动”。Swap 生效后，Crash 可能少了，但卡顿、延迟、请求排队会先出现。对用户来说，体验未必更好。

FAQ

Q：重启后 Swap 失效，是不是 EC2 不支持持久化？
A：不是。大多数情况下是你挂载的是临时资源，或者没写自动挂载配置。

Q：为什么我已经加了 8GB Swap，应用还是挂？
A：说明根因不是“少一点内存”，而是应用持续吃内存、容器限制过小，或者进程本身存在泄漏。

Q：新账号会影响排查吗？
A：会。新账号如果付款失败、实例被停、风控核验没过，你的排查窗口会被打断。先保证账号可用，再做系统优化。

Q：要不要一开始就上大实例？
A：如果你已经明确是生产业务、内存峰值稳定，直接上更合适。否则先用小 Swap 验证，再根据 1~3 天监控数据决定是否升级。

如果你愿意，我可以继续按你的 EC2 系统版本（Amazon Linux / Ubuntu / CentOS）、部署方式（裸机 / Docker / ECS）给你整理一版更具体的排查命令和处理步骤。