大约一周前，我查看了内存的 DO 图表，感到非常惊讶：
该图表已稳定运行一年多。我停止并重新启动容器后，内存使用率有所下降，但在过去几小时内，它又回升到了之前的水平。
这是什么原因导致的？top 和 ps 命令显示主要罪魁祸首是 postgres 进程。以下是 free 命令的输出信息：
$ free -mh
total used free shared buff/cache available
Mem: 7.8Gi 2.5Gi 142Mi 2.3Gi 5.1Gi 2.6Gi
我甚至无法通过 DO 控制台访问该 Droplet。它因 OOM（内存溢出）而崩溃。幸运的是，我已经安装了 SSH 密钥，可以从个人笔记本电脑访问，因此目前仍能访问该 Droplet。
我该怎么办？由于预算紧张，调整 Droplet 大小是最后的手段，我想知道是否有其他解决方案。这看起来完全出乎意料。我当前运行的版本是 2.7.0.beta5。
最近有什么变化吗？你升级了吗？
我过去14天的图表中，唯一的垂直跃升也出现在5月11日，但幅度较小，从78%上升至89%。也许我们当时进行了升级？
看起来与主机相关，因为对我来说内存使用量下降了。将版本升级到 beta9 是在 10 日添加的，所以我可能在那时进行了重建（并且磁盘使用量显示下载了新的镜像），不过我不记得升级过主机，但也可能升级了。
你没有配置交换空间吗？
没有，我们一直运行的是 2.7beta5 版本。我们有一段时间没有进行任何更改了。
我之所以没有升级到最新版本，是因为上次升级后，我们的前端开发人员提出了一些顾虑，因为那次升级给他的样式代码引入了一些破坏性变更（我只是一个系统管理员，对这类事情一无所知）。我认为这些问题在 Discourse 中已经得到修复，但我们一直在等待下一个小版本发布后再进行升级。
主机上可能是什么原因导致的？
调整 Droplet 规模会使我们的账单翻倍，所以我真的不想这么做，但这可能是最简单的解决方案。
交换空间是默认配置，我不太确定具体细节。
那 /sidekiq 显示什么呢？
如果添加交换空间，就能避免内存溢出（OOM）。你不想遇到 OOM，也不希望出现大量的页面交换活动，否则内存使用量的上升可能重要，也可能不重要。（这或许值得研究，但那是另一回事。）
我建议你运行
vmstat 5 5
或类似命令，以查看页面交换活动的情况。
此外，
free -h
比
free -mh
更有用，因为剩余交换空间的大小确实很重要。
