Terminal Server very slow

what are the specs for the machine.. i.e. RAM, Disk subsystem

See bellow.

What's the actual physical hardware on the host? CPU(s), RAM/CPU, and RAM total? What's the disk subsystem setup?

I have a good explanation in my EE article on performance: Some Hyper-V Hardware & Software Best Practices.

Throwing more vCPUs and vRAM at a VM may actually be detrimental to its overall performance.

With the hardware setup known I can make some recommendations on the VM's configuration.

The Host is a Hyper V running 3 VMS Exchange, Domain Controller and Terminal Server
The Terminal server has the most RAM and CPU.
The work around I found now is to reboot the server daily. Since I do this there is no more complaints but I would like to fix the cause of that.
Also when the problem happen it take for ever to reboot. I usually have to force a turn off if not it will be hours.

The E5-2620v4 is an 8 core CPU. I suggest reducing the RDS VM vCPU count to 4.

The physical server's RAM is 64GB. That's 32GB per CPU in a dual CPU setup (each CPU has a memory controller). 20GB of vRAM should be okay but not guaranteed to be a cause in the performance problem.

What is the physical disk/RAID setup on the host?

I explain how vCPUs to physical cores work in my EE article: Some Hyper-V Hardware & Software Best Practices.

It's a Raid 10.
I had it before at 4 CPU and I changed it to 12 hoping that will help.

RAID 10 what? What are the specifics please?

# Disks
Make/Model
Logical Drives on the array

This is the full list of the host

I see the 1.6TB Intel S3610 series. There are four of them in RAID 10? If yes, then I/O at the disk level should be more than enough to handle the overall workload setup.

Is that just two 32GB sticks of RAM?

Yes it is.

Okay. That's a _huge_ performance hit for the hardware.



Each CPU has four memory channels. The primary channel slot in blue and the secondary slots in black. When all primary slots have memory in them, preferably the same size and speed, the board actually stripes memory across them much like a disk RAID 0 stripe. Dual Rank memory sticks will outperform Quad Rank sticks. Each channel (blue + black slots) can hold a total of 8 Ranks. In higher density settings it's not uncommon for us to have a pair of 64GB Quad Rank sticks in each channel (1x blue + 1x black).

With one 32GB stick per CPU that's not a lot of memory bandwidth to be working with. I'm suspecting that this is one of your bottlenecks.

My EE article Some Hyper-V Hardware and Software Best Practices goes into some detail on the "why".

So is there an work around to improve performance other that what I'm doing now by just rebooting daily?
Users reports problems specially when they start a browser eider IE or Chrome. CPU specially goes over 90% but if I reboot daily it's OK
This happen only if I don't reboot for a week or so.

Set up a Group Policy Object to force log-off at the end of the day. That will close their sessions and eliminate the possibility that one of their LoBs (Line-of-Business) have a memory leak.

Let them know that they need to log off daily!

What we do:

On all Session Hosts we drop a shortcut on the Public\Desktop profile location:
1: New Shortcut
2: Logoff.exe
3: Name: Log Off
4: Save
5: Change Icon to the gold button with the white key:

Browsers are a world of hurt in any RDS setup. We hit this a lot. Firefox seems to be about the best but some users pull the portable version of Chrome down and use that. It's a bit of a pig.

EDIT: Use PerfMon to monitor in-guest memory usage and performance.

This is something that they do daily. Every user I instruct to log off at the end of the day and they all do. Worst I saw is one once in a while to forget to log off but I never had more than one left on the server at the end of the day

Okay, then it's time to look for the culprit. The behaviour indicates something leaking memory.

A/V?
  + This is the number one culprit in my mind as opening a browser would put the A/V client on high alert so to speak
Management software?
Remote monitoring and access?

Make sure all of the above is at the most recent version and check their release notes for any errata on bad behaviour.

The memory leak testing link I put in above is also another thing to do. That may help to narrow down what's causing the problem.