Limit cpu usage for remote desktop users

Is it remotedesktop or a process they are using within their session? Perhaps when you allocate "20%" to the resources, it makes the session think that 20% is 100% to the user, but not to the hosting cpu?
-rich

ASKER

Hi Rich,

It is a process within their session.

I tried using the registry key method to limit the cpu usage for individual user and that worked. But this won't work in our environment as there too many management work involved.

If it's not the remotedesktop process itself, I take it that it must be a windows critical process or you'd terminate that. Is it the traditional mstsc.exe client or perhaps a web-based one?
I've also read that this may help in some situations: http://blogs.technet.com/b/askperf/archive/2012/03/06/performance-issues-due-to-inactive-terminal-server-ports.aspx
-rich

ASKER

Sorry, the process was the one I launched from within TS session. It is a cpu stress test program which I used to test WSRM. Users use mstsc to connect to the RD sessions.

A stress-test is designed to do that (use 100%), so your using that to test the CPU limitations you're trying to apply. You want to prevent users from using 100% cpu, sorry I became confused a bit:
>The RD users always used up 100% of the CPU time.
The RD users CAN use up to 100%... not "always used 100%".
http://technet.microsoft.com/en-us/library/cc753280.aspx
http://technet.microsoft.com/en-us/library/cc771218%28v=ws.10%29.aspx (use the per session method)
Looking at the PDF you attached, seems like you've done all that, might have a look in the windows event logs to see if there is something not applying perhaps?
-rich

ASKER

OK, let me be abit more clear,

My intention is to limit the cpu resource per user on each RD session in my RD server.
So what I did was setting WSRM based on the doc. I provided and used a CPU stress program to test my configuration. However, the setup didn't seem to work as I am seeing 100% cpu utilization everytime I ran the cpu stress program.

I am not sure what else I can use to test my configuration other than a cpu stress program. As I mentioned earlier, I can use reg key method (see link below) to limit the usage (using the same stress program).
http://technet.microsoft.com/en-us/library/ff384148%28v=ws.10%29.aspx

Nothing is going to keep your CPU from hitting 100%, and you would be ill-served if it did. There are products that can hard clamp the CPU from hitting 100%, but what you end up with is poorer performance, and wasted CPU power. CPU spikes at 100% are ok.. what is *not* ok is a process that hits 100% and stays there.

But, what you need to do is look for individual processes that spike the CPU, and dominate the system, along with enable the MS Fair Sharing policies. The Fair Sharing is not as advanced as TScale, but it does a reasonably adequate job. What it basically does is take the amount of CPU time being asked for, and evenly divides it between the requests to keep things 'fair'.

On the other hand, if you have processes that are eating up your CPU time, you need to look at the best way you can either eliminate them, or implement a more advanced solution to clamp those processes down. For example, Flash is a known CPU hog, and too many instances of it can eat up your RDS environment. Citrix handles this by redirecting Flash to the client.

Cleaning up the configuration of applications can help also. An example of this is Office. There are several functions in Office that can be optimized - like turning *off* Check spelling as you type - if you have a fast typist, this can be a serious CPU hog.

The last possibility is that you just have too many users per server with the application load you have. The scaling of RDS hosts is completely dependent on your users, your applications, etc.

Coralon

>Nothing is going to keep your CPU from hitting 100%, and you would be ill-served if it did.
Actually after messing around with this, it does! I've been able to limit the CPU to 20% as well, I'm not sure why it's not applying with the method outlined in the PDF, I followed along and it worked for me. You have to use a windows 7/2008 or higher OS, which I think the author is doing.
-rich

Don't forget the rest of what I said.. clamping it at 20% means you won't get the full usage of the CPU, and the users will feel the performance limitation. What happens is the user needs more CPU, and then when the CPU is clamped, they end up with their processing threads queued, and have to wait until there is enough CPU left to process their threads. So, instead of improving things, it makes it worse.

Your best bet is the Fair Sharing, and *only* clamping down the processes that are truly misbehaved.

Coralon

ASKER

Just looking for window of time to get to this. Thanks for your patience.

ASKER CERTIFIED SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ASKER

Coralon,

It is not like I want to limit the cpu utilization to 20%. What I really want is to limit the total amount of cpu usage to 80% for all RD users and there will be resource for admin. or other application for non RD sessions.

Unfortunately, we are not ready to purchase third party software for this tasks as we didn't budget for it.

ASKER

Rich,

I tried both the consume.exe utility from the Windows resour ce kit as well as Heavyload (cpu stress program) and they both behave the same. I reset WSRM to default and tried it again, the result is the same.

I am running WSRM on 2008 R2.

Even capping it at 80% is going to punish your users.. the issue is not *hitting* a 100%, it is *hanging* at 100%.

Coralon

Really depends on what they are doing... using office checking email even watching youtube takes next to nothing on the CPU. Users won't know the difference for most applications. If they were gaming maybe... but what do you run that's taking 20% or more constantly on your CPU? There really aren't that many user applications I've seen that need that much CPU. Sure a spike (maybe a large sort action in Excel) might take longer but it's not going to be too bad in my opinion, ymmv.
-rich