On 04/11/2012 03:00 PM, Reindl Harald wrote: > > > Am 11.04.2012 10:51, schrieb Paul J Stevens: >> On 04/11/2012 10:42 AM, Paul J Stevens wrote: >> >>> Please file a bug, if you will. >> >> No need. Fixed already. > > does this also fix the (reintroduced) problem to stop > if a client tries to store a > 500 MB message in the > dafts folder? > > i tried this yet and dbmail-imapd starts to consume hughe > memory and CPU and is no longer responsible for any > client
After testing with 100MB size message appends I came up with: http://git.dbmail.eu/paul/dbmail/commit/?id=4b095dbcb956aa3538b21912ba34b0db088e4967 which will improve the situation, but *not* fix it completely. The OOM situation is caused by excessive copying: - from the network to a receive buffer - from the receive buffer to the token buffer - from the token buffer to the append command's argument list and that's just from the imap network handler. After this the string in the argument list is converted into a DbmailMessage object, which leads to even more copying. Above patch will improve the CPU load significantly, but not the copying... Maybe we should set a configurable limit on APPEND message sizes. No use allowing 1GB messages on APPEND if your MTA doesn't allow messages larger than 100MB for example. -- ________________________________________________________________ Paul J Stevens pjstevns @ gmail, twitter, skype, linkedin * Premium Hosting Services and Web Application Consultancy * www.nfg.nl/i...@nfg.nl/+31.85.877.99.97 ________________________________________________________________ _______________________________________________ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
