Recently I spent lots of time to check how to improve PVS 7.* server performance to reduce the vDisk loading time.
And it seems on the internet there are lots of articles talking about tuning storage (both storage server and PVS server) to enable ‘oplock’.
But I found that almost all these articles are based on PVS 5.* and windows 2003/2008.
So do we still need to tuning storage/SMB for PVS servers?
Citrix has a good article to answer this quetion:
Just check the summary part:
Using file share storage for vDisks is still a valid and recommended approach, if sufficient capacity and high availability is in place. Especially in environments without redundant resp. highly available file services, I’d rather recommend local replicated vDisk stores instead of using just a single file server that definitely constitutes a single point of failure. And no one needs to invest in expensive file clustering solutions if its only purpose would be to provide file shares for vDisk storage.
Caching will help to significantly reduce the load on file servers or filers. Unlike earlier versions, there are no tuning requirements, neither for the PVS servers, nor for file servers. The defaults are perfectly fine. Sizing guidelines for PVS server memory (RAM) from past articles still apply.
Consider the caching behavior of the SMB redirector. There is a chance that shutting down all target devices connected to a particular vDisk will also remove the vDisk’s cache entries and the cache will need to be warmed up again on the next boot.
Leverage the latest SMB protocol if possible, at the time or writing this article it’s SMB 3.1.1. Not only Windows file servers support SMB3, but also modern filers such as NetApp, and even my home lab Synology is able to support SMB3.
Leasing is key for caching, so don’t use SMB 1.x or 2.0 (in fact you shouldn’t even enable the optional SMB 1.x feature on your PVS servers), and forget about any ‘oplock tuning’. Anything from SMB 2.1 onwards is fine with its defaults, but SMB 3.x brings added features that might be beneficial for you, such as ODX when taking copies of a vDisk file.
So it seems the only thing we need to do is to disable SMB 1.0 on PVS server. How to do it? Here is the link:
When we publish a website URL via Citrix, we always to lockdown the website user can access.
The easiest way is to use IE lock down mode. To enable lock down mode is simple, you only need to add “-p” parameter.
iexplorer -k http://wwww.google.com
Then when user start the application, they will get a full screen IE with no addressbar, no bottons.
But please be aware that, in lock down mode there is no exit botton, so User need to press ALT+F4 to close IE.
Is there any better option?
Yes, you can use below script:
Set objArgs = WScript.Arguments
If objArgs.Count = 0 Then
WScript.Echo "No URL provided, please supply a URL to open" & VbCrLf & VbCrLf & "e.g. CScript OpenURL.vbs http://www.google.com"
Set objIE = CreateObject("InternetExplorer.Application")
iHeight = .height
iWidth = .width
objIE.StatusBar = False
objIE.Visible = True
objIE.AddressBar = False
objIE.MenuBar = False
objIE.ToolBar = False
objIE.Top = 0
objIE.Left = 0 + 8 'Move to the side just a bit to show the desktop
objIE.Width = iWidth - 16 'Shrink to let a bit of the desktop show on the sides
objIE.Height = iHeight - 28 'Shrink a bit to see the taskbar
Then publish “IE.vba www.google.com”
-enable enables license management. The first upload to Citrix occurs seven days after you install the License Server.
-disable disables license management. We recommend that you use the License Management Service to manage your licensing environment.
-query displays the current configuration.
I’m running a Citrix Netscaler VPX in my lab, and I just noticed that even though there is no connection, the CPU usage for this VPX is 100%.
You can change this behavior by doing the following:
On the left, go to System > Settings.
On the right, in the bottom of the second column, click Change VPX Configuration Settings.
Change the CPU Yield drop-down to YES, and click OK.
After making this change, you can see an immediate drop-off in CPU consumption.
Bottleneck: provisioning services. Customers note there is excessive Network I/O and CPU utilization.
Bottleneck: vDisk fragmentation or server virtual instances. Customer notes there is excessive page file utilization and disk I/O.
Bottleneck: delays mounting new vDisks. Check for excessive Network and Disk I/O on delivery controllers.
Bottleneck: delivery controllers. Check for excessive historical CPU utilization.
Bottleneck: slow application enumeration. Check for excessive disk and network I/O on the data collectors.
Bottleneck: slow session creation noted within the director console: Check for historical CPU and Memoyr consumption, consider adding VCPU and memory when/where needed.
Bottleneck: higher than expected user logons. Check for high CPU and/or network utilization (not historical but may trend at random intervals). Add processing or new delivery controller if necessary to handle the expected loads.
Bottleneck: issues with local host cache (LHC). Disk and Page File I/O in excess can cause unanticipated issues with LHC. Alert and adjust when/where needed.
Bottleneck: Processor intensive apps. Check questionable servers for larger disk I/O and page file utilization. Consider adding more VCPU’s and/or memory to offset the demand on disk and page file.
Bottleneck: vDisk and/or Provisioning Services. Check for higher than normal CPU and/or Memory consumption as a deficiency will slow down the loading of vDisks and caching via Provisioning Services (PVS).
Bottleneck: Web interface authentication. Consider adding more memory and looking at network utilization trends. It may be necessary to either add more memory or to add an additional WI to your GSLB URL.
Bottleneck: slow PXE and vDisk. Check for memory and/or network utilization and consider addresssing depending on noted trends.
Bottleneck: target device latency. Check CPU and network I/O for spikes and/or trending issues.