[Mailman-Users] Hardware Requirements

[Scott Courtney]

On Thursday 11 July 2002 11:59 am, J C Lawrence wrote:
> On Thu, 11 Jul 2002 08:43:06 -0400
>
> Scott Courtney <courtney at 4th.com> wrote:
> > On Thursday 11 July 2002 12:14 am, J C Lawrence wrote:
> >> a) Add more RAM.  Number of queue runners for your MTA
> >
> > Here's a silly question: Is it worth considering *really* upping the
> > RAM, say to two gigabytes, and then putting /var/spool/mqueue on a RAM
> > disk?
>
> Probably not, for two simple reasons:
>
>   1) Too small.  He has a fairly large number of lists and the high
>   probability of flash bursts in traffic, both in terms of numbers of
>   messages and total size of outbound spool.  I could trivially see a
>   RAM disk that small being exhausted.

Agreed, though with the addition of the dedicated MTA relay servers and
just using the local SMTP to send to them at LAN speeds, this might not
be an issue.

>
>   2) No battery backup (the other side of the stability issue you
>   mention).  Doing it properly would involve something like a Rupp solid
>   state disk (which is also big enough for a spool) with battery backup
>   -- which would also happen to blow his budget.

I make the assumption of a UPS on *any* machine that is used as a server.

[...]
>

I wrote:

> > I suspect my first paragraph above is not practical.
[...]

And from your comments, it appears that my first suspicion of my own idea
was correct: it's not practical. Thanks for the enlightenment about Sendmail
internals; I didn't realize it did so many explicity sync() calls.

>
> Ignoring the use of battery backed up solid state disks (which I know of
> a few large mail shops using), this assumes that archiving is
> synchronous with receipt and broadcast.

Good point.

>
> >> b) drop the CPU speed if it will save any money, though I suspect
> >> that's as low as you can buy these days.
> >
> > With respect, I disagree. The price difference between CPU speeds
> > below about 1 GHz is insignificant.
>
> Err, that's what I said.

Sorry, then...that wasn't the way I read your post. I stand corrected.

[...]
>
> >> c) go SCSI with /var/spool/MTA, /var/log, and /var/www on different
> >> spindles.
> >
> > Yes, definitely. Also, for a system that will have this many files on
> > it, consider using a journaling filesystem rather than ext2.
[...]
>
> Journalling actually is a loss in this sort of scenario due to the extra
> tracking and buffer copy overhead.  The nice thing about ReiserFS and
> XFS in particular is that the other optimisations they make more than
> make up for that cost.

Which was my point, though re-reading my post I appear not to have expressed
it very well. I meant use of a journaled filesystem because (1) they are
generally faster than ext2, though as you correctly point out this is for
reasons other than the journaling itself, and (2) because in the event of
an abrupt shutdown, doing an fsck on 120G would be, ummm, nontrivial.

I'm sorry I wasn't very clear on this. My internal subtext was much more
detailed than what I wrote.

>
> Please see the large mail system stuff I wrote up in the FAQ last year.
>

I browsed that when I first started with Mailman, but I'll go back and re-read
again for interest. :-)

> > Just out of curiosity, what are you planning to do for backup media?
> > You may need a secondary SCSI controller channel to prevent contention
> > for bus bandwidth during large backup runs. It could be a lower-cost
> > SCSI board than the primary, probably.
>
> Ahem.  He doesn't have enough SCSI targets to make that a problem.
> Remember how SCSI disconnect works.

Fair enough, and good point. Thanks for the enlightening reply to my post.

Scott

-- 
-----------------------+------------------------------------------------------
Scott Courtney         | "I don't mind Microsoft making money. I mind them
courtney at 4th.com       | having a bad operating system."    -- Linus Torvalds
http://4th.com/        | ("The Rebel Code," NY Times, 21 February 1999)
                       | PGP Public Key at http://4th.com/keys/courtney.pubkey