• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Schreibzugriff mit NFS ist langsam

G

Gamic

Member
Hallo,

ich habe mein Netz von SUSE 10.0 auf SUSE 10.2 umgestellt.
Der Schreibzugriff auf den NFS-Server ist bei kleinen Dateien erstaunlich langsam und liegt oft bei 50 kB/s. Große Dateien (über 50 MB) werden mit 12 MB/s geschrieben. Beoachtet habe ich mit gkrellm.

Der Export erfolgt so:
Code: 
/var/lib/nfs # more etab
/nfs/share      10.0.0.0/24(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,subtree_check,secu
re_locks,acl,mapping=identity,anonuid=65534,anongid=65534)

Nun kann durch Tausch von sync gegen async die Übertragungsrate auch bei kleinen Dateien locker über 5 MB/s gesteigert werden. Doch war bei SUSE 10.0 auch mit sync die Übertragungsrate akzeptabel und wenigstens nie deutlich unter 500 kB/s.

Im Bugzilla gibt es auch einen Beitrag im dem ein langsamer NFS-Zugriff bemängelt wird. Wie sieht es hier aus. Welche Erfahrungen habt Ihr gemacht.

Was ist mit der Option subtree_check? Ist es sinnvoll (oder vertretbar) no_subtree_check zu setzen? Was kann sich zwischen SUSE 10.0 und 10.2 geändert haben, daß die Geschwindigkeit so einbricht?
 
OP
G

Gamic

Member
jengelh schrieb:
Gamic schrieb:
Welche Erfahrungen habt Ihr gemacht.
Zum Vergrößern anklicken....
Lastet bei mir das Ethernetkabel bis irgendwo 70 - 80 mbit/s aus... 8)
Zum Vergrößern anklicken....

Dann kopiere mal /etc auf den Server (cp -a /etc /nfsshare). Die durchschnittliche Transferrate liegt bei mir unter 100 kB/s. Für ein 100 MBit/s Netz einfach nicht akzeptabel.
Bei Verwendung der Option "async" erziele ich rund 5MB/s.
Dateisystem auf dem Server ist XFS (noch mit SUSE 10.0 erstellt).
 
J

jengelh

Guru
wackelt so zwischen 2 - 6 mbit/s...
Code: 
# mount blah:/jengelh /mnt
# time cp -a /etc /mnt

real    0m34.227s
user    0m0.090s
sys     0m1.320s

# du -s /etc
19564   /etc
Hm... mediocre. Ich nehme mal an, das liegt daran, dass /etc so verf*** viele Dateien enthält. Denn mit large files geht's:
Code: 
22:08 ichi:/erk # sh syncme 
66653 files to consider
(rsync upload einer 100+MB Datei:)
    86278144  25%    8.72MB/s    0:00:28
(iptraf output:)
 Pkts captured (all interfaces):      172050 │ TCP flow rate:  55183.00 kbits/s
Also... zählen wir mal die Dateien in /etc:
Code: 
/etc# for d in `find . -mindepth 1 -maxdepth 1 -type d`; do n=`find "$d" | wc -l`; echo -e "$n\t$d"; done | sort -g
10      ./samba
11      ./hal
11      ./ssh
12      ./cron.daily
12      ./security
13      ./PolicyKit
13      ./logrotate.d
13      ./ppp
18      ./vmware
20      ./nagios
20      ./xinetd.d
22      ./pm
23      ./udev
24      ./skel
27      ./openldap
33      ./pam.d
33      ./texmf
34      ./cups
34      ./php5
36      ./mail
44      ./profile.d
55      ./joe
57      ./fonts
61      ./ssl
76      ./apache2
90      ./alternatives
105     ./X11
184     ./sysconfig
269     ./init.d
271     ./l7-protocols
417     ./opt
/etc/opt# for d in `find . -mindepth 1 -maxdepth 1 -type d`; do n=`find "$d" | wc -l`; echo -e "$n\t$d"; done | sort -g
12      ./kde3
404     ./gnome
Scheiß Gnome! Das macht BTW auch den Firefox-Start langsam... Aufteilen von Konfiguratoinsdateien (apache 2.x und sysconfig) ist ja nett, aber man kann's auch übertreiben.
 
