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