背景：1GB 机器为什么总在半夜"死"

VPS 是租来的远程虚拟服务器，你在上面装系统、跑服务，内存多大直接决定能同时跑多少东西。1GB 内存的机型在促销季特别常见——便宜，有时一年只要几十块，拿来跑代理、博客、机器人、小工具都够用。但它有个脾气：内存一满，Linux 内核的 OOM Killer（内存不足终结者）就会挑一个进程杀掉保命，被杀的往往正是你最不想停的那个服务。表现就是服务半夜莫名其妙停了，重启又好了，过几天再犯。

先说结论：1GB 不是不能用，而是不能像 4GB 机器那样"装完就不管"。下面三步按顺序做：先给缓冲，再减负担，最后学会看日志定位真凶。做完这三步还频繁出事，再考虑升级配置，那时你也知道钱该花在哪。

前置知识：会用 SSH 登录 VPS，会粘贴执行命令，会用 systemctl 启停服务。不需要懂内核源码。

验机还没做的先看这篇：低价 VPS 到手先别装面板：10 分钟验机清单，确认商家给你的配置和下单时一致，再开始优化。

第 1 步：先看家底，再加 swap 缓冲

动手前先看真实家底：

复制free -h

重点看 Mem 一行的 total 和 available。注意区分两个数：available 是真正能给新程序用的内存，used 里还包含系统拿去当缓存的部分，缓存会在内存紧张时自动让路，所以"used 很高"不一定是问题，"available 长期低于 100MB"才是危险信号。

然后加 swap。swap 是硬盘上划出的一块空间，内存实在不够时系统会把不常用的内存页临时挪到这里，换来不被 OOM 直接杀进程的机会。对 1GB 机器，加 1GB swap 是个稳妥的起点：

复制sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

再让它开机自动生效，往 /etc/fstab 末尾加一行：

复制/swapfile none swap sw 0 0

最后调一个参数，让系统尽量晚用 swap——swap 毕竟在硬盘上，速度比内存慢得多，频繁进出会让服务变卡：

复制echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

swappiness=10 的意思是：不到万不得已不动 swap。验证一下 free -h 里出现 Swap 一行就说明生效了。

这里要纠正一个常见误解：swap 不是内存扩容，更不是"加了 swap 就能跑 4GB 的程序"。它只是缓冲垫，帮你扛住内存短暂冲高的尖峰。如果 swap 长期占满，说明负担本身就超了，得回到第 2 步减负，而不是继续加 swap。

第 2 步：精简常驻服务，把内存花在刀刃上

1GB 机器最忌讳"全家桶"式安装。先列出所有开机自启的服务，逐个过一遍：

复制systemctl list-unit-files --state=enabled

每个服务都问一句：它在跑吗？我用得上吗？面板类、可视化监控、没在用的数据库，都是内存大户。一台只跑两三个轻服务的机器，完全没必要装重型面板；数据库能用 SQLite 的就别上 MySQL；Web 服务选 Nginx 这类轻量的，别在 1GB 上同时装两套。

日志也是隐形开销。系统日志默认可能越攒越大，限制一下 journal 的体积：

复制sudo journalctl --vacuum-size=100M

并在 /etc/systemd/journald.conf 里把 SystemMaxUse 设为 100M，重启 systemd-journald 生效。别小看这一步，日志把磁盘写满引发的连锁故障，比内存不足更难查。

应用层面也要设上限。跑 Docker 的话，给每个容器加内存限制，避免一个容器失控拖垮整机：

复制docker run --memory=256m --memory-swap=512m 你的镜像

跑 Node 程序可以用环境变量限制堆内存，跑 Python 多进程服务要控制 worker 数量——worker 开 8 个和开 2 个，内存占用能差出几倍。原则就一条：每个服务都要有明确的内存预算，而不是"用到多少算多少"。

第 3 步：服务又挂了，先查 OOM 日志再动手

服务挂了别急着重启了事，先确认是不是 OOM 干的：

复制dmesg | grep -i 'out of memory\|killed process' | tail -20

如果看到 Out of memory: Kill process 字样和被杀的进程名，真凶就找到了。再结合时间点回忆：当时是不是在跑备份、更新、爬虫这类定时任务？很多"半夜死机"其实是定时任务和服务抢内存撞在了一起，错峰执行就能解决。

如果想提前预警而不是事后查日志，可以装一个轻量的看门进程（例如 earlyoom），它在内存真正耗尽之前就按规则先杀掉最占内存的非关键进程，比内核 OOM Killer 下手更有章法。不过要提醒一句：看门进程本身也要占内存，规则配错了反而会误杀正常服务，装之前先在白天手动测试一次。

最后给一张"该升级了"的判断表，符合两条以上就别硬撑了：

现象	说明
swap 长期占用超过一半	负担持续超载，缓冲已成常态
每周都会出现 OOM 记录	尖峰不是偶发，是常态
服务响应经常突然变慢几秒	内存和 swap 来回倒腾，机器在挣扎
加服务前都要先算半天内存	机器已经限制了你的用法

1GB 机器的正确心态是"小而精"：服务少而明确、每个都有预算、日志有人管。做到这三点，一台促销价买来的小机器完全可以稳稳跑一年；做不到，给它加再多 swap 也只是把死机推迟几天。