OP
G

Gamic

Member
ich danke Dir für Deine Hilfe.
Mein Server hat da wohl ein Problem mit SUSE 10.2. Mit SUSE 10.0 war noch alles bestens .
Ich werde der Sache mal nachgehen.
 
OP
G

Gamic

Member
Und noch meine "Benchmark"

async:
#time cp -r /etc/ /nfs/share/scratch/
real 0m9.396s
user 0m0.056s
sys 0m0.948s

sync:
# time cp -r /etc/ /nfs/share/scratch/
real 1m56.612s
user 0m0.108s
sys 0m1.280s

# du -s /etc/
27504 /etc/ -> 2769 Dateien
 
OP
G

Gamic

Member
jengelh schrieb:
Wer sync verwendet ist selber schuld.
Zum Vergrößern anklicken....

nun, die Option async bewirkt bei einem Crash den Verlust aller noch nicht auf die Platte geschriebenen Daten und der Client hat keine Möglichkeit das zu merken. Die Daten auf der Platten können OK sein, oder auch nicht. Auch mit sync bewirkt die Option "wdelay" ein verzögertes Schreiben beim Kopieren vieler Dateien, aber ohne die Unsicherheit wie bei async.

Ich habe inzwischen einen weiteren Test mit einem anderen Server (auch SUSE 10.2) durchgeführt. Dort liegt die Übertragungsrate mit sync bei etwa 2 MB/s. Mein alter Server hat wohl ein Problem mit SUSE 10.2.
 
OP
G

Gamic

Member
Die Sache wird immer komischer. Die schlechte Transferrate tritt nur auf den Platten hdb und hdc auf. Auf hda ist die Transferrate super.
Auf hdb1 ist ext3, auf hdc1 xfs und auf hda? ebenfalls ext3. Alle Dateisysteme sind frisch mit SUSE 10.2 angelegt worden.
In der Logfile sind keine Einträge die auf Probleme mit den Festplatten oder dem Dateisystem hindeuten. Die Transferrate zwischen den Platten (lokal mit cp) liegt auch bei 50 MB/s.
Ich habe jedenfalls keine Idee mehr wo das Problem liegen könnte.
 
J

jengelh

Guru
Manche blöde BIOSe wollen partout an eins der vier möglichen IDE-Geräte kein DMA größer UDMA2 vergeben... ähnliches Problem bekannt. Aber dass das bei zwei Geräten gleichzeitig passiert - noch nicht gesehen. Jedenfalls: Wenn du hdb, hdc, hdd, zykelst oder tauscht, wie auch immer, könntest du feststellen, dass es immer hdc/hdd ist, denen das Speed fehlt. Trifft das zu? Was sagt hdparm?
 
OP
G

Gamic

Member
Alle Festplatten laufen mit UDMA 5. Lokales Kopieren ist kein Problem (>50MB/s). Ebenso große Dateien über das Netz (>10 MB/s). Nur bei vielen kleinen Dateien über NFS auf andere Festplatten als hda geht es nicht. Es sind also beide IDE Kanäle betroffen. hda ist eine WD 10 GB, hdb eine Hitachi 160 GB und hdc eine Seagate 320 GB.
Viele kleine Dateien mit scp oder smb sind kein Problem.

Der Rechner wird von Linux grundsätzlich sehr gut unterstützt. Es ist ein Compaq Deskpro 800EN mit Intel Chipset, P3 800 MHz und Intel Netzwerkkarte. Zum Booten von SUSE 10.2 war jedoch der Kernelparameter "maxcpus=0" notwendig, weil der Kernel sonst nicht gebootet hat. Debian Etch (mit fast gleicher Kernelversion) hat dieses Problem nicht.

Ich werde wohl die SUSE 10.0 Platte wieder anschließen. Man sollte Dinge die gut funktionieren lieber doch nicht ändern.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben