On 10/31/2011 09:34 PM, Simon wrote:
Hi There,
This may be slightly OT… but I'm wondering if someone would be able to
give me a few pointers new dbmail mysql VM please?
Currently it has 2 VCPUs (Xeon E5645 @ 2.4GHz) and 1GB RAM (note: this
is only in testing, no mail flow to it or no client connections, and we
are using imapsync to populate it). It has apron 1000 mailboxes using
80GBs worth of DBMail database and is running well during this testing
mode. We are about to put this into production and we will increase the
RAM to 10GB…
I have two questions:
1). Is it worth adding more VCPUs?
Considering how easy it is to add more VCPUs later, why not wait and see
how it copes?
2). Would any body be able to assist with mysql config to best utilise
the resources of the new VM?
Current my.conf is http://www.nzlocal.com/simon/dbmail_my_conf.txt
A few obvious things jump out as quite badly wrong in there. Do you plan
to have any MyISAM tables in there apart from the mysql system database?
If not, you don't need to up the key_buffer from the default 8M.
There is not much point in limiting max_binlog_size to 100M. Depending
on what your load is, this will result in many, many binlog files.
For 80GB of DBMail you probably want nearer 16-20GB of RAM.
innodb_buffer_pool_size should be big enough to contain all the index
data. You will have to guesstimate how big this is, I'm sure somebody
here can provide a reasonable ball park for the DBMail database in terms
of what fraction of the data is indexes. Either way, 128M is way, way
too small. If you up the memory in the VM to 20GB you probably want to
set innodb_buffer_pool to about 16GB.
innodb_log_file_size also looks on the small side, but it depends on how
much is written to the database during your daily peak hour. There is
nothing to lose from increasing this several-fold, except MySQL will
take a little longer to start.
Also beware of O_DIRECT. This is the preferred setting on bare metal,
but in VMs and especially on SANs this can cause a serious slow-down. Do
some testing.
Virtualization will degrade MySQL performance by 40%+ on CPU and memory
I/O bound tasks (if you have sized your memory appropriately and tuned
your MySQL accordingly, you should be CPU and memory I/O bound). It will
likely be even worse if you start to get disk I/O bound. If such a
performance hit is an issue for you, run on bare metal.
HTH
Gordan
_______________________________________________
DBmail mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
