-2

I installed Ubuntu 18.04 on Hyper-V Win Server 2016.

And network performance of the Ubuntu is bad: I'm hosting few sites (Apache + PHP) and sometime response time is > 10 seconds. Sometimes it is fast.

As I troubleshooted, I see this netstat results:

# netstat -s | egrep -i 'loss|retran'
3447700 segments retransmitted
226 times recovered from packet loss due to fast retransmit
Detected reordering 6 times using reno fast retransmit
TCPLostRetransmit: 79831
45 timeouts after reno fast retransmit
6247 timeouts in loss state
2056435 fast retransmits
107095 retransmits in slow start
TCPLossProbes: 220607
TCPLossProbeRecovery: 3753
TCPSynRetrans: 90564

What can be cause of such high "segments retransmitted" number? And how to fix it?

Few notes:
- VMQ is disabled for Ubuntu VM
- The host system Network adapter is Intel I210
- I disabled IPv6 both on host and in VM

Here is WireShark showing, that it takes ~7 seconds to connect (just initial connection) to my site Propovednik.com:

That's how WireShark shows connection to my site

Sep 20: So far, the issue seems to be caused by OVH / SoYouStart bad network:

This command shows 20-30% packets loss:

sudo ping us.soyoustart.com -c 10 -i 0.2 -p 00 -s 1200 -l 5
Slavik
  • 1,488
  • 1
  • 15
  • 24

1 Answers1

0

The problem could be anywhere along the network, including the workstation where you work from. I suggest you check the network as retransmissions and packetloss means that either something is malfunctioning or misconfigured. If this is on a wireless network, you could be out of range of your router.

I am pinging the website you noted from my computer and there is no packetloss.

DustWolf
  • 516
  • 7
  • 10
  • for regular ping command I don't see much of packet loss, too. But if I start sending them but faster - I see 10-20% loss. Try this command and you would see: sudo ping us.soyoustart.com -c 10 -i 0.2 -p 00 -s 1200 -l 5 I opened the support case with the provide (OVH), and they asked my to try MTR - it shows packets loss, too. – Slavik Sep 21 '18 at 18:55
  • The -l parameter will by definition cause you to have "packetloss" because preloaded pings do not wait for an answer, and a ping without an answer is considered to be one with packetloss. It is easy to reproduce such results even sending pings in a LAN which experiences no losses. You may also be triggering firewalls that may be filtering your overzealous pinging. – DustWolf Sep 22 '18 at 19:14