[Mailman-Users] Large Lists manipulations

[Tass]

My issue is not with its sending speed (in fact it still nice and
fast) but with sheer management issues.

It is a 10K+ list that is for outgoing announcements.. 1-4 week of about
4K...

DNS and MTA are non issues.. I have my own name servers and a heavily
customized PostFix as well as softupdate on the spool ... so mail goes out
fast ..

my issues are just with trying to do member operation ... it would nice if
you could split it up into smaller sets or have some direct edit tool that
may be faster than remover_members seems to be.

 On Wed, 5 Dec 2001, J C Lawrence wrote:

> On Wed, 5 Dec 2001 08:28:53 -0500 (EST) 
> tass  <tass at kenderhome.com> wrote:
> 
> > SCSI alas is not an option (which is where I think the bottleneck
> > is).  It is an 80GB IBM EIDE hardrive with UDMA66 Celeron 500
> > 686class 512M Ram
> 
> Its a little difficult to say much without knowing how much list
> traffic you'd be dealing with or what your outbound bandwidth is.
> Assuming reasonable outbound bandwidth (T1+), a posting rate of
> ~10 messages a day, and ~10% slow MX'es, I'd:
> 
>   -- set SMTP_MAX_RCPTS to be reasonably large (in the 50 - 100
>   range)
> 
>   -- make sure I had a local cacheing nameserver installed
>   (recommend: pdnsd)
> 
>   -- tune my MTA to be sensitive to system load.  Using Exim as the
>   MTA would make this particularly easy.
> 
>   -- tune the MTA for rapid fall-offs for slow MX'es and hard
>   bounces no later than 4 days (as per RFC recommendation).
> 
> Note that running a 10K member list on such hardware is not
> inherently a problem.  It can and should work quite nice without
> much stress or strain.  It all really depends on two  things:
> 
>   1) How busy the list is
> 
>   2) What your percentage of slow MX'es is (which controls what your
>   average queue size is).
> 
> The less saturated the system is, the more attractive Postfix is as
> an MTA.  Nicely enough, Postfix is fast enough and clever enough in
> its spool handling that it will delay the saturation point
> significantly.  However, if you are at or near saturation point the
> Exim's queue handling will be a lot nicer to you and your system,
> with its graceful fall-offs for system load.
> 
> > I have about 80% disk cap still open
> 
> If you can, throw another disk in there, then put /var/spool/<MTA>
> on it and put it on a __different___ IO chain from your main drive.
> This will reduce IO and head contention for your mail spool.
> 
> -- 
> J C Lawrence                
> ---------(*)                Satan, oscillate my metallic sonatas. 
> claw at kanga.nu               He lived as a devil, eh?		  
> http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
> 

--
|Tass Chapman| tass at kenderhome.com   : PGP key @ pgpkeys.mit.edu:11371 |
| http://www.kenderhome.com          : KEYID: 0x5BC152A1               | 
|ICQ UIN:394570                                                        | 
--