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

Reply via email to