Sabemos muito pouco sobre o seu teste de subversão para responder à pergunta. Tente baixar o test.img do repositório depois que você o tiver confirmado, ele deve satisfazer totalmente sua conexão. Meu palpite é que você está medindo ao tentar clonar um repositório que normalmente é representado com muitos pequenos arquivos individuais, tornando assim muitas conexões necessárias e, assim, tornando mais lenta a transferência.
Subversion em uplink de 1 Gb
1
é possível usar o uplink de 1 Gb? Tenho 2 servidores com 1 Gb uplink
176.9.xxx.xxx - servidor
# 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 - cliente
# 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
Alguns testes básicos
# 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
Ao mesmo tempo, quando eu faço o download de algum projeto do svn, a velocidade do http é de cerca de 100 Mbit / s no máximo. Mas um arquivo binário simples foi baixado na velocidade máxima
# 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
Qualquer conselho seria muito apreciado.
Update1
Como você vê, a velocidade é de cerca de 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
Update2Omesmoarquivo,masviaprotocolosvn,avelocidadeemtornode250Mbit/s
#timesvncosvn://svn.example.net/./Test/ATest/test.imgCheckedoutrevision1.real0m46.075suser0m15.338ssys0m4.811sCarga do sistema durante o checkout
# 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
por ALex_hha
01.02.2014 / 14:40
2 respostas
0
por
01.02.2014 / 14:45
0
Como você pode obter boa velocidade com benchmarks somente de rede, parece que o problema é o próprio SVN.
O SVN é lento. Ele faz muito trabalho ao receber e enviar um arquivo.
O processamento envolve copiar os dados várias vezes: copiar do buffer de rede para a memória do programa; da memória do programa para um buffer de disco de saída; de um buffer de disco para o disco. Isso é pelo menos 3 cópias e se o desenvolvedor não tiver cuidado, pode haver mais cópias (ou seja, extrair os dados do fluxo HTTP, decodificá-los do formato de arquivo SVN em dados simples, etc). Programas como cp / wget / rsync são altamente otimizados e tentam fazer cópias zero ... apenas manipular os dados no lugar.
Estou especulando, mas .... O SVN não foi projetado para ser rápido. Foi projetado para ser confiável. Portanto, manter as coisas simples (copiar os dados estritamente em cada camada) é mais importante do que algoritmos complexos que reduzem a cópia de dados.
Uma forma de saber se um programa está fazendo muito pré e pós-processamento é se o tempo de "usuário" é alto. No seu exemplo, o tempo do usuário foi 30% do tempo: 1m40.768s reais usuário 0m48.885s sys 0m3.738s 48.885s é aproximadamente 31% do tempo total. Isso é muito processamento para cada bloco de dados recebidos. Há 48,2 segundos de tempo não contabilizados. Este é o sistema que espera por disco ou rede; o que poderia indicar que seu armazenamento tem discos lentos).
Compare isso com a cópia de um arquivo grande (1382445394 bytes ou ~ 1.3G) usando o comando "cp" altamente otimizado:
$ time cp bigfile.mp4 copyofbigfile.mp4
real 0m3.268s
user 0m0.005s
sys 0m0.994s
O tempo do "usuário" é de 0,005s. Isso significa que "cp" é basicamente configurar um monte de parâmetros e deixar o kernel fazer todo o trabalho. Quase 70% do tempo é gasto esperando pelo disco (e isso está no meu laptop com todos os SSDs).
Você obtém um desempenho melhor usando o protocolo svn: em vez de http :. Isso indica que a biblioteca HTTP que eles estão usando está reduzindo o desempenho. Faz sentido que o protocolo nativo seja mais rápido.
A sua pergunta original era "é possível utilizar o uplink de 1 Gb?" Eu especularia que a resposta é "sim", mas você precisará corrigir o gargalo. Mudar para o protocolo SVN é um bom primeiro passo. Parece que a CPU mais rápida ou a RAM mais rápida ajudaria também.
Essa é a minha recomendação para um arquivo. Se houver vários arquivos envolvidos, você terá um problema diferente. Entre os arquivos, o SVN faz outro processamento. Isso pode estar ligado à CPU, mas também pode ser vinculado ao disco (se estiver aguardando o arquivo para fsync () antes de ir para o próximo arquivo). Esse é um conjunto totalmente diferente de benchmarks e análises para realizar.
por
01.02.2014 / 16:54
Tags svn apache-2.2