SFTP na gigabitu jen 10-14 MB/s

[rado3105]

sftp, scp ide na 1gbitovom pripojeni len 10-14MB/s, iperf ukazuje 666mbit/s. Neviete kde je problem? ci to je vytazenostou cpu? ftp ide ale taktiez len okolo 20MB/s..
je to protokolom? je nejaky protokolo kde by to slo rychlejsie....? spojene su dva pc gigabitovym pripojenim....ethtool ukazuje v oboch zariadeniach gigabitove spojenie....
vdaka

[Reklama]

[RDa]

Nekdy zalezi na disku, a pak dost casto na smeru - u me je kopirovani stejny smerem takto: storage cte od uploaderu pres nfs 45MB/s, ale kdyz uploader zapisuje na storage tak to jede nekdy 3, nekdy 12, nekdy 30MB/s... pritom tam nejsou paralelni pristupy. Omezenim v poli to neni, lokalne to zvlada pres 100MB/s.

[rado3105]

disky na oboch pc maju zapis minimalne 60mbyte/s...
nfs ide cez udp....teda aspon starsie verzie....

ma niekto server a ide mu kopirovanie rychlejsie, ako najrychlejsie, aky protokol?

[RDa]

Namatkove, cteni z meho NFS storage:

$ dd if=*****.avi  bs=1M of=/dev/null
393+1 records in
393+1 records out
412649660 bytes (413 MB) copied, 6.1934 s, 66.6 MB/s



Lokalne to jede samozrejme omnoho lepe (6x3TB,Raid5): hdparm -t /dev/md0
/dev/md0:
 Timing buffered disk reads: 1444 MB in  3.00 seconds = 481.13 MB/sec

Pres FS:
d if=****.ts bs=1M of=/dev/null
3466+1 records in
3466+1 records out
3635271212 bytes (3.6 GB) copied, 8.96154 s, 406 MB/s


Pokud se jedna o 1Gb propoj, predpokladam ze je to LAN. Je nutne pro LAN pouzivat FTP?? protoze neprijde me, ze to ma nejake specialni vyhody, spis to ma mnoho nevyhod. Proto provozuji NFS(lin server+client) + Sambu(lin server/win client)

[PanKapitanRUM]

Pro info:

Je tu hrozně málo informací

Proč to třeba jede pomalu:
-nějaké CPU nestíhá podávat data (nízký výkon jednoho CPU)
-je problém s ovladačem třeba síťové karty  (defaultní ovladač dělá kraviny)
-je tam nějaký firewall, který provoz brzí (nejspíš bude jeden stroj Widle a brzdí to)
-síťovka může být připojená přes PCI rozhraní a pokud se perou IRQ, dělá to bordel: http://cs.wikipedia.org/wiki/PCI_(sb%C4%9Brnice)
....těch problémů tam může být hromada.

[Reklama]

[PanKapitanRUM]

Reklamy Google

クラウドの日立システムズ
ITライフサイクルの全領域を支援。 IT最新事例、セミナー、サービス hitachi-systems.com

Jak ten počítač poznal, že se chci začít učit Japonsky, to je mi vážně záhada!

[RDa]

U me dela iperf 595 resp 586 mbit/s ... takze NFS jede tak jak jen muze.

U tazatele bych zkusil jine zpusoby prenosu (sftp/http/nfs/samba) pripadne jine disky (nasdilet /dev/shm), aby se nasel ten bottle-neck. Dobrym nastrojem je taky nejake monitorovani (gkrellm) - cpu/load/sitovka a pod. Dava to rychle vedet kde je neco spatneho.

[rado3105]

Kopirovanie je z debiana na archlinux.
Procesor ide na serveri okolo 30%, na klientskom okolo 70% pri kopirovani zo samby...(rychlost ako pri ftp - 20MB/s)...

[rado3105]

server:
eth1      Link encap:Ethernet  HWaddr 64:70:02:10:1e:92 
          inet addr:10.1.1.1  Bcast:10.1.1.31  Mask:255.255.255.224
          inet6 addr: fe80::6670:2ff:fe10:1e92/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:24019963 errors:0 dropped:5 overruns:0 frame:0
          TX packets:77594247 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3886335660 (3.6 GiB)  TX bytes:1539657825 (1.4 GiB)
          Interrupt:20 Base address:0x6000

klient:
sudo ifconfig enp2s0
enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.1.1.14  netmask 255.255.255.224  broadcast 10.1.1.31
        inet6 fe80::20a:e4ff:fe39:dffd  prefixlen 64  scopeid 0x20<link>
        ether 00:0a:e4:39:df:fd  txqueuelen 1000  (Ethernet)
        RX packets 6742635  bytes 10046678933 (9.3 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1391643  bytes 121419857 (115.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16 

[lons]

toto je stara znama vec o SSH, riesenie: High Performance SSH/SCP - HPN-SSH patchset

[PanKapitanRUM]

toto je stara znama vec o SSH, riesenie: High Performance SSH/SCP - HPN-SSH patchset

No vidíš, máš pravdu, když jsem ožralej nevidím všechna písmenka.
Viděl jsem FTP a SCP, SCP mě netrápilo, protože to pomalu jezdí.
Nj  míň chlastat...

[rado3105]

Existuje nejaky protokol ktory dosiahne vysoku rychlost bez aplikovania patchov do jadra? co som zatial nasiel tak rcp....len s tym mam problem rozbehat to....

[Mirek Prýmek]

Existuje nejaky protokol ktory dosiahne vysoku rychlost bez aplikovania patchov do jadra? co som zatial nasiel tak rcp....len s tym mam problem rozbehat to....

To bys asi musel napsat, o co přesně ti jde, jaký má být účel. Vyladění síťové propustnosti je dost komplexní záležitost, vyžaduje to hodně znalostí a hodně detailního ladění. Hraje tam roli rychlost disku, síťové prvky po cestě, protokol, síťová karta, její ovladače, její nastavení (různé ty offloadingy, jumbo framy a podobná magie), OS, přerušení, celkové vyladění železa na maximální propustnost...

Jestli ti jde jenom o kopírování soborů mezi dvěma počítači, tak se na to vyprdni, protože to budeš měsíc zkoumat a ve finále s trochou štěstí dosáhneš zrychlení o 5% a dál ani ránu, protože to třeba brzdí ne úplně kvalitní switch nebo ne úplně dobře napsaný ovladač karty...

[ondro]

Kopirovanie je z debiana na archlinux.
Procesor ide na serveri okolo 30%, na klientskom okolo 70% pri kopirovani zo samby...(rychlost ako pri ftp - 20MB/s)...

70% je vela, problem je vo vykone CPU.  CPU nestiha spracovavat data. Aky tam mas CPU?  Sietovy prenos je celkom narocny ykon CPU. Samozrjeme smejd sietovka mu v tom ani trochu nepomoze

[Mirek Prýmek]

70% je vela, problem je vo vykone CPU.  CPU nestiha spracovavat data. Aky tam mas CPU?  Sietovy prenos je celkom narocny ykon CPU. Samozrjeme smejd sietovka mu v tom ani trochu nepomoze

Pokud je to při sftp, tak se není čemu divit, to šifrování taky něco stojí...