PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Samba Problem: Schreiben langsam, Lesen schnell



Felix-Wombat
22.01.12, 16:31
Hallo zusammen,

habe mich soeben hier angemeldet um oben kurz genanntes Problem mit Euch zu diskutieren. Habe schon einen Beitrag dazu gefunden, jedoch ist da keine Lösung enthalten.

Problembeschreibung:

Ich habe einen kleinen Desktop Rechner (Fujitsu Siemens C610) als Server in meinem Netzwerk laufen. Betriebssystem ist Linux Mint 11 (LXPE). Läuft soweit auch richtig gut. Nur bei dem Samba-Server gibt es das Problem der Dateiübertragung. Der Server hängt in einem 1000er LAN und meine Workstation ebenfalls. Zumindest dort sollten gut Übertragungsraten möglich sein (NetGear Switch).

Festplatte (WD Studio II Raid 1 2x 2000 GB) über FireWire 400 angeschlossen (an Soundkarte)


Das Lesen vom Server über Samba läuft mit durchschn. 30 MByte/s
-> Transferrate ist auch konstant und schwankt NICHT

Das Schreiben auf den Server über Samba läuft mit 2-3 MByte/s
-> Transferrate schwankt extrem (TaskManager-Anzeige teilweise auf 0%) -> siehe Anhang

Wenn ich im Netzwerk von meiner Workstation auf einen anderen PC etwas schreibe, geht das mit voller Leistung des 100 MBits Lans (der andere Rechner hat nur eine 100er Karte). Also immernoch schneller als das Schreiben auf den Linux Rechner.

Habe nun schon einmal probiert für die Netzwerkkarte des Servers (Intel 82547) den neuen Treiber zu installieren, das hat aber leider auch nichts geholfen.

NETIO sagt:



TCP connection established.
Packet size 1k bytes: 54.49 MByte/s Tx, 53.04 MByte/s Rx.
Packet size 2k bytes: 52.58 MByte/s Tx, 52.95 MByte/s Rx.
Packet size 4k bytes: 74.18 MByte/s Tx, 54.21 MByte/s Rx.
Packet size 8k bytes: 90.50 MByte/s Tx, 55.52 MByte/s Rx.
Packet size 16k bytes: 91.92 MByte/s Tx, 56.35 MByte/s Rx.
Packet size 32k bytes: 96.41 MByte/s Tx, 56.56 MByte/s Rx.
Done.

UDP connection established.
Packet size 1k bytes: 50.30 MByte/s (0%) Tx, 40.00 MByte/s (44%) Rx.
Packet size 2k bytes: 30.21 MByte/s (0%) Tx, 35.30 MByte/s (51%) Rx.
Packet size 4k bytes: 44.88 MByte/s (0%) Tx, 14.19 MByte/s (87%) Rx.
Packet size 8k bytes: 61.35 MByte/s (0%) Tx, 996.74 KByte/s (99%) Rx.
Packet size 16k bytes: 62.51 MByte/s (0%) Tx, 105.08 KByte/s (99%) Rx.
Packet size 32k bytes: 75.08 MByte/s (0%) Tx, 21.28 KByte/s (99%) Rx.
Done.



ethtool sagt:



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 pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: umbg
Wake-on: umbg
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes



smb.conf sieht wie folgt aus, auch hier habe ich schon viel anhand von Tipps ausprobiert.



[global]
log file = /var/log/samba/log.%m
profile acls = yes
passwd chat = *new*password* %n\n *new*password* %n\n *changed*
socket options = TCP_NODELAY
#logon drive = H:
map to guest = bad user
interfaces = 192.168.1.101/255.255.255.0 # eth0
encrypt passwords = yes
passdb backend = tdbsam
nt acl support = yes
logon home = \\%N\%U # L bzw N
netbios name = felix-srv
server string = %h
#logon script = logon.cmd
winbind enum users = no
unix password sync = yes
local master = yes
logon path = \\%N\%U\profile
workgroup = WORKGROUP
update encrypted = yes
syslog = 0
security = user
passwd program = /usr/bin/passwd %u
wins support = yes
panic action = /usr/share/samba/panic-action %d
max log size = 4096
obey pam restrictions = yes

#performnce
socket options = TCP_NODELAY IPTOS_LOWDELAY
read raw = yes
write raw = yes
oplocks = yes
max xmit = 65535
dead time = 15
getwd cache = yes
lpq cache = 30



Vielleicht fällt ja jemandem noch etwas hilfreiches ein. Bin dankbar für jeden Tipp.

