PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : NFS sterbenslangsam (sund so mancher anderer Dienst auch)



hackbert
27.02.06, 22:00
Moin!
Ich habe hier einen kleinen Server am laufen mit NFS. Ich kann das Export mounten, aber sobald ich schreiben will wird es elendig langsam. So mancher Dienst auf dem Server hat schon mit demselben Problem gemuckt (FTP zum Beispiel), aber manche Dienste gehen superschnell (HTTP z.B.). Gibt es irgendein tool, mit dem ich die Verbindungsgeschwindigkeit generell mal testen kann?

marce
27.02.06, 22:05
netio z.B.

hackbert
27.02.06, 22:18
Habe jetzt die Messung durchgeführt... Sieht eigentlich ganz gut aus:


NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel

TCP connection established.
Packet size 1k bytes: 4078 KByte/s Tx, 10650 KByte/s Rx.
Packet size 2k bytes: 4169 KByte/s Tx, 10519 KByte/s Rx.
Packet size 4k bytes: 4157 KByte/s Tx, 10324 KByte/s Rx.
Packet size 8k bytes: 4168 KByte/s Tx, 10064 KByte/s Rx.
Packet size 16k bytes: 3992 KByte/s Tx, 9914 KByte/s Rx.
Packet size 32k bytes: 4133 KByte/s Tx, 10242 KByte/s Rx.
Done.
Woran kann es sonst noch liegen, dass das NFS sooo langsam ist. Hier mal meine /etc/exports (nicht sehr spektakulär):


# cat /etc/exports
# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
/backup 192.168.0.1(rwx)

kreol
27.02.06, 22:49
Was steht denn in der fstab? Hast Du schon mit rsize und wsize experimentiert? Hier läuft es so ganz gut:
...nfs rw,rsize=8192,wsize=8192,noauto,users,sync,hard 0 0


Kreol

hackbert
27.02.06, 22:54
Hab's auch mit Deinen Parametern versucht. Ich kann zwar sauber mounten (das geht auch recht fix), aber sobald ich daten kopieren will stockt es. Am Anfang war es so, dass die ersten paar kBytes rübergingen und dann nichts mehr, aber jetzt scheint es fast so, als könne gar nicht geschrieben werden. Es kommen leider auch keine Fehlermeldungen. Und ein Prozess der schreiben will terminiert einfach nicht. Man kann ihn nurnoch killen...

LKH
28.02.06, 09:21
Hi,

nur mal so ein rumstochern im Nebel:

- bei NFS ist es notwendig, das auf beiden Seiten (also Server und Client) der Portmapper läuft. Tut er das?

- wenn andere Dienste auch hängen, kann das an einem Timeout beim DNS Reverse Lookup liegen.

- läuft das Netz ansonsten problemlos? Keine Fehler, Drops oder Overruns?

Mehr fällt mir grade nicht ein ... ;)

LKH

hackbert
28.02.06, 11:55
- bei NFS ist es notwendig, das auf beiden Seiten (also Server und Client) der Portmapper läuft. Tut er das?
ja.



- wenn andere Dienste auch hängen, kann das an einem Timeout beim DNS Reverse Lookup liegen.
jetzt scheinen die anderen Dienste gut zu gehen. Keine Ahnung warum. Daran scheint es also auch nicht zu liegen...


- läuft das Netz ansonsten problemlos? Keine Fehler, Drops oder Overruns?
ja.

Ich habe mal ein Bisschen rumprobiert. Das Problem besteht nur bei größeren Dateien. Kleine Dateien werden anstandslos kopiert...

bla!zilla
28.02.06, 12:01
Was für NICs verwendest du? Mir ist so ein Effekt von DEC Tulip Treibern (zu Zeiten eines Kernel 2.2) bekannt. Mal ein Kernel-Update gemacht?

hackbert
28.02.06, 12:10
debianbox:~# lspci
(...)
0000:00:0f.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 02)
(...)
debianbox:~# lsmod
(...)
sis900 18436 0
(...)
debianbox:~# lsmod

bla!zilla
28.02.06, 12:28
SIS900 Chipsatz. Onboard? Kernel-Update versucht? Welchen Kernel fährst du?

hackbert
28.02.06, 12:31
SIS900 Chipsatz. Onboard? Kernel-Update versucht? Welchen Kernel fährst du?
- Nicht onboard, steckt im PCI-Slot
- Kernel-Update habe ich noch nicht gemacht
- Derzeit 2.6.8 installiert (Distri-Kernel)

bla!zilla
28.02.06, 12:45
Hast du mal einen Paketmitschnitt gemacht, mit Ethereal z.B., um zu gucken was da Protokolltechnisch passiert? Wenn nein, bitte mal machen und Ergebnis hier posten. Danach mal ein Kernel-Update durchführen.

hackbert
28.02.06, 16:17
Ich habe jetzt mal Ethereal dabei laufen lassen und mir ist folgendes aufgefallen:
es kommt andauernd "[RPC retransmission of #299]V2 WRITE Call, ...".
Was hat das zu bedeuten?

bla!zilla
28.02.06, 16:19
Poste mal etwas mehr von dem Mitschnitt.

hackbert
28.02.06, 16:25
Anbei der Dump...

bla!zilla
28.02.06, 16:33
Du hast aber nicht irgendwie einen Paketfilter (iptables) laufen, oder? Portmapper läuft wirklich auf beiden Maschinen?

hackbert
28.02.06, 17:00
Auf beiden Maschinen läuft /sbin/portmap (das ist der doch, oder?). Iptables hatte ich früher hier auf dem Rechner am Laufen. Ist aber wieder leer:


