There is almost no VM overhead these days. mySQL is disk I/O bound, not CPU bound.
With VMWare you can setup your partitions to be raw disks (not virtual disk files) so you get native I/O. If you were to get some SSD's, I bet you would even see some significant performance increase too even over a true native system. Also consider sharding your tables to put some on raw/ssd/vmdk depending on how they're used. VMWare has options that are nearly bare-metal. There are other free options like KVM that are built right into the kernel. I personally use VirtualBox here at work for development, but I use VMWare Workstation at home. At previous jobs, we used VMWare Server (free) for all the UAT from the test servers themselves to the test guest OS (XP, Win7, OSX, Linux, browser variants, etc.) Virtual Machines are the ONLY way to go these days IMHO. It's silly to try and setup mySQL on different ports and go through all that hassle and configuration. With VM's you can just clone one to setup a new instance, you have fail-over, backups, they're easy to move to new hardware, they have console GUIs, intelligent shuffling of resources, maximizing hardware, minimizing costs (electric, carbon, space, etc). There are so many benefits and almost no detriments to a VM these days with computers as powerful as they are. Even updating the VMs (patching) is fairly straight forward with the major Linux distros (many even have web GUI front ends to push patches to all VMs, not to mention automated unattended updates if you desire) Just do it. DO IT! You won't ever look back, and like Reindl said, you'll wonder how you got this far without VMs. :-) -Daevid. There are only 11 types of people in this world. Those that think binary jokes are funny, those that don't, and those that don't know binary. > -----Original Message----- > From: Claudio Nanni [mailto:claudio.na...@gmail.com] > Sent: Thursday, March 03, 2011 2:14 PM > To: Reindl Harald > Cc: mysql@lists.mysql.com > Subject: Re: best practice: mysql_multi, VMs w/single > instance per or doesn't matter? > > Just know that there is not-a-problem in running multiple > instances on the same host, > then all you have to do is to evaluate the performance factor. > In your case I would not introduce the overhead of the VMs, > but take advantage of this to learn how to manage multiple > instances on the > same host that is always useful. > > You can have a look at Giuseppe Maxia's MySQL > Sandbox<http://mysqlsandbox.net/> > > Or if you wish I can share my technique I use since 3.23. > > Cheers > > Claudio > > > > 2011/3/3 Reindl Harald <h.rei...@thelounge.net> > > > i would use virtual machines because port/socket/configuration > > > > after running our whole infrastructure on vmware i can not > understand > > how i could live without machine-snapshots and auto-failover :-) > > > > on hardware with virtualization support performance is also > > not a problem and ESXi is free without support on hardware > > matching the HCL > > > > Am 03.03.2011 22:52, schrieb Sid Lane: > > > I've always had a single physical server that is the qc > mysql database > > for > > > all our applications but it's now up to 85 schemas so I > want to break it > > up > > > along the same lines as production (where there's > redundant pools of > > mysql > > > servers by application class). > > > > > > my basic question is whether it's better to run multiple > instances on the > > > same host or run single instances on multiple VMs on the > same physical > > > server. I can see slight advantages/disadvantages to > each but no obvious > > > upside nor downside to either. > > > > > > remember, this is dev/qc, not prod, so I'm leaning toward > VMs so I don't > > > have to manage port #s in configs or expect developers to > remember that > > > (also, I don't have to modify scripts for multiple > instances, paths, > > etc). > > > not big reasons for sure but all else equal I'll go the > less work route > > and > > > the only upside to multi I see is not having to reload > the box as VM > > host. > > > > > > any compelling argument for either approach? > > > > > > > -- > Claudio > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
