Toon posts:

[FC6] NFS Share blijft op 1MB/s

Pagina: 1
Acties:

zondag 14 januari 2007 13:30

Acties:
  • H@rry
  • Registratie: Maart 2001
  • Laatst online: 01-12-2025

H@rry

Topicstarter
Ik ben overgestapt van FC5 naar FC6 op mijn desktop. Alleen nu heb ik een vervelend probleem (wel meerdere maar nu eerst ff deze :P)

Op mijn server draait FC5 (eerst FC4 maar nu geupdate naar FC5, ik dacht misschien helpt het) met een NFS share. Deze share heb ik op mijn desktop gemount via fstab

192.168.0.1:/data /data nfs auto,user,_netdev 0 0

Werkte altijd prima. Nu heb ik dus laatst FC6 erop gezet en na een minuut of wat dan zie ik mijn download blijven hangen op 1.0 MB/s. Op zich niet zo heel erg, alleen mijn server word er bokke traag van en ook mijn desktop levert wat performance in.

Wat ik geprobeerd heb:
nfs-utils downgraden - lijkt beter maar het gebeurt nog steeds
server van fc4 naar fc5 - geen verschil
verschillende opties in de fstab - geen verschil
wireshark/ethereal - ik heb het idee dat mijn dekstop steeds pakketjes herhaald ofzo

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143

No.     Time        Source                Destination           Protocol Info
      1 0.000000    192.168.0.1           192.168.0.2           RPC      Continuation

Frame 1 (1286 bytes on wire, 1286 bytes captured)
Ethernet II, Src: ViaTechn_c5:ef:1f (00:40:63:c5:ef:1f), Dst: AsustekC_cd:dc:26 (00:0c:6e:cd:dc:26)
Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.2 (192.168.0.2)
Transmission Control Protocol, Src Port: nfs (2049), Dst Port: 881 (881), Seq: 0, Ack: 0, Len: 1220
    Source port: nfs (2049)
    Destination port: 881 (881)
    Sequence number: 0    (relative sequence number)
    [Next sequence number: 1220    (relative sequence number)]
    Acknowledgement number: 0    (relative ack number)
    Header length: 32 bytes
    Flags: 0x18 (PSH, ACK)
    Window size: 1002
    Checksum: 0x979e [correct]
    Options: (12 bytes)
Remote Procedure Call

No.     Time        Source                Destination           Protocol Info
      2 0.000008    192.168.0.2           192.168.0.1           NFS      V3 READ Call (Reply In 556), FH:0x43fc2ca6 Offset:1769472 Len:32768

Frame 2 (206 bytes on wire, 206 bytes captured)
Ethernet II, Src: AsustekC_cd:dc:26 (00:0c:6e:cd:dc:26), Dst: ViaTechn_c5:ef:1f (00:40:63:c5:ef:1f)
Internet Protocol, Src: 192.168.0.2 (192.168.0.2), Dst: 192.168.0.1 (192.168.0.1)
Transmission Control Protocol, Src Port: 881 (881), Dst Port: nfs (2049), Seq: 0, Ack: 1220, Len: 140
    Source port: 881 (881)
    Destination port: nfs (2049)
    Sequence number: 0    (relative sequence number)
    [Next sequence number: 140    (relative sequence number)]
    Acknowledgement number: 1220    (relative ack number)
    Header length: 32 bytes
    Flags: 0x18 (PSH, ACK)
    Window size: 20898
    Checksum: 0x8206 [incorrect, should be 0xca8e (maybe caused by checksum offloading?)]
    Options: (12 bytes)
    [SEQ/ACK analysis]
        [This is an ACK to the segment in frame: 1]
        [The RTT to ACK the segment was: 0.000008000 seconds]
Remote Procedure Call, Type:Call XID:0x94299252
Network File System, READ Call FH:0x43fc2ca6 Offset:1769472 Len:32768

No.     Time        Source                Destination           Protocol Info
      3 0.000013    192.168.0.1           192.168.0.2           TCP      [TCP segment of a reassembled PDU]

Frame 3 (1506 bytes on wire, 1506 bytes captured)
Ethernet II, Src: ViaTechn_c5:ef:1f (00:40:63:c5:ef:1f), Dst: AsustekC_cd:dc:26 (00:0c:6e:cd:dc:26)
Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.2 (192.168.0.2)
Transmission Control Protocol, Src Port: nfs (2049), Dst Port: 881 (881), Seq: 1220, Ack: 0, Len: 1440
    Source port: nfs (2049)
    Destination port: 881 (881)
    Sequence number: 1220    (relative sequence number)
    [Next sequence number: 2660    (relative sequence number)]
    Acknowledgement number: 0    (relative ack number)
    Header length: 32 bytes
    Flags: 0x10 (ACK)
    Window size: 1002
    Checksum: 0x1f52 [correct]
    Options: (12 bytes)
    TCP segment data (1440 bytes)

