Interesting - Pauls Reply was blocked by Barracuda-Spamfirewall
Seems this was only a temporary problem
Zeit: 2012-01-27 10:05:06
Aktion: Geblockt
Begründung: Barracuda Reputation (213.214.111.4)
Absender-IP-Adresse: dbmail01.icns.fastxs.net[213.214.111.4]> For a really large database I would not do any storage transition > initially. New messages will be stored in the new schema, old messages > are still available good to know that transition should be painless database is around 10 GB, i guess not too large i would shutdwon the mailservices before transition late at night running on a fat VM with > 10 GB RAM on a VM (HP ProLiant, ESxi 4.1) backed by a HP MSA SAN should do the job quite fast > This will break IMAP body searches (who uses those??) hmm - i do :-) > As to the connection-pooling: ymmv. PostgreSQL has a different > sweetspot than MySQL. It depends on the concurrency levels you > experience 2.2 has currently around 250 mysql-connections a smaller count would free per-connection-buffers for innodb_buffer-pool what i am missing are the parameters for connection pooling the "dbmail.conf" from the last RC-sources looks like the dbmail 2.2.x AFAIR pooling is only for imap currently and nor for POP3 or am i missing something here? Thanks and best wishes from vienna Harry Am 29.01.2012 22:17, schrieb Thomas Raschbacher: > > > ----------------original message----------------- > From: "Paul J Stevens" > To: "DBMail mailinglist" [email protected] > Date: Fri, 27 Jan 2012 10:04:59 +0100 > ------------------------------------------------- > > >> On 01/27/2012 03:28 AM, Reindl Harald wrote: >>> sounds good and happily you are still alive! >>> >>> is there any documentation how transition to "single instance >>> storage" works on existing hughe databases and recommended >>> configurations for connection-pooling >> >> For a really large database I would not do any storage transition >> initially. New messages will be stored in the new schema, old messages >> are still available. This will break IMAP body searches (who uses >> those??), but everything else works just fine. >> >> When you feel like everything is working as it should, you may start >> migrating old content in batches at times when fewer clients are >> connected. >> >> dbmail-util is used for that >> >> -M:: >> migrate legacy 2.2.x messageblks to mimeparts table. >> >> -m limit:: >> limit number of physmessages migrated. Default 10000 per run. >> >> As to the connection-pooling: ymmv. PostgreSQL has a different >> sweetspot than MySQL. It depends on the concurrency levels you >> experience. Start low, say at 5 concurrent database connections, and >> increase only if really necessary. >> >> If you use a load-balancing solution using multiple dbmail heads, keep >> the pool small and keep an eye on 'mysqladmin processlist'. >> >> Remember: dbmail can easily handle dozens of concurrently connected >> mail clients - hundreds if you have fast hardware - and still pipeline >> all queries through just a few database connectors. Having just a few >> database connectors running can actually give you better performance >> under some circumstances since lock contention in the database will be >> very low. > > > nice and easy migration it seems :) I like it. > > Is there a feature list / comparision to 2.x somewhoere? > > Keep up the good work! > > Regards, > Thomas R -- a happy dbmail user ;) > P.S.: @paul: are you still working together with egroupware folks to improve > egw email client+dbmail? -- Mit besten Grüßen, Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / software-development / cms-solutions p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
