• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

VMWare + RDS 2008 R2

M

mikkhail

n00b
Joined
Aug 23, 2012
Messages
45
Hi Guys,

I am only on a service desk level but I have to deal with massive performance problems for one of our clients.

They have 90 users spread across 3 RDS servers.

Each server started with:
1 vCPU
12GB vRAM
2 vNICs

We have tried installing updates, hotfixes, defragging, turning off TOE (Due to Outlook ballooning) but general slowness has not improved. I know it is poor design but I am looking for suggestions to increase performance.

We have even tried upgrading to 4 vCPUs on each server and this still hasn't resolved the problem.

It would also be good for you to know that the application which functions with SQL indexes direct on the server, rather than the SQL box.

Poor design, I know.

Any suggestions?
 
These are VMs, correct? What are they stored on? What are the specs of the datastore?
 
Yes they are VMs. (VMWare 4.1)

3 x ESX Host:
8 x 2.393 GHz
49084.31MB
NICs: 7

Storage: 3 x VMFS (NetApp)
 
Can you go into more detail on the performance issues?
Have you ensured that your RDS Broker is properly spreading your clients across the 3 RDS servers evenly?

What type of tasks are these clients doing? Are the RDS servers tweaked to not give full aero/etc/etc to each client connecting?
 
As /usr/home said. What are the specs of the datastore or hard disk subsystem supporting the RDS servers and/or the LOB apps that the RDS sessions run?
 
RDS Broker is not enabled.

This was an extremely poor design which was handed over to support without and we couldn't do anything about it.

I'm not sure on the datastore specs / hard disk subsystem supporting the ESX hosts which the servers sit on - but I can say that no other clients are experiencing performance problems.

They were on two physical terminal servers before and they didn't have any performance problems, now they have three with double the specifications.

If it were my option, I would be creating another RDS server, install load balancing with a Remote Desktop Gateway, and roll them over to this over a weekend.

P.S They don't even have roaming profiles.
 
Hi guys,

I also work for the same company and have been dealing with this client for a large period of time, I can tell you that the applications that they run are as follows:

* MYOB - 32 bit
* Office package - 32 bit
* Procura - SQL database that index data on client side also a 32 bit application
* IE9 - 32 bit

They are running off a 64 bit server 2008 R2 server, as mikkhail has stated we have run a number of things to try and fix the overall performance but it's getting to the point where we are running out of ideas. We have checked for aero and the setting is already turned off.

I have run a fair amount of performance monitors to help to get a better understanding of the issue, below are the results of some of the monitors.

Average disk queue length:

RDS1: Average: 2.238 Max: 176.875 Duration: 22 hours
RDS3: Average: 3.354 Max: 475.351 Duration: 1 day 5 hours

Content Switching:

RDS1: Average: 5,948 Minimum: 768.993 Max: 170,358.692 duration: 22 hours
RDS3: Average: 8,031 Minimum: 236.984 Max: 163,095.251 duration: 1 day 5 hours

We have also ran persistent pings from client side to SQL server to see if there were any drop outs which the users have also been frequently complaining of:

RDS1 to SQL: 83,290 packets running at 5000 bytes for 14 hours with max users on server 0% packet loss
RDS2 to SQL: 79,410 packets running at 5000 bytes for 12 hours with max users on server 0% packet loss
RDS3 to SQL: 17,500 packets running at 5000 bytes for 5 hours, with max users on server 0% packet loss

SQL to RDS1: 83,109 packets running at 5000 bytes for 14 hours with max users on server 7 packets dropped, 0% packet loss.
SQL to RDS2: 79,490 packets running at 5000 bytes for 12 hours with max users on server 49 packets dropped, 2% packet loss.
SQL to RDS3: 17,598 packets running at 5000 bytes for 5 hours with max users on server 14 packets dropped, 1% packet loss.

I am trying to acquire the stats of the datastores these ESX host sit on and will provide further information if needed.

Any ideas? This setup is extremely poor and I'm running out of solutions to fix this environment. Thanks
 
mikkhail said:
RDS Broker is not enabled.

This was an extremely poor design which was handed over to support without and we couldn't do anything about it.

I'm not sure on the datastore specs / hard disk subsystem supporting the ESX hosts which the servers sit on - but I can say that no other clients are experiencing performance problems.

They were on two physical terminal servers before and they didn't have any performance problems, now they have three with double the specifications.

If it were my option, I would be creating another RDS server, install load balancing with a Remote Desktop Gateway, and roll them over to this over a weekend.

P.S They don't even have roaming profiles.
Click to expand...

Look. Lets be brutally honest. The design is so flawed that any troubleshooting or expectation of troubleshooting described situation is virtually impossible. Not only is the VMware side probably not setup best practice, the RDS side DEFINITELY isn't either. If you are on the HD and you are being asked to 'fix' this. I would wholeheartedly recommend that you push them to do a redesign of one or the other or both.

We could be here all day/week/month and never really get to the bottom of the issue.
 
mikkhail said:
<snipped>
They have 90 users spread across 3 RDS servers.
<snipped>
It would also be good for you to know that the application which functions with SQL indexes direct on the server, rather than the SQL box.
<snipped>
Click to expand...

30 users per server.... indexing operations on the RDS server itself (they are SQL clients) .... hmmm. Seems like a lot of disk I/O would be going on.

The DB app seems like it was meant to be run on regular PCs (isolated CPU/Disk i/o per user) ... have you tested/benchmarked without that app in use?
 
SIngle vCPU with 30 users isn't going to cut it.

With Terminal Servers / Citrix, virtualisation only pays when you are doing 32bit so 2vCPU and 4Gb memory then scale out i.e. more servers max of say 20-25 per box.

If you want or can go 64bit then go physical, 1 box (24x64Gb will hit 100+ users depending on the workload you are putting through it.

That being said at 30 users it might be slow but not unusable.
You really need to get some perfmon counters of the usual problems, being disk/processor/memory/network, chances are it's disk but without the counters you are pissing in the wind.
 
Last edited:
You must log in or register to reply here.
Back
Top