Vielen Dank und Grüße

Felix

DrunkenFreak
22.01.12, 16:35
Um die Festplatten auszuschließen, könntest du mit sar mal gucken, was die Auslastung während der Übertragung macht. Gleiches gilt auch für die CPU und andere Prozesse. Kann sein, dass der Rechner einfach am Limit hängt beim Schreiben.

Sebastian Henrich
02.02.12, 18:15
Leg mal lokal auf dem Server im selben Verzeichnis wie die Samba Freigabe eine 1 GB große Datei mit dd an:

dd if=/dev/zero of=/tmp/test.dd bs=1M count=1000
Die Ausgabe von dd zeigt Dir wie lange der Server gebraucht hat und wie hoch die Schreibrate war. Wenn der Wert in Ordnung ist, kannst Du die Platten als Fehlerquelle ausschließen.

Verschlüsselst Du die Daten auf dem Server?

Felix-Wombat
21.02.12, 19:03
Leg mal lokal auf dem Server im selben Verzeichnis wie die Samba Freigabe eine 1 GB große Datei mit dd an:

dd if=/dev/zero of=/tmp/test.dd bs=1M count=1000
Die Ausgabe von dd zeigt Dir wie lange der Server gebraucht hat und wie hoch die Schreibrate war. Wenn der Wert in Ordnung ist, kannst Du die Platten als Fehlerquelle ausschließen.

Verschlüsselst Du die Daten auf dem Server?

So! Es gibt Neuigkeiten. Ich hab den Befehl mit dd mal ausprobiert und siehe da, auch so lahm wie über Samba (siehe unten). Die Festplatte alleine kann nicht der Flaschenhals sein, da sie an anderen Systemen prima läuft. Vielleicht liegt es an dem Firewire Controller oder der Systemplatte. Diese stellt nämlich ein 16GB Flashspeicher dar. Wäre nur etwas unlogisch, denn was hat die Platte mit dem Transfer auf eine externe HDD zu tun?

Ich probiere nun mal die Externe über USB anzuschließen. Da müssten ja min. 30 MB mögl. sein.



1000+0 Datensätze ein
1000+0 Datensätze aus
1048576000 Bytes (1,0 GB) kopiert, 481,975 s, 2,2 MB/s


EDIT: Die Daten sind NICHT verschlüsselt!


EDIT2:

Also habe mal über USB getestet und dort kommt in etwa das Gleiche bei rum.

Der 16GB Compactflashspeicher bringt:


1048576000 Bytes (1,0 GB) kopiert, 29,1853 s, 35,9 MB/s


Daran kann es also auch nicht liegen. Wenn Firewire und USB so lahm ist, kann es dann vielleicht an irgendeinem Treibermodul liegen, was auf den PCI-Bus geht? USB hängt da ja auch dran oder nicht?

Danke und Grüße Felix

Sebastian Henrich
21.02.12, 21:41
Kannst Du die Tests mit dd mal an einem anderen PC bzw. mit einer anderen externen Festplatte machen? Nicht das die Festplatte eine Macke hat. Hast Du geprüft ob die Firmware des My Book Studio II aktuell ist. Laut den Release Notes (http://support.wdc.com/download/notes/Win_Univ_FW_Updater_31011_ReleaseNotes.pdf) sind mehrfach USB Kompatibilitätsprobleme gefixt worden.

Felix-Wombat
21.02.12, 22:47
Kannst Du die Tests mit dd mal an einem anderen PC bzw. mit einer anderen externen Festplatte machen? Nicht das die Festplatte eine Macke hat. Hast Du geprüft ob die Firmware des My Book Studio II aktuell ist. Laut den Release Notes (http://support.wdc.com/download/notes/Win_Univ_FW_Updater_31011_ReleaseNotes.pdf) sind mehrfach USB Kompatibilitätsprobleme gefixt worden.

Ja das Firmware Update habe ich gerade gemacht, nachdem ich zuvor voller entsetzen die langsame Schreibrate auch über eSATA an meinem Windows PC feststellen musste. Das muss wohl in den letzten Monaten passiert sein. Scheint demnach ein Defekt zu sein und ich habe bei WD schon ein RMA Vorgang ausgelöst mit einem Austausch.

Vielen Dank dennoch für Eure Mühe. Hätte ich nicht gedacht, dass es an der Platte liegen würde.

Grüße Felix

Sebastian Henrich
21.02.12, 22:48
Viel Erfolg beim Umtauschen!