A user asked for help in finding the source of general slowness in a VMware environment with 4-6 screens, no GPUs, and W10 Kiosks. ControlUp is being used to identify the bottleneck but CPU and RAM are not the source. GPU memory was discussed as a possible bottleneck, and it was suggested to check settings like Display memory limit, CPU metrics, network connectivity and RTT times, plus the fact that the EDT protocol can help. The user later reported that their lobbying for GPUs paid off, and they are getting 12 servers with 2xAmpere A16 GPUs.
Read the entire ‘Troubleshooting General Slowness in a VMware Environment with Multiple Screens’ thread below:
Hello,
Our users having from 4 to 6 screens with persistant MCS VDIs are suffering from general slowness. They were on IGEL TCs but now they are on W10 kiosk pcs.
I use ControlUp to try to find the problem, we gave them more CPUs and RAM, but they still complain and I am afraid that I don’t find the bottleneck.
If CPU and RAM are not the issues, what would you recommend me to do?
I don’t have Remote-DX yet… And nvidia cards are not in the budget for the moment…
Thanks in advance, cheers, JCM
what kind of hypervisor are these one? Make sure there’s enough video memory assigned and that 3d is turned off. 4-6 screens is an awful lot though for running without gpu’s so getting proper performance might be challenging in whatever way.
Also what kind of OS are these machines running?Hello, it’s on VMware, W10, and I have set "Display memory limit" to max…
Also it sounds like you swapped the client and increased the monitor count at the same time. I take it you’ve tested the win10 client with fewer screens? I had to do something very similar before (for Citrix) on a trading floor and I had to configure a custom amount of ram for display (max wasn’t enough) and I also had to dedicate CPU to the VM (increase shares in esx). I remember it did take a lot of trial and error though to get to a point where it was decent performance.
Do you have the option of offloading the rendering to the client? That may also helpThe link from @member is relevant even if it is for Horizon and was the one i was thinking about when you mentioned that amount of monitors. Remember that all of this is done in software so performance will not be great.
Hum ok I was wondering which part of the VMware article was relevant for Citrix… Still reading it, thanks.
Concerning the number of screens, I should have mentioned that in the complete set of questions we asked helpdesk to ask, the users don’t complain when working from home with max two monitors! Which was a key finding for me.
As far as offloading is concerned, this is what I want to do now that they are on kiosks laptops. Still trying to figure out the best settings to do it
Actually I am new in this environment and just herited this… Thanks again.
the fact that they have no issues with 2 monitors when working from home aids in my thinking that the video memory just can’t keep up.
Seems like there are a lot of requirements on the Horizon side… take it you have checked all of these – https://docs.vmware.com/en/VMware-Horizon-Client-for-Windows/2209/horizon-client-windows-installation/GUID-56FEBFD1-E7CB-4290-BED0-8495DA4D1059.html
So ignore my Horizon post, I realise now you are using CitrixAs Wouter said, some can be relevant even if I’m using Citrix ..
Same, I also missed the citrix part. The video memory still is relevant in my opinion
Yes for defo, I know in Citrix you can configure a reg to set the video memory higher than you can the max in the console (or at least you used to be able to).
first step would be to see if the 3d option is disabled in the vm’s. With this enabled the OS & applications might think it really has 3d capabilities while that would only slow things down.
This is what I already did, I mentioned that I have set "Display memory limit" to max…
Check the CPU metrics for the VM and make sure there is nothing there. The rendering is all done in CPU so it needs instant access to CPU, any wait times and you will see lag, also network connectivity is important so again make sure there is no latency and low rtt times.
I would guess even with HDX you need heaps of bandwith available to be able to keep up with that amount of screens.
HDX is v.efficient but I wouldn’t be trying to do this over a slow link that’s for sure
Thanks for your replies, I will check all this and feedback here.
I just have to add that I discovered that we are not using EDT, i.e. still TCP. I’m not sure if this woùld make a real change.
I don’t think EDT will make any difference here, but its easy to enable so worth a try
I shall add that these specific users are using Bloomberg and heavy Excel tables, plus loads of 3rd party or in-house business apps…
Jumping in the thread… I had similar experience at a customer using Dell thinclients with only (:)) 2 wide 49" screens… After a lot of troubleshooting, we found that the GPU memory was the bottleneck. It was with remote PC (using 1U servers). Bloomberg for sure is not helping, we discovered that the "TV module" was killing the GPU so I can’t imagine how it goes with a virtualised one…
Thanks for the comment. In fact, lobbying for GPU cards paid off, and very quickly. The budget has been released and we are getting the new Vxrail boards and GPU cards for users with more than 4 screens soon…
nice!
Mind to share what gpu’s you will be getting and what profiles you will assign?@member I will do this asap
We are getting 12 servers with 2xAmpere A16 GPUs each. They are racked and waiting for configuration. I’ll let you know.
Continue reading and comment on the thread ‘Troubleshooting General VDI Slowness with Multiple Screens’. Not a member? Join Here!
Categories: All Archives