On 10/2/2017 7:58 AM, Dimitri Maziuk wrote:
PS there is nothing except postfix, spamd, mailman, and apache serving
mailman's interface running on this server. It' running at load avg of 0.0
on 24 cores in 128GB of RAM. AFAICT the only reason for the software to
croak on the list that size is its own coding.
While mailman routinely handles much larger lists (1), you seem to be very
concerned about the size of a HTTP-based bulk add operation when there are
other methods of adding that many recipients. Perhaps mailman does have a
bug in the area, but there are many other potential factors that could slow
things down or stop them completely (2).
It also sounds like there are other issues with the system, like postfix
delivery times and the length of the CGI timeout.
If you're receiving "please stop" messages from users, maybe those users
don't want to be on this list at all.
This all seems like making a mountain out of a molehill. If you've been
satisfied with mailman, why not continue to be satisfied in all other areas
and just not to large bulk adds via http? (My car is a great car but won't
carry 500kg of cargo, so I don't ask it to.)
Later,
z!
(1)
https://wiki.list.org/DOC/What%20is%20the%20largest%20list%20Mailman%20can%20run%3F)
(2) is the mailman installed on local disk or an NFS share? what the locking
scheme? timeouts? etc
------------------------------------------------------
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
