|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Craig Sanders (cas
taz.net.au)Date: Thu Sep 27 2001 - 04:40:35 CDT
On Thu, Sep 27, 2001 at 11:37:46AM +0300, Liviu Daia wrote:
> On 26 September 2001, Alexander <ml
ambrosa.it> wrote:
> [...]
> > Title: the best mode to deliver 1.000.000 email messages (recipient
> > are ALL different and email are ALL different) in few hours during a
> > single delivery session.
> >
> > You suppose to have a SMP Linux server (i.e. dual P-III 800 Mhz, 512
> > MB Ram, SCSI Raid 5, kernel 2.4.9 and RaiserFS) and a good internet
> > connection (4 Mbit/sec full bandwidth) and a fast DNS server near me.
it was mentioned earlier in the thread that the queue size probably
wouldn't exceed 1GB because the messages were quite small (even though
there's a million of them in the queue).
in that case, a 2GB sold-state disk would be a good idea for the queue
directory. can't get faster than that for disk I/O. formatting it with
reiserfs would be good too.
> Wietse already explained how to setup Postfix for best performance.
> Here's an additional checklist, mainly for the rest of the system:
>
> - if possible, use OpenBSD or FreeBSD with softupdates rather than
> Linux;
alternatively, configure and use linux properly rather than believe
propaganda.
> - if you insist on using Linux, use a 2.2.x kernel, not a 2.4.x one,
> and turn OFF the swap; buy more RAM if you feel you're running out of
> it;
2.4.x kernels are perfectly adequate, indeed much better than 2.2.x kernels.
and there's no need to turn off the swap.
adding RAM is always a good idea.
> - use RAID 0+1, not 5, and (if you have that choice) mirror the stripes
> instead of striping the mirrors;
my testing a few months ago proved that RAID5 is significantly faster
than RAID0+1 for the kind of disk loads you see on mail servers.
the tests were performed using the exact same hardware, and same
software, on the same machine - dual P3-866 with 512MB RAM, hardware
raid card with 32MB non-volatile cache, and 6 x 18GB IBM drives.
RAID0 is certainly faster than anything else, but RAID1 or RAID0+1 is
slow. think about how it works - raid0 is striping which is fast. raid1
is mirroring which is slow, every write has to be mirrored to the mirror
drive...so by striping several raid1 arrays together you end up with
striped access to slow devices.
still, a solid-state-disk would make this a moot point.
> - use ext2; Xfs and Jfs are not yet ready for prime time, and
> everything else is slower than ext2 for mail handling;
ext2 would be one of the worst choices for a mail server's filesystem.
xfs is reliable and ready for prime-time in my experience. i'm using it
on several low volume mail servers, as well as several web and postgres
servers. i also use it on my amanda backup server (to get around the 2GB
file size limit in ext2).
it's not as fast as reiserfs for mail loads, but it's a LOT faster than
ext2.
reiserfs also works reliably, and i've been using it on production mail
servers for over a year. reiserfs is also much faster than anything else
for the kind of disk i/o you see on a postfix server - lots of little
files being created, renamed, and deleted.
dunno about jfs or ext3. haven't used either of them yet. no need to, so
far.
> - install a caching DNS on the SAME machine as the mail server, a nearby
> one is not good enough; use djbdns for that instead of bind; turn off
> logging for lookups, and give it plenty of memory to keep the cache;
yep. caching dns is good. don't think i'd use djbdns though.
> - if you trust your UPS, turn off sync writes to the queue
> ("chattr -R -S /var/spool/postfix")
only necessary if you run ext2 for your queue directory - which is a bad
idea if performance is important to you.
craig
-- craig sanders <castaz.net.au>
Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch - To unsubscribe, send mail to majordomo
postfix.org with content (not subject): unsubscribe postfix-users
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]