XenDesktop 7.6 VDA CPU & Memory Footprint
If you install the Citrix XenDesktop 7.6 Virtual Desktop Agent (VDA) on a small Windows 7 VM, you may be in for a big surprise, and not a good one. This article documents issues I have experienced and how to work around them.
I started with Windows 7 x64 in a Generation 1 VM on Windows 8.1 Client Hyper-V. The machine had 1 vCPU, Dynamic Memory enabled, startup RAM, and minimum RAM were both at 512 MB. I had used this configuration for quite some time without any problems. Method of access: RDP (using Royal TS).
Then I installed the VDA from the XenDesktop 7.6 ISO in Remote PC mode, not choosing HDX 3D Pro.
Gray Screen After Logon
When I tried to log on after the mandatory reboot all I got was a gray screen surrounded by black:
The session was not dead at all, it showed as active in Citrix Studio and I could log the user off from there. But the desktop never appeared.
I noticed high CPU usage of ctxgfx.exe. If I am not mistaken that is the process responsible for H.264-encoding the display graphics. Apparently that task is a bit much for a single vCPU. To get the VDA to play nicely two policy settings are required:
- Desktop Composition Redirection: disabled
- Legacy Graphics Mode: Enabled
Black Border Around Desktop
With those two policy settings in place things were much better: I was able to actually see the desktop and interact with it:
However, the black border remained.
As it turned out this issue is documented in CTX200073. The root cause of the black border is that the Citrix WDDM display driver tries to allocate 128 MB of memory during system startup. If that fails, you get the black border.
In my case, the proposed solution from the Citrix KB article does not apply. There is simply not enough RAM available during boot. Increasing the Startup RAM of the VM from 512 MB to 1024 MB fixed the problem.
Citrix VDA Memory Usage
I took this as an opportunity to take a closer look at the VDA’s memory usage. Our uberAgent monitoring product has a useful dashboard for this task. It displays all the running applications along with their CPU/memory/disk/network footprint. Take a look at this screenshot where the red arrows highlight applications that are part of the XenDesktop 7.6 Virtual Desktop Agent:
The total RAM footprint of the VDA is a whopping 374 MB (a few minutes after boot). That is huge! And this does not even include drivers running in kernel space!
I remember talking with Citrix’s Juliano Maldaner at BriForum Amsterdam 2007 about the planned new architecture (then only a concept, now called FMA). One of the goals was to separate workers and controllers and not install the full product on the workers but only a light-weight agent. Well, that may not have worked out, after all. Installing XenApp 6.5 probably increases the memory footprint less than installing the XenApp/XenDesktop 7.6 VDA.
Counting the Citrix Receiver + SSON module, Online Plugin, Profile Manager and the Self Service plugin towards the VDA footprint is not quite correct imho. They are completely separate components, and not always needed or installed.
Those combined shaves off 76 MB.
Agreed, still 298 MB left, so your point that it’s not a “lightweight” agent stands.
thanks for your article. I would like to add points which should be put into consideration :
a) a VDA is not a client. In fact, it is a service which delivers all the HDX capabilities to the desktop which are needed to give the user a remote, PC-like user experience.
b) in you conclusion you referred your discussion with Juliano. This was back in 2007, and since then the development in IT in general has evolved.
RAM became cheap, often Bandwidth became cheaper, applications changed with regards to their multimedia content, new devices and device standards came to the market.
That said, to deliver the best user experience more code had to embeded into the VDA. The term “lightweight” of 2007 does not match with the term “lightweight” in 2014. You as a real good experienced programmer knows that probably much more than I do.
Hello Marc, I suspect the extra amount of RAM is tributed to using the .NET framework in all modules, not to added much more lines of code compared to the former XA 6.5 IMA architecture.
I wonder why Citrix relies so much on the resource hungry .NET framework.
BTW, RAM may have become cheaper, but user density is key in cloud deployments. Bandwidth hasn’t become cheaper compared to extra requirement in XD7.x now.
So,what are the consequences if VDA doesn’t find the 298 MD of RAM to allocate.