On Wed, 2006-10-25 at 10:32 -0700, kbaker wrote: > I have read around that the general rule is to calculate how much ram would > be > used for one connection... multiply that by max connections and that should > be
IMAP connections may spend significant amount of time idling if you have desktop clients, so it's reasonable to have a large number of DBMail processes swapped out. If you have only web IMAP clients, then you'll have little or no idle time and swapping will be your enemy. So for desktop clients, I'd say... max connections can be 3-4 times real memory. For web clients, keep max connections 1:1 with real memory. Better that one client waits on an available process than everybody wait for swapping. These are my gut-feeling numbers. You will have to benchmark it in your environment! > less than how much ram you have on the machine... leaving some room for the > OS. > This will give MySQL the room it needs for query and user caches w/o having > to > page to the file system helping with speed and then overall connection > management. I believe that MySQL uses mlock to prevent its caches from paging. The numbers you give will be allocated all at once by its slab allocator and will be unavailable to other processes. > Any thoughts? > > This is a great start. This should definitely get you rolling. We need more real world test results with large installations, on the DBMail 2.2 code base. As you get your system set up, please take a look at Mozilla's mstone benchmark took: http://www.mozilla.org/projects/mstone/ I haven't had time to play with it much, but if you're looking to justify the business case for DBMail to a boss or to clients, hard numbers talk :-) For comparison, let's see how we stack up to these: http://www.isode.com/whitepapers/mbox-benchmark.html Aaron
