是否可以利用 1 Gb 上行链路？我有 2 台服务器，上行链路均为 1 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
一些基本测试
# 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
如有任何建议，我们将不胜感激。
更新1
如你所见，速度大约是 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
更新2 相同的文件，但通过 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
结账时系统加载
# 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
答案1
我们对您的颠覆测试了解甚少，无法回答这个问题。提交 test.img 后，尝试从存储库下载它，它应该完全满足您的连接要求。我猜您在尝试克隆存储库时进行测量，该存储库通常由许多单独的小文件表示，因此需要许多连接，从而减慢传输速度。
答案2
因为您可以通过仅网络基准测试获得良好的速度，所以问题似乎出在 SVN 本身。
SVN 很慢。它在接收和发送文件时做了很多工作。
处理过程涉及多次复制数据：从网络缓冲区复制到程序内存；从程序内存复制到传出磁盘缓冲区；从磁盘缓冲区复制到磁盘。这至少需要 3 次复制，如果开发人员不小心，可能会有更多次复制（即从 HTTP 流中提取数据、将其从 SVN 文件格式解码为纯数据等）。cp/wget/rsync 等程序经过高度优化，并尝试执行零复制... 只需就地操作数据即可。
我猜测，但是……SVN 的设计目的不是速度快。它的目的是可靠。因此，保持简单（严格将数据复制到每一层）比减少数据复制的复杂算法更重要。
判断程序是否在进行大量预处理和后处理的一种方法是“用户”时间是否很长。在您的示例中，用户时间占总时间的 30%：实际 1m40.768s 用户 0m48.885s 系统 0m3.738s 48.885s 约占总时间的 31%。对于收到的每个数据块，这需要进行大量处理。有 48.2 秒的时间没有被记录下来。这是系统在等待磁盘或网络；这可能表明您的存储磁盘速度很慢）。
与使用高度优化的“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 库正在降低性能。本机协议更快是有道理的。
您最初的问题是“是否可以利用 1 Gb 上行链路？”我猜测答案是“可以”，但您需要解决瓶颈问题。切换到 SVN 协议是一个很好的第一步。看起来更快的 CPU 或更快的 RAM 也会有所帮助。
这是我针对 1 个文件的建议。如果涉及多个文件，那么您会遇到不同的问题。在文件之间，SVN 会进行其他处理。这可能是 CPU 限制，但也可能是磁盘限制（如果它在移动到下一个文件之前等待文件 fsync()）。这是一组完全不同的基准测试和分析。