Home / Nerdio Academy / Windows Virtual Desktop / How to Troubleshoot Performance in Windows Virtual Desktop (WVD) Environments – Part 3 of 5 (RAM)

How to Troubleshoot Performance in Windows Virtual Desktop (WVD) Environments – Part 3 of 5 (RAM)

Vadim Vladimirskiy
Vadim VladimirskiyFounder & CEO, Nerdio
0 commentsFebruary 04, 2020Articles

For Part 1 of Troubleshooting Performance in WVD Environments, click here.

For Part 2 of Troubleshooting Performance in WVD Environments (CPU), click here.


On Windows Virtual Desktop (WVD) session hosts, RAM is primarily consumed by applications that run within users’ sessions.  Modern applications use a lot of RAM.  Each Google Chrome tab, open Word document, Outlook, Teams, and other apps can consume tens or even hundreds of MBs of RAM.  With multiple users sharing a session host VM, this usage can add up quickly and consume all available RAM.

High memory usage in it of itself is not an issue.  An application loading its bits into RAM will run faster than having to fetch data from a much slower disk.  However, when too many applications load too much of their data into RAM, then hard faults (previously known as page faults) start to slow down the VM.

A hard fault happens when a memory page that an application expects to find in RAM is unavailable and the page has been moved to the pagefile on disk.  This causes the operating system to go to disk to retrieve this data, which takes orders of magnitude more time than fetching it from RAM.  Consistently high page faults are an indication that the system is starved for available RAM.  Simply high RAM usage (used RAM as % of total available) is not a problem on its own but it is usually an indication that hard page faults are likely.

Diagnosing RAM-related performance issues can be done using Windows Resource Monitor.  This tool can be launched from the performance tab of Task Manager or by running “resmon” from the Run dialog box.  Looking at memory usage in the Task Manager will tell you the amount of RAM used but won’t tell you anything about hard faults.

In the Resource Monitor>Memory tab you want to focus on the Hard Faults/sec counter first.  If you’re seeing little or no activity there the system is likely not RAM constrained at the moment.  Bursts or constant hard fault activity is an indication of a performance issue.



If there are hard faults, then sort the running processes by the “Hard faults/sec” column and look for the ones contributing most to the performance issue.

RAM-related performance issues can result from too many users and applications, a single process hogging an unreasonable amount of RAM, or a faulty application that doesn’t release the RAM even when it’s not using it.


How RAM contention manifests itself to the end-user

  • “Not responding” applications
  • Slow log on and log off
  • Slow launching of new applications
  • Slow switching between windows
  • Already-running applications slow, jittery. Idle applications slow to resume.
  • Unexpected app crashes
  • Windows errors for low virtual memory

What to do about RAM-related performance issues?

  • If high memory usage is the result of normal user and application load on the VM then the only thing to do is upgrade the VM size to one with more RAM or spread users out over more session host VMs. The most cost effective first step is to upgrade from a general purpose VM size (e.g. Dsv3) to a memory optimized VM size (e.g. Esv3).  The memory optimized instances double the amount of available RAM while keeping the number of CPU cores constant and only increase the VM price by approximately 15%.
  • If high memory usage is the result of a faulty process or application, close that process or sign out the user. It is a good idea to educate users to log off their desktop session at the end of the day or put in place automation policies that will automatically log users off after a certain period of inactivity.
  • Applications that cause memory leaks can pose a challenge when session hosts stay on for long periods of time. Scheduling VMs to restart on a regular basis (e.g. nightly) or using autoscaling can prevent such problems by clearing the memory on a regular basis.


Stay tuned for Part 4 of our series on Troubleshooting Performance in WVD Environments: Disk, coming in a couple of weeks.


Have you signed up for our weekly newsletter? Subscribe now so you won't miss any new content.

Sign up now