1

In our network I have several PCs which sync files from an rsync server (without encryption) to their local hard disk. Often (not always) it is really slow. In sum it took 33 min for 2 GB to transfer on a GBit network. The whole package of ~8 GB / 300000 files took more than an hour (I didn't measure the whole thing).

The server is on 10 GBit network. The clients and everything between is on an 1 GBit network. The server's and the client's CPU and RAM usage is low.

I setted up a virtual machine doing the same and sniffed the traffic using Wireshark. It came up there is a huge amount of TCP Dup ACK packets. Nothing happens in the transfer but the TCP stack is sending continuous Dup ACK packets with the same sequence numbers. The sequence number graph shows it.

Ping times are good (< 1 ms). What can cause this behavior? How to fix it?

EDIT 1:

I also tested it with a client from the same subnet. TCP Dup ACK occurs too but only a few times. The transfer is much faster. I got 1,5 GB in only 1:45 min. So I think it must be a network related problem. Maybe a tcp setting in the OS or a router problem(?)

enter image description here

Michael
  • 325
  • 6
  • 19
  • The problem is probably not the network but the large number of small files, which require many file system calls on both the local and remote file systems to determine if the files are modified or not. – HBruijn Jul 29 '16 at 07:37
  • Similar to [this Q&A](http://serverfault.com/q/365103/37681) – HBruijn Jul 29 '16 at 07:39
  • Both, the server's hard disk and the client's hard disk is doing nearly nothing in the pauses. So I don't think it's a IOPS problem. iostat confirms it. – Michael Jul 29 '16 at 08:07
  • Did you seup VM in the same subnet where your server is? – user1700494 Jul 29 '16 at 08:56
  • The real clients are in a different subnet. The test VM ist another different subnet. – Michael Jul 29 '16 at 09:16

0 Answers0