). We allocate about 3.5gb to each virtual server, with a goal of running approximately 4 servers simultaneously. As you can imagine, we have seen some performance issues based almost exclusively on the database when doing large queries on several of the virtual machines at once.Hypothesis: Moving the virtual disk that contains the database to the SSD should substantially improve performance (at least read performance) because of the elimination of random physical disk i/o and replacement with direct flash memory i/o via the SSD (which can be 10-50x faster than a physical drive).
I have noted that when you have a base "snapshot" of your virtual machine, for each allocated disk drive there is a main file on the host, which appears (as far as I can tell) to be "read-only" and secondary file which appears to be where all the updates to the disk are written. This is what permits us to quickly restore a virtual machine to a previous "snapshot" state by simply dropping the secondary file. We can also merge the two files to create a new base "snapshot" which incorporates all the changes.
We would like to improve performance by moving the virtual disk to an SSD, but we are concerned that excessive I/O (particularly I/O to the database part of the virtual environment) will cause premature wear on the SSD (which has an average write life of approx. 10,000 writes per bit - I recognize that the SSD itself has some balancing firmware to reduce this impact, but I still am concerned that there may be excessive per bit I/O on the disk during high volume transaction loads which we test with quite frequently which could quite possibly result in thousands of i/o's to the same blocks in the database in a little as an hour).
My idea/question/inquiry is that I would like to move the base snapshot file for the virtual disk drive to the SSD (for read purposes), but have most or all writes go to the regular SATA disk. This should dramatically improve read/search time on the database (which will now occur on the SATA) while substantially reducing write i/o impact on the SSD. I will probably do a merge of the current version and snapshot every night onto the SSD, but this means that the SSD will only incur a few write i/o's per bit per day, which will still provide a life expectancy for the drive of several years or more.
As far as I can tell, the two files (base and secondary) for a virtual disk have to be in the same directory on the host Linux system. If this is not true, that would be a GREAT advantage, as I could then position the main and secondary files on different drives (one on the SSD and the other on the SATA).
However, if I must keep them in the same directory, my question is will it work to have the base file located on the SSD, with a symlink from the VBox storage directory pointing to it. I.e., the VBox storage directory will still appear to have both the "read-only" part of the drive as well as the active secondary part, even though the read-only part will actually exist on the SSD instead.
Ultimate question: does anyone know any reason that VBox wouldn't be able to read that main part of the virtual drive via the symlink?
I realize this is not a trivial question and if anyone needs more info, please feel free to ask, either here or direct at jon@likelist.com (my email address).
Thanks!
Jon Rosen