This message was deleted.
# _general
s
This message was deleted.
a
FSlogix + WEM in use?
k
We are using Ivanti appsense with mandatory profiles. 95% policies are triggered off after desktop is loaded. We have setup triggers and general optimizations like Citrix Optimizer etc The image itself is fairly chunky.
l
I would suggest getting an EM log file and loading it up in EMMon to check the logon timings.
k
Mind my ignorance, EM stands for?
k
Use UberAgent/ControlUp to get a breakdown of your logon process and troubleshoot from there
l
@King ston Environment Manager. EMMon is a tool in the EnvironmentManagerPolicyTools64.MSI installation. Its in the software\products folder of the UWM download.
k
thanks guys Yup got uberagent installed. Majority of the time is taken by shell startup and others (doesn't help) Landon, will read up on that. Does that given breakdown of policies timings or all components of login process?
l
Just AppSense stuff. Chances are you have a Windows Setting Group with alot of data killing the logon time or you have a policy in pre-desktop thats killing it. In both cases EMMon will tell you what the issue is if its AppSense related.
k
Excellent, very helpful. We believe it's our PVS servers getting hammered also, are there any tips from that perspective?
l
If it's your PVS servers then it should be fairly easy to highlight. Look for high memory usage and high disk queues on these boxes. Are you using ram caching for PVS?
Also , stub paths, have you stripped these out?
k
Thanks Leee In regards to active setup, I have checked and it is bloated indeed!..defo gnna look into that now Also in regards to PVS, do you mean just look at CPU and Ram during peak hours? We are using ram caching with overflow to HD. I just saw that tho we got the above setup, the value is set to very low number, which should be 1024 at least I guess.
l
That's does depend on how varied your workload is X number of users. Ram and disk IO on your PVS servers. Stub path cleanups will speed you up alot.
j
What is your RAM Cache size? 1024 is fairly low. I would suggest 4096 for XenApp servers.
to start
k
1024 is what we have it set to. We are using win 10 non persistent VDIs. I am a bit new to PVS, we have fully flash storage, so wondering what impact will be if the value for RAM is too low etc?
l
Okay. So 1024 of ram cache for a VDI is pretty high and should cater for most use cases. What's your reboot schedule like?
k
Reboot of machines is done by user log off from session. In regards to PVS servers themselves we don't reboot.
l
Of course.. doh......
Should be fine. Have you checked vdisk retries?
k
Retries are high on some machines and others are very good. So logged on now, can see about 5 machines with 2000+!!! The majority are in single/double figures with about 80 machines from 100-600 One thing I have checked which we haven't added to the PVS servers is the reg key for disabletaskoffload has not been set.
l
Okay. Retires should be in double figures only for a period of a day in my experience. What virtual environment do your PVS servers run on?
k
All running on VMware 6.7 All sitting on nuttanix 2 are still on server 2008r2 and 2 are now on server 2016.
l
And the storage for your VHDs?
k
Same, all flash - all our prod sits on nuttanix hardware.
l
Sure but do you have an smb share for you VHDs or local storage to each server and replicate the disks around?
k
Ah ok, that I do not know exact answer. I believe it is local storage to each server.
l
Okay, that should be fine then. Ram Usage and Disk I/O (Reads and Writes per second) and Ram Usage.
k
Nutanix/PVS and write cache to RAM?
l
That what he said Kees, school us please.
Ram with overflow to disk
1024 per vdi
k
Yup.
k
In general: MCS on Nutanix performs better than PVS due to shadow clones. Besides that, we would advice not to use write cache to RAM w/ overflow due to the perf impact of that solution
k
Thank you kees. What option would be best in regards to PVS.
k
I’d go for RAM cache set to 0 with overflow to disk, performance wise
(That doesn’t solve your issue tho)
l
Of course MCS would be the better choice and be far more scalable in general (with ease) but that doesn't solve the issue
oh.... lol, you reading my mind internationally?
Kingston, would there be an appetite to import your pvs vhd to AHV and spin up some MCS machines.
?
k
Migration from PVS to MCS is a couple of minutes work 🙂
k
We can try, I am not the nutanix guy here, but can defo suggest it and see how it runs and if something we can do going forward. A bit of a newbie , so just getting ideas, which have been great.
k
Did you see the best practise guide for CVAD on our portal? That might be a good doc as well
l
Well worth reaching out on areas like this. Nutanix is also great kit!
k
Wait.. those retries are telling, are those VMs on the same node? If so: you might want to check networking on that specific node
k
That I will have a look at now and investigate. I will check the guide as well, thank you both. Will post results back here as soon as.
l
No worries, as Kees mentioned. The retries will generally slow things down. That does need to be reviewed too.
MCS will alleviate this issue though and is the recommended solution for nutanix due to the nature of the underlying tech.
k
Those retries worry me, 2000 or even anything above 10-20 a day would worry me. Seems like an issue on the networking side (might be as simple as E1000 nics vs VMXnet 3 for example)
l
I wrote an article on MTU and making sure that's correct