为什么这个网络连接这么慢？

11

运行Ubuntu 9.10的Linux服务器上的网络性能速度出现问题。在1000mbit / s的有线以太网连接上，所有类型的流量的传输速度约为1.5MB / s。最近，该服务器已比samba达到55MB / s。我尚未更改硬件或网络设置。我会定期运行更新，并且这台计算机上正在运行Ubuntu仓库中的最新版本。

硬件设置

台式机Windows PC-1000交换机-1000交换机-Linux服务器

所有交换机都是netgear，并且它们的连接均显示绿灯，表示连接速度为1000mbit / s。当连接速度仅为100mbit / s时，指示灯为黄色。其他诊断信息：

root@server:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0c:6e:3e:ae:36
          inet addr:192.168.1.30  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:6eff:fe3e:ae36/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:28678 errors:0 dropped:0 overruns:0 frame:0
          TX packets:73531 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2109780 (2.1 MB)  TX bytes:111039729 (111.0 MB)
          Interrupt:22

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:113 errors:0 dropped:0 overruns:0 frame:0
          TX packets:113 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:23469 (23.4 KB)  TX bytes:23469 (23.4 KB)


root@server:~# ethtool eth0
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pg
        Wake-on: g
        Current message level: 0x00000037 (55)
        Link detected: yes

root@server:~# mii-tool
eth0: negotiated 1000baseT-FD flow-control, link ok

服务器认为其连接速度为1000mbit / s。我已经通过使用Samba复制文件测试了传输速度。我还使用服务器上的netcat（nc目标10000 <aBigFile）将其转移到Windows（nc -l -p 10000），并看到了类似水平的性能下降。

我使用hdparm测试了硬盘的速度，并得到：

root@server:~# hdparm -tT /dev/md0
/dev/md0:
 Timing cached reads:   1436 MB in  2.00 seconds = 718.01 MB/sec
 Timing buffered disk reads:  444 MB in  3.02 seconds = 147.24 MB/sec

使用DD读取相同文件进行传输会产生以下结果：

paul@server:/home/share/Series/New$ dd if=aBigFile of=/dev/null
3200369+1 records in
3200369+1 records out
1638589012 bytes (1.6 GB) copied, 12.7091 s, 129 MB/s

我很沮丧是什么原因导致较差的网络性能（比网络的性能低2个数量级）？

— 保罗·基布尔
source

serverfault可能是询问此类问题的更好场所。

— Maciej Piechotka 2010年

尝试使用ServerFault 问题，了解可用于解决网络连接缓慢的常规技术。

如果没有任何变化，请怪罪磨损（电缆）。

— 梅尔（Mel）

6

您应该考虑检查的一些事项：

双工-如果一方认为该链路是全双工的，而另一方认为该链路是半双工的，则表示不良。
开关不良？绕过/他们。
巨型帧。9000字节的MTU减少了开销，这应该增加吞吐量（放弃一点延迟）。听起来您的问题太糟糕了，但这无济于事。
TCP功能：ECN，SACK，拥塞控制算法
TCP发送/接收窗口大小（Linux的详细信息）

netperf非常适合对网络性能进行故障排除。但是netcat一点也不坏。

— 布莱恩·凯恩
source

6

以我的专业经验，我一直努力在GNU / Linux上使用Samba来获得良好的可靠网络性能。您提到您已经达到了55 MBps的速度，我相信，所以我猜想肯定还有其他事情在起作用。

但是，您是否尝试过NFS，FTP和SCP？带宽问题在不同协议之间是否一致？如果是这样，则很可能缩小到物理连接。如果结果不一致，则很可能是软件问题。

除了测试其他协议之外，您还在传输中使用加密吗？例如，使用rsync -zSweet可以启用压缩功能，但是这是以CPU成本为代价的，这严重影响了传输的整体速度。如果SSH与配合使用rsync，则在压缩的基础上进行加密，并且CPU会承受一点压力，从而导致严重的速度损失。

— 亚伦·托彭斯（Aaron Toponce）
source

2

尝试netstat -i查找rx / tx错误。
尝试netstat -s查找tcp问题-比较文件复制前后的值，并查找重置或重新传输中的大峰值。

— 拉斐尔·费雷拉
source

las，在100MB之后，根本没有TX / RX错误，并且从测试开始到结束，重置次数一直是4

— Paul Keeble 2010年

0

您可能会检查网络的拥塞；也许其他一些设备正在消耗您的全部带宽？

除此之外，您的网络接口和/或其驱动程序可能有问题。很奇怪

— Pmalmsten
source

在测试时，这些是网络上仅有的两个设备，其他都没有。

— Paul Keeble 2010年

0

如果有可能，要消除大多数疑问确实是操作系统/驱动程序/卡问题，请使用交叉电缆将计算机连接在一起。这将消除方程式中的开关和其他可能的网络问题。

— 斯蒂芬·贾兹泽夫斯基
source