Loading ...
Sorry, an error occurred while loading the content.

234927Re: filling incoming queue

Expand Messages
  • Victor Duchovni
    Feb 29, 2008
    • 0 Attachment
      On Fri, Feb 29, 2008 at 08:32:05PM +0100, Pavel Urban wrote:

      > Victor Duchovni wrote:
      > >On Fri, Feb 29, 2008 at 08:00:54PM +0100, Pavel Urban wrote:
      > >
      > >>[root@relay2new skripty]# tail -1000000 /var/log/maillog |./analyzuj.pl
      > >
      > >It would be better to print the cleanup and qmgr counts for any given
      > >minute on the same line, much easier to understand, but in aggregate,
      > >you have delivered ~93,000 messages and received ~127,000, so the queue
      > >is now 34,000 messages longer than 1,000,000 log entries ago.
      > >
      > >To drain the queue, clearly the output rate needs to exceed the input
      > >rate. Normally, qmgr is able to fill the active queue as fast as mail
      > >comes in and the incoming queue is nearly empty. In your case incoming
      > >queue scans are slower than the arrival rate, but deliveries from the
      > >active queue are fast.
      > >
      > >Is the queue on a very slow disk? Have you tried mounting with "noatime"?
      > >
      > >>[root@relay2new ~]# ls -l /var/spool/postfix/incoming/7/3/7349D7E7B3B
      > >>-rwx------ 1 postfix postfix 2748 Feb 29 19:54
      > >>/var/spool/postfix/incoming/7/3/7349D7E7B3B
      > >>[root@relay2new ~]# date
      > >>Fri Feb 29 19:54:57 CET 2008
      > >
      > >So timestamps don't appear to be the problem.
      > >
      > >>lookups are just hashed tables (.db), no ldap, no mysql.
      > >
      > >Why is the queue manager so I/O starved? Perhaps the disk is totally
      > >saturated by input processing, if so, reduce the input concurrency
      > >until the queue manager catches up. The work-load may be too big for
      > >the hardware. Consider RAID controllers with battery caches, ...
      > >
      >
      > /dev/sdb1 on /var/spool type ext3 (rw,noatime)
      >
      > On the second disk, it is even
      >
      > /dev/sdb1 on /var/spool type ext3 (rw,noatime,data=writeback)
      >
      > . It is HW RAID1, 10 and 15k disks. You are confirming my initial
      > suspision - it is not enough and I cannot do anything else on an
      > application level. I shall try some benchmarking on a backup server and
      > then perhaps SAN with bigger FibreChannel disks and cache.
      >

      SAN could be slower, Postfix probably cares more about latency than
      bandwidth. Is the SAN caching on the controler inside your machine
      or on the controller in the array? (More likely the latter).

      In any case, I get ~200 msgs/sec on Dell 2850 class hardware with Battery
      RAID cache (onboard no SAN) enabled. That's 12,000 per minute, and you
      are topping out at 1/12th of that, so either the NVRAM cache is disabled
      or too small.

      Your volume of deferred mail also seems high. Are you scanning the
      deferred queue too often?

      --
      Viktor.

      Disclaimer: off-list followups get on-list replies or get ignored.
      Please do not ignore the "Reply-To" header.

      To unsubscribe from the postfix-users list, visit
      http://www.postfix.org/lists.html or click the link below:
      <mailto:majordomo@...?body=unsubscribe%20postfix-users>

      If my response solves your problem, the best way to thank me is to not
      send an "it worked, thanks" follow-up. If you must respond, please put
      "It worked, thanks" in the "Subject" so I can delete these quickly.
    • Show all 15 messages in this topic