[Mailman-Users] Summary, whats next?

[Alan L. Waller]

Set up a caching DNS server on the Mailman server, this is installed by 
default in RH7.2 just start it by

/etc/rc.d/init.d/named start

These are the final value I found via many hours of testing to get the max 
performance out of my server with 550 lists and about 400,000 users

This is found in /your local dir/mailman/Mailman/Defaults.py

#####
# VARIABLES DEPENDING ON THE SIZE OF YOUR LISTS, THE PERFORMANCE OF YOUR
# HARDWARE, NETWORK AND GENERAL MAIL HANDLING CAPABILITIES, ETC.


# Set this to true to turn on MailList object lock debugging messages, which
# will be written to logs/locks.  If you think you're having lock problems, or
# just want to tune the locks for your system, turn on lock debugging.
LIST_LOCK_DEBUGGING = 1


# This variable specifies how long the lock will be retained for a specific
# operation on a mailing list.  Watch your logs/lock file and if you see a lot
# of lock breakages, you might need to bump this up.  However if you set this
# too high, a faulty script (or incorrect use of bin/withlist) can prevent the
# list from being used until the lifetime expires.  This is probably one of
# the most crucial tuning variables in the system.
LIST_LOCK_LIFETIME = hours(15)


# This variable specifies how long an attempt will be made to acquire a list
# lock by the qrunner process.  If the lock acquisition times out, the message
# will be re-queued for later delivery.
LIST_LOCK_TIMEOUT = seconds(15)


# cron/qrunner lock lifetime.  This is probably the second most crucial tuning
# variable in the system.  See the notes for LIST_LOCK_LIFETIME above.  Watch
# your logs/smtp file and make sure that QRUNNER_LOCK_LIFETIME is set longer
# than the longest period you see here.  It is a bad thing if multiple
# qrunners run at the same time.
QRUNNER_LOCK_LIFETIME = hours(48)


# Two other qrunner resource management variables.  The first controls the
# maximum lifetime of any single qrunner process, and the second controls the
# maximum number of messages a single qrunner process will, er, process.
# Exceeding either limit causes qrunner to exit, reclaiming system resources
# and deleting the lock.  Other qrunners will then process the remaining
# messages.  Set either to None to inhibit this resource check.
QRUNNER_PROCESS_LIFETIME = hours(4)
QRUNNER_MAX_MESSAGES = 150000

Regards,

Al


At 10:57 PM 4/28/2002 +0200, Danny Terweij wrote:

>Hello,
>
>Still no success of fast processing the qfiles dir.
>
>WITH DEFAULT MAILMAN VALUES at Default.py file
>
>I did do the following :
>Using SMTPDirect module to 127.0.0.1 port 25 (Normal Sendmail)
>Using SMTPDirect module to 127.0.0.1 port 250 (Sendmail no DNS resolving
>according the FAQ)
>Using SMTPDirect module to 192.168.0.1 port 25 (Another SMTP server running
>on windows 2000)
>Using Sendmail module
>
>All  methods are the same results. qrunner is processing just 1 message at
>the time and the next message at the qfiles dir is processed about 10
>minutes later.
>
>So qrunner is processing the qfiles dir for about 10 messages in 1 hour.
>Because there are more than 10 messages comming in .. the qfiles dir is
>growing and growing.
>
>Now you may tell me what i now can try to make qrunner faster processing.
>
>Mailman 2.0.10
>Pentium 120, 96Mb ram
>2x40gb HDD
>Redhat 7.2
>
>Greetings,
>Danny Terweij
>
>
>
>
>
>------------------------------------------------------
>Mailman-Users mailing list
>Mailman-Users at python.org
>http://mail.python.org/mailman/listinfo/mailman-users
>Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py