[TriLUG] mailman tuning

[jonc at nc.rr.com]

Chris,

I've seen this issue thousands of times in the past. Most likely you are using the default database setup and that database size has hit some local threshold that pretty much makes it take forever to do any lookups or mods. When the database is small enough then most mods happen in RAM - the read/writes are cached in RAM. When the size gets too big to cache in RAM, then it does the actual read/writes to disk - and waits for the commits. 

Slowwwwwwwwwwwwwwwwwww becomes an understatement in this scenario.

The easiest fix for this, is to create a small ram drive and run Mailman from that drive.  Modify your Mailman startup/stop scripts to mount the RAM drive - sync the files up to the Mounted drive, then start Mailman.  On stopping, have it sync the files to an on-disk copy, then stop mailman. Be sure to make nightly backups.

The Size of your RAM drive should be about 2x the current size of your Mailman install.
Trust me, you will love it.  Once you have done this, then everything happens directly in RAM again, and it is very spiffy (that's an old fart term for fast). 
 
Jon Carnes

---- Magnus <magnus at trilug.org> wrote: 
> Christopher L Merrill wrote:
> > We have a few opt-in mailing lists that we are currently using mailman
> > for.  However, mailman goes to 100% CPU for a LONG time when we send
> > to our largest list (IIRC, it has ~15000 subscribers).  By LONG time,
> > I mean hours to days.
> 
> Mailman is a suite of programs that each do many different things.
> 
> Have you been able to isolate which process is consuming your
> time/resources?
> 
> I manage a couple of pretty stout Mailman servers so might be able to
> offer some suggestions once you've isolated the bottleneck.
> -- 
> TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ  : http://trilug.org/faq/
> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/