Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: rado3105 01. 03. 2013, 23:05:47
-
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
-
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.
-
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?
-
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)
-
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.
-
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!
-
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.
-
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)...
-
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
-
toto je stara znama vec o SSH, riesenie: High Performance SSH/SCP - HPN-SSH patchset
-
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...
-
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....
-
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...
-
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
-
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í...
-
A ještě ze samby ... ono, když se to nasčítá, tak to odpovídá ... ještě hloupý dotaz, kabel máš také gigabitový? :-D
-
Když už jsme u toho - možná to i souvisí, mám Mint 14 (Ubuntu 12.10) a ve FUSE je nějaký bug, kdy při připojení např. přes smb to jede cca poloviční rychlostí a přenosy se i zasekávají, podobné sftp. A to i při připojení přes n- wifi, FUSE 6MB/s, cifs asi 11MB/s. Připojuji se proto skriptem přes cifs, sshfs a tam je vše ok.