Samba(NFS auf einem Client langsam

uzumakinaruto

uzumakinaruto

Tripel-As
Hi,

ich habe ein wirklich sonderbares phänomen.

smb/nfs ist auf einem client verdammt langsam.
wenn ich wireshark starte um zu gucken warum ist es wieder normal.
aber ich sehe dabei auch das einige fragmente verloren gehen.

an der firewall kann es nicht liegen, die habe ich auch mal ausgeschaltet und es bleibt weiterhin so (smb/nfs habe ich dort auch nicht eingeschränkt)

wenn ich über sftp dateien übertrage geht das ratz-fatz (auch ohne wireshark)
ich kann mir das nicht erklären.

am server kann es nicht liegen, da andere clients im netzwerk nicht das problem haben.
an meinem pc kann es auch nicht liegen, da ja sftp immer schnell überträgt und smb im zusammenhang mit wireshark.

der smb log ist leider überhaupt nicht aussagekräftig.

über hilfreiche kommentare bin ich dankbar
 
Wenn du die Server über Namen und nicht über IPs ansprichst, dann prüfe mal, ob die Verbindung zum DNS ok ist. Ich hatte ein ähnliches Problem auch schonmal und da half es dann im Endeffekt die angesprochenen Hostnamen/Domains in der hosts-Datei einzutragen (bei Windows-Clients in %SystemRoot%\system32\drivers\etc\hosts zu finden). Evtl. kann auch eine statisch gesetzt Route Abhilfe schaffen. Ist das Problem eigentlich nur weg, wenn du Wireshark nutzt oder verschwindet es auch bei tcpdump? Läuft die Netzwerkkarte evtl. im promiscuous-Modus?
 
wenn wireshark an ist läuft sie im promiscuous modus .. macht das programm ja von alleine.
dns ist okay, forward und reverse lookups funktionieren in alle richtungen.

achso .. es ist ein multiboot system ... smb = windows .. nfs = ubuntu

und ich verwende immer den namen des servers, ob bei nfs, smb oder sftp
aber unter windows habe ich es auch schon über die ip probiert, selbes problem
mit und ohne gemaptes laufwerk.

ich kann mir darauf keinen reim machen. sftp macht an sich ja nichts anders, aber wieso ist es DORT schneller als unter smb/nfs?
 
Naja, SFTP macht schon einiges anders als SMB und NFS. So wird z.B. eine Art SSH-Tunnel für die Übertragung verwendet, der während der gesamten Übertragung bestehen bleibt, während bei NFS und SMB bei jeder Anfrage eine neue Verbindung aufgebaut werden muss. Deswegen wirken sich ja auch DNS-Probleme so negativ auf diese beiden Protokolle aus.
 
es scheint irgendwie was mit der nic zu tun zu haben. ich habe das mal mit netio getestet

test mit netio - [xp- debian-server] clients waren der netio server

mein Client - tcp (onboard - 100 MBit)
Code:
TCP connection established.
Packet size  1k bytes:  2152 KByte/s Tx,  5410 KByte/s Rx.
Packet size  2k bytes:  1548 KByte/s Tx,  5464 KByte/s Rx.
Packet size  4k bytes:  1265 KByte/s Tx,  4705 KByte/s Rx.
Packet size  8k bytes:  1096 KByte/s Tx,  4422 KByte/s Rx.
Packet size 16k bytes:  976 KByte/s Tx,  4254 KByte/s Rx.
Packet size 32k bytes:  2015 KByte/s Tx,  4475 KByte/s Rx.

UDP connection established.
Packet size  1k bytes:  9044 KByte/s (20%) Tx,  6747 KByte/s (0%) Rx.
Packet size  2k bytes:  53248 Byte/s (99%) Tx,  1787 KByte/s (0%) Rx.
Packet size  4k bytes:  0 Byte/s (100%) Tx,  4988 KByte/s (0%) Rx.
Packet size  8k bytes:  0 Byte/s (100%) Tx,  3440 KByte/s (0%) Rx.
Packet size 16k bytes:  0 Byte/s (100%) Tx,  3990 KByte/s (0%) Rx.
Packet size 32k bytes:  0 Byte/s (100%) Tx,  4008 KByte/s (0%) Rx.


mein Client - udp (pci - 1000 MBit) server war auch netio server
Code:
TCP connection established.
Packet size  1k bytes:  10045 KByte/s Tx,  11297 KByte/s Rx
Packet size  2k bytes:  8077 KByte/s Tx,  11511 KByte/s Rx.
Packet size  4k bytes:  6826 KByte/s Tx,  11389 KByte/s Rx.
Packet size  8k bytes:  5575 KByte/s Tx,  9579 KByte/s Rx.
Packet size 16k bytes:  4872 KByte/s Tx,  8655 KByte/s Rx.
Packet size 32k bytes:  4896 KByte/s Tx,  8245 KByte/s Rx.

UDP connection established.
Packet size  1k bytes:  3449 KByte/s (0%) Tx,  11464 KByte/s (0%) Rx.
Packet size  2k bytes:  2251 KByte/s (0%) Tx,  11496 KByte/s (0%) Rx.
Packet size  4k bytes:  2490 KByte/s (0%) Tx,  11686 KByte/s (0%) Rx.
Packet size  8k bytes:  2857 KByte/s (0%) Tx,  11666 KByte/s (0%) Rx.
Packet size 16k bytes:  3155 KByte/s (0%) Tx,  353 KByte/s (96%) Rx.
Packet size 32k bytes:  3102 KByte/s (0%) Tx,  0 Byte/s (100%) Rx.


anderer Client - tcp
Code:
TCP connection established.
Packet size  1k bytes:  11434 KByte/s Tx,  10680 KByte/s Rx.
Packet size  2k bytes:  11415 KByte/s Tx,  10166 KByte/s Rx.
Packet size  4k bytes:  11080 KByte/s Tx,  10768 KByte/s Rx.
Packet size  8k bytes:  11418 KByte/s Tx,  11412 KByte/s Rx.
Packet size 16k bytes:  11439 KByte/s Tx,  10606 KByte/s Rx.
Packet size 32k bytes:  11470 KByte/s Tx,  10744 KByte/s Rx.

UDP connection established.
Packet size  1k bytes:  11431 KByte/s (0%) Tx,  10913 KByte/s (0%) Rx.
Packet size  2k bytes:  11132 KByte/s (3%) Tx,  7018 KByte/s (0%) Rx.
Packet size  4k bytes:  11328 KByte/s (3%) Tx,  8591 KByte/s (0%) Rx.
Packet size  8k bytes:  11633 KByte/s (0%) Tx,  9506 KByte/s (0%) Rx.
Packet size 16k bytes:  11602 KByte/s (0%) Tx,  9982 KByte/s (0%) Rx.
Packet size 32k bytes:  11530 KByte/s (1%) Tx,  10349 KByte/s (0%) Rx.
 
Was bisher noch nicht zur sprache gekommen ist, das durch nfs bzw. Samaba immer etwas an Übertragungsgeschwindigkeit verloren geht ... das liegt in der Natur der Sache. Die Protokolle von NFS und SMB sind eben etwas dicker als wenn du nur mit scp die bits über den stream jagst. Deswegen hast du da auch Verlust bei der Übertragung.
Aber so viel sollte es nicht sein ... also 4 MB/s Verlust wäre schon hart :D
 
Schon mal einer daran gedacht einfach mal das Bios des rechner auf default zu stellen ? NIC nen schuss ?!
 

Ähnliche Themen

NFS (4) sehr langsam!

Zurück
Oben