No.     Time        Source                Destination           Protocol Info
      4 0.000019    192.168.0.1           192.168.0.2           TCP      [TCP segment of a reassembled PDU]

Frame 4 (1506 bytes on wire, 1506 bytes captured)
Ethernet II, Src: ViaTechn_c5:ef:1f (00:40:63:c5:ef:1f), Dst: AsustekC_cd:dc:26 (00:0c:6e:cd:dc:26)
Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.2 (192.168.0.2)
Transmission Control Protocol, Src Port: nfs (2049), Dst Port: 881 (881), Seq: 2660, Ack: 0, Len: 1440
    Source port: nfs (2049)
    Destination port: 881 (881)
    Sequence number: 2660    (relative sequence number)
    [Next sequence number: 4100    (relative sequence number)]
    Acknowledgement number: 0    (relative ack number)
    Header length: 32 bytes
    Flags: 0x10 (ACK)
    Window size: 1002
    Checksum: 0x8c9e [correct]
    Options: (12 bytes)
    [Reassembled PDU in frame: 36]
    TCP segment data (1440 bytes)

No.     Time        Source                Destination           Protocol Info
      5 0.000140    192.168.0.2           192.168.0.1           TCP      881 > nfs [ACK] Seq=140 Ack=4100 Win=20898 Len=0 TSV=4629844 TSER=1265998745

Frame 5 (66 bytes on wire, 66 bytes captured)
Ethernet II, Src: AsustekC_cd:dc:26 (00:0c:6e:cd:dc:26), Dst: ViaTechn_c5:ef:1f (00:40:63:c5:ef:1f)
Internet Protocol, Src: 192.168.0.2 (192.168.0.2), Dst: 192.168.0.1 (192.168.0.1)
Transmission Control Protocol, Src Port: 881 (881), Dst Port: nfs (2049), Seq: 140, Ack: 4100, Len: 0
    Source port: 881 (881)
    Destination port: nfs (2049)
    Sequence number: 140    (relative sequence number)
    Acknowledgement number: 4100    (relative ack number)
    Header length: 32 bytes
    Flags: 0x10 (ACK)
    Window size: 20898
    Checksum: 0xf469 [correct]
    Options: (12 bytes)
    [SEQ/ACK analysis]
        [This is an ACK to the segment in frame: 4]
        [The RTT to ACK the segment was: 0.000121000 seconds]

No.     Time        Source                Destination           Protocol Info
      6 0.000145    192.168.0.1           192.168.0.2           TCP      [TCP segment of a reassembled PDU]

Frame 6 (1506 bytes on wire, 1506 bytes captured)
Ethernet II, Src: ViaTechn_c5:ef:1f (00:40:63:c5:ef:1f), Dst: AsustekC_cd:dc:26 (00:0c:6e:cd:dc:26)
Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.2 (192.168.0.2)
Transmission Control Protocol, Src Port: nfs (2049), Dst Port: 881 (881), Seq: 4100, Ack: 0, Len: 1440
    Source port: nfs (2049)
    Destination port: 881 (881)
    Sequence number: 4100    (relative sequence number)
    [Next sequence number: 5540    (relative sequence number)]
    Acknowledgement number: 0    (relative ack number)
    Header length: 32 bytes
    Flags: 0x10 (ACK)
    Window size: 1002
    Checksum: 0x9c04 [correct]
    Options: (12 bytes)
    [Reassembled PDU in frame: 36]
    TCP segment data (1440 bytes)

No.     Time        Source                Destination           Protocol Info
      7 0.000150    192.168.0.1           192.168.0.2           TCP      [TCP segment of a reassembled PDU]

Frame 7 (1506 bytes on wire, 1506 bytes captured)
Ethernet II, Src: ViaTechn_c5:ef:1f (00:40:63:c5:ef:1f), Dst: AsustekC_cd:dc:26 (00:0c:6e:cd:dc:26)
Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.2 (192.168.0.2)
Transmission Control Protocol, Src Port: nfs (2049), Dst Port: 881 (881), Seq: 5540, Ack: 0, Len: 1440
    Source port: nfs (2049)
    Destination port: 881 (881)
    Sequence number: 5540    (relative sequence number)
    [Next sequence number: 6980    (relative sequence number)]
    Acknowledgement number: 0    (relative ack number)
    Header length: 32 bytes
    Flags: 0x10 (ACK)
    Window size: 1002
    Checksum: 0xc0dd [correct]
    Options: (12 bytes)
    [Reassembled PDU in frame: 36]
    TCP segment data (1440 bytes)

No.     Time        Source                Destination           Protocol Info
      8 0.000153    192.168.0.2           192.168.0.1           TCP      881 > nfs [ACK] Seq=140 Ack=6980 Win=20898 Len=0 TSV=4629847 TSER=1265998745


