PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Samba - schreiben auf share lzu langsam



Los_Andros
09.02.05, 21:45
Hallo,
ich habe hier einen Sambaserver aufgesetzt (SuSE 9.2 auf einem Pentium 233).

Eigentlich scheint alles zu gehen, aber das Schreiben auf die Files ist extrem langsam (mkdir dauert ca. 1 Minute)

Verbunden sind die Rechner über einen Switch in einem Netgear DSL Router.

So sieht meine smb.conf aus:


[global]
printing = cups
printcap name = cups
printcap cache time = 750
cups options = raw
printer admin = @ntadmin, root, administrator
map to guest = Bad User
security = user
workgroup = NET
interfaces = 192.168.0.3/255.255.255.0
encrypt passwords = Yes
os level = 2

[homes]
comment = Home Directories
valid users = %S
browseable = no
read only = no
inherit acls = yes

[users]
comment = All users
path = /home
read only = no
inherit acls = yes
veto files = /aquota.user/groups/shares/

[mp3]
comment = MP3s
path = /home/mp3
writeable = yes
valid users = @wg
force group = wg
read only = No
force directory mode = 0770


Ich verstehe es nicht, es ist einfach zu langsam!

Polarizer
10.02.05, 12:29
Was sagt denn die Ausgabe von ifconfig, viele Fehler oder Kollosionen?


RX packets:6156631 errors:0 dropped:0 overruns:0 frame:0
TX packets:6768325 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
Hast Du das Netzwerk mal mit netperf[1] durchgemessen?

[1] http://www.netperf.org/netperf/NetperfPage.html

---SonOfOdin---
10.02.05, 12:55
Stichwort: ntfs. Da war doch noch was ?!? :confused:

Los_Andros
10.02.05, 15:32
Ich weiß es jetzt nur noch aus dem Kopf, aber es sind keine dropped, keine kollisionen und keine Fehler.

@---SonOfOdin---
wie ntfs? Läuft doch auf einem Linuxrechner und ein Linuxrechner greift darauf zu.
Filesystem ist Reiserfs auf einem verschlüsseltem LVM

tictactux
10.02.05, 15:48
Also bei Verschlüsselung und Pentium 233MHz würde ich auf die CPU-Auslastung
während des Schreibens achten, und evtl. einen Test mit einem unverschlüsselten
Share auf dem gleichen Rechner machen. Verschlüsselung braucht CPU-Leistung..
Wie sieht's mit RAM-Ausstattung aus (wird geswappt) ?
Gruß,
Wolfgang

Los_Andros
11.02.05, 10:17
Das schau ich mir heute Abend nochmal an.
Wäre schade, wenn ich mein LVM nicht verschlüsseln könnte.

Los_Andros
12.02.05, 18:12
Also an der Verschlüsselung liegt es nicht.
CPU Auslastung ist nur nach der Passworteingabe hoch, dann konstant niedrig.

Das Schreiben auf den Share lokal geht wie gewohnt schnell, nur "remote" dauert es eine Ewigkeit.
Dabei bleibt aber die CPU Auslastung gewohnt niedrig.

Lokal:
andy@Samba:/home/mp3> time mkdir testdirlokal
real 0m0.021s
user 0m0.009s
sys 0m0.012s

Remote:
andy@andy:/media/mp3> time mkdir testdir
real 0m29.999s
user 0m0.001s
sys 0m0.001s

Ausgabe von ifconfig remote:
Samba:/home/mp3 # ifconfig
eth0 Protokoll:Ethernet Hardware Adresse 00:50:BF:98:D3:E6
inet Adresse:192.168.0.3 Bcast:192.168.0.255 Maske:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7870 errors:0 dropped:0 overruns:0 frame:0
TX packets:7454 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 Sendewarteschlangenlänge:1000
RX bytes:591776 (577.9 Kb) TX bytes:6622356 (6.3 Mb)
Interrupt:9 Basisadresse:0xf400

lo Protokoll:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 Sendewarteschlangenlänge:0
RX bytes:392 (392.0 b) TX bytes:392 (392.0 b)



Schaut alles vernünftig aus, aber irgendwas stimmt da nicht

troubadix
13.02.05, 12:23
Hi,

blöde Frage aber wieso nutzt Du von Linux zu Linux ein sambashare, ich verwende hier immer nfs??

troubadix

