阿里云99元ECS 2C 1.6GB 远程开发频繁死机排查与优化实战

入手了阿里云99元/年的性价比 ECS（2 vCPU / 1.6GB 内存），使用 VS Code Remote SSH 远程开发时频繁死机。本文记录了使用 qoder CLI 排查问题、定位到内存耗尽+无 Swap 的根本原因，以及添加 Swap 文件、调整 swappiness 参数等优化方案的全过程。

· 运维部署

  • 阿里云
  • ECS
  • 故障排查
  • VS Code
  • 远程开发
  • Swap
  • qoder
  • 内存优化

问题背景

最近入手了阿里云一款99元/年的性价比ECS：

  • 规格：2 vCPU / 2 GB 内存
  • 系统：Rocky Linux 9.8 (Blue Onyx)
  • 内核：Linux 5.14.0-687.15.1.el9_8.x86_64
  • 磁盘：40GB
  • 用途：远程开发 + 小服务运行

本来想着这个配置做轻量开发应该够用，可没想到实际用起来频繁死机。

问题现象

使用 VS Code Remote SSH 远程开发过程中：

  • 服务器突然卡死，SSH 无法连接
  • 需要去阿里云控制台强制重启才能恢复
  • 重启后短时间内再次卡死，陷入死循环
  • 控制台监控显示 CPU 使用率约 59.3%，并未满负荷

一开始以为是 CPU 性能不够，后来发现不对 —— CPU 没满为什么会卡死呢？

AI 辅助排查尝试

既然遇到问题了，那就请 AI 帮忙看看。

第一次尝试：火山方舟 ark-cli

最近看到火山方舟推出 9.9 元 Coding Plan，想着试试：

npm i @volcengine/ark-cli@latest -g

安装完成登录后，发现 ark-cli 并不是类似 Claude Code 这种直接在终端里分析代码和系统的 AI 编程助手，交互方式不符合预期，于是放弃。

第二次尝试：阿里云 qoder-cli

既然是阿里云的机器，那就试试阿里自家的 qoder cli：

curl -fsSL https://qoder.com.cn/install | bash

安装非常顺利，一键完成，登录后就是熟悉的终端 AI 交互界面。

我直接提问：

当我使用 vscode 远程开发时，这台服务器会死机，我已经重启很多次，帮我查找原因。

qoder 反应非常快（毕竟阿里内网访问，延迟低），开始自动分析系统信息：

  • 检查重启历史
  • 分析内存使用
  • 查看 Swap 配置
  • 列出进程占用

几分钟就给出了完整的排查报告，原因定位非常准确。

根本原因：内存耗尽 + 无 Swap

qoder 定位的问题和我后续验证一致：

内存使用情况

总内存: 1.6 GB
已用:   1.2 GB (76%)
可用:   409 MB
Swap:   0 (未配置)

内存消耗分析

进程内存占用占比
VS Code 远程开发环境~823 MB50%
qoderclicn435 MB26%
learn-backend-1 (Docker)340 MB21%
4x Python uvicorn workers330 MB20%
dockerd + containerd160 MB10%

关键点：VS Code Remote 自己就占了一半内存！

崩溃机制

  1. 内存耗尽 —— 物理内存用完了
  2. 无 Swap 缓冲 —— 内核 kswapd 疯狂回收内存
  3. 内存抖动（thrashing） —— 几乎所有进程都在等待 IO
  4. SSH 无法响应 —— 表现为”卡死”
  5. 只能强制重启 —— 重启后内存很快再次耗尽，死循环

为什么 CPU 使用率不高？因为大部分时间 CPU 在等待内存换页 IO，其实系统已经卡住了。

优化方案

根据 qoder 的建议，实施了以下优化：

1. 添加 2GB Swap 文件（必须）

目的：提供内存缓冲，防止内存耗尽时系统直接卡死。

# 创建 2GB swap 文件
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

# 设置开机自动挂载
echo '/swapfile none swap sw 0 0' >> /etc/fstab

2. 调整 Swappiness 参数

目的：优先使用物理内存，Swap 仅作为应急缓冲。

# 临时设置
sysctl vm.swappiness=10

# 永久设置
echo 'vm.swappiness=10' >> /etc/sysctl.conf

默认值是 30，设置为 10 表示仅在物理内存不足时使用 Swap。

3. 应用层优化建议

方案 A：升级 ECS 实例规格（长期解决）

  • 当前：2 CPU / 1.6GB 内存
  • 建议：2 CPU / 4GB 内存（ecs.c6.large）
  • 优势：根本解决问题

方案 B：优化应用配置

  • 减少 uvicorn workers：从 4 个减少到 2 个，节省约 160MB
  • 限制 Docker 内存：在 docker-compose.yml 中配置内存限制
  • 检查内存泄漏：关注长期占用大内存的进程

方案 C：VS Code 远程开发优化（重要）

VS Code Remote 在 1.6GB 小内存机器上默认占用约 800MB+，占了一半！

VS Code 各进程内存占用（实测）：

进程内存占用
VS Code 扩展主机~472 MB
VS Code Server~95 MB
Markdown 语言服务~74 MB
PTY 主机~67 MB
JSON 语言服务~62 MB
文件监视器~53 MB
合计~823 MB

优化建议：

  1. ✅ 不用时关闭 VS Code —— 断开连接后约 5 分钟自动释放全部内存，可立即释放 ~800 MB
  2. ✅ 禁用不必要的扩展 —— 在远程环境中只保留必需扩展
  3. ✅ 避免同时开多个窗口 —— 每个窗口都有独立的扩展主机
  4. ✅ 调整自动关闭超时 —— 缩短断连后的等待时间，更快释放内存

断开 VS Code 后，内存使用从 1.1 GB 降至约 300 MB，非常可观。

验证结果

优化后的系统状态（7月12日实测）：

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           1.6Gi       1.3Gi        72Mi       0.0Ki       401Mi       325Mi
Swap:          2.0Gi       415Mi       1.6Gi

$ swapon --show
NAME      TYPE SIZE   USED PRIO
/swapfile file   2G 415.4M   -2

$ sysctl vm.swappiness
vm.swappiness = 10

结果：

  • ✅ Swap 缓冲正常工作，已使用 415 MB
  • ✅ 系统保持稳定运行，没有再出现卡死
  • ✅ SSH 随时可以连接，不再需要强制重启

经验总结

给小内存 ECS 用户的建议

  1. 一定要开 Swap —— 1GB-2GB 内存的机器，Swap 是生命线
  2. VS Code Remote 很耗内存 —— 不用就关，及时释放
  3. CPU 不高不代表系统正常 —— 内存耗尽导致的内存抖动，CPU 使用率也上不去，但系统已经卡死
  4. AI 辅助排查真高效 —— qoder 这种终端 AI 能快速定位问题，节省大量时间

性价比王 99 元 ECS 还能战吗？

当然能战！只要做好优化：

  • 添加 Swap 作为缓冲
  • 养成关闭 VS Code 的习惯
  • 控制应用进程数量

1.6GB 内存足够轻量开发 + 小服务运行，99 元/年还要什么自行车 🚲

参考资料