no pressure, sytemd is handling the daily restarts perfectly :-) the interesting fact is that we last week upgraded to Fedora 19 x86_64 in production and dbmail, gmime as well as libzdb are self packed as RPM
dbmail and gmime sourcecode is the same, i brought only libzdb to the latest version and dbmail did only get a update from 3.1.9 to http://git.dbmail.eu/paul/dbmail/commit/?h=dbmail_3_1&id=e5ad1e579562e22fc215b6186696eaba07213cb1 i guess it is unlikely but not impossible that the few dbmail-commits between raised this or libzdb, the rest of the dbmail-specific environment is more or less unchanged fact is that dbmail-imapd is always memory-hungry, but not that much dbmail-3.1.9-4.fc19.20140107.rh.e5ad1e579562e22fc215b6186696eaba07213cb1.x86_64 gmime-2.6.19-1.fc19.20140107.rh.x86_64 libzdb-3.0-2.fc19.20140107.rh.x86_64 however, thanks for feedback and dig in this best wishes from vienna Am 15.01.2014 19:27, schrieb Paul J Stevens: > I haven't seen significant leakage from libzdb in quite some time. But I > haven't tested zdb3 yet. The main suspect > for leakage that is very difficult to trace appears to be gmime. > > I'll try to make time for this next week. > > > Reindl Harald <[email protected]> schreef: > > Hi Paul > > may it be that some of the memory-eating is triggered by libzdb? > all is working fine with 3.0 too (only re-compile needed) but > it looks like once a day the imap-process dies after consume > more than 1 GB memory > > if i am right in that observation the main question is if it is > libzb itself or something how dbmail acts with it and if yes > is the result only more visible with libzb 3.0 > > do you see any chance to have a look in that?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
