Bu ağ bağlantısı neden bu kadar yavaş?


11

Ubuntu 9.10 çalıştıran bir Linux sunucusunda ağ performans hızı ile ilgili bazı sorunlar yaşıyorum. Tüm trafik türlerindeki aktarım hızları 1000mbit / s kablolu ethernet bağlantısında yaklaşık 1,5 MB / sn'dir. Bu sunucu yakın geçmişte samba üzerinden 55MB / s'ye ulaştı. Donanım veya ağ kurulumunu değiştirmedim. Güncellemeleri düzenli olarak çalıştırıyorum ve Ubuntu'nun depolarından en son ve en iyisi bu makinede çalışıyor.

Donanım Kurulumu

Masaüstü Windows PC - 1000 anahtarı - 1000 anahtarı - Linux sunucusu

Tüm anahtarlar netgeardır ve hepsi bağlantıları için yeşil bir ışık gösterir, bu da bağlantının 1000mbit / s olduğu anlamına gelir. Bağlantı sadece 100mbit / s olduğunda ışıklar sarıdır. Diğer teşhis bilgileri:

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

Sunucu 1000mbit / s bağlantıya sahip olduğunu düşünüyor. Samba kullanarak dosyaları kopyalayarak aktarım hızını test ettim. Ayrıca Windows'a (nc -l -p 10000) aktarmak için sunucuda netcat (nc target 10000 <aBigFile) kullandım ve benzer düşük performans seviyeleri gördüm.

Sabit disklerin hızını hdparm kullanarak test ettim ve aldım:

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

Aynı dosyayı DD kullanarak aktarmak için okumak aşağıdakileri üretti:

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

Çok üzüldüm. Ağın kapasitesinden 2 büyüklükte daha düşük olan düşük ağ performansına ne sebep olabilir?


serverfault muhtemelen bu tür sorular sormak için daha iyi bir yerdir.
Maciej Piechotka

Yavaş bir ağ bağlantısı sorunlarını gidermek için yararlı olan genel teknikler için bu ServerFault sorusunu deneyin .

Hiçbir şey değişmezse, aşınma ve yıpranmayı (kablolar) suçlayın.
Mel

Yanıtlar:


6

Kontrol etmeyi düşünmeniz gereken bazı şeyler:

  1. Çift Taraflı - bir taraf bağlantının tam çift yönlü olduğunu ve diğer taraf bağlantının yarı çift yönlü olduğunu düşünüyorsa, kötülük bekleyin.
  2. Arızalı anahtar? Baypas et.
  3. Jumbo çerçeveler. 9000 bayt MTU yükü azaltır, bu da verimi arttırır (biraz gecikmeyi kaybeder). Sorununuz o kadar kötü görünüyor ki, bu yardımcı olmaz.
  4. TCP özellikleri: ECN, SACK, tıkanıklık kontrolü alg
  5. TCP Gönderme / Alma penceresi boyutları ( linux için ayrıntılar )

netperf ağ performansında sorun gidermede harikadır. Ama netcat bir tutamda kötü değil.


6

Profesyonel deneyimlerime göre, GNU / Linux üzerinde Samba ile iyi bir ağ performansı elde etmek için mücadele ettim. Bununla birlikte 55 MBps hıza ulaştığınızı söylemiştiniz, bu yüzden sanırım başka bir şey kesinlikle oyunda.

Ancak, NFS, FTP ve SCP'yi denediniz mi? Bant genişliği sorunları farklı protokollerde tutarlı mı? Eğer öyleyse, muhtemelen fiziksel bağlantıya daralmıştır. Tutarsız sonuçlar alırsanız, bu muhtemelen bir yazılım sorunudur.

Diğer protokolleri test etmenin yanı sıra, aktarımda şifreleme mi kullanıyorsunuz? Örneğin, rsync -zsıkıştırmayı etkinleştirmek için kullanmak tatlıdır, ancak aktarımın genel hızını ciddi şekilde etkileyen bir CPU maliyetiyle gelir. Kullanılıyorsa SSHile rsync, o zaman sıkıştırma üstünde şifreleme var ve CPU şiddetli hız cezaları neden stres biraz altında olacak.


2
  1. Deneyin netstat -ive rx / tx hataları arayın.
  2. netstat -sTcp sorunlarını deneyin - dosya kopyalamadan önce ve sonra değerleri karşılaştırın ve sıfırlamalarda veya yeniden iletimlerde büyük ani artışlar arayın.

Ne yazık ki 100MB'den sonra hiç TX / RX hatası yok ve sıfırlama sayısı testin başlangıcından sonuna kadar sürekli olarak 4 oldu
Paul Keeble

0

Ağınızın tıkanıklığını kontrol edebilirsiniz; belki diğer bazı cihazlar tüm bant genişliğinizi tüketiyor?

Bunun ötesinde, ağ arayüzünüzde ve / veya sürücüsünde bir sorun olabilir. Oldukça garip.


Test sırasında bunlar ağdaki sadece iki cihazdı, başka bir şey yoktu.
Paul Keeble

0

Mümkünse, bunun aslında bir OS / sürücü / kart sorunu olduğundan şüphe duymak için, çapraz kablo kullanarak bilgisayarları birbirine bağlayın. Bu, anahtarı ve diğer olası ağ sorunlarını denkleminizden kaldıracaktır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.