On Mon, Mar 18, 2019, at 9:14 AM, Dmitry Makovey wrote:
In the last couple of month we've observed some odd behavior from MM3 (namely the core) where it seems like email that is about to be sent to a large-ish mailing list (10K users) has been processed yet never gets sent out until we restart the core.
This is indeed weird, I don't think 10k is too much, but it also depends on your MTA. How fast do they allow sending emails and if there is any rate limiting.
I wouldn't necessarily consider this a performance problem in Core, since it is still just processing only one email. All it needs to do is send them all out, which is where the problem should be.
I'd imagine debug logging on outgoing runner should give some more pointers on what is going on.
You can configure the smtp runner to log extra information (copied from docs)1:
[logging.smtp] path: smtp.log
# The smtp logger defines additional options for handling the logging of each # attempted delivery. These format strings specify what information is logged # for every message, every successful delivery, every refused delivery and # every recipient failure. To disable a status message, set the value to 'no' # (without the quotes). # # These template strings accept the following set of substitution # placeholders, if available. # # msgid -- the Message-ID of the message in question # listname -- the fully-qualified list name # sender -- the sender if available # recip -- the recipient address if available, or the number of # recipients being delivered to # size -- the approximate size of the message in bytes # seconds -- the number of seconds the operation took # refused -- the number of refused recipients # smtpcode -- the SMTP success or failure code # smtpmsg -- the SMTP success or failure message
every: $msgid smtp to $listname for $recip recips, completed in $time seconds success: $msgid post to $listname from $sender, $size bytes refused: $msgid post to $listname from $sender, $size bytes, $refused failures failure: $msgid delivery to $recip failed with code $smtpcode, $smtpmsg
I'd also recommend looking into MTA logs for anything un-usual.
I would appreciate any pointers on where to look for the source of the problem. At the moment, since I can't reliably reproduce it I can't really test it nor do I know where to look next time things get stuck. Mailing list in question is high profile thus when event like this happens I have only limited time amount to spend on troubleshooting/digging before I just restart the core (which by the way takes about 45min to fully start... which is another puzzle to solve at
How do you measure that it takes 45 mins to start?
What database backend are you using?
later time)
-- Sr System and DevOps Engineer SoM IRT
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
*Attachments:*
- signature.asc
-- thanks, Abhilash Raj (maxking)