Hey all,

This morning I was tinkering with my VMs, and I noticed that when running four of them at once, things lagged a little.

After pulling up the System Monitor, I saw my RAM and CPU usage were well below the specs on this new machine I pigged out on last semester. Then I turned to my HDD activity light, and saw it on almost constantly.

This begs the question - have any virtualization utilities, when there is a computer or server with gluttonous amounts of RAM, come up with some sort of read/write performance optimization where the VM HDD is copied to the RAM to speed up operations, then copied back when it's done?

Tis all

EDIT: Scroll below for quick test of this

I'm not at all sure that would be any better than just giving copious amounts of RAM to each VM, given how efficient Linux is with using excess RAM for disk cache. I do know that miraculous things happened with the performance of my VMs when I put their virtual disks on an SSD.

I decided to make a quick 40 minute experiment from this. With a Dell Inspiron 3650, with 16 GB RAM, a Skylake i7, and a 7200 rpm 2 TB HDD, I did a trial to compare the install, boot, and arbitrary command execution time for a VirtualBox VM of openSUSE 42.2 64-bit with the Server/Text mode.

The host operating system was an up-to-date openSUSE 42.2 under Plasma 5, with Firefox playing Pandora and various StackOverFlowish tabs open. My non-cache RAM usage (that still included the RAM disk) did not exceed 9.5 GB, and my swap usage did not exceed about 100 MB.

The RAM disk: A 8.2 G tmpfs RAM disk was used.

Setting Up the VM

- I made a 3.5 GB Dynamically Allocated VDI virtual hard disk for both the experimental (RAM Disk) VM and the control (HDD VM)
- For the RAM disk VM, the install DVD of openSUSE was copied over and used. The openSUSE DVD for the control VM was on my HDD
- Both installations were done in text mode, and the whole 3.5 GB virtual HDD was given to a ext4 root partition for both VMs. A few files were downloaded in the installation, although with my internet connection and the size of the files, the download times are a negligible part of the install times.

Installation

- The time from Accepting the Overview screen of the YaST Installation to when a reboot was prompted was measured. It was:
Control Experiment
4:06 2:24
Fairly dramatic timing gain

2nd Boot

- The timing of the second boot of each VM was from hitting VirtualBox's Start button to text console login screen with the 8 second default GRUB Timeout deducted:
Control Experiment
0:15 0:11
Modest but noticeable gain

Updating the System

- The time to download 175 package updates with "zypper up", measured from typing Yes to accept zypper's proposed changes to the return to the command line, including download times (which should be reasonably consistent between each VM):

Control Experiment
4:37 3:40
- Noticeable gain, but not overly dramatic

Running "dd if=/dev/zero of=test.umg bs=1024 count=0 seek=$[1024*400]":

- This command's self reported time to write 400 MB was taken:

Control Experiment
0.003951s 0.001165s

Big performance gain, as expected in this area

Conclusion

At least from a back of the envelope experiment without many trials or other host machine processes that could affect performance being carefully monitored, copying a VM to a RAM Disk does reveal some big performance benefits for tasks that are heavy in reading/writing. Copying the DVD file into the RAM Disk was almost instantaneous, and copying the produced 2.2 GB VM took back to my HDD took about 14 seconds, which does not offset the performance gains made during the installation or update, or that after a few boots.

It could be a decent optimization in some cases.

Presuming most of the guest I/O is user files, you might be able to mirror it to that tmpfs and bias the reads to the in-memory copy (set the disk as write-mostly). Remove the in-memory copy on the way down, rebuild on boot.

Another thing that you could do to speed up a HDD bound system is to add a second HDD. Then load balance across the two drives.

-------------------------------------
Steve Stites

Both seem like they could be decent optimizations.

Adding those to things like VMWare, VBox, KVM, or whatnot sounds like it could lend a competitive edge for them in some scenarios, although it sounds like some of it could be configured manually by the end-user.

If I were to make a test then I'd wouldn't use the growing virtual drive. I'd commit it to size fully before launch.

How would that factor into a performance test?

Because I answered on wrong thread I guess. opps

1 members found this post helpful.