现在是服务器是2c2g 20g 搭建完之后 还没有发帖子 内存就占满了 即使swap有6g也无法使用
1 Like
通常来说 Discourse 2G 的 RAM 已经没有什么问题了。
根据官方帖子的说法是：
You can easily run Discourse off a VPS with 2GB of RAM. You may want to consider setting up swap if you don’t have that already. Running ./discourse-setup will do this for you.
但实际使用来说，2G 可能还是稍微小了一点点。
我们的服务器跑的是 4G。
类似你服务器占满 2G 的问题，可能主要还是有其他进程在使用你的服务器资源。
SSH 到服务器上使用命令，top 或者 htop 看看服务器上的资源是那个被使用得更多？
不认为 Docker 容器会用掉你 2GB 的内存。
问题是，我们的服务器还增加了 Docker 的内核数量，好像也没有你的这么多呢？
SSH
最好的办法就是 SSH 到服务器上，去看看那个进程占的内存最多。
有时候一些 VPS 的监控程序也占了不少的内存的。
unicorn worker 都是给 Discourse 的。
你用的是什么操作系统呀？RHEL 的还是其他的呢？
用户 1000 都是 Discourse 的。
感觉你的进程也没有看出来什么奇葩的地方，是不是因为不同的操作系统对内存的管理可能会不一样？
我用的是 RHEL 的操作系统，从我的进程来看内存管理貌似还可以。
觉得可以采取的方法是加到 4G 内存吧。
最开始我们用的也是 2G，但感觉 2G 还是有点少，毕竟 Docker 里面还跑了 PGSQL 和 redis。
就算 Ruby 不怎么消耗内存，PGSQL 这东西内存也少不了。
2 Likes
Ubuntu，我问gpt，说那几个进程是discourse的，可能是默认吃满资源吧
我的是ubuntu18.0.4 我觉得也有可能吧 当我重启之后，如果什么都不做的话，只会再用1.1个g
如果有人发了个帖或者回复的一个帖 内存就直接拉到95% 也不知道是什么原因 discourse相关信息也搜不到 太少的资料了 而且我给予了他6g的swap 并做好了相关设置，但是还是得在物理内存达到了90%才能使用
我服务商的此类型产品已经售卖完了 不过我还是觉得discourse太庞大了 flarum我搭建完使用只占用了0.8G 请问您的4GRAM 占用在多少？
您好，我 4G 的占用在 1.57G。
总感觉这个问题是操作系统的内存管理问题，我用的是 RHEL，因为企业用户基本上是 RHEL 的比较多。再说我自己对 RHEL 命令比其他版本的熟悉些。
另外，UNICORN_WORKERS: 2 这个参数我没有调，用的是 2。
上面有句话是这么说的。
## How many concurrent web requests are supported? Depends on memory and CPU cores.
## will be set automatically by bootstrap based on detected CPUs, or you can override
UNICORN_WORKERS: 2
Discourse 会根据你 CPU 和的性能去优化的，有时候 VPS 的 CPU 处理能力不够也会增加内存的使用的。
Discourse
Discourse 的容器里面有 PGSQL，这种大象级别的开源数据库，怎么说 2G 内存也就只能说能跑起来。
如果把数据库独立出来的话，PGSQL 在我们其他的一些项目中至少要给到 32G 到 64G 的内存。
以前一个项目，MySQL 就给了 128G 的内存。
整体感觉来说，DIscourse 在数据层上面的处理还不算太糟糕。
Discourse 里面有一个 UNICORN_WORKERS: 2 配置，这个会根据机器的性能动态去调整的。
我觉得 VPS 不同的主机供应商的 CPU 数量是有水分的，有些比较实际的公司，虽然也是 V-CPU，但是线程方面给得足够。
有些公司在搭建 VPS 上的硬件服务器比较好，比如用个 CPU 是 Intel 的高端至强新版本，那肯定比 i7 这种机器要好一些。
这些配置也会影响到 VPS 中的 CPU 处理能力。
但，这个不同 VPS 是不会告诉用户的，感觉有时候是不是换个 VPS 的机房看看。
实测4c8g跑起来最舒服 不过4g就够了
1 Like
硬件这东西还是越大越多越好。
Discourse 单独使用了容器，使用 Discourse 的服务基本上在服务器上会占用 80 端口。
这太机器就只跑 Discourse 就差不多了。
非常同意，对于一般流量的网站用个 8G 内存肯定是比较好的，基本上不用太担心负载的问题。
硬盘最好也稍微大点，给个 1TB 也够用了。
原来如此 不过经过我和我的朋友测试 discourse内存占用过高 完全是因为Node.js
他会持续吃满你的内存
我最近在想办法把我的服务器切换成Rhel
刚开机我的discourse只占用了1.2G 但是发帖就会占用1.8G
我这个配置一样卡
Slow down, too many requests from this user.
Please retry again in 3 seconds.
Error code: id_10_secs_limit.
连续点3个页面就出现这个
这个是触发了rate limit，不是因为你卡
解决方法两种，
去修改containers/app.yml，把 templates/web.ratelimited.template.yml 那一行删掉（直接禁用速率限制，不推荐）
或者去修改templates/web.ratelimited.template.yml:
params:
reqs_per_second: 36 #每秒内最大请求数
burst_per_second: 36
reqs_per_minute: 600 # 每分钟内最大请求数
burst_per_minute: 300
conn_per_ip: 60 #每个ip最大连接数
run:
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /server.+{/
to: |
limit_req_zone $binary_remote_addr zone=flood:10m rate=$reqs_per_secondr/s;
limit_req_zone $binary_remote_addr zone=bot:10m rate=$reqs_per_minuter/m;
limit_req_status 429;
limit_conn_zone $binary_remote_addr zone=connperip:10m;
limit_conn_status 429;
server {
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: "/location @discourse {/"
to: |
location @discourse {
limit_conn connperip $conn_per_ip;
limit_req zone=flood burst=$burst_per_second nodelay;
limit_req zone=bot burst=$burst_per_minute nodelay;
可以把上面有注释的几行它改大一些
改完了rebuild
好像还有别的ratelimit限制，自己在源码搜吧，懒得找了
@Lhcfl 在后面的解释是正解。
我比较懒，直接把连接限制给删除了。
API 的调用也有限制，我也把 API 的调用限制给删除了：Discourse 使用 API 进行数据恢复的时候提示行为 many times 错误
你的实例上面的那个问题不是 Discourse 的问题，因为 Discourse 设置速率来保护网站不被过度消耗资源。
我觉得用Debian开discourse会流畅许多
我现在在Debian上宝塔 开论坛加几个网站每天也最多吃4G运行内存左右
虽然我开的那几个也就一个云盘吃的多一些
AMD High Performance
4 vCPU, 8192 MB RAM, 180 GB NVMe, 6.00 TB Transfer
就是价格每个月40美金左右 不知道是不是有点小贵
