>I know this could easily get out of hand, but I'm wondering about changing
>a mailing list server. Currently, it is an HP/715 with 32 megs of RAM,
>a SPECint92 rating of 36, SPECfp of 72.
SPEC*92 has been repudiated by SPEC. its a computational
benchmark of fixed size. it fits in L2 cache. Parts have been cooked.
Mail is a network app. you need a host that has good networking and
>It serves a couple of dozen automotive related lists, under majordomo,
>with a "fanout" of about 2.5 million messages per month, where fanout is a
>somewhat useless number found by multiplying the number of list members by
>the number of messages.
i am using majordomo for the FreeBSD mailing lists. we have 11,000
direct subscribers, some number of which are mail exploders. since may 25th
4am (as i write its now may 30th 6am) we have handled 890,000 messages
and 1.75GB of mail thru the smtp8 mailer alone.
>That is, if there are 500 members, and 1,000 messages per month, that's a
>fanout of 500,000 per month. Better metrics for mailing list loads would
>also be welcome.
we use a PC with 64MB, 4 scsi disks.
>So I'm currently wondering if some Pentium based PC, with a decent ethernet
>card, can handle the load. The machine also serves as an FTP site, with a
>dozen or so connections during the day, and as a web server. The CPU is
>usually about 90% idle, while it waits for disk IO and 30 to 40 packets
>per second to get pumped out to a fairly busy net. Could a new Pentium,
>running Linux, perhaps, handle this sort of work?
ftp, web, mail. there are all net and disk intensive programs.
a *good* quality 586 will do fine. i would recommend against linux.
its networking and *synchronous* disk speed are not as fast as FreeBSD.
read the usenix96 paper by mary baker and kevin lai of stanford
context switching will be critical as well.
context switch: FreeBSD flat graph @ 100usec
Linux exponential graph crosses FreeBSD at 19 procs
network tcp: FreeBSD: 65.95MB/s
disk synchronus: FreeBSD: 65ms
Linux: no data available
Linux: (asynchronous) 0ms
0ms means that the data is *not* on the disk.
should something bad happen the data is gone.
Jonathan M. Bresler 202-452-2831 breslerj @
MS-169 Federal Reserve Board of Governors Washington DC 20551
Speaking for myself. Others speak for the Federal Reserve Board of Governors