Nu heb ik gelezen dat FC6 enkele performance tweaks heeft gehad voor NFS dus ik weet niet of het daarmee te maken heeft.

Ik ben al een tijdje aan het zoeken om het voor mekaar te krijgen maar het wil maar niet lukken, en ik kan ook nergens wat vinden.

GoT a clue? Specs

zondag 14 januari 2007 13:37

Acties:
  • hammerhead
  • Registratie: April 2000
  • Laatst online: 08:03

hammerhead

Is het probleem alleen aanwezig met NFS, of ook met andere protocollen? Dus als je bijvoorbeeld FTP gebruikt, blijft hij dan ook na een aantal minuten hangen op 1MB/s?

Aviation is proof that given the will, we have the capacity to achieve the impossible.
--Eddie Rickenbacker

zondag 14 januari 2007 15:45

Acties:
  • H@rry
  • Registratie: Maart 2001
  • Laatst online: 01-12-2025

H@rry

Topicstarter
Nee niet met FTP.

Het punt is namelijk, als ik /data wil unmounten zegt ie:
code:
1
2
3

[root@ben ~]# umount /data
umount: /data: device is busy
umount: /data: device is busy


En als er dan een moment is dat mijn netwerkspeed op 0 staat gaat unmounten wel. En op mijn server zie ik meerdere nfsd processen bovenaan staan met top. Dus het moet met NFS te maken hebben. En als ik dan mijn /data geunmount heb, dan is mijn server weer normaal en is er niks aan de hand, mount ik /data weer dan begint het feest weer.

GoT a clue? Specs

maandag 15 januari 2007 08:54

Acties:
  • Carpetsmoker
  • Registratie: Augustus 2004
  • Laatst online: 03-12-2015

Carpetsmoker

geen rare dingen in top en/of vmstat?

maandag 15 januari 2007 12:39

Acties:
  • H@rry
  • Registratie: Maart 2001
  • Laatst online: 01-12-2025

H@rry

Topicstarter
nee... wat is raar

de nfsd processen staan bovenaan als het gebeurt, dat lijkt me ook vrij logisch.

GoT a clue? Specs

maandag 15 januari 2007 13:24

Acties:
  • Carpetsmoker
  • Registratie: Augustus 2004
  • Laatst online: 03-12-2015

Carpetsmoker

Nee, dat is op zich niet raar, mijn NFS server is een AMD K6-2 300MHz, en als ik met 100Mbit/s files ga trekken neemt nfsd al gouw 30%/40% CPU in beslag.

Losse gedachten die me te binnen schieten:

- Je kunt eens kijken of je UDP connections uit hebt staan (-u switch)

