Why Virtual Desktop Memory Matters

I have seen several Virtual Desktop projects with “bad storage performance”. Sometimes because the storage impact simply was not considered, but in some cases because the project manager decided that his Windows 7 laptop worked ok with 1GB of memory, so the Virtual desktops should have no issue using 1GB as well. Right? Or wrong? I decided to put this to the test.



Test setup

To verify the way a windows 7 linked clone (VMware View 5) would perform on disk, I resurrected some old script I had laying around on vscsiStats. See my older blogposts:

This time round I took a Linked clone, and ran these scripts against its first two disks. The first disk is the base disk (too bad vscsiStats cannot determine between the replica and the linked clone itself!), the second disk is the disposable disk where, yes indeed, the Windows swapfile lives.

These measurements were put up to some testing, like booting the VM, idling the VM and performing regular workload on the VM. In this blogpost I will focus on disk behaviour during steady state workload, but where I used 1,5GB of memory versus 512MB of memory.


Comparing the base disk behaviors

During steady state workload (no, not a synthetic workload, but me actually doing some work on the VM) the base disk behaves not all that different. This is no surprise, since I did similar tasks in both tests, which should trigger similar disk usage. First, we look at the number read blocks versus their block sizes versus time:

Base Disk reads during steady state. VM1 has 1.5GB of memory, VM2 only 512MB.

Interestingly, the 512MB VM actually reads more from its base disk (which is either the replica or the linked clone). This can be explained by the fact that VM2 has only 512MB of memory: Less stuff is cached in memory, which means more has to be read from disk. I think the replica might actually be hit heavier here and not the linked clone (things like loading DLLs) but unfortunately I cannot determine this from the vscsiStats tool. Indication one that giving a virtual desktop less memory increases its disk I/O !

Now look at the write side of things:

Base Disk writes during steady state. VM1 has 1.5GB of memory, VM2 only 512MB.

There is actually hardly any difference on disk writes in this scenario; a lot of 4KB writes are taking place in both cases, and the numbers aren’t that different. This makes sense, since the workload between the two tests was similar.

Now for some more geeky stuff: Seek distances. These are the read distances observed between the 1,5GB and the 512MB VM:

Base Disk read distances during steady state. VM1 has 1.5GB of memory, VM2 only 512MB.

VM1 spiking at the beginning of its test run appears to be an anomaly. Overall it is obvious that the 512MB VM clearly performs more reads, which also are very random (near the edges of the graph).

Looking at the seek distances for writes we find this:

Base Disk write distances during steady state. VM1 has 1.5GB of memory, VM2 only 512MB.

Funny. Even though the number of writes are about the same for both VMs, the 512MB VM appears to show a more random behavior when it comes to writes to the base disk (most writes on the edge of the graph), while the 1.5GB VM has a more evenly spread seek distance for writes to its base disk.


Comparing the disposable disk behaviors

Even more interesting to see should be the disposable disk. As one of the VMs has far less memory assigned, the swap file of this particular VM should be hit much heavier. To confirm this, we first use some vscsiStats and Excel magic to come up with the reads of both VMs:

Disk reads from the Disposable disks for two VMs. VM1 has 1,5GB of memory assigned, VM2 only 512MB.

Cannot be clearer. VM1 actually does not read its disposable disk AT ALL during this steady state load. VM2 though performs massive reading, mostly at small 4KB blocks. Looking at the actual amount of I/Os (and comparing them to the reads performed on the linked clone disk) it actually matches the regular workload. Basically by giving the VM less memory, we managed to DOUBLE the number of reads. Wow.

Now for the writes performed to the disposable disk. Some more magic pops up this graph:

Disk writes to the Disposable disks for two VMs. VM1 has 1,5GB of memory assigned, VM2 only 512MB.

How cool is that? The first VM with 1,5GB of memory does perform some writes to its disposable disk, but these are very few very small chunks (4KB blocks). The VM that has only 512MB of memory on the other hand is writing out loads of data to the disposable disk, at blocks of 1MB!

Since I can’t wait to see the randomness of this I/O behavior, let’s look at the seek distance for reads on the disposable disk:

Disk seek distance for reads from the Disposable disks for two VMs. VM1 has 1,5GB of memory assigned, VM2 only 512MB.

As expected, there is nothing going on with VM1 (since it does not perform any reads). But look at VM2! It is reading heavily, some stuff is sequential, but most of the reads are random (towards the edges of the graph).

Last but not least, we look at the seek distance for writes to the disposable disk:

Disk seek distance for writes to the Disposable disks for two VMs. VM1 has 1,5GB of memory assigned, VM2 only 512MB.

As you can see, the few small writes that were performed by the 1,5GB VM are very random in nature. The writes to disk by the 512MB VM on the other hand are very sequential, with only a few being random.


Conclusion

Looking through all the graphs, there are some interesting things to note:

  1. The 512MB VM performs more reads from the base disk. Funny enough, most of these “extra” reads are 16KB reads;
  2. Both VMs show the same write strategy to the base disk (which makes sense since they perform comparable workloads);
  3. The 512MB VM performs way more disk I/O on its disposable disk as expected;
  4. The 512MB VM reads a lot of small (4KB) random blocks from the disposable disk;
  5. The 512MB VM writes a lot of very large (1MB) sequential blocks to the disposable disk, indicating huge amounts of data being written.

This proves that cutting assigned memory on a virtual desktop can have tremendous effect on the use of the underlying storage. As the storage component is a complex one to scale, I would recommend to never try to save on assigned memory. The costs you might save on server memory has to be reinvested (and you’d probably even need more) on the storage side!

Comments are closed.

Soon to come
Blogroll
Links
Archives