ti-enxame.com

Por que essa conexão de rede é tão lenta?

Estou tendo alguns problemas com a velocidade de desempenho da rede em um servidor Linux executando o Ubuntu 9.10. As velocidades de transferência em todos os tipos de tráfego são de cerca de 1,5 MB/s em uma conexão Ethernet com fio de 1000 MBit/s. Este servidor atingiu 55 MB/s sobre o samba no passado recente. Não mudei o hardware ou a configuração da rede. Eu executo atualizações regularmente e os melhores e mais recentes repositórios do Ubuntu estão rodando nesta máquina.

Configuração de hardware

Desktop PC com Windows - switch 1000 - switch 1000 - servidor Linux

Todos os switches são netgear e todos eles mostram uma luz verde para suas conexões, o que significa que a conexão é de 1000mbit/s. As luzes ficam amarelas quando a conexão é de apenas 100mbit/s. Outras informações de diagnóstico:

[email protected]:~# 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)


[email protected]:~# 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

[email protected]:~# mii-tool
eth0: negotiated 1000baseT-FD flow-control, link ok

O servidor acha que tem uma conexão de 1000mbit/s. Testei a velocidade de transferência copiando arquivos usando o Samba. Também usei o netcat (nc target 10000 <aBigFile) no servidor para transferir para o Windows (nc -l -p 10000) e vi níveis semelhantes de desempenho ruim.

Testei a velocidade dos discos rígidos usando hdparm e obtive:

[email protected]:~# 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

Ler o mesmo arquivo para transferência usando DD produziu o seguinte:

[email protected]:/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

Eu estou perplexo. O que pode estar causando o mau desempenho da rede, que é 2 ordens de magnitude menor do que a rede é capaz?

11
Paul Keeble

Em minha experiência profissional, tenho lutado para obter um bom desempenho de rede sólido com Samba no GNU/Linux. Você mencionou que atingiu velocidades de 55 MBps com ele, o que eu acredito, então acho que algo mais está definitivamente em jogo.

No entanto, você tentou NFS, FTP e SCP? Os problemas de largura de banda são consistentes nos diferentes protocolos? Em caso afirmativo, provavelmente se restringe à conexão física. Se você obtiver resultados inconsistentes, provavelmente é um problema de software.

Além de testar os outros protocolos, você está usando criptografia na transferência? Por exemplo, usando rsync -z é ótimo para habilitar a compactação, mas tem um custo de CPU, que afeta seriamente a velocidade geral da transferência. Se estiver usando SSH com rsync, então você tem criptografia no topo da compressão e sua CPU estará sob um pouco de estresse, causando graves penalidades de velocidade.

6
Aaron Toponce

Algumas coisas que você deve considerar verificar:

  1. Duplex - se um lado pensa que o link é full duplex e o outro lado pensa que o link é half duplex, espere mal.
  2. Interruptor com defeito? Ignore isso/eles.
  3. Quadros Jumbo. O MTU de 9000 bytes diminui a sobrecarga, o que deve aumentar a taxa de transferência (perdendo um pouco de latência). Parece que seu problema é tão grave que isso não vai ajudar.
  4. Recursos do TCP: ECN, SACK, alg de controle de congestionamento
  5. Tamanhos de janela de envio/recebimento TCP ( detalhes para linux )

netperf é ótimo para solucionar problemas de desempenho de rede. Mas o netcat não é ruim em apuros.

6
Brian Cain
  1. Experimentar netstat -i e procure por erros rx/tx.
  2. Experimentar netstat -s e procure por problemas de tcp - compare os valores antes e depois da cópia do arquivo e procure por grandes picos em reinicializações ou retransmissões.
2
Rafael Ferreira

Você pode verificar o congestionamento de sua rede; talvez alguns outros dispositivos estejam consumindo toda a sua largura de banda?

Além disso, talvez algo esteja errado com sua interface de rede e/ou seu driver. Bem estranho.

0
pmalmsten

Se possível, para remover a maioria das dúvidas de que é realmente um problema de sistema operacional/driver/placa, conecte os computadores juntos usando um cabo cruzado. Isso removerá o switch e outros possíveis problemas de rede de sua equação.

0
Stephen Jazdzewski