- Je kunt een proberen met een andere client te verbinden...?
Of een andere NFS server te draaien
Probeer ook eens een LiveCD van een ander OS, Bv. FreeBSD (http://www.freesbie.org/)
http://www.freebsd.org/do...handbook/network-nfs.html

- Is de Disk I/O wel normaal als lokaal op de server files kopieert?

- Is zowel upload als download 1MB/s?

- DNS issue? voeg je machines toe aan /etc/hosts

- Firewall issue?

- Draai eens rpc.statd en rpc.lockd

- mount_nfs met -L switch (Do not forward fcntl(2) locks over the wire.) dit is trouwens een freebsd switch, weet niet of dat onder linux ook hetzelfde is
Het punt is namelijk, als ik /data wil unmounten zegt ie:
umount: /data: device is busy
Dit is "normaal" NFS zuigt eigelijk enorm...

maandag 15 januari 2007 13:49

Acties:
  • H@rry
  • Registratie: Maart 2001
  • Laatst online: 01-12-2025

H@rry

Topicstarter
ik ben een beetje aan het klooien geweest en ik denk dat ik de reden heb dat het op 1MB/s blijft.

Ik heb een share data en een share data2. Deze staan allebei op 2 verschillende hd's. Nu heb ik op data een symbolic link naar een map op data2. Dus bijv:

/data/Music > /data2/Music

Nu moet ik dus data en data2 gemount hebben wil ik die link kunnen volgen op de client. Werkte allemaal prima op FC4 en FC5 maar FC6 pikt dit dus niet. Nu heb ik die link weggehaald en een mount -obind van gemaakt. Nu gaat ie niet meer op 1MB/s maar ik kan alleen de inhoud niet lezen op de client, maar op de server wel.

dat mount -obind werkt wel voor proftpd als je buiten je scope komt zeg maar van je proftpd scope... hoe moet ik dat zeggen... je snap me wel denk ik. :P

Dus probleem 1 ongeveer opgelost, nu een nieuw probleem erbij :P

GoT a clue? Specs

maandag 15 januari 2007 14:55

Acties:
  • Carpetsmoker
  • Registratie: Augustus 2004
  • Laatst online: 03-12-2015

Carpetsmoker

hmm, symlinks werken gewoon bij mijn, bv
ln -s /usr/home/carpetsmoker /nfs/
ls /nfs/carpetsmoker
[HOOP ZOOI]

Mijn exports:
/nfs -alldirs -maproot=root -network=192.168.100

maandag 15 januari 2007 16:42

Acties:
  • H@rry
  • Registratie: Maart 2001
  • Laatst online: 01-12-2025

H@rry

Topicstarter
Symlinks werken ook wel, maar daardoor (tenminste zo blijkt het) blijft die snelheid dus steken.

Nu moet ik dus nog een manier vinden om die zooi te linken naar me /data

GoT a clue? Specs

zaterdag 20 januari 2007 21:07

Acties:
  • H@rry
  • Registratie: Maart 2001
  • Laatst online: 01-12-2025

H@rry

Topicstarter
te vroeg gejuichd, het probleem is er nog steeds.

Het enige vreemde at ik kan vinden met Wireshark is die NFS V3 READ CALL die de error:

Checksum: 0x8206 [incorrect, should be 0xca8e (maybe caused by checksum offloading?)]

geeft.


Geen NFS/Netwerk genieën aanwezig die dit kunnen verklaren?

GoT a clue? Specs

woensdag 24 januari 2007 18:30

Acties:
  • H@rry
  • Registratie: Maart 2001
  • Laatst online: 01-12-2025

H@rry

Topicstarter
Interessante ontwikkeling:

Ik heb NFSv4 geprobeerd, hielp niet, en vervolgens Samba. Dat heb ik nu dus draaien, maar naar verloop van tijd gebeurd precies hetzelfde! Hij blijft data pompen op 1mb/s down en rond de 30kb/s up

er komen dan heel veel
code:
1
2
3

  14277 17.108000   192.168.0.2           192.168.0.1           TCP      41107 > microsoft-ds [ACK] Seq=50758 Ack=12316727
  14278 17.109173   192.168.0.1           192.168.0.2           TCP      [TCP segment of a reassembled PDU]
  14279 17.110538   192.168.0.1           192.168.0.2           TCP      [TCP segment of a reassembled PDU]

van deze pakketen op deze volgorde. Heel apart.. ik ben het spoor een beetje bijster.

GoT a clue? Specs

donderdag 25 januari 2007 09:40

Acties:
  • hammerhead
  • Registratie: April 2000
  • Laatst online: 08:03

hammerhead

Als samba ook een probleem oplevert zou ik zeggen dat er nog maar twee opties overblijven: Of je hebt een probleem met je netwerk of je hebt een probleem met je harde schijven. Geeft de uitvoer van ifconfig misschien errors/etc voor je netwerk kaarten?

Aviation is proof that given the will, we have the capacity to achieve the impossible.
--Eddie Rickenbacker

donderdag 25 januari 2007 19:20

Acties:
  • H@rry
  • Registratie: Maart 2001
  • Laatst online: 01-12-2025

H@rry

Topicstarter
ifconfig op mijn pc:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

[root@ben dev]# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:0C:6E:CD:DC:26  
          inet addr:192.168.0.2  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:6eff:fecd:dc26/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1492  Metric:1
          RX packets:1460923 errors:0 dropped:0 overruns:0 frame:0
          TX packets:864182 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2078187820 (1.9 GiB)  TX bytes:71009926 (67.7 MiB)
          Interrupt:9 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1814 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1814 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4990808 (4.7 MiB)  TX bytes:4990808 (4.7 MiB)


ifconfig op de server:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

[root@data ~]# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:40:63:C5:EF:1F  
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::240:63ff:fec5:ef1f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1492  Metric:1
          RX packets:72806386 errors:0 dropped:0 overruns:0 frame:0
          TX packets:114049858 errors:77 dropped:0 overruns:0 carrier:77
          collisions:15417697 txqueuelen:1000 
          RX bytes:502568505 (479.2 MiB)  TX bytes:3669064927 (3.4 GiB)
          Interrupt:11 Base address:0x6000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:6574 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6574 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:9774603 (9.3 MiB)  TX bytes:9774603 (9.3 MiB)

sit0      Link encap:IPv6-in-IPv4  
          NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)


niks aan de hand lijkt me.

ik zal ipv6 nog ff proberen uit te zetten, je weet maar nooit

GoT a clue? Specs

Pagina: 1
Reageer

Apple iPhone 17 LG OLED evo G5 Google Pixel 10 Samsung Galaxy S25 Star Wars: Outlaws Nintendo Switch 2 Apple AirPods Pro (2e generatie) Sony PlayStation 5 Pro

Tweakers is onderdeel van DPG Media B.V.
Alle rechten voorbehouden - Auteursrecht © 1998 - 2026 • Hosting door TrueFullstaq