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