我们已从邮件列表迁移过来，许多用户仍主要通过电子邮件使用我们的论坛。
大约有 300 名用户处于邮件列表模式。但 Discourse 在发布新主题时似乎只发送了约 75 到 80 封邮件。
我比较了多位成员的邮件列表用户设置，它们都是一样的。
跳过部分中也没有任何内容。
我不知道应该从哪里入手查找可能导致此问题的原因。
所有用户都激活了吗？也许他们收不到任何邮件？
是的，这些都已激活。
不幸的是，这似乎也是随机的。我有几个用于设置相关内容的账户，它们的行为也不尽相同。
现在我查看了一些这里较旧的话题，情况似乎很相似：https://meta.discourse.org/t/mailing-list-mode-not-sending-to-more-than-just-a-couple-of-users/80486/3
可能是同一个问题。不过，我不知道如何按照该帖子解决方案中的建议更改设置。
我尝试运行以下命令：
User.find_by_username(‘Neuer.test’).mailing_list_mode
但得到以下错误：
NoMethodError: undefined method `mailing_list_mode’ for #User:0x00005569c4038af8
邮件列表模式是在 user_options 表中设置的。请尝试运行 UserOption.where(mailing_list_mode: true)。若要获取所有启用了邮件列表模式的用户 ID，请运行 UserOption.where(mailing_list_mode: true).pluck(:user_id)
谢谢你，@simon
我按照你帖子中的建议生成了一个列表。实际上，这是一组列表。它会生成一个用户 ID 列表，然后大约到第 50 个时显示 :...skipping...，接着又从头开始，使用相同的用户 ID，并在底部添加一个新的 ID，如此重复大约 4 到 5 次。中间还有一大段空白行。但这可能是正常行为？
无论如何，这远远不是通过邮件列表模式订阅的完整用户列表（目前只有 58 个，我预期大约有 350 个）。
随后我对这些 ID 进行了一些检查，发现它们都没有收到最近的一则帖子。
我还运行了 UserOption.where(mailing_list_mode: false).pluck(:user_id)，结果又得到了 29 条记录。
运行 UserOption.where(mailing_list_mode: 1).pluck(:user_id) 得到的数量与 true 的情况类似，并且是相同的用户。
总的来说，我在大约 400 个激活用户中只找到了约 90 个。这非常奇怪，我也不明白到底发生了什么。
非常感谢您的任何帮助。
附：在搜索结果底部最后一个 : 之后，我该如何退出，以便运行另一个查询？
当查询返回的文本超出屏幕显示范围时，它会以较少的内容进行展示。你可以自行搜索了解其工作原理。
按空格键进入下一页，按 / 键进行搜索，按 q 键退出。
所以我认为这听起来像是邮件正被投递给活跃用户。其他用户可能处于非活跃状态？
谢谢 Jay。
不，我们有超过 450 名活跃用户。我看不出有什么规律。我查看了几天前的一篇早期帖子，当时通过邮件列表模式发送给了 334 名用户。
此后唯一的变化是，我们在 DNS 中添加了 SPF 记录，因为我们之前向 Google 发送邮件时遇到了问题。但这仅涉及我们的邮件服务器，我没有更改 Discourse 中的任何 SMTP 设置。
@pfaffman 我刚刚安装了数据浏览器，也许我可以在那里运行一个查询？
这真让我头疼 
我本来想发帖说，不知怎么一切似乎都“自行解决了”，因为有 336 人收到了各种最近的帖子。
但随后，同一用户在短时间内对某条帖子连续回复了两条消息。181 名成员收到了这两条消息，38 名成员只收到了一条，还有 117 人完全没有收到任何电子邮件。
请问还有其他日志可以查看，以便查明原因吗？Sidekiq 中没有任何相关记录。
问题似乎是 421.4.7.0 错误：来自该 IP 地址的连接过多。
奇怪的是，这似乎主要发生在某一位会员身上。
我该如何修复？
日志显示如下：
消息（报告了 1957 份副本）
作业异常：421 4.7.0 dd27022.xxxxxx.com 错误：来自 xxx.xxx.xx.xxx 的连接过多
### 回溯
/usr/local/lib/ruby/2.6.0/net/smtp.rb:969:in `check_response'
/usr/local/lib/ruby/2.6.0/net/smtp.rb:553:in `do_start'
/usr/local/lib/ruby/2.6.0/net/smtp.rb:518:in `start'
mail-2.7.1/lib/mail/network/delivery_methods/smtp.rb:109:in `start_smtp_session'
mail-2.7.1/lib/mail/network/delivery_methods/smtp.rb:100:in `deliver!'
mail-2.7.1/lib/mail/message.rb:2159:in `do_delivery'
mail-2.7.1/lib/mail/message.rb:260:in `block in deliver'
actionmailer-6.0.1/lib/action_mailer/base.rb:589:in `block in deliver_mail'
activesupport-6.0.1/lib/active_support/notifications.rb:180:in `block in instrument'
activesupport-6.0.1/lib/active_support/notifications/instrumenter.rb:24:in `instrument'
activesupport-6.0.1/lib/active_support/notifications.rb:180:in `instrument'
actionmailer-6.0.1/lib/action_mailer/base.rb:587:in `deliver_mail'
mail-2.7.1/lib/mail/message.rb:260:in `deliver'
actionmailer-6.0.1/lib/action_mailer/message_delivery.rb:114:in `block in deliver_now'
actionmailer-6.0.1/lib/action_mailer/rescuable.rb:17:in `handle_exceptions'
actionmailer-6.0.1/lib/action_mailer/message_delivery.rb:113:in `deliver_now'
/var/www/discourse/lib/email/sender.rb:212:in `send'
/var/www/discourse/app/jobs/regular/notify_mailing_list_subscribers.rb:90:in `block (2 levels) in execute'
/var/www/discourse/app/models/email_log.rb:35:in `block in unique_email_per_post'
/var/www/discourse/lib/distributed_mutex.rb:33:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:14:in `synchronize'
/var/www/discourse/app/models/email_log.rb:31:in `unique_email_per_post'
/var/www/discourse/app/jobs/regular/notify_mailing_list_subscribers.rb:89:in `block in execute'
activerecord-6.0.1/lib/active_record/relation/batches.rb:70:in `block (2 levels) in find_each'
activerecord-6.0.1/lib/active_record/relation/batches.rb:70:in `each'
activerecord-6.0.1/lib/active_record/relation/batches.rb:70:in `block in find_each'
activerecord-6.0.1/lib/active_record/relation/batches.rb:136:in `block in find_in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:238:in `block in in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:222:in `loop'
activerecord-6.0.1/lib/active_record/relation/batches.rb:222:in `in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:135:in `find_in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:69:in `find_each'
/var/www/discourse/app/jobs/regular/notify_mailing_list_subscribers.rb:61:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
rails_multisite-2.0.7/lib/rails_multisite/connection_management.rb:63:in `with_connection'
/var/www/discourse/app/jobs/base.rb:221:in `block in perform'
/var/www/discourse/app/jobs/base.rb:217:in `each'
/var/www/discourse/app/jobs/base.rb:217:in `perform'
sidekiq-6.0.4/lib/sidekiq/processor.rb:196:in `execute_job'
sidekiq-6.0.4/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'
sidekiq-6.0.4/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'
sidekiq-6.0.4/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'
sidekiq-6.0.4/lib/sidekiq/middleware/chain.rb:143:in `invoke'
sidekiq-6.0.4/lib/sidekiq/processor.rb:163:in `block in process'
sidekiq-6.0.4/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/job_retry.rb:111:in `local'
sidekiq-6.0.4/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq.rb:37:in `block in <module:Sidekiq>'
sidekiq-6.0.4/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/processor.rb:257:in `stats'
sidekiq-6.0.4/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.0.4/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/job_retry.rb:78:in `global'
sidekiq-6.0.4/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.0.4/lib/sidekiq/logger.rb:10:in `with'
sidekiq-6.0.4/lib/sidekiq/job_logger.rb:33:in `prepare'
sidekiq-6.0.4/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.0.4/lib/sidekiq/processor.rb:162:in `process'
sidekiq-6.0.4/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.0.4/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.0.4/lib/sidekiq/util.rb:15:in `watchdog'
sidekiq-6.0.4/lib/sidekiq/util.rb:24:in `block in safe_thread'
您需要向您的电子邮件服务提供商咨询，这与 Discourse 无关。
@codinghorror
所以我更换了邮件服务提供商，现在通过 Amazon SES 发送邮件。这似乎解决了几周的问题。但现在 Discourse 又开始在向邮件列表订阅者投递邮件的过程中随机中断发送。日志中没有错误。我已经重新构建了容器，目前看来又正常了。还有其他地方可以查找潜在的错误日志吗？
Sidekiq 中有卡住的任务吗？
不，很遗憾没有。
过去几天我也遇到了类似的问题。邮件未能发送给邮件列表用户，Sidekiq 中没有积压的任务，并且出现了相同的日志错误。我尝试过重建，但似乎没有效果。这确实给我们的用户带来了极大的困扰。
似乎发生的情况是：重建后，如果收到新帖子，它会被发送出去，但在此之后，后续的帖子或回复都不会再发送。
非常感谢您的任何帮助！
Ed
这对我来说真成了一个令人沮丧的问题。
今天，Discourse 在仅发送了 15 封邮件后，就突然停止向邮件列表订阅者发送邮件。这不是服务商的问题，因为我已经更换了服务商。日志中也没有任何错误信息，Sidekiq 中也没有任务被卡住。
看来唯一的解决办法就是重新构建。有没有办法自动按计划的时间间隔执行重新构建？至少这样我就不需要一直监控它了。
您可以设置一个 cron 任务来实现这一点。
某些用户是否已达到每日最大邮件发送限制？他们是否禁用了邮件？（这无法解释为什么重建能解决问题）。您的内存是否充足？日志中是否有相关记录？
内存不足 是一个非常清晰的错误信息。
编辑：哎呀。我把你和其他话题搞混了，所以这些关于多站点的内容虽然都是事实，但在这里可能毫无意义。
我相当确定我的仅多站点实例运行在 4GB 内存上，但那台机器并没有同时运行 MySQL、Apache 和 WordPress。我的站点配置为 (staging + production)*(discourse + wordpress)，在我将其升级到 8GB 之前曾让我头疼不已。该配置包括 Postgres、Redis、Traefik、Prometheus 和 MariaDB 的容器，以及 2 个 WordPress 和 2 个 Discourse 容器（并非多站点模式，因为预发布环境需要能够拥有与生产环境不同的插件）。
如果省钱是你的首要目标，且你的 Discourse 站点访问量较低，那么为每个站点单独使用一台 5 美元（1GB）的 Droplet 可能是最佳选择。
是的，我明白了 
我使用的是标准共享 CPU，并且只在 droplet 上运行一个 Discourse 站点。