Hi there, I'm spending a lot of time trawling through logs at the moment. Our primary mail server is experiencing high load yet CPU usage is less than 50%, memory less than 75% and disk usage minimal.
I've turned on debugging and set absolutely everything to maximum logging and have noticed some oddities that I could do with some help understanding. They could be normal, or could mean something. After turning session logging to max I get loads of these, I'd say anywhere up to 50 each message: 2014-11-28 11:41:40 m1-xxxxx-xxxxx [Worker_7] 1.1.1.1 <[email protected]> to: [email protected] info: Maillog - no log - log-condition is zero As far as I can tell, it logs one of these for each line of data that is processed as follows: >2014-11-28 11:47:07 [Worker_1] <doing line ###DATA# >2014-11-28 11:47:07 [Worker_1] <Maillog >2014-11-28 11:47:07 [Worker_1] <matchSL - [email protected] - noCollecting 2014-11-28 11:47:07 m1-xxxxx-xxxxx [Worker_7] 1.1.1.1 <[email protected]> to: [email protected] info: Maillog - no log - log-condition is zero So this begs two questions, firstly when there is nothing to be logged, does it need to write a line saying so? Secondly, is there a reason for matchSL running for every single line? My instinct is that the decision on whether to log or not based on sender address should be made once when the header is received and repeating it many times is wasting resources. I also get a constant stream of these: 2014-11-28 11:40:54 [Worker_1] <error >2014-11-28 11:40:54 [Worker_1] <error >2014-11-28 11:40:54 [Worker_1] <error >2014-11-28 11:40:54 [Worker_1] <error >2014-11-28 11:40:54 [Worker_1] <error 2014-11-28 11:40:54 [Worker_1] <error All workers except worker 1 log them once, immediately after a seterror and it seems to follow a greylisting rejection. Worker 1 also logs occassional seterrors that match up with greylisting rejections. The oddity is that it also logs a continual stream of errors that don't seem to match up with anything. I've tried to get some more information out of strace, but it leaves me equally puzzled. I see a lot of EAGAIN (Resource temporarily unavailable), but no information about which resource is unavailable. I also understand that these are logged as normal behaviour when a process listens for connections on a TCP port and there is nothing there. Monitoring file and network activity shows it all pretty low with every call being returned quickly. Still, I see ASSP not responding to connections on the admin interface for minutes at a time. When I turned on debug mode, I turned it on at 11:20:15. It wasn't until 11:27:14 that ASSP wrote the following to the logs: [Main_Thread] Info: starting partial debug mode to file /usr/local/assp/debug/1417174034.dbg Any thoughts or suggestions on this one? Thanks, Colin ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk _______________________________________________ Assp-test mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-test
