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

Re: performance of postfix

Expand Messages
  • Viktor Dukhovni
    ... When the scanner throughput is too low, the delay shows up in the active queue of the pre-scan Postfix instance, not in the scanner time to scan a message
    Message 1 of 9 , May 22, 2013
    • 0 Attachment
      On Wed, May 22, 2013 at 03:00:44PM -0500, Stan Hoeppner wrote:

      > > You'll probably find occasional
      > > latency sending messages through the content filter. If that's a
      > > problem, tune the content filter to remove DNS lookups or raise
      > > its concurrency. If the content filter is using all available CPU
      > > resources, tune it to do less, or find a more efficient one.
      > >
      > > Before any of that, locate the log entries showing delayed deliveries,
      > > read them, and figure out the reasons for the delay.
      >
      > I'm using spamc/spamd via pipe so it doesn't add to delays in postfix/local log stamps. To see the spamd delays I use:
      >
      > ~$ grep scantime /var/log/mail.log|mawk '{ print($12) }'|cut -f1 -d,

      When the scanner throughput is too low, the delay shows up in the
      active queue of the pre-scan Postfix instance, not in the scanner
      time to scan a message logs. Messages sitting in active wating to
      be scheduled for scanning are not seen by the non-telepathic scanner.

      --
      Viktor.
    • Stan Hoeppner
      ... The only point I was making is that some of the logwatch summary values may not be accurate, providing him a heads up as he had apparently never used
      Message 2 of 9 , May 22, 2013
      • 0 Attachment
        On 5/22/2013 4:04 PM, Viktor Dukhovni wrote:
        > On Wed, May 22, 2013 at 03:00:44PM -0500, Stan Hoeppner wrote:
        >
        >>> You'll probably find occasional
        >>> latency sending messages through the content filter. If that's a
        >>> problem, tune the content filter to remove DNS lookups or raise
        >>> its concurrency. If the content filter is using all available CPU
        >>> resources, tune it to do less, or find a more efficient one.
        >>>
        >>> Before any of that, locate the log entries showing delayed deliveries,
        >>> read them, and figure out the reasons for the delay.
        >>
        >> I'm using spamc/spamd via pipe so it doesn't add to delays in postfix/local log stamps. To see the spamd delays I use:
        >>
        >> ~$ grep scantime /var/log/mail.log|mawk '{ print($12) }'|cut -f1 -d,
        >
        > When the scanner throughput is too low, the delay shows up in the
        > active queue of the pre-scan Postfix instance, not in the scanner
        > time to scan a message logs. Messages sitting in active wating to
        > be scheduled for scanning are not seen by the non-telepathic scanner.

        The only point I was making is that some of the logwatch summary values
        may not be accurate, providing him a heads up as he had apparently never
        used logwatch prior to installing it and posting his summary table. I
        was not attempting to troubleshoot his larger issue in this post.

        --
        Stan
      Your message has been successfully submitted and would be delivered to recipients shortly.