在1Gb上行链路上颠覆

是否有可能利用1 Gb上行链路？我有2 Gb上行链路服务器

176.9.xxx.xxx – 服务器

# uname -a Linux svn.example.net 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64 GNU/Linux # cat /etc/debian_version 6.0.8 # svnadmin --version svnadmin, version 1.6.23 (r1485506) compiled May 29 2013, 10:00:56 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.apache.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository back-end (FS) modules are available: * fs_base : Module for working with a Berkeley DB repository. * fs_fs : Module for working with a plain file (FSFS) repository. # 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 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) Link detected: yes

144.76.xxx.xxx – 客户端

 # uname -a Linux test.example.net 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux # cat /etc/redhat-release CentOS release 6.5 (Final) # svnadmin --version svnadmin, version 1.6.11 (r934486) compiled Apr 11 2013, 16:13:51 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository back-end (FS) modules are available: * fs_base : Module for working with a Berkeley DB repository. * fs_fs : Module for working with a plain file (FSFS) repository. # ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000033 (51) drv probe ifdown ifup Link detected: yes

一些基本的testing

 # iperf -c 176.9.xxx.xxx -t 60 ------------------------------------------------------------ Client connecting to 176.9.xxx.xxx, TCP port 5001 TCP window size: 19.3 KByte (default) ------------------------------------------------------------ [ 3] local 144.76.xxx.xxx port 42619 connected with 176.9.xxx.xxx port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-60.0 sec 4.15 GBytes 594 Mbits/sec # iperf -c 144.76.xxx.xxx -t 60 ------------------------------------------------------------ Client connecting to 144.76.xxx.xxx, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 176.9.xxx.xxx port 54666 connected with 144.76.xxx.xxx port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-60.0 sec 3.17 GBytes 453 Mbits/sec

同时当我通过http从svn下载一些项目时，速度最高约为100 Mbit / s。但是一个普通的二进制文件已经以最快的速度被下载

 # axel -a -v http://176.9.xxx.xxx/test.img Initializing download: http://176.9.xxx.xxx/test.img File size: 1101824020 bytes Opening output file test.img Starting download Connection 3 finished ] Connection 0 finished ] Connection 1 finished ] [100%] [..................................................] [ 94.3MB/s] [00:00] Downloaded 1050.8 megabytes in 11 seconds. (96588.44 KB/s) # wget http://176.9.xxx.xxx/test.img --2014-02-01 14:21:13-- http://176.9.xxx.xxx/test.img Connecting to 176.9.xxx.xxx:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1101824020 (1.0G) [text/plain] Saving to: “test.img” 100%[=================================>] 1,101,824,020 51.0M/s in 21s 2014-02-01 14:21:34 (49.9 MB/s) - “test.img” saved [1101824020/1101824020] # curl -o test.img http://176.9.xxx.xxx/test.img % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1050M 100 1050M 0 0 56.8M 0 0:00:18 0:00:18 --:--:-- 57.2M

任何意见将不胜感激。

UPDATE1

正如你看到的速度是100 Mbit左右

 # time svn co http://svn.example.net/Test/ ./Test/ Authentication realm: <http://svn.example.net:80> Authorization required. Password for 'user': A Test/test.img Checked out revision 1. real 1m40.768s user 0m48.885s sys 0m3.738s

从svn下载速度

Update2同样的文件，但通过svn协议，速度在250 Mbit / s左右

 # time svn co svn://svn.example.net/ ./Test/ A Test/test.img Checked out revision 1. real 0m46.075s user 0m15.338s sys 0m4.811s

通过svn协议从svn下载速度

系统负载结帐

 # top top - 18:26:34 up 60 days, 10:14, 1 user, load average: 0.25, 0.06, 0.02 Tasks: 214 total, 1 running, 213 sleeping, 0 stopped, 0 zombie Cpu0 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 99.0%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 0.0%us, 0.9%sy, 0.0%ni, 99.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu7 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 16377584k total, 15345624k used, 1031960k free, 203640k buffers Swap: 8388600k total, 1956k used, 8386644k free, 13597864k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5449 www-data 20 0 409m 68m 3656 S 100 0.4 2:17.41 apache2 6885 root 20 0 10976 1340 944 R 1 0.0 0:00.28 top

我们对你的颠覆testing知之甚less以回答这个问题。尝试从库中下载test.img后，它应该完全满足您的连接。我的猜测是，你正在testing，而试图克隆一个通常是由许多个人小文件代表的存储库，从而使许多必要的连接，从而减缓转移。

因为你可以通过networking基准testing获得很好的速度，所以SVN本身就是一个问题。

SVN很慢。接收和发送文件时做了很多工作。

处理包括复制数据多次：从networking缓冲区复制到程序的内存; 从程序的内存到出口的磁盘缓冲区; 从磁盘缓冲区到磁盘。至less有3个副本，如果开发人员不小心，可能会有更多副本（即从HTTPstream中提取数据，将其从SVN文件格式解码为普通数据等）。像cp / wget / rsync这样的程序是高度优化的，并试图做零拷贝…只是操纵数据。

我在猜测，但是… SVN的devise不是很快。它的devise是可靠的。因此，保持简单的事情（严格将数据复制到每个图层）比减less数据复制的复杂algorithm更为重要。

如果一个程序正在进行大量的预处理和后处理，那么一种方法就是如果“用户”时间很长。在你的例子中，用户时间为30％：真实1m40.768s用户0m48.885s sys 0m3.738s 48.885s约占总时间的31％。对于接收到的每个数据块来说，这是一个很大的处理过程。有48.2秒的时间下落不明。这是等待磁盘或networking的系统; 这可能表示您的存储器具有较慢的磁盘）。

与此相比，使用高度优化的“cp”命令复制大（1382445394字节或〜1.3G）文件：

 $ time cp bigfile.mp4 copyofbigfile.mp4 real 0m3.268s user 0m0.005s sys 0m0.994s

“用户”时间是0.005秒。这意味着“cp”基本上是设置了一堆参数，并让内核完成所有工作。几乎70％的时间都花在等待磁盘（这是我的笔记本电脑，所有的SSD）。

使用svn：协议而不是http：来获得更好的性能。这表明他们正在使用的HTTP库正在降低性能。原生协议更快是有道理的。

你原来的问题是“可以使用1Gb上行链路吗？我会推测答案是肯定的，但是你需要解决瓶颈问题。切换到SVN协议是一个不错的第一步。它看起来像更快的CPU或更快的RAM也会有所帮助。

这是我对1个文件的build议。如果涉及多个文件，那么你有一个不同的问题。在文件之间SVN做其他处理。这可能是CPU绑定的，但也可能是磁盘绑定（如果它正在等待文件fsync（），然后移动到下一个文件）。这是一套完整的基准和分析performance。