A full capture of the stream as seen by the client can be downloaded here: (never used that service before, but seems legit). When this first starts happening, it happens a lot that day for that client, but may be fine again the next day, while another machine gets the problem. Everything works well, until suddenly TCP ACK's from the client is delayed by 20ms as opposed to the normal ~0.1ms (as seen on client capture), at which time the server has already started re-sending segments (see TCP Duplicate-package). We seem to have drilled it down to the above linked image. I'm also sure we've managed to get for instance 2.5Mbps on the iperf while at the same time 850Mbps in SQL performance tester - same clientserver, at the same time!
The DC has 4 ESX hosts, and different switches, none which seems to have any problem and the issue can arise on whichever server.
This happens at any of our ~100 directly fiber-connected sites towards our DC. If we have to computers simultaniously transferring data from a server, both located at the same place in the network, one can struggle, and one can be fine. This happens -within session-, it can be SQL-requiring application, SQL-performancetesting, SMB and iPerf - anything, really. We're struggling with a machine "here and there" in our ~1000 machine network where suddenly connections to servers are dropped from ~850Mbps down til 2.5Mbps. Relevant image from wireshark capture at client: (3 segments recieved at the same time, 1st segment re-transmitted 0.02s later and just after the client ACKs the three first segments) As change on server-side is the fix, I'm guessing the server just stops sending segments sometimes, as if it was waiting for ACKs but aren't really, then after 20ms does a F-RTO retransmit thingie. Forcing Internet template on win2019 mitigates issue, but no idea what source problem is. Update 8th sept: Stuck on the same issue. Next step: gathering new pcap's on server+client simultaniously. Both working and bugging sessions are marked as Datacenter template, so it's not the source of the problem itself. Update 6th sept: Found that forcing Internet tcp template in WinSrv2019 mitigates the issue, but we do not know what causes the issue. Update 4th sept: Gonna take up this thread again on Monday! Thanks for all tips so far :)
0 kommentar(er)
