All these extra log details - stored in the database - is this going to
grow out of control? Would this table be periodically flushed so that it
wouldn't end up being bigger than is manageable.
As it is our mail server is logging 30-40 lines per second during peak
usage. I don't mind this going to a logfile but inserting this into the
database is going to make performance suffer unless I put the table on a
different disk. It makes no sense to me that for a simple read on the
database - e.g. check for mail - needs to correspond with a write to the
database for no reason except for statistics that I might read on the
rare occasion.
At least if the code is written for this please make a switch in the
database so that we can turn it off.
Sorry for the pessimistic view, just I want to have our servers at peak
performance.
Josh.
On Thu, 2007-09-06 at 09:59 +0200, Michael Monnerie wrote:
I'd also like a field messages_transferred, mostly for pop, but also
possible for imap I guess.
For IMAP it might be nice to know both messages retrieved (or I guess
message parts, as you don't have to retrieve the whole thing, do you?)
and messages APPENDed separately. Probably even byte counters for
up/down would be useful there.
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail