我们刚买的VPS自带3G内存+1G分区交换空间——我还需要设置一个交换文件吗,还是说这样就够了?
对于小型 Discourse 实例来说,这已经足够了。
我的意思是,不是从它是否会运行得很快等方面考虑,而是从它是否会产生任何错误,例如无法分配额外内存等。我的问题有意义吗?另外,添加一个优先级更低的文件交换会有帮助吗?只是为了确保。
直接购买一个更强大的VPS,至少配备8GB内存。否则你将浪费时间。
这没有回答我的问题。
我无法想象在少于 8GB 内存的情况下运行 Discourse。
Discourse 团队成员说没问题,我相信它没问题。
祝你好运。
Discourse-setup 将会标记任何内存问题。
这也不能回答我的问题。也许我的问题提得不好?
我的论坛托管在 Digital Ocean 的 2GB 内存/50GB 磁盘的 droplet 上,运行得相当不错。
当时 Discourse 安装指南推荐的最低配置是 1GB,但后来我升级了。
如果你能提供更多关于你的论坛规模/繁忙程度的信息,我相信你会得到更详细的答复。
我认为 Discourse 安装程序会自动设置一个交换文件(我没有手动操作),所以我想这部分回答了你的问题。
我认为它会在安装时创建一个 2GB 的交换文件,前提是它检测到你还没有。
编辑: 我认为这个说法更准确:
官方最低支持是 1G 内存 + 2G 交换空间 - 如果你的论坛很小,这样就足够了。不过,每次更新都会稍微变大一些,所以我预计总有一天会不够用。
要让论坛正常工作而不崩溃,内存和交换空间的总和是重要的数字。
要让论坛响应迅速而不至于太慢,内存越多越好。所以,如果 1G 内存 + 2G 交换空间足够,那么 3G 内存 + 1G 交换空间也足够,并且性能可能更好。
我有两个论坛,都相当小,一个运行在 1+2 配置上,另一个运行在 2+2 配置上。
去年我写了这些:
编辑:如果你有足够的磁盘空间来添加交换空间,那就这样做吧——没有理由不这样做,而且可能需要。free 命令会告诉你使用了多少,vmstat 命令可以提供运行中的评论。但平均使用量不重要——峰值使用量才重要。
好的,我的问题更偏向理论性。我无法预测论坛的受欢迎程度。我想了解的是,在某些情况下,我应该怎么做来减轻内存不足的理论可能性。我不知道 Discourse 在什么时候消耗内存最多——是在进行备份时,还是在调整图片大小时,还是在通过管理员控制台更新时,还是……我一无所知。
所以我的想法是,我应该创建多大的交换文件,以确保在内存不足的情况下,Discourse 不会崩溃,只会变得非常慢。同时,我发现已经有一个 1G 的交换分区了,所以我的想法是,如果 3G 实际内存 + 1G 分区交换还不够……我是否也应该创建一个几 GB 的交换文件,并且优先级比分区交换(1G)更低。希望我的问题现在更清楚了。
如果它确实这样做了,那么是的。更新安装自述文件会很有用。从以前官方建议在安装自述文件中创建交换文件的时代过来的,我现在有点困惑,它是否是自动完成的,或者不再需要了,或者有其他原因将其从官方操作指南中移除。
……如果它检测到 1G 的交换分区,但还有基于分区的交换呢?
那么,我问题的延续是,拥有两个交换区域(一个基于分区,另一个基于文件)是个好主意吗?
完全没问题,可以拥有多个交换分区(或者多个交换文件)
我认为最大的内存峰值是在升级期间——届时论坛可能会宕机,直到你能获得帮助。
另外,值得将 overcommit 设置为更宽松的设置:如果你还没有调整过,你会在升级日志中找到相关说明。
警告 overcommit_memory 设置为 0!在内存不足的情况下,后台保存可能会失败。要解决此问题,请将 ‘vm.overcommit_memory = 1’ 添加到 /etc/sysctl.conf 中,然后重新启动或运行命令 ‘sysctl vm.overcommit_memory=1’ 使其生效。
这之前已经被多次提及,但对于将其添加到标准的 Discourse 安装配置中存在阻力。这是一种无法在 docker 镜像内部完成的设置,必须在宿主机上完成。
你所能做的就是降低风险,如果你有更多的资金,你可以更大程度地降低风险。这个问题属于权衡的范畴!
如果我有无限的磁盘空间,我肯定会添加高达 4G 的交换空间,然后再考虑其他问题——这不会有什么坏处。如果我有无限的资金,我会购买最大内存。但就我而言,我没有。
如果你预计你的论坛可能会增长,你应该期望随着时间的推移增加运行它所需的资源,而不是期望一次性配置好机器。
我还没有增加我用于论坛的机器的配置,但我预计我会,也许是今年,也许是明年。
应该可以。我通常会设置 1 和 2gb 的 droplet,并带有 2gb 的交换空间,它们都能正常工作。目前重建需要大量内存,但这应该可以。
你需要更有想象力。
我只会在每月浏览量接近一百万且数据库相当大的网站上运行这么多内存。
我在首次安装 Discourse 时就提到了这一点(Warnings: overcommit_memory and Transparent Huge Pages
这是我之前写的一篇文章:
特别是
开箱即用的内核将拒绝无法满足的分配。通过此调整,它将接受这些分配,失败可能会避免,或者可能会稍后在分配变为使用时发生。
如果您的 RAM 和交换空间总量足够大,您将永远不需要更改此设置。如果总量不够大,更改它可能会有帮助。
还有
它是为了增加可用的虚拟内存量。(即 RAM 和交换空间的总和。)如果您耗尽了 RAM,您将开始遇到性能问题。但是,如果您耗尽了虚拟内存,进程将无法启动,或者会死亡或被杀死。这很残酷。
我们那些 RAM 和磁盘都很小的人可能无法自由地添加大量的交换空间,但 2G 似乎是一个不错的最低限度。(如果您有 16G RAM,您可能不需要任何交换空间,但这是另一回事。当问题是事物失败时,重要的是两者的总和。)
至于阻力,我认为是因为人们认为此更改是为了 redis 的利益,而大多数人不需要它。
编辑:这个最近的帖子 可能是个例子,一个小型实例耗尽了内存,并且没有设置 overcommit。但我们不知道设置 overcommit 是否会解决这个问题——该用户升级到了 8G RAM。
