• 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.

XenApp

J

jenuster

Limp Gawd
Joined
Mar 8, 2011
Messages
154
I have a graphic intensive application that I'm trying to publish that takes up 50% of cpu utilization with 2 VCPU's upon startup (loading of real time graphics is what causes this). So two users loading up this published app at the same time would cause CPU to be 100% for about 2 minutes.

Once the graphics loads the CPU has low activity. Question is how would you scale this for 50 users-. I understand that it is highly unlikely that all 50 users will start this particular application at once.

I'm thinking Citrix has some sort of way to set a limit on how much CPU is utilized by a published app.
 
You say vCPUs....this virtualized? Under what? If so how many XenApp servers on a host and what CPUs does the host have?
 
Yes virtualized (ESX 4.1). One XenApp server for now on one host. CPU=INtel X5650 @2.6 (2 sockets, 6 cores per socket). With Hyperthreading on I have 24 logic procs.

I should add it's a 5 node cluster with similar hardware and there are other Vm's on these hosts..but average cpu utilization. is about 14 % across all the hosts
 
Last edited:
Adding more XenApp servers that sits on one host? Or spreading XenApp servers across multiple hosts? I'm assuming you mean the latter.
 
+1 on no overcommitting of CPU resources and really, the fewer vCPUs per XenApp server the better. I avoid going above 2 vCPUs. CPU ready and scheduling in general is the bane of terminal servers. I personally hate TS and would prefer to use VDI, but they still have a place which sucks. It also really depends on the application being hosted. We had some 16bit pos app being hosted where having more than 1 vCPU per TS box made performance unacceptable. Very weird behavior. We ended up with 6 TS servers each able to host about 20 users... and a special cluster of 2 hosts just for the damn things where we could avoid overcommitment. A "no overcommit" cluster if you will. Terrible sacrafices, really.
 
Yep. XenApp chews up resources. We're doing an 82-blade UCS install right now and I think 16 or 18 of them are XenApp with like a 10:1 or 8:1 consolidation ratio....annoying.
 
Wow two host cluster just for XenApp? Did you have one/several applications that were CPU intensive or did you just have a large scale of users?
 
netjunkie, you stated earlier not to overcommit. And for your example you stated that if you have 12 cores only to assign 12 vcpu's. By 12 cores are you referring to logical cores or physical cores?
 
jenuster said:
Wow two host cluster just for XenApp? Did you have one/several applications that were CPU intensive or did you just have a large scale of users?
Click to expand...

N+1. One host would have more than cut it, but we had a 2 host cluster just for failover purposes. The plan was to have both hosts "not overcommitted", so no DRS -- but we would accept during maitenance / HA events that it would be 2:1 max pCPU core to vCPU ratio. It was worth it just for backup/recovery and other business processes to keep them virtual as opposed to physical servers.

EDIT: Keep in mind these things were not all that CPU intensive. The problem is that CPU ready and scheduling at all makes the users complain about responsiveness. So their start menu delays a pinch, who cares? It's things like that users notice, not a report they run that is delayed a few seconds.
 
Btw why was DRS disabled? I figure it would be a good idea to leave it on especially if you have a user that decides to fire up some application that takes up a lot of the cpu. In that case wouldn't you want the VM to be moved over to the host in the cluster?
 
jenuster said:
Btw why was DRS disabled? I figure it would be a good idea to leave it on especially if you have a user that decides to fire up some application that takes up a lot of the cpu. In that case wouldn't you want the VM to be moved over to the host in the cluster?
Click to expand...

There isn't any overcommit so there is never competition for resources. That is the point, and even if DRS were turned on it most likely would never move anything except MAYBE for memory balance if it could skew the standard deviation enough on its own. That wouldn't be a reason we'd want it to move anything. I didn't go as far to break vMotion by setting affinities, but the idea was that there should always be a core free to run and DRS could disrupt that - however unlikely it might be. The whole point of the cluster was the vCPU to pCPU core ratio is never to exceed 1:1 EXCEPT in an HA event or maintenance.
 
I'm still researching this and I've read that with the improvements made in the cpu scheduler in 4.1, that increasing beyond 2 vCPU's per XenApp vm should't be a problem. The cpu ready time should be acceptable. Thoughts on this?
 
Try it...but the information I linked is current for 4.1 from someone that knows XenApp far better than me. You can do it...just keep an eye on performance and user experience.
 
You must log in or register to reply here.
Back
Top