小内存云服务器是怎么活下来的：我的 1G 机器自救笔记

最近一直在折腾几台便宜的小机器，印象最深的一台只有 1G 内存。刚拿到手的时候我还挺乐观的，觉得不就是跑个代理、挂几个小服务吗，能有多难。结果装完系统、起了几个进程，内存直接见底，SSH 都开始卡顿。那一刻我才明白，小内存机器不是不能用，而是得换一种用法：先算账，再动手。

我先做的事是看清楚到底是谁在吃内存。用 free 和 top 看了一圈，发现真正的大头不是某个服务本身，而是我一股脑全装上的东西：面板、监控、数据库、缓存，一个不少。单个看都不大，加起来就把 1G 占满了。于是我开始做减法：面板先不要了，命令行够用；数据库能用轻量的就用轻量的；不需要常驻的东西，改成需要时再启动。砍完一轮，内存立刻松了一口气。

第二步是加 swap。这一步很多人觉得是“作弊”，其实对小机器来说就是救命绳。我给 1G 的机器加了 1G swap，并且把 swappiness 调低，让系统尽量先用物理内存，实在不够了再去用 swap。这样平时速度不受影响，偶尔内存一紧张，机器不会直接把进程杀掉，而是先喘口气。有一回我半夜跑了个稍大一点的任务，早上起来看日志，swap 确实用上了，服务还活着——这就够了。swap 不是让你在小机器上跑大应用的借口，它只是把“直接死机”变成“慢一点但还活着”。

第三步是给服务定规矩。以前我装完服务就扔在那儿不管，现在会先看它的默认配置：有没有内存上限、日志会不会无限长、会不会自动重启。日志这件事特别容易被忽略，几个月不清理，一个小服务也能把磁盘写满。后来我养成了习惯：重要的服务设好重启策略，日志定期轮转，磁盘和内存每周看一眼。不是每天盯着，而是每周花几分钟扫一眼，心里有数就行。

线路这件事，我之前也踩过坑。同一台机器，换个网络环境，延迟能差好几倍。一开始我总怀疑是配置写错了，反复改协议、改端口，折腾半天没效果。后来换了个网络测试，延迟马上正常了，才意识到问题根本不在机器上，在路上。从那以后我养成了一个习惯：出问题先换个变量测一下，是机器的问题、配置的问题，还是路的问题，分清楚再动手，省了很多无用功。

还有一个体会是，别在小机器上贪多。我现在给每台机器都定了个角色：这台只做代理出口，那台只跑轻量网站，互不抢资源。以前总想着一台机器全包，结果哪个都跑不好。分开之后反而省心，出问题也好定位，知道该去看哪台、看哪个服务。

最后说一点心态上的变化。刚开始玩云服务器的时候，我总想一步到位，配最好的、装最全的。后来才发现，便宜小机器的玩法是“够用就好”：先让它稳定跑起来，再一点点加东西。每加一个服务就观察几天，内存、磁盘、延迟都没问题再留下来。这样攒下来的机器虽然配置不高，但胜在稳定，不会三天两头掉线让我半夜爬起来修。

如果你手里也有一台 1G 或者 2G 的小机器，不妨先别急着升级配置。先看看内存都去哪了，砍掉不用的东西，加个 swap 兜底，给日志和服务定好规矩，再把每台机器的角色分清楚。很多时候，机器不是不够用，只是被我们用得太贪心了。稳定跑下来，比一时跑得快重要得多。