05.11.09, 17:58, "Kenneth Marshall" <k...@rice.edu>:
> On Fri, Nov 06, 2009 at 02:19:34AM +0300, devel anaconda wrote:
> > Hello everybody!
> >
> > I have a high-performance server (dual quad-core Xeon 2.8Ghz + 16GB RAM +
> > 2SCSI disks 140Gb), RedHat Enterprise Linux 5.4, software RAID1 + Postfix
> > 2.5.9.
> > This server serves only smtp traffic. The only thing postfix should do -
> > receive mails for one user and send it to local script via pipe. Like this:
> >
> > user: |/usr/local/bin/script
> >
> > The flow is about 250-300 mails per second.Everything is going fine, if
> > there is no queue. But when queue grows to 10000+ letters (for some
> > reasons), postfix loses control of it. deferred queue is null, active queue
> > is almost null, but incoming queue is growing and growing. When incoming
> > queue is about 100k+ letters, postfix just can't pick it up, until I stop
> > incoming traffic. I'm wondering, why such a server can't handle this
> > workload? Even if I do the following:
> >
> > user: /dev/null
> >
> Your system is not a high-performance server I/O-wise. Your two disks can only
> handle 200-300 fsync's to disk per second and postfix will always sync your
> mail to disk before passing it on for local processing. You will need a
> battery backed caching RAID controller or fast SSD drive for the
> /var/spool/postfix directories to allow you to go faster. You could maybe
> move the spool directory to a RAM or tmpfs file system as well. You lose
> the safety net for messages if you have a power or other hardware problem.
Firs of, thank you Kenneth, Wietse, Victor and Corey for quick answer.
So I must confess, all looks like the bottle neck for now is a IO performance
of my system. Unfortunately, I cannot move all the postfix's spool to tmpfs or
/dev/shmem because of large size of queue (sometimes about a 80-100Gb), and I
cannot move only incoming queue to RAM, because of postfix's specific file
moves (I need to patch postfix, so it can move messages in
split-partitions-queue). Please, correct me, if I'm wrong, but if the current
bottle neck is limited fsync, so I can do the following (at my own risk):
--- postfix-2.5.9/src/global/mail_stream.c.orig 2009-11-05 23:27:23.000000000
+0300
+++ postfix-2.5.9/src/global/mail_stream.c 2009-11-05 23:27:34.000000000
+0300
@@ -292,9 +292,9 @@
|| (want_stamp && stamp_path(VSTREAM_PATH(info->stream), want_stamp))
#endif
|| fchmod(vstream_fileno(info->stream), 0700 | info->mode)
-#ifdef HAS_FSYNC
+/* #ifdef HAS_FSYNC
|| fsync(vstream_fileno(info->stream))
-#endif
+#endif */
|| (check_incoming_fs_clock
&& fstat(vstream_fileno(info->stream), &st) < 0)
)
?
It disables fsync() on each incoming mail. Plus, if I mount my ext3 partition
with option commit=30 or even commit=100, can it helps a bit?
> It probably never needed more than 5-8 local processes to sink only 200-300
> messages per second. That is why you do not see more. Add a "sleep 1" to
> your script and see what happens then. :)
Yes, it did the trick :)
