我在同一networking上的两台Linux服务器之间传输文件。 这是他们两个的networkingconfiguration：
服务器1：
eth0的设置：
Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: on Supports Wake-on: pumbag Wake-on: g Current message level: 0x00000001 (1) drv Link detected: yes
服务器2：
eth0的设置：支持的端口：[TP]
Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: Unknown Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000007 (7) drv probe link Link detected: yes
两台服务器连接到同一台交换机，支持1 Gig，Cat5e / Cat6。
我真的不知道什么可能导致这种速度。 我读过，也许“自动协商”configuration可能会做到这一点？ 我能否以某种方式检查协商的速度是多less？
要添加到iwaseatenbyagrue的答案，可能有几件事情在这里，并保持你的眼睛，你正在testing是重要的。
首先， rsync的第一次运行涉及目标上的写入开销。 当less量的大文件被复制时，这是相当便宜的，假设你有一半体面的光盘，但它可以使事情比你的networkingbuild议慢。 当大量小文件被复制时，这可能是非常昂贵的：每次在光盘上放置文件时，必须更新inode，更新目录文件等等，并且这引入了潜伏。 这些FS操作所需的时间缩短了可用于复制更多文件内容的时间，因此您的表观吞吐量会像石头一样下降。
其次， -h业务。 当你中途杀死一个rsync然后重新运行时， rsync再次从头开始，但是由于rsync对目标端已经存在的内容是明智的，并且不会重新复制它，所以表观吞吐量将会好得多，至less在这之前经过了第一次停止的地方。 因此，rsync的第一次和第二次运行没有任何其他变化 ，性能可能会有很大的不同。 在担心第二个苹果是一个有趣的颜色，即橙色之前，确保你比较了苹果和苹果。
你也可能会发现，如果要复制的文件的语料库是小文件和大文件的混合文件，那么rsync的性能会有所不同，具体取决于它通过语料库的程度。 往上看。
Upshot： 如果你想testing你的networking，只testing你的networking ，不要通过挑选一个也testing你的FSes，底层存储设备等的testing来混淆其他问题.netcat是一个非常好的工具，可以去除尽可能多的无关材料从一个networkingtesting，因为你可以在一端提供来自/dev/urandom不可压缩的数据，并且用很less的工具开销（没有压缩，encryption等）在networking上推送它。
这不是一个答案，但是您可能需要单独validationnetworking吞吐量，而不是使用networking+磁盘吞吐量（可能还有其他因素，如使用基于SSH的rsync的encryption开销，如果使用压缩的压缩开销等）。
iperf是一个很好的工具，可以让你确认你的networking是如何执行的，而不是你端到端吞吐量的performance。
我怀疑在你的情况下（特别是根据你提到的rsync运行之间的差异），你的networking吞吐量最终会大概是它应该是什么，这将倾向于远离networking成为你的瓶颈 – 但这是纯粹的猜测。