Мы перешли с рассылки, и многие пользователи до сих пор пользуются нашим форумом преимущественно через электронную почту.
Примерно 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). Чтобы получить идентификаторы пользователей всех пользователей с включённым режимом почтового списка, выполните UserOption.where(mailing_list_mode: true).pluck(:user_id)
Спасибо, @simon.
Я сгенерировал список, как вы и советовали в своём посте. На самом деле это несколько списков. Генерируется список ID пользователей, и когда он доходит примерно до 50 записей, появляется сообщение :...skipping..., после чего процесс начинается заново с теми же 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, и тех же пользователей.
Всего я нашёл около 90 из 400 активных пользователей. Всё это очень странно, и я не понимаю, что происходит.
Буду очень признателен за любую помощь.
P.S. Как выйти после последнего : в конце результатов поиска, чтобы можно было запустить другой запрос?
Когда запрос возвращает больше текста, чем помещается на экране, он отображает его с сокращениями. Вы можете найти в Google, как это работает.
Пробел переключит на следующий экран, / выполнит поиск, q завершит работу.
Похоже, что письма доставляются активным пользователям. Остальные, возможно, неактивны?
Спасибо, Джей.
Нет, у нас более 450 активных пользователей. Я не могу увидеть какой-либо закономерности. Я посмотрел более ранний пост от нескольких дней назад, который был отправлен 334 пользователям через режим рассылки.
Единственное изменение с тех пор — мы добавили SPF-запись в наш DNS, так как у нас возникли проблемы с отправкой писем в Google. Но это было связано с нашим почтовым сервером; я не менял настройки SMTP в Discourse.
@pfaffman Я только что установил Data Explorer. Может быть, я могу выполнить там запрос?
Это начинает меня сводить с ума 
Я собирался написать, что, как-то так, всё само собой «наладилось», поскольку 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 нет застрявших задач, и в логах появляется та же ошибка. Я пробовал пересобрать систему, но это, похоже, не помогло. Это действительно вызывает у наших пользователей сильное беспокойство.
Кажется, что происходит следующее: после пересборки, если приходит новый пост, он отправляется, но после этого последующие посты и ответы больше не отправляются.
Буду очень признателен за любую помощь!
Эд
Для меня это превращается в действительно раздражающую проблему.
Сегодня Discourse решил перестать отправлять письма подписчикам рассылки после того, как доставил всего 15 писем. Это не проблема провайдера, так как я уже сменил провайдера. Также в логах нет сообщений об ошибках, и в Sidekiq ничего не застряло.
Кажется, единственный способ обойти это — выполнить пересборку.
Есть ли возможность автоматически запланировать пересборку через определённые промежутки времени? Хотя бы тогда мне не придётся постоянно следить за этим.
Вы можете настроить cron-задачу для этого.
Не достигли ли некоторые пользователи лимита отправляемых писем в день? Не отключили ли они рассылку? (Это не объясняет, почему пересборка что-то исправит). Достаточно ли у вас оперативной памяти? Нет ли записей в логах?
недостаточно памяти — довольно понятное сообщение об ошибке.
РЕДАКТИРОВАНИЕ: Ой. Я перепутал вас с другой темой, поэтому всё это про мультисайты, хотя и верно, здесь может не иметь смысла.
Я почти уверен, что мой экземпляр, работающий только в режиме мультисайта, использует 4 ГБ ОЗУ, но на нём также не запущены MySQL, Apache и WordPress. Мой сайт с конфигурацией (staging + production)*(discourse + wordpress) доставлял мне немало хлопот, пока я не увеличил память до 8 ГБ. Это включает контейнеры для PostgreSQL, Redis, Traefik, Prometheus и MariaDB, а также по два контейнера для WordPress и Discourse (не мультисайт, так как на тестовом окружении должны быть возможность использовать другие плагины, чем на продакшене).
Если ваша цель — сэкономить деньги и у вас сайты Discourse с низкой нагрузкой, то, вероятно, лучше разместить каждый из них на отдельном droplet за $5 (1 ГБ).
Да, я понял 
У меня стандартный общий процессор, и на моем дроплете запущен только один сайт Discourse.