我现在无法重启，一旦有机会我会回来报告。至少需要几天时间。
我应该感到警惕吗？如果我需要分配更多资源，那也没关系。
是的，你应该感到警惕。
你的余地很小，几乎没有磁盘缓存的空间。
但在分配更多资源之前，你应该找出是什么原因导致了这种非同寻常的内存使用情况。
1 个赞
我现在做不了太多，我正在路上。我这周末会回来继续，并且一定会弄清楚是怎么回事。谢谢你的提示 
3 个赞
看起来只是一个过期的重启导致了这个问题。我重启了服务器，现在数字看起来好多了
root@discourse:~# free
total used free shared buff/cache available
Mem: 3927308 977624 2246208 42880 703476 2646836
Swap: 2097148 0 2097148
2 个赞
如果您再次遇到类似情况，询问 discourse 哪些进程正在使用内存可能会有所帮助 - 输出在
https://example.com/admin/upgrade#/processes
按 RAM 使用量排序。我认为这只会显示在容器中运行的进程。在命令行中，您可以使用
ps aux | sort -nr -k 4 | head -22
或类似命令，以查看包括所有容器中所有进程的使用情况。
如果重启解决了内存不足的问题，那么很可能存在某种失控的进程，它会（也许缓慢地）运行直到引起麻烦。
编辑：嗯，我看到我提到了根据 RAM 使用量（RSS）读取进程。这可能有用，但在此情况下，我们实际上更关心虚拟内存使用量：我们应该按 VSZ 列（第 5 列）进行排序。
2 个赞
这个 discourse 实例是很多年前首次设置的，所以可能是在进行交换文件检查之前。我已经手动应用了那些代码行，现在已经创建了交换文件。谢谢。
要让 docker 使用交换文件，我需要应用这个吗？或者说，这个建议的目的是什么？
我找到了这个讨论 vm.overcommit_memory 是什么，但我不明白为什么需要进行任何此类更改：
这与运行 Redis 有关，与升级 Discourse 无关。
我认为这不仅仅是这样——让我试着解释一下。这个建议来自 Redis，Redis 推荐它是因为 fork 一个进程需要大量的虚拟内存，而 Redis 会 fork 来进行后台保存，但实际上并不需要这些虚拟内存。
这对于许多 Unix 应用程序来说是很典型的：它们会 fork，但不需要将内存使用量加倍。因为这对许多应用程序来说是典型的，而且这是一个内核设置，它会改变所有容器中所有进程的行为，当虚拟内存面临压力时，它可能会将失败转化为成功。
在我们许多人使用的廉价小型实例上，虚拟内存经常面临压力。尤其是在升级或重建期间。
因此，更改此设置可能与升级成功或失败有关，特别是当最近有增加虚拟内存需求的更改时。
默认情况下，内核会拒绝无法满足的分配。通过此调整，它将接受这些分配，失败可能会被避免，或者当分配变为使用时，失败可能会稍后发生。
如果您的 RAM 和 swap 总量足够大，您将永远不需要更改此设置。如果您的总量不大，更改它可能会有帮助。
2 个赞
free 命令会告诉你配置了多少 swap 以及使用了多少。我认为在你运行那些命令后，它就会被使用。
这是为了增加可用虚拟内存的数量（即 RAM 和 swap 的总和）。如果你耗尽了 RAM，你就会开始遇到性能问题。但是，如果你耗尽了虚拟内存，进程将无法启动，或者会死亡或被杀死。这会很糟糕。
我们这些拥有少量 RAM 和少量磁盘的人可能无法自由地添加大量 swap，但 2G 似乎是一个不错的最小值。（如果你有 16G RAM，你可能不需要任何 swap，但那是另一回事。当问题是事物失败时，重要的是两者的总和。）
2 个赞
啊哈。我想我大概明白了，但这是一个很好的解释。所以这就是为什么我在我为客户做的每一个安装虚拟机上都设置了它。
我想我们是否应该让 discourse-setup 在创建交换空间时更改这些设置。
1 个赞
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.