我一直在日志中看到这个——数值在 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 错误或某种更大的问题。
您有日志吗？
2 个赞
Ed_S
(Ed S)
4
自进行那些内核配置更改以来，您是否已重新启动服务器？
也许
lscpu
也会有帮助
1 个赞
Falco
(Falco)
5
你不应该将 UNICORN_SIDEKIQS 调得这么高，只增加工作进程但
这不应该发生。
可能的原因是：
- 你受到资源限制，因为：
a) 你的网站已经超出了服务器资源的承载能力
b) 你错误地分配了资源
- 堆栈中存在 bug
我建议你改为：
UNICORN_SIDEKIQS: 1
DISCOURSE_SIDEKIQ_WORKERS: 20
这应该能释放你服务器的一些内存。
要获取更多信息，你需要在一个 PostgreSQL 控制台中运行有问题的作业，并报告瓶颈是什么。
1 个赞
抱歉消失了一段时间，感谢大家的回复。
我认为 Redis 变慢的主要原因是 THP 仍然启用（我原以为不是这样）：
对于 PG 崩溃，对我来说主要的解决方案是在 app.yml 中添加这个：
docker_args:
- "--shm-size=34g"
该值设置为 db_shared_buffers + 2GB，其中 db_shared_buffers 是主机总内存的 25%。
覆盖默认的 512m：
1 个赞
Ed_S
(Ed S)
7
我回顾了您的发帖历史，在 Very slow Sidekiq issue … massive numbers of unread user notifications 中看到您运行的是一个 32 核 128 GB 的服务器，拥有非常庞大且活跃的用户群。因此，在这种情况下，我明白为什么 34G 并不是一个很大的数字！不过，为了提供背景信息，了解您的设置规模可能会有所帮助（也很有趣）——可能在这里，甚至在您的个人简介中？（也许是每日和每月活跃用户数、数据库备份大小、服务器配置中的内存、交换空间、磁盘、CPU。）甚至可以开一个帖子，专门分享我们的统计数据——无论大小。
