是否应将默认交换空间增加到 3GB 或 4GB？

安装
1

我刚做了一堆升级，并决定解决内存错误的最简单方法就是将交换空间加倍到 4GB。缺点是，在 1GB 的液滴上只有 25GB 的 SSD，所以损失 4GB 的空间用于交换是一个相当大的数量，而且只有 25GB 已经有点紧张了。

那么，我们是否应该将 discourse-setup 改为默认值为 3GB？

你觉得怎么样，@Falco？

6 个赞
2

如果那能解决问题，我完全赞成。

2 个赞
3

我是否可以强烈建议安装脚本也设置影响内存处理的两个内核可调参数？ 知道每个似乎有问题的人至少有一个良好的内核设置起点将是件好事。

2 个赞
4

对我来说，这似乎是个明智的想法。我无法想象在专用的 discourse 实例上 THP 有什么价值，而 overcommit 可以帮助避免 OOM。

可以考虑分别提供这些选项，并将它们设置为默认响应，选择非默认选项则可以退出？

另外，脚本可以在更改设置之前使用 sysctl 来了解是否需要更改设置。如果有人已经使用不同的文件进行了这些更改，那么创建重复的覆盖可能会造成混淆。我认为并非所有 Linux 发行版都默认关闭内存 overcommit。

if $(sysctl -n vm.overcommit_memory) != 1 ; then
    ....
fi
3 个赞
5

冒着稀释关于内核可调参数的重要信息的风险，还有第二个考虑因素：当前的脚本仅在低 RAM 机器上创建交换空间。我认为这是一个错误，因为交换空间在最大化 RAM 的可用性方面仍然有用，但更重要的是，如果有人为了速度或方便而在大 RAM 机器上创建他们的 Discourse，然后将其缩小到小 RAM，这会引起麻烦。

设置应该在所有情况下都创建交换空间（除非已经足够）。拥有多个交换文件是有效的，有时也很有用。

2 个赞
6

我不是决定者，但我会在我设置的机器上设置这些参数，但这是一个 shell 脚本，几乎所有安装 Discourse 的人都会运行它。它需要尽可能简单，而且我们确定这些设置在树莓派和 Mac 以及人们尝试做的任何其他胡闹设备上都有效吗？而且你用来测试它是否已设置的任何方法是否都适用于所有这些平台？这似乎很难。

我编写了 discourse-setup，我觉得对它进行更改有点可怕。

始终提供创建交换空间并非坏事。也许总是提供设置 3 或 4 GB 的交换空间？但然后设置多少？我曾经知道一个经验法则是让交换空间的大小与内存相同。现在，如果你不创建交换空间，你唯一的选择就是按 Ctrl+C 退出。所以，我们要么强迫人们创建交换空间，要么添加另一个是/否问题（这将导致我修改运行 discourse-setup 的脚本 :crying_cat_face:）哦！或者我们可以让它由 --skip-swap 开关控制。这对我来说似乎还可以。如果你足够聪明，知道交换空间，那么你就能找到跳过它的开关；我们可以在那个警告消息中添加一个关于该开关的注释。

也许还可以添加一个关于 --skip-connection-test 在其失败时的注释。
我认为如果他们已经设置了交换空间，可以安全地假设他们知道自己在做什么。

1 个赞
7

谢谢！是的，完全理解，我也会有同样的感受。当然需要仔细考虑和测试。而且这至少要在几个托管提供商的廉价机器上，以及在 Pi 上进行。不确定 Windows 或 Mac 是否需要支持，如果需要的话，那也得支持。我更倾向于将它们用作开发机器，这是另一回事。

确实。也许是目前看起来必要的任何数量。它似乎已经上了一个台阶。但如果不知道这些报告是否包含或不包含过载调整，我真的很难过。我相当确定我们从之前的讨论中知道过载调整是有区别的。

而且我们确实知道，在 25G 实例上，尤其是在 20G 实例上，磁盘空间很紧张。我正在这样的机器上运行：25G 磁盘和 1G RAM，这已经需要 2G 交换空间，而且现在可能需要更多；以及 20G 磁盘和 2G RAM，我目前有 1G 交换空间。

我不建议增加更多的“是/否”问题。命令行选项似乎是更好的途径。

如果我们真的要修改这个脚本，我认为我会建议使用几个 1G 的交换文件，因为这可以最大限度地提高灵活性，不会浪费任何东西，而且这是最容易做出决定的时间。

我不太确定这一点。如果最小的实例带有纯粹的 Ubuntu 或 Debian，碰巧已经有一些交换空间——这需要检查——那么如果不够，我们就会遇到问题。最好使用 free 来测量 RAM+swap，像往常一样针对现有的小于 1G 的配置（我认为是 AWS，也许是 Oracle）进行调整，然后添加 1G 的交换文件，直到达到某个商定的数量，无论现在是多少。希望总共 4G 足够，并且内核过载设置得当。

我很乐意帮忙。

2 个赞
8

嗯。是的。我希望我能想到检查一下我刚刚调整过的那些。

嗯。我倾向于一个更好，但多个确实增加了灵活性，然后就可以让 discourse-setup 添加另一个交换文件，如果需要更多的交换，这意味着我们可以告诉每个人运行 discourse-setup 来“修复”他们的交换问题。也许还可以解决过载问题——也许只明确地尝试为我们关心的 Linux 做这件事。

