> A 486, with maybe 16 meg of memory and a slow hard drive, ought to be more 
> than ample, assuming (a fair assumption), that it's going to run some sort of 
> standard mailing list software, like, say, mailman under Linux.  We're 
> talking about a mailing list, after all, that, on a busy day, has fewer than 
> several dozen emails.

the current list server is a PPro 200 with 128MB RAM. it has a 9GB SCSI
disk, and another 18GB SCSI disk.
what beats it up, is that mailman stores its data in huge mbox files; which
have to be locked for each read & write. the server doesn't just get
mailling list traffic; there's also a great many requests for the LKML
archives (lots of web spider traffic, among the real people looking).
when a webspider reads list data; the mbox file for that list has to be
read, once for each message on the list. when we want to add a message to
that list; the mbox file has to be locked, and so other processes block when
trying to read it (or write to it themselves).

so here are some of the options (note that these are not necessarily
exlcusive, we could do several of these):
1. rewrite mailman to use an SQL backend. this way we can do lots of
concurrent reads & writes, without blocking lots of processes.
2. make a separate physical disk for LKML; or TCLUG. this will alleviate the
disk head chatter to a degree, and make somewhat more concurrency possible.
won't alleviate all the process blocking, tho.
3. get more memory, so more of the mbox files can be held in RAM. the
machine physically won't take more memory tho; so this isn't an option.
4. get a completely separate box for TCLUG mail. a 486 may suffice; but note
that 486s usually have really awful disk controllers by today's standards. a
few-hundred MHz machine with as much memory as we can cram into it, would be
worlds better.

IMHE; my posts seem to take about a half-day to show up. but I've never lost
one.

Carl Soderstrom
-- 
Network Engineer
Real-Time Enterprises
(952) 943-8700