Am 24.08.2011 11:47, schrieb Robin Horforth: > On 8/23/2011 9:19 PM, I wrote: >>> is it faster now? >>> the settings below was also important, i tried only to split because i >>> was not sure which version you are using >> >> Oh yes, big improvement! >> >> 18577 msgs (560MB) imported in: >> >> real 107m55.162s >> user 1m57.277s >> sys 0m16.965s > > *GACK*! > > I spoke too soon. I didn't notice that the import task was killed about 56% > of the way through the process. As > you warned me, I'd run out of memory. (The PERL module has an odd memory > leak/bug where its memory usage only > ascends as it processes emails.) > > Given that the process seems to get slower as more emails are APPENDED to a > given mailbox, I'm not sure there is > all that much of an improvement in speed. When the script finishes properly, > I'll provide an update. > > My apologies for jumping the gun and spreading bad data to the list
no problem 3 GB Memory on your VM is a little bit small having in mind that each connection needs memory for imapd/pop3d and per-connection buffers additional to the OS himself, postfix and the innodb-buffer is really important i can not imagine how i would deal with 3 GB because this hurts if there are many open connections or as in your case something allocates memory too limit the maximum of imap-connections is often not possible depending on the number of users - this will be much better in dbmail 3.x by using connection-pooling but with 2.x you have for every imap-connection a imapd-process and a db-connection with all its overheads (don't forget mysql-connections from postfix/sasl) in the 3 years using dbmail now i learned that as much RAM as possible is the only way to get this really fast running
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
