Jump to content
Welcome to our new Citrix community!
  • 0

PVs slowness 1912 + 2016


Yogesh Vedha

Question

Facing slowness issue with PVS 1912 and windows 2016 targets, the PVS target takes 15 minutes to boot.  It stuck in black screen for first 3 minutes and later 10 minutes in windows logo and around 14 minutes the windows logo starts to circle and to me it looks like the actual boot starts here.
Retries count is 0.
Captured wireshark logs at the PVS server side, TFTP completes within a minute, lno errors in expert information and statistics shows the bulk packet transfer starts only after 14 minutes.
Targets devices are in VMware and uses NSX-T virtual switch so facing difficultly to capture the target device boot network log as our network claims promiscuous mode is not supported with NSX.
Citrix case is open but unable to capture target device logs so the case is on hold
Since it's a secure environment I am not allowed to share the wireshark or any logs in this forum.

The same vdisk boots within 3 minutes in  another PVS farm and if I point the same target device to a remote PVS farm they boot in 6 minutes.
Tried different vdisk from the problem server and it took around 15 minutes .
PVS MTU is set to 1506 no fragmentation of frames observed during Ping test to the destination
PVS server utilisation is less than 40%, our network confirms there is no issues with the network side, vdisk is locally placed on the PVS server disk,tried copying the vdisk file from PVS server to target machine local drive the transfer rate goes above 110 MBPS per sec and completes within reasonable time.this file copy may use SMB and actual PVS traffic will be on UDP, i couldn't figure out a way to do a test UDP tranfer.

Since we couldn't capture the Target device logs because of NSX we couldn't progess this case further. Any thoughts .

Link to comment

1 answer to this question

Recommended Posts

  • 0

If you have a wireshark capture of the complete process, I would suggest plotting activity against time -- filter the PVS protocol based on port number and then plot data size against time - this is interesting because it will show if there is a big delay when no I/O traffic is occurring plus it will show if there is a lot of activity target->server and server->target (interested in the target->server because that would indicate if we end up using server-side caching which could certainly cause the slowdown). 
 

If you are seeing constant traffic server->target and it seems low then look at the latency of your store which means looking on the server itself (either I/O disk latency and rates if using a local store or SMB request throughput and latency if using a shared store.

 

Simon

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...