我一直在日志中看到这个——数值在 100k 到 135 万之间——但接近 100k 的读数似乎相当普遍：
您的 Redis 网络连接性能极差。
上次的 RTT 读数是 [97069, 103986, 98459, 100762, 381617]，理想情况下应该小于 1000。
确保 Redis 与 Sidekiq 运行在同一个可用区或数据中心。
如果这些值接近 100,000，则意味着您的 Sidekiq 进程可能
CPU 过载；请降低您的并发度以及/或参阅 https://github.com/mperham/sidekiq/discussions/5039
这是否表明 Redis 无法使用足够的 CPU？尽管服务器本身有充足的 CPU 和内存空间。
另外：
Sidekiq 正在为 'www.example.com' 使用过多内存（使用量：3570.19M），正在重启
这是在使用 Discourse stable 3.3.2 的一体化 app.yml。
来自 app.yml：
UNICORN_SIDEKIQS: 9
DISCOURSE_SIDEKIQ_WORKERS: 5
我还向主机添加了此配置：
Sidekiq 仪表板信息：
看起来 Redis 的内存使用量似乎无法超过 1024M。
如果有人有什么想法，我将不胜感激！ 
为了跟进这个问题，我遇到了与 Jobs::PostAlert 相同的问：
在使用 4 个 Sidekiq 和 5 个（默认）线程进行当前测试时，这些作业通常需要 15 分钟。看来 Sidekiq 的每秒作业速度主要取决于同时运行的作业数量以及有多少线程可用于其他作业。
将 Sidekiq 增加到 6 个或更多（5 个线程）将提高队列清除速度，但 PostgreSQL 会经常崩溃（我猜测是由于同时运行了过多的 Jobs::PostAlert 作业）。
这是 Stable 3.3.2 版本。如果我没记错的话，来自链接线程的更改和修复似乎已在 3.3.2 版本中实现。
Postgres 永远不应该崩溃，这通常表明存在 Postgres 错误或某种更大的问题。
您有日志吗？
1 个赞
Ed_S
(Ed S)
4
自进行那些内核配置更改以来，您是否已重新启动服务器？
也许
lscpu
也会有帮助
Falco
(Falco)
5
你不应该将 UNICORN_SIDEKIQS 调得这么高，只增加工作进程但
这不应该发生。
可能的原因是：
- 你受到资源限制，因为：
a) 你的网站已经超出了服务器资源的承载能力
b) 你错误地分配了资源
- 堆栈中存在 bug
我建议你改为：
UNICORN_SIDEKIQS: 1
DISCOURSE_SIDEKIQ_WORKERS: 20
这应该能释放你服务器的一些内存。
要获取更多信息，你需要在一个 PostgreSQL 控制台中运行有问题的作业，并报告瓶颈是什么。
