一台 8 核 8G 香港服务器竟被构建过程打挂了？一次真实的 OOM 排障记录

在日常开发中，服务器性能瓶颈往往来自 CPU 或磁盘。但我这次遇到的问题却完全出乎意料——一台看似不低配置的 8 核 8GB 香港服务器，在部署项目时会直接卡死甚至宕机。

最夸张的是：明明只是构建一个前端项目，服务器居然瞬间失去响应，连 SSH 都断开。

这类问题反复出现，才促使我彻底调查其背后原因。

痛点：8GB 内存 + 多容器，看似充足却频繁卡死

我的服务器运行环境如下：

• 8 核 CPU，8GB 内存
• Ubuntu 20.04
• 使用 Dokploy 管理多个 Docker 容器
• 一个业务 backend 服务
• 一个博客站点
• 一个统计服务
• 以及数据库、Redis、代理服务等依赖容器

从表面看，8GB 内存足以承担这些轻量级服务。

但现实是，部署构建项目时服务器会出现：

• 卡顿到无法输入指令
• SSH 自动断开
• 所有容器瞬间中断
• 日志显示系统触发 OOM Kill（内存溢出强制杀进程）

这让我意识到，问题绝不仅仅是资源不够简单。

深入排查：被杀死的竟然不是构建进程，而是代理服务

查看系统内核日志后发现：

Out of memory: Killed process ... (某代理服务)

也就是说：

• 不是业务服务崩溃
• 不是构建程序被杀
• 而是代理层进程被系统终止

这是典型的 Linux OOM（Out Of Memory）机制：当内存不足时，系统会优先杀掉占用较大、相对不重要的进程，以维持整体系统可用性。

表面上看像是"服务器卡死"，本质上是构建瞬时内存峰值导致系统紧急自救。

构建期间究竟发生了什么？

部署过程中需要执行 Next.js、TypeScript、Webpack/Turbopack 等构建任务，这类构建涉及：

1. 编译大量 TS/TSX 文件
2. 分析数百个依赖包
3. 构建依赖图
4. 预渲染页面
5. Tree shaking
6. 压缩与打包
7. 默认启用并行构建（多线程）

这些步骤会造成高峰内存占用，在实际项目中构建峰值可能达到：

• 4GB ~ 6GB 或更高

服务器上的常驻容器则占用约：

• 1.8GB ~ 2.0GB

因此构建阶段总内存占用轻松突破 8GB。

当系统无法再分配内存时，就会触发 OOM Kill → 服务被杀 → SSH 掉线 → 看似宕机。

根因确认：是构建瞬时峰值，不是内存泄漏

查看构建前后的容器资源占用：

• 所有容器总占用约 2GB
• 构建结束后内存恢复正常
• 无容器存在持续性泄漏

这说明问题来自短时间的资源峰值，而非程序长期占用异常。

类似情况在前端工程化中非常常见。

解决方案：添加 Swap，为系统提供缓冲区

考虑到：

• 构建内存峰值是偶发的
• 服务器内存不需要升级
• 构建时长占比不高
• 多容器环境更容易触发 OOM

因此最实用的方案是添加 Swap。

什么是 Swap？

Swap 是磁盘上的备用内存，当物理内存耗尽时，系统会把部分不活跃的数据写入 Swap，从而避免 OOM。

Swap 的特点如下：

对于构建阶段爆内存的情况，Swap 是非常理想的解决方案。

实施步骤：为 Ubuntu 添加 4GB Swap

执行以下命令：

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

使用以下命令查看结果：

free -h

示例输出：

Swap: 4.0Gi 0B used 4.0Gi free

至此，一个有效的系统保护机制已经启用。

效果：构建稳定运行，再无 OOM Kill

添加 Swap 后：

• 构建过程稳定
• SSH 不再掉线
• 容器不会被误杀
• 整台服务器不再无故卡死

此前动不动宕机的情况彻底消失。

总结

这次排障让我深刻理解了一个道理：服务器配置够用不代表峰值够用。

对于运行多容器 + 需要执行构建任务的服务器，强烈建议：

1. 监控内存峰值：不要只看平均占用
2. 添加 Swap：作为系统的安全缓冲区
3. 考虑分离构建：将 CI/CD 构建放到专用机器或云服务
4. 设置容器内存限制：防止单个容器吃掉所有资源

希望这篇文章能帮助遇到类似问题的朋友快速定位并解决问题。