Sluggish performance within Windows 7/10 VDI session (Non network related!)

I’ve come across this now with multiple customers. Most of the time it’s showing up when people are moving to windows 10, after experiencing poor performance with W7 desktop VMs and as part of the migration process, they buy all new tin.

They experience sluggish responses when opening various apps and for example with IE, it’s painfully obvious that something is wrong. It will spike the CPU to a high percentage, take quite a while to open, then the CPU will drop and it’ll be OK for browsing until more tabs are opened and similar behaviour will occur.

When this occurs, I always ask if there’s any resource pools set, any QoS or similar on the storage and so on, but generally, I know there isn’t. vSphere monitoring will show that everything is OK, so will anywhere you look within Horizon and vROPs. I’ll ask if the physical hardware has power management/saving on within the BIOS and I usually get the following answers:

“Oh, I’m sure it’s been turned off, but I didn’t build the servers”

“Yep, no power management, vSphere says so.”

“I don’t know. How do you even do that?”

“I’ve asked and they say it has been.”

Every time. Every. Time. 

It can be difficult to definitely show that this is the source of the problem when everything you have access to says it all should be OK, plus people also have many different levels of experience with these things. I came across it about 7 years ago when the company I worked for had a mix of Dell and HP servers and being a PC gaming enthusiast, I was always trying to eke out as much performance of a PC as I could, so I tried to do the same with servers – no overclocking though! So power saving settings would be the first thing to get turned off!

So if you’re experience similar problems, with apps spiking the CPU, being sluggish, then the CPU dropping, check your physical hardware to make sure power management isn’t set to power saving, it’ll save you a whole load of heart ache! This also applies to Citrix as well.

If you need proof of this, or want to check it, there’s various tools, but I always check using Systrack – we have a tool as part of the suite called Resolve, which allows for in-depth analysis of specific machines (as well as the ability to compare to other machines/groups) and this will show straight away if a machine is being throttled, or has memory ballooning. Throttling can also show if a CPU is overheating and the BIOS throttles it back to avoid shutting down – many a place have thought they need new machines, or new CPUs, but no, they simply need to get those dusty fans cleaned out!

throttle

May show up a little bit too small for some screens, but what you’d see, is the CPU is throttled to 66%. The CPU usage is low, but due to the throttling, the Thread count and interrupt per seconds are high. The CPU should be 100% or even higher with some modern CPUs, but unless you’re really trying to save some power… You don’t want it lower than 100%

What’s also interesting, is when people go back to the older servers with Windows 7 on and realise that the poor performance throughout, was also due to the power management not being turned off… as a fair few manufacturers ship hardware with this as default…

IGEL and Lakeside Systrack

Obviously I’ve been in a new role at Lakeside so I’ve been living/breathing/travelling/living that, as well as more citrix environments *cough cough* – but that doesn’t really matter if I’m honest, as systrack works equally well with both. Actually, it works brilliantly with everything you can throw it at. I’m still amazed at the pain points that systrack could have fixed for me over the past 5 years and aside from new customers I’m dealing with, I’m also seeing some familiar faces from the past that I know can make use of it!

This post is to show that IGEL, as a partner, has jointly developed a solution to monitor their IGEL OS with systrack – now, as anyone in EUC who has used thin clients or a thin OS will know, they’re a little black box unless you start digging into logs, which may not actually make much sense! Now you can use the analytics to show what’s going on, in conjunction with whatever VDI solution you’re always monitoring.

I know of projects using various zero/thin clients that still complain about latency, performance issues etc and they STILL have no monitoring or any insight whatsoever and the technical skills of the people on the ground are low, to to say the least!

IGEL and Lakeside

Troubleshooting non responsive VMs

Sorry for the gap in posting…well…anything… New role has kept me very busy!

Most of us will have our own little tips and tricks on troubleshooting, but recently I had a customer who had a machine hanging, that looked suspiciously like VMware Tools was causing an issue, but they had no idea how to troubleshoot. I’d suggested various options, including simply getting the logs, checking ESXi services and so on and it wasn’t anything they’d had to do before, so I really needed something quick and fully features to suggest to them. There’s a great VMware KB which uses the process of:

Validate the scope – find out the scope of the problem and accurately define what the symptoms are (no point in just having someone screaming “It’s crashing, IT’S CRASHING!”

Identify the cause – so many possibilities! Storage, services crashing, resource contention, a task on the VM…

Action Plan – Take action to remediate the issue – once the cause has been established, focus on what is causing the issue and define a plan to resolve it.

https://kb.vmware.com/s/article/1007819