hauptbox:/home/hackbert# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
hauptbox:/home/hackbert#

bla!zilla
28.02.06, 17:41
Poste mal bitte "rcpinfo -p localhost" von beiden Maschinen.

hackbert
28.02.06, 17:45
Auf dem Server

# rpcinfo -p localhost
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100003 2 udp 2049 nfs
100003 2 tcp 2049 nfs
100005 1 udp 658 mountd
100005 2 udp 658 mountd
100005 1 tcp 661 mountd
100005 2 tcp 661 mountd
Auf dem Client:

rpcinfo -p localhost
Program Vers Proto Port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
391002 2 tcp 943 sgi_fam
100024 1 udp 957 status
100024 1 tcp 960 status
100021 1 udp 32769 nlockmgr
100021 3 udp 32769 nlockmgr
100021 4 udp 32769 nlockmgr

bla!zilla
28.02.06, 17:50
Ich vermisse auf deinem Server einige Prozesse. Auf meinem Server sieht das so aus:



svr-lev-01:~ # rpcinfo -p localhost
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100024 1 udp 39203 status
100021 1 udp 39203 nlockmgr
100021 3 udp 39203 nlockmgr
100021 4 udp 39203 nlockmgr
100024 1 tcp 40943 status
100021 1 tcp 40943 nlockmgr
100021 3 tcp 40943 nlockmgr
100021 4 tcp 40943 nlockmgr
100005 1 udp 32666 mountd
100005 1 tcp 32666 mountd
100005 2 udp 32666 mountd
100005 2 tcp 32666 mountd
100005 3 udp 32666 mountd
100005 3 tcp 32666 mountd


Ich sehe bei dir keinen nlockmgr und status.

hackbert
28.02.06, 17:56
Ich benutze den userspace NFS-Server... Kann es daran liegen?
EDIT: Habe jetzt mal den nfs-kernel-server installiert und rpcinfo sagt nun:


# rpcinfo -p localhost
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 640 status
100024 1 tcp 643 status
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100021 1 udp 1026 nlockmgr
100021 3 udp 1026 nlockmgr
100021 4 udp 1026 nlockmgr
100021 1 tcp 1041 nlockmgr
100021 3 tcp 1041 nlockmgr
100021 4 tcp 1041 nlockmgr
100005 1 udp 687 mountd
100005 1 tcp 690 mountd
100005 2 udp 687 mountd
100005 2 tcp 690 mountd
100005 3 udp 687 mountd
100005 3 tcp 690 mountd

Richtig schreiben geht aber immernoch nicht...

bla!zilla
28.02.06, 18:07
Joar, daran wird´s gelegen haben. Ich verwende auch den Userspace NFS Server. Passe bitte mal testweise seine /etc/exports an:

/backup 192.168.0.0/255.255.255.0(rw,root_squash,sync)

hackbert
28.02.06, 18:11
habe in meiner fstab nun ein Bisschen mit rsize und wsize rumgespielt. Bei beidem auf 1024 scheint es eine Verbesserung zu geben. Immerhin kommt der Netzwerkverkehr ins Rollen. Man hört lautes Rödeln der Festplatte und es dauert Ewigkeiten, bis die Datei übertragen ist...

bla!zilla
28.02.06, 18:13
1024 ist suboptimal. Optimal sind 8192. Ich mounte /home von meinem Server (SUSE 10.0) an meinem Notebook (auch SUSE 10.0) und nutze darüber mein Homedirectory. Ich verwende am Client folgende Optionen: rsize=8192,wsize=8192.

hackbert
28.02.06, 18:16
Mit rsize=8192,wsize=8192 kommt wieder das Problem, dass nichts geschrieben wird. Kann das mit der MTU zusammenhängen? Wenn ja, was sollte ich tun?

kreol
28.02.06, 18:19
NFS-howto (http://mysite.verizon.net/res0yizl/id12.html). Da steht auch was über Geschwindigkeitsoptimierung iVm der Blockgröße.


Kreol

bla!zilla
28.02.06, 18:20
Mit rsize=8192,wsize=8192 kommt wieder das Problem, dass nichts geschrieben wird. Kann das mit der MTU zusammenhängen?

Nö, außer du sorgst dafür das alleine deine Pakete mit gesetztem DF Bit rausgehen.

hackbert
28.02.06, 18:28
Nö, außer du sorgst dafür das alleine deine Pakete mit gesetztem DF Bit rausgehen.
Nicht, dass ich wüsste. Kann man das irgendwo nachsehen?

hackbert
28.02.06, 18:35
Wenn ich NFS über TCP verwende geht es auch mit den 8192-Werten. Allerdings immernoch sterbenslangsam...

kreol
28.02.06, 19:03
Hast Du Dir schon das Howto von oben angesehen? Die maximal mögliche Blockgröße wird wohl sowohl von dem Server-Kernel als auch von der verwendeten NFS-Version bestimmt, wobei der 2.6.8 mit 8KB wohl keine Probleme hat. Experimentier einfach mal mit ein paar Werten bzw. verschiebe mal größere Dateien hin und her, wie in dem Howto beschrieben.

Welche Transferraten hast Du z.B., wenn Du Dateien zwischen Server und Client hin- und herschiebst, d.h., als Quelle mal den Server und mal den Client nimmst. Da habe ich auch enorme Geschwindigkeitsunterschiede, siehe hier (http://www.linuxforen.de/forums/showthread.php?t=201307)


Kreol