2 个赞
9

我不同意。交换空间并非总是好的。它曾经在某些情况下（即使没有交换）对于使 VM 代码更均匀很重要，但 VM 算法已经改变了。

那是基于非常旧的内核代码启发式方法，现在已不再适用。

另外，在考虑测量时：我甚至不知道在使用 zswap 时您想如何测量交换空间和内存。但这可能是“首先，不造成伤害”的情况。

2 个赞
10

我几乎可以肯定，“过多交换”的唯一缺点是占用了比绝对必要更多的磁盘空间。这也是为什么最好有几个大小适中的交换文件——如果需要回收磁盘空间，可以逐步关闭和删除它们。另外，我认为 Linux 在逐步使用它们方面做得相当不错：

名称                       类型  大小   已用  优先级
/var/local/swap/swapfile.1 文件 1024M 863.6M   -2
/var/local/swap/swapfile.0 文件 1024M   4.6M   -3

我们面临的情况是，廉价实例在 RAM 和磁盘空间方面都非常有限，而 Discourse 随着其中许多软件包的不断发展，占用的空间越来越多。但尽管如此，我认为还是有明智的方法来应对这种情况，以帮助那些无法轻易放弃并将其月费翻倍或翻四倍的人。

1 个赞
11

交换速度很慢，以至于我不会将“几乎没有空间了”作为在此时添加超过 1GB 到默认建议的理由。每一 GB 交换空间都很多，正如在一个专用的 Discourse 实例上所经历的那样。

是的，默认情况下 Linux 按优先级顺序使用交换空间，并且可以将相同的优先级用于多个设备以显式分条交换。但我建议，为小型网站添加大量交换空间并不是特别有价值。

因此，如果大约十年后人们偶尔遇到 2GB 的问题，我建议将默认值设置为 3GB 而不是 4GB。专用的 Discourse 实例所需的交换空间量不应随内存的增加而特别增加，因为实际将被交换出去的内容变化不大。

随着内存的增加而增加交换空间的想法主要来自通用计算，基于一种普遍的假设，即您需要的 RAM 越多，需求可能就越大。但我认为，专用 Discourse 实例上的交换压力不太可能遵循这种模式。

THP 特定于支持大页面的平台，而并非所有平台都支持。处理此问题的通用方法是查看它是否存在。在我的一台树莓派上：

$ sysctl sys.kernel.mm.transparent_hugepage.enabled
sysctl: cannot stat /proc/sys/sys/kernel/mm/transparent_hugepage/enabled: No such file or directory
$ echo $?
255

相比之下，过量使用（overcommit）是 Linux 过去几十年的通用 VM 参数。在同一台树莓派上：

$ sysctl vm.overcommit_memory
vm.overcommit_memory = 0

在 shell 中解析 free 的输出有点麻烦。作为 procps 的原始作者，对于这个问题，我只会查看 /proc/meminfo 中的 SwapFree。:smiley:

2 个赞
12

我同意在我们成本受限的世界里，通过 RAM 大小来扩展交换空间不再是一个好计划。接下来历史上的想法似乎是 RAM 很大，你不需要交换空间。之后就是一些交换空间有用的智慧，因为它允许更好地利用 RAM。（在一个不受限制的世界里，我们拥有大量的 RAM，但这只是一个小众市场。）

在过去几个月里，我们看到越来越多的人遇到内存不足的问题和重建失败。越来越多的人发现 Web 升级失败，但命令行工作正常。从简单的支持角度来看，以及从产品声誉的角度来看，我认为我们需要改变通常的建议和通常的设置。我认为 3G 的交换空间是最简单最小的改变，如果我们不做其他事情的话，我们应该这样做。

但我仍然认为多个较小的交换文件是更明智的选择——我们在这里看到过指向它的支持线程。而且我仍然认为最好尝试根据 RAM+交换空间来调整大小，因为这是限制因素，是导致人们遇到麻烦的原因。计算方法可能有所不同。通常的注意事项适用于哪些策略是可维护的、可理解的、具有长久性的。

至于透明大页，我的理解是“透明”会导致问题：内核可能会进行合并和拆分，从而降低性能而没有多大好处。我非常确定大页不适合小型系统。

13

这更多地与工作负载的特性有关，而不是系统的大小。在一个拥有 1GB RAM 的系统上，如果进程相当稳定且拥有大块的 RAM，默认的 2MB hugepages 可以减少 TLB 抖动并提高性能；TLB 无法覆盖 1GB RAM 的映射。这通常只是 CPU 用于查找内存进行合并与 TLB 缓存未命中之间的权衡，并且在 1GB 机器上有许多工作负载可以从 THP 中获得显著的好处。（许多禁用它的建议来自其实现早期；自那时以来它已得到实质性改进。）禁用 Discourse 的 THP 的建议不是因为 1GB RAM 的大小，而是特定于将 redis 与磁盘持久化一起使用，这是 Discourse 使用的一种功能：

https://redis.io/docs/management/optimization/latency/#latency-induced-by-transparent-huge-pages

不幸的是，当启用了透明大页面的 Linux 内核在 fork 调用之后，Redis 会因为持久化到磁盘而产生很大的延迟。Huge pages 是导致以下问题的原因：
…

2 个赞