Re: Finding the Bottleneck
Well... I'm not sure if you saw the "top" output I sent to the list a
while back, but the swap isn't touched at all. The 128M ram seems to be
sufficient at this time. I'm not sure that throwing more memory at it
would help much, would it? I think even if more ram is put in, it will
just use at buffers..... er.... that MIGHT help, right? Would be an easy
solution if 256M would help get an extra 20% performance :-)
Concerning the dns server, if it was not run locally, then every single
dns lookup would have to go across the network. Now that would be a LOT of
requests that would otherwise have been answered nearly instantly if it
The mail queue is on its OWN disk (disk 2). Everything else is on disk 1.
The mail queue disk ONLY has the mail queue and absolutely nothing else.
It is there for that specific purpose (even though it hasn't helped that
much). Also, log files in syslog already have "-" in front of the file
name so they aren't synced every write.
We've tried just about everything (except the raid setup) to get every
last ounce of performance out of this... but it doesn't seem like its made
a huge difference :-/
----- Original Message -----
From: "Rich Puhek" <email@example.com>
To: "Russell Coker" <firstname.lastname@example.org>
Cc: "Jason Lim" <email@example.com>; <firstname.lastname@example.org>
Sent: Saturday, June 09, 2001 7:11 AM
Subject: Re: Finding the Bottleneck
> Memory memory memory! True, memory is not currently a limiting factor,
> but it likely could be if he were running BIND locally. As for making
> sure that the server is not authoratative for other domains, that will
> help keep other DNS demands to a minimum.
> The mail server will chew up a load of memory (or can anyhow.. his
> doesn't seem too bad). A highly-utilized DNS server will also chew up a
> load of memory. You do not want the DNS server to swap, so you need to
> have enough memory to be sure it can cache enough information.
> As for speed, if you have a machine on a LAN set up as a caching-only
> DNS server (that's what I was trying to say before), I'm thinking I'll
> take the LAN latency hit over having the MTA competing for resources
> with the DNS server.
> Other than that, yea, some kind of RAID solution would be cool for him.
> I'd also look at making sure /var/log is on a seperate drive from
> /var/spool/mail. I saw an email that indicated that /swap was seperate
> from /var/spool, but nothing about where the log files were located. Not
> synching after evey write will help obviously, but I recall seeing quite
> a benefit from seperate drive for /var/log and /var/spool.
> Russell Coker wrote:
> > On Friday 08 June 2001 05:47, Rich Puhek wrote:
> > > In addition to checking the disk usage, memory, and the other
> > > suggestions that have come up on the list, have you looked at DNS?
> > > Quite often you'll find that DNS lookups are severely limiting the
> > > performance of something like a mailing list. Make sure that the
> > > server itself isn't running a DNS server. Make sure you've got one
> > Why not? When DNS speed is important I ALWAYS install a local DNS.
> > Requests to 127.0.0.1 have to be faster than any other requests...
> > > two DNS servers in close proximity to the mail server. Make sure
> > > the DNS server process isn't swapping on the DNS servers (for the
> > The output of "top" that he recently posted suggests that nothing is
> > swapping.
> > > with 128 MB of RAM as your DNS server. Also, if possible, I like to
> > > have the DNS server I'm querying kept free from being the
> > > server for any domains (not always practical in a real life
> > > I know).
> > How does that help?
> > If DNS caching is the issue then probably the only place to look for a
> > solution is djb-dnscache.
> > --
> > http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
> > http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
> > http://www.coker.com.au/projects.html Projects I am working on
> > http://www.coker.com.au/~russell/ My home page
> > --
> > To UNSUBSCRIBE, email to email@example.com
> > with a subject of "unsubscribe". Trouble? Contact
> Rich Puhek
> ETN Systems Inc.
> To UNSUBSCRIBE, email to firstname.lastname@example.org
> with a subject of "unsubscribe". Trouble? Contact