tictactux
13.02.05, 13:50
Also an der Verschlüsselung liegt es nicht.
Tja, dann würde ich systematisch die beteiligten Komponenten prüfen:
1. Netzwerkkarte: bringt die Karte im Server die erwartete Leistung mit
anderen Protokollen? Test: mit ftp, scp (oder auch wie Polarizer sagte:
netperf). Was für eine Karte ist es?
2. Dateisystem: sind keine "Extremfälle" gegeben (z.B: 100000 Dateien/
Verzeichnisse im betroffenen Verzeichnis)? Ist auch das Kopieren einzelner
großen Dateien mit Samba so langsam, oder ist das ein Overhead "per Zugriff"?

3. Namensauflösung von und zu dem Sambarechner. Gibt es evtl. Konflikte?
4. Hardwareprobleme allgemein: können z.B. DMA-Probleme bei gleichzeitiger
Aktivität von Netzwerk und IDE ausgeschlossen werden (s. log-Dateien)?

Konkreteres fällt mir leider nicht ein.
Gruß,
Wolfgang

Los_Andros
13.02.05, 17:42
@troubadix
1. Es sit noch ein Windowsrechner im Netz, deshalb geht eh nur Samba, aber trotzdem
2. Ich finde nfs ist nicht wirklich sicher und Samba bietet da mehr Möglichkeiten


@tictactux
DNS kann es nicht sein, da ich über /etc/hosts die Namen auflöse (im Netzwerk)
Es scheint Overhead pro Zugriff zu sein.
Irgendetwas scheint am Samba nicht zu passen.

Bei der Netzwerkkarte handelt es sich um eine:
Linksys NC100 Network


Tja, da werde ich jetzt wohl noch sehr lange suchen müssen

tictactux
13.02.05, 17:51
sieht aus, als sei das eine Karte für die mehrere Treiber in Frage kommen
(Tulip-Familie). Könnte man auch testen.
Allerdings würde ich als erstes (ich wiederhole mich ;) ), prüfen ob das
Verhalten samba-spezifisch ist, indem ich andere Protokolle teste.

Los_Andros
14.02.05, 10:43
Ich hab noch ne Standard Realtek Karte rumliegen, ich glaube die baue ich mal ein und teste erneut.
Bzw. wie / welchen Treiber kann ich anstelle dem vorhandenen wählen?

tictactux
14.02.05, 14:38
Welcher der tulip-Treiber am besten zu der Karte paßt kann ich lieder nicht
sagen (ich kenne sie nicht, hab die Info nur aus Google).
In der Beschreibung der verschiedenen Treiber steht meistens, für welche
Modelle man sie verwenden sollte (die Hilfe bei "make menuconfig" oder
in /usr/src/<kernel>/Documentation/networking bzw. drivers/net/tulip/).
Ich hab aber etliche tulip-Karten (SMC 10 und 100 MBit, sowie CARDBUS),
und weiß daher, daß es neben dem Modul tulip noch Sachen wie tulip_old, de4x5,
xircom_* gab.
Normalerweise würde ich von einer tulip-Karte weniger Probleme als einer
Realtek erwarten..

Los_Andros
17.02.05, 21:05
AAAALLLLLLLLSSSSSSSSOO,
geht immer noch nicht.

Habe folgendes versucht:
lokal smbmount am Sambaserver:
Samba:/tmp # mount -t smbfs //localhost/mp3 /tmp/mp3
Password:
Samba:/tmp # cd mp3
Samba:/tmp/mp3 # time mkdir ttt
real 0m0.028s
user 0m0.008s
sys 0m0.013s

Also, es geht normal schnell.


Dann dachte ich, ok, es muß irgendwo zwischen dem Ausgang des Sambaservers und meinem Rechner liegen.
Habe nach langem Hin und Her die Netzwerkkarte am Sambaserver getauscht.
Folge: Netzwerk geht immer noch, aber Samba immer noch nicht schnell:

Samba:~ # ethtool eth1
Settings for eth1:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes



Und nun bin ich mit meinem Latein am Ende

Los_Andros
17.02.05, 21:39
So,
Tausend Stunden später folgt die Lösung:

...
I was having this problem and finally found a temp fix for it. The symptoms
seem to be this:
--> You are on a linux client
--> You have mounted a samba drive from you linux client to a linux server.
--> When you try to make modifications or copy file from your client to the
server, it takes a long time or times-out.
--> Your /var/log/mesages file states smb_trans2: invalid data , disp=0,
cnt=0, tot=0, ofs=0

It seems that some CIFS code got trampled on during a smb kernel patch. I
believe this will be fixed in the 2.6.10 kernel (pretty soon I hope). For
now, you can add the following entry to your smb.conf file:
"unix extensions = no"
This temp solution was posted to the samba listserver last month, but I
thought I would post it again since it cause me a lot of headaches.
Cheers everyone. Happy Holidays.

Mike Lee