[TriLUG] mailman tuning

[Jeremy Portzer]

jonc at nc.rr.com wrote:
> 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). 
>  

Sorry, but a RAM drive seems pretty dangerous - what happens if  you 
lose power to the machine?  All changes are lost, right?

Yes, I realize that in a datacenter environment, you shouldn't really 
lose power - but other things can happen to cause a system to be 
rebooted unexpectedly (hardware problems, kernel crash, etc.)

And plus, Linux already caches in memory the most frequently-accessed 
disk blocks.  That's what all those "caches" and "buffers" things are 
that you see in the output of "free" (or in top).

There have got to be other ways to solve this - as Magnus went over, a 
more in-depth analysis of the bottleneck is clearly required first 
before making any assumptions about a fix.

--Jeremy