If you get only %20 to %30 speed improvement then you haven't done
it correctly.

Something is still hammering the disk. I suspect your mail submission
software.

Have you measured the performance with the smtp-source and smtp-sink
utilities?

/etc/postfix/main.cf:
    relayhost = localhost:9999

./smtp-sink -c :9999 100

./smsp-source -c -m 1000 -s 10 -d -l 2048 -t foosome.where localhost:25

        Wietse

Les Howard:
> I've experiemted with William's fastfs trick. It did give a performance
> boost, but only about %20 to %30 faster. Nowhere near the %500 to %1000
> it boasted possible. I have my dual-postfix setup w/ fallback_relay
> configured with the main postfix on a tmpfs and the fallback postfix on
> disk. I'll let you know how this configuration fares after I run my
> test next week.
>
> Les
>
> Les Howard wrote:
>
> > Thanks everyone for the insightful and helpful advice.
> >
> > I'm gonna try both Wietse's suggestion of running 2 postfixes w/ the
> > fallback_relay trick and William's fastfs trick. I'll see what kind of
> > results I get out of these approaches and report back to the list.
> >
> > For the purpose this mailserver is going to be used for I can tolerate
> > a loss-of-messages if there was a reboot or some other failure. This
> > is going to be used purely for generating/delivering customized
> > messages to members of our website on a periodic basis. If a big
> > heaping pile of messages were to go missing every once in a while
> > noone would notice or likely even care. The messages are generally
> > something like:
> >
> > Dear <insert username here>,
> > Thank you for subscribing to our beautifully wonderful
> > site. Here's a lits of things that we think you might be
> > interested in based on information you've provided us. If
> > you follow any of these links your life will undoubtedly
> > change for the better.
> >
> > Plus if I can demonstrate to management that I can get the performance
> > they need I may be able to talk them into some real fast disk
> > solution.
> >
> > Les
> >
> > Wietse Venema wrote:
> >
> >> The incoming+active+deferred directories must be on the same file
> >> system. The other directories can be elsewhere.
> >>
> >> By design, once a file is written to stable storage, it stays there
> >> until it is delivered. It is not copied. It is not even appended
> >> to. This is a basic principle on which Postfix is built. Violating
> >> them would break the system forever.
> >>
> >> What you can do is to run two Postfix instances, one on fast storage
> >>
> >> and one on slow storage. The slower Postfix is configured as
> >> fallback_relay so that it gets most of the deferred mail. The two
> >> Postfix instances can even run on the same machine.
> >>
> >> This fallback_relay trick works, except for deliveries that fail
> >> in the middle of an SMTP session. I have to rewire some smtp client
> >> logic to make it send all deferred mail to the fallback_relay.
> >>
> >> However, running off tmpfs means that you will irrevocably lose
> >> mail when the machine halts/reboots. Postfix is designed not to
> >> lose mail for trivial things like that.
> >>
> >> Wietse
> >>
> >> Les Howard:
> >> >
> >> > I'm trying to get some more performance out of a Sun box (e450, 4
> >> CPUs)
> >> > I'm tweaking up as a postfix based mail generator. I've done some
> >>
> >> > testing and disk IO is clearly a huge bottleneck (much as I
> >> expected and
> >> > people here had warned me). I wish I had some sort of striped
> >> RAID or
> >> > other really high performance disk, but for now I'm stuck with
> >> what I've
> >> > got (2 drives, one for all the system stuff and the other for
> >> postfix,
> >> > configured as /var/spool/postfix right now). Fortunately I do
> >> have
> >> > plenty of available RAM (1 GB). So I figured I'd try to put the
> >> active
> >> > and incoming spool directories on a tmpfs (in-memory filesystem),
> >> but
> >> > leave deferred and the rest of /var/spool/postfix on-disk (since
> >> > deferred won't need to be accessed as much; and may tend to grow
> >> much
> >> > larger than the other two). But when I made incoming and active
> >> each
> >> > separate tmpfs partitions qmgr started giving me "rename from
> >> incoming
> >> > to active: cross-device link" errors and wasn't happy at all. I'm
> >>
> >> > running Solaris and did something like this to configure my tmpfs
> >> > partitions (/var/spool/postfix is already its own filesystem on a
> >> > separate disk):
> >> > mount -f tmpfs -o size=128m swap
> >> /var/spool/postfix/incoming
> >> > mount -f tmpfs -o size=64m swap /var/spool/postfix/active
> >> >
> >> > My question is: which spool directories can be put on separate
> >> > partitions/devices and which can't; when (if ever) is it a good
> >> idea to
> >> > do so (I know you can't hard link/unlink across filesystems; so I
> >> figure
> >> > my change would make moving in/out of deferred slower, but would
> >> really
> >> > speed up incoming to active movement, since that would be all
> >> > in-memory). Does my idea above seem valid (active and incoming in
> >> a
> >> > ramdisk, all others on a real disk)? Would I be better off
> >> mounting all
> >> > of /var/spool/postfix as a tmpfs and then mounting
> >> > /var/spool/postfix/deferred (and others) as a physical partition?
> >> Does
> >> > anyone have a recommended scheme for which spool directories to
> >> put in
> >> > RAM and which not to? Or some other recommended method to get
> >> more
> >> > performance out of what I've got.
> >> >
> >> > Thanks,
> >> >
> >> > Les
> >> >
> >> > --
> >> > "Anyone who slaps a 'this page is best viewed with Browser X'
> >> label on a
> >> >
> >> > Web page appears to be yearning for the bad old days, before the
> >> Web,
> >> > when you had very little chance of reading a document written on
> >> another
> >> >
> >> > computer, another word processor, or another network."
> >> >
> >> > -Tim Berners-Lee in Technology Review, July 1996
> >> >
> >> >
> >> >
> >> >
> >> >
> >
> > --
> > "Anyone who slaps a 'this page is best viewed with Browser X' label on
> > a
> > Web page appears to be yearning for the bad old days, before the Web,
> > when you had very little chance of reading a document written on
> > another
> > computer, another word processor, or another network."
> >
> > -Tim Berners-Lee in Technology Review, July 1996
> >
>
> --
> "Anyone who slaps a 'this page is best viewed with Browser X' label on a
>
> Web page appears to be yearning for the bad old days, before the Web,
> when you had very little chance of reading a document written on another
>
> computer, another word processor, or another network."
>
> -Tim Berners-Lee in Technology Review, July 1996
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]