Trage NFS

[Paul van der Vlis]

Hallo,

Een klant klaagt over traag NFS 3. Het uitpakken van een zip-bestand met
veel kleine bestanden kost bijvoorbeeld een minuut, terwijl het op het
lokale filesysteem maar een seconde duurt. Als hij via Samba mount duurt
het 3 seconden.

Zoiets staat in /etc/exports:
/data 192.168.1.0/255.255.255.0(rw,no_root_squash,no_subtree_check)

Zoiets staat op de client in /etc/fstab:
192.168.1.1:/data /data nfs rw 0 0

Iemand een idee wat dit zou kunnen zijn?

Groet,
Paul.


--
Paul van der Vlis Linux systeembeheer Groningen
http://www.vandervlis.nl

[Martijn van Buul]

Paul van der Vlis (pa...@vandervlis.nl) schreef:

> Hallo,
>
> Een klant klaagt over traag NFS 3. Het uitpakken van een zip-bestand met
> veel kleine bestanden kost bijvoorbeeld een minuut, terwijl het op het
> lokale filesysteem maar een seconde duurt. Als hij via Samba mount duurt
> het 3 seconden.
>
> Zoiets staat in /etc/exports:
> /data 192.168.1.0/255.255.255.0(rw,no_root_squash,no_subtree_check)
>
> Zoiets staat op de client in /etc/fstab:
> 192.168.1.1:/data /data nfs rw 0 0
>
> Iemand een idee wat dit zou kunnen zijn?

Ik vrees dat het voor een deel inherent is aan NFS. Je zou kunnen spelen
met de blocksize, maar of dat nou veel netto resultaat gaat opleveren...
Geen idee. Er is een performance hack die hier wel eens effect zou kunnen
sorteren (mounten met -o async), maar het komt je stabiliteit niet ten
goede.

Zie http://nfs.sourceforge.net/nfs-howto/ar01s05.html, in het bijzonder
paragraaf 5.9.

--
Martijn van Buul - pi...@dohd.org

[Paul van der Vlis]

Op 25-05-12 13:26, Martijn van Buul schreef:

Hmm. Ik heb klanten die met een home-directory op NFS werken, en ik hoor
ze niet klagen eigenlijk.

Zou de optie "no_wdelay" voor deze klant nog zinvol kunnen zijn, of zou
het misschien iets met DNS te maken kunnen hebben?

[Jeroen Beerstra]

Op 25-05-12 12:43, Paul van der Vlis schreef:

> Hallo,
>
> Een klant klaagt over traag NFS 3. Het uitpakken van een zip-bestand met
> veel kleine bestanden kost bijvoorbeeld een minuut, terwijl het op het
> lokale filesysteem maar een seconde duurt. Als hij via Samba mount duurt
> het 3 seconden.
>
> Zoiets staat in /etc/exports:
> /data 192.168.1.0/255.255.255.0(rw,no_root_squash,no_subtree_check)
>
> Zoiets staat op de client in /etc/fstab:
> 192.168.1.1:/data /data nfs rw 0 0
>
> Iemand een idee wat dit zou kunnen zijn?
>
> Groet,
> Paul.
>
>

Ik heb soortgelijke ervaringen, met async btw: uitpakken van een archief
met veel kleine bestanden duurt erg lang. Zo ook werken met een stevige
svn repo. Factoren langzamer dan lokaal iig. Max throughput is wel dik
in orde, beter dan samba, maar nfs blinkt niet uit in veel io ops.

Ben bang dat Martijn dus gewoon gelijk heeft.

--
jb

[Paul van der Vlis]

Op 26-05-12 10:10, Jeroen Beerstra schreef:

Hmm, het probleem is dat het op deze manier niet bruikbaar is voor deze
klant... Ik doe wel vaker dingen met NFS, ook met mensen wiens
homedirectory op NFS staat, en ik hoor eigenlijk geen klachten.

[Richard van den Berg]

Op 25-05-12 12:43, Paul van der Vlis schreef:

> Hallo,
>
> Een klant klaagt over traag NFS 3. Het uitpakken van een zip-bestand met
> veel kleine bestanden kost bijvoorbeeld een minuut, terwijl het op het
> lokale filesysteem maar een seconde duurt. Als hij via Samba mount duurt
> het 3 seconden.
>
> Zoiets staat in /etc/exports:
> /data 192.168.1.0/255.255.255.0(rw,no_root_squash,no_subtree_check)
>
> Zoiets staat op de client in /etc/fstab:
> 192.168.1.1:/data /data nfs rw 0 0
>
> Iemand een idee wat dit zou kunnen zijn?

Helaas niet. Is alle firmware up-to-date? Op het werk aan de hand gehad:
http://qatsi.ath.cx/susy/?p=26

Hier goede ervaring met NFS:

:/tmp# time tar xjf /usr/src/linux-source-3.1.tar.bz2

real 1m23.518s
user 0m54.486s
sys 0m7.150s

:/mnt/backup# time tar xjf /usr/src/linux-source-3.2.tar.bz2

real 1m57.357s
user 0m59.833s
sys 0m10.213s

Zo ziet de netwerkdata grafiek ervan uit:
http://qatsi.ath.cx/~ravdberg/linux/nfs_2012-05-26.png

/tmp en /usr is dezelfde SCSI RAID5 set, /mnt/backup een SATA RAID1 set
in een QNAP TS-410 via NFS gemount.

uname -a
Linux whale 3.1.8.rvdb #1 SMP Wed Feb 8 20:04:50 CET 2012 i686 GNU/Linux

--
Richard

[Jeroen Beerstra]

Op 26-05-12 16:10, Richard van den Berg schreef:

$ time tar xzf views-7.x-3.3.tar.gz

real 0m0.065s
user 0m0.049s
sys 0m0.035s


$ time tar xzf /home/jeroen/Downloads/views-7.x-3.3.tar.gz

real 0m2.879s
user 0m0.077s
sys 0m0.244s

Denk niet dat ik toe hoef te lichten welke nfs is en welke niet :)

Hamvraag is denk ik: is jouw nfs nou zo veel sneller dan de mijne of
valt RAID5 SCSI voor dit doel wat tegen? En natuurlijk in hoeverre is
dit een eerlijke test:

$ time `tar xzf views-7.x-3.3.tar.gz; sync`

real 0m0.766s
user 0m0.032s
sys 0m0.049s

--
jb

[Martijn van Buul]

Richard van den Berg (ravd...@inter.invalid) schreef:

> Hier goede ervaring met NFS:
>
>:/tmp# time tar xjf /usr/src/linux-source-3.1.tar.bz2
>
> real 1m23.518s
> user 0m54.486s
> sys 0m7.150s

Verschil tussen "real" en "user": 29 seconden, waarvan 7 seconden besteed
aan "sys". Beetje kort door de bocht, maar die 29 seconden is wat je kwijt
bent geweest aan de disk I/O.

>:/mnt/backup# time tar xjf /usr/src/linux-source-3.2.tar.bz2
>
> real 1m57.357s
> user 0m59.833s
> sys 0m10.213s

Verschil tussen "real" en "user": 58 seconden, waarvan 10 seconden besteed
aan "sys".

Verder vind ik het overigens erg opvallend dat er 10 seconden verschil in
"user" zit. Dat geeft waarschijnlijk aan dat er iets als PowerNow (cq
SpeedStep) actief is.

Al met al ben je in het geval van NFS twee keer zoveel tijd kwijt geweest
aan I/O. Rekening houdend met het feit dat er ook I/O tijd schuilt in het
*inlezen* van die tarball (terwijl dat in het tweede geval waarschijnlijk
uit een diskcache komt) is het verschil in write performance *meer* dan een
factor 2. Dit had je eventueel kunnen uitsluiten door de tarball in een
ramdisk te zetten.

De totale hoeveelheid data die geschreven wordt tijdens het uitpakken van
die tarball is eigenlijk beperkt. Uit je graph volgt dit overigens ook: De
throughput is eigenlijk maar laag, en komt niet boven de 5.9 MB/s uit.

Interessanter is de vraag hoe de verdeling van bestandsgroottes is. Ik weet
niet welke kernelversie jij precies gebruikt hebt, maar ik heb 3.2.18 van
kernel.org geplukt. Erg veel verschil zal het wel niet maken.

3.2.18 is (uitgepakt) 431649626 bytes groot [1], over 37619 bestanden [2],
wat betekent dat de gemiddelde bestandsgrootte ruim 11K is. Dat is niet
bijzonder klein. Interessant is in dit geval ook de verdeling:

* Er zijn maar 2443 bestanden kleiner dan 256 bytes. Dit zijn relatief
weinig files, in vergelijking met een willekeurige svn checkout, waar met
name de svn metadata in .svn bijzonder veel hele kleine bestandjes
opleveren.
* Er zijn 4831 files tussen 256 en 1024 bytes[4]
* Er zijn 4841 files tussen 1024 en 2048 bytes[5]
* Er zijn 6193 files tussen 2048 en 4096 bytes.
* Er zijn 6692 files tussen 4096 en 8192 bytes
* Er zijn 5727 files tussen 8192 en 16384 bytes.
* Er zijn 3894 files tussen 16384 en 32768 bytes
* Er zijn 2998 files van 32KB of groter.

Een Linux kernel valt m.i. dus niet echt onder de noemer "veel kleine
bestanden", terwijl dat nou juist is waar NFS op stuk gaat. Maar zelfs
*dan* is de performance al gehalveerd t.o.v. een native filesystem.

Martijn

[1] du -s -b linux-3.2.18
[2] find linux-3.2.18 -type f| wc -l
[3] find linux-3.2.18 -type f -size -256c| wc -l
[4] find linux-3.2.18 -type f -size +255c -size -1024c | wc -l
[5] Ja, eh, zie [4], maar dan met andere getallen :)

[Martijn van Buul]

Paul van der Vlis (pa...@vandervlis.nl) schreef:

> Hmm. Ik heb klanten die met een home-directory op NFS werken, en ik hoor
> ze niet klagen eigenlijk.

Tsja, dat hoeft ook niet verkeerd te gaan, het hangt er helemaal van
af hoe ze hun homedirectory gebruiken.

> Zou de optie "no_wdelay" voor deze klant nog zinvol kunnen zijn, of zou
> het misschien iets met DNS te maken kunnen hebben?

Het heeft gegarandeerd niets met DNS te maken. Eventuele DNS-problemen
zou je krijgen bij het opbouwen van de verbinding, niet als die verbinding
al een poosje staat.

Voor de rest geldt: Meten is weten. tcpdump draaien, kijken of daar rare
dingen opvallen (zoals rpc retransmissions) en eventuele UDP fragmentatie,
als je UDP gebruikt. Als je TCP gebruikt is het sowieso interessant om
te weten hoeveel retransmissions je hebt, en in hoeverre je TCP windows
worden gebruikt.

Ik neem tenminste aan dat je NFS mount over een lokaal netwerk gebeurt. Zo
niet, dan zit daar de fout. NFS over een VPN oid kan, maar verwacht er
geen flitsende resultaten van.

[Paul van der Vlis]

Op 29-05-12 21:41, Martijn van Buul schreef:

> Paul van der Vlis (pa...@vandervlis.nl) schreef:
>> Hmm. Ik heb klanten die met een home-directory op NFS werken, en ik hoor
>> ze niet klagen eigenlijk.
>
> Tsja, dat hoeft ook niet verkeerd te gaan, het hangt er helemaal van
> af hoe ze hun homedirectory gebruiken.

Ik zat me nog af te vragen wat er met tijdelijke bestanden gebeurd.

Wordt alles bij het uitpakken over het netwerk naar de lokale /tmp
gestuurd en daarna weer terug? Dat moet haast wel, en zoiets geeft
natuurlijk wel vertraging.

>> Zou de optie "no_wdelay" voor deze klant nog zinvol kunnen zijn, of zou
>> het misschien iets met DNS te maken kunnen hebben?
>
> Het heeft gegarandeerd niets met DNS te maken. Eventuele DNS-problemen
> zou je krijgen bij het opbouwen van de verbinding, niet als die verbinding
> al een poosje staat.

Dat zou ik inderdaad ook verwachten.

Ik denk dat wellicht die "async' optie ook veel zou kunnen helpen.

> Voor de rest geldt: Meten is weten. tcpdump draaien, kijken of daar rare
> dingen opvallen (zoals rpc retransmissions) en eventuele UDP fragmentatie,
> als je UDP gebruikt. Als je TCP gebruikt is het sowieso interessant om
> te weten hoeveel retransmissions je hebt, en in hoeverre je TCP windows
> worden gebruikt.

Dat is inderdaad een goede tip. Alleen schiet mijn kennis daar wellicht
wat tekort...

> Ik neem tenminste aan dat je NFS mount over een lokaal netwerk gebeurt.

Inderdaad.

> Zo niet, dan zit daar de fout. NFS over een VPN oid kan, maar verwacht er
> geen flitsende resultaten van.

Dat doe ik inderdaad ook wel, het werkt best aardig.

[Martijn van Buul]

Paul van der Vlis (pa...@vandervlis.nl) schreef:
> Op 29-05-12 21:41, Martijn van Buul schreef:
>> Paul van der Vlis (pa...@vandervlis.nl) schreef:
>>> Hmm. Ik heb klanten die met een home-directory op NFS werken, en ik hoor
>>> ze niet klagen eigenlijk.
>>
>> Tsja, dat hoeft ook niet verkeerd te gaan, het hangt er helemaal van
>> af hoe ze hun homedirectory gebruiken.
>
> Ik zat me nog af te vragen wat er met tijdelijke bestanden gebeurd.

Tijdelijke bestanden belanden vaak in /tmp of /var/tmp, maar dat is in
wezen applicatie-specifiek.

> Wordt alles bij het uitpakken over het netwerk naar de lokale /tmp
> gestuurd en daarna weer terug? Dat moet haast wel, en zoiets geeft
> natuurlijk wel vertraging.

Er wordt naar alle waarschijnlijkheid een pipe opgespannen voor de
communicatie tussen tar en de decompressor-du-jour. Waar de opslag daarvan
terechtkomt weet ik niet uit mijn hoofd, maar het zou me niets verbazen als
dat in een van de ramdisks terecht komt. Het maakt overigens niet zo heel
veel uit (als het op een 'normaal' filesystem terecht komt is de kans dat
het nooit buiten de diskcache komt (en daardoor nooit daadwerkelijk naar
disk wordt geschreven bijzonder groot). Waar de uiteindelijk uitgepakte
tarball terechtkomt daarbij irrelevant.

>>> Zou de optie "no_wdelay" voor deze klant nog zinvol kunnen zijn, of zou
>>> het misschien iets met DNS te maken kunnen hebben?
>>
>> Het heeft gegarandeerd niets met DNS te maken. Eventuele DNS-problemen
>> zou je krijgen bij het opbouwen van de verbinding, niet als die verbinding
>> al een poosje staat.
>
> Dat zou ik inderdaad ook verwachten.
>
> Ik denk dat wellicht die "async' optie ook veel zou kunnen helpen.

Ja, maar die kan je dus ook hoofdpijn opleveren. Het is het eeuwig compromis
tussen snelheid en dataveiligheid.

>> Voor de rest geldt: Meten is weten. tcpdump draaien, kijken of daar rare
>> dingen opvallen (zoals rpc retransmissions) en eventuele UDP fragmentatie,
>> als je UDP gebruikt. Als je TCP gebruikt is het sowieso interessant om
>> te weten hoeveel retransmissions je hebt, en in hoeverre je TCP windows
>> worden gebruikt.
>
> Dat is inderdaad een goede tip. Alleen schiet mijn kennis daar wellicht
> wat tekort...
>
>> Ik neem tenminste aan dat je NFS mount over een lokaal netwerk gebeurt.
>
> Inderdaad.
>
>> Zo niet, dan zit daar de fout. NFS over een VPN oid kan, maar verwacht er
>> geen flitsende resultaten van.
>
> Dat doe ik inderdaad ook wel, het werkt best aardig.

"Best aardig" ja, maar het zal nooit in de buurt komen bij een native
filesystem. Waar NFS last van heeft is latency tussen je NFS client en de
NFS server, omdat er te pas en te onpas op een bevestiging moet worden
gewacht. Daar heb je bij grote bestanden in verhouding minder last van.
Zeer simplistisch voorgesteld komt het wegschrijven van een bestand onder
NFS neer op de volgende "discussie":

NFS Client NFS Server

"Hey, server, maak effe bestand X aan"
"OK, is gebeurd, hier is je
referentie"
"Cool, kun je daar de volgende data
naartoe schrijven?"
"Yup."
"Bedankt, sluit die file nu maar weer af"
"Wat jij wil."


Dat is voor een gedeelte noodgedwongen synchroon, en betekent dat de client
zit te wachten totdat de server antwoord heeft gegeven. Voor kleine
bestanden (zeg, minder dan whatever de MTU is) wordt de netto
doorvoersnelheid dan ook voornamelijk bepaald door het gebabbel tussen
client en server, en dus door je netwerk latency. Voor grote bestanden gaat
de daadwerkelijke bandbreedte een grotere rol spelen. Jammer genoeg kijken
mensen vaak niet verder dan "bandbreedte", wat zich uit in netwerkkaarten
en switches die een aardige doorvoersnelheid hebben, maar een betrekkelijk
slechte latency.

[Winfried Tilanus]

On 05/30/2012 10:56 AM, Paul van der Vlis wrote:

Hoi,

>> Voor de rest geldt: Meten is weten. tcpdump draaien, kijken of daar rare
>> dingen opvallen (zoals rpc retransmissions) en eventuele UDP fragmentatie,
>> als je UDP gebruikt. Als je TCP gebruikt is het sowieso interessant om
>> te weten hoeveel retransmissions je hebt, en in hoeverre je TCP windows
>> worden gebruikt.
> Dat is inderdaad een goede tip. Alleen schiet mijn kennis daar wellicht
> wat tekort...

Wat mij vrij goed bevalt, is met tcpdump remote een dump maken en die
dan lokaal met wireshark openen. Zeker als je niet erg bedreven bent in
het lezen 'raw' lezen data of van te voren niet goed weet waar je naar
op zoek bent, maken de filters en de highlighting van wireshark het
spitten in pakketten een stuk aangenamer.

Zie ook:
http://www.wireshark.org/docs/wsug_html_chunked/AppToolstcpdump.html

groet,

Winfried

[Paul van der Vlis]

Op 30-05-12 12:02, Martijn van Buul schreef:

> Paul van der Vlis (pa...@vandervlis.nl) schreef:
>> Op 29-05-12 21:41, Martijn van Buul schreef:
>>> Paul van der Vlis (pa...@vandervlis.nl) schreef:
>>>> Hmm. Ik heb klanten die met een home-directory op NFS werken, en ik hoor
>>>> ze niet klagen eigenlijk.
>>>
>>> Tsja, dat hoeft ook niet verkeerd te gaan, het hangt er helemaal van
>>> af hoe ze hun homedirectory gebruiken.
>>
>> Ik zat me nog af te vragen wat er met tijdelijke bestanden gebeurd.
>
> Tijdelijke bestanden belanden vaak in /tmp of /var/tmp, maar dat is in
> wezen applicatie-specifiek.
>
>> Wordt alles bij het uitpakken over het netwerk naar de lokale /tmp
>> gestuurd en daarna weer terug? Dat moet haast wel, en zoiets geeft
>> natuurlijk wel vertraging.
>
> Er wordt naar alle waarschijnlijkheid een pipe opgespannen voor de
> communicatie tussen tar en de decompressor-du-jour. Waar de opslag daarvan
> terechtkomt weet ik niet uit mijn hoofd, maar het zou me niets verbazen als
> dat in een van de ramdisks terecht komt. Het maakt overigens niet zo heel
> veel uit (als het op een 'normaal' filesystem terecht komt is de kans dat
> het nooit buiten de diskcache komt (en daardoor nooit daadwerkelijk naar
> disk wordt geschreven bijzonder groot). Waar de uiteindelijk uitgepakte
> tarball terechtkomt daarbij irrelevant.

Het zal in elk geval twee keer over het netwerk moeten, lijkt me.
Het uitpakken gebeurd immers op de lokale processor.

<knip>

> Zeer simplistisch voorgesteld komt het wegschrijven van een bestand onder
> NFS neer op de volgende "discussie":
>
> NFS Client NFS Server
>
> "Hey, server, maak effe bestand X aan"
> "OK, is gebeurd, hier is je
> referentie"
> "Cool, kun je daar de volgende data
> naartoe schrijven?"
> "Yup."
> "Bedankt, sluit die file nu maar weer af"
> "Wat jij wil."
>
> Dat is voor een gedeelte noodgedwongen synchroon, en betekent dat de client
> zit te wachten totdat de server antwoord heeft gegeven. Voor kleine
> bestanden (zeg, minder dan whatever de MTU is) wordt de netto
> doorvoersnelheid dan ook voornamelijk bepaald door het gebabbel tussen
> client en server, en dus door je netwerk latency.

Bedankt voor je uitleg.

> Voor grote bestanden gaat
> de daadwerkelijke bandbreedte een grotere rol spelen. Jammer genoeg kijken
> mensen vaak niet verder dan "bandbreedte", wat zich uit in netwerkkaarten
> en switches die een aardige doorvoersnelheid hebben, maar een betrekkelijk
> slechte latency.

De latency daar lijkt me in orde:
25 packets transmitted, 25 received, 0% packet loss, time 23997ms
rtt min/avg/max/mdev = 0.073/0.074/0.078/0.011 ms

[Richard van den Berg]

Op 27-05-12 19:29, Jeroen Beerstra schreef:

> Hamvraag is denk ik: is jouw nfs nou zo veel sneller dan de mijne of
> valt RAID5 SCSI voor dit doel wat tegen?

Over het NASje en Smart Array 6400 Controller heb ik helemaal geen klagen.

--
Richard

[Martijn Lievaart]

On Thu, 31 May 2012 10:20:02 +0200, Winfried Tilanus wrote:

> On 05/30/2012 10:56 AM, Paul van der Vlis wrote:
>
> Hoi,
>
>>> Voor de rest geldt: Meten is weten. tcpdump draaien, kijken of daar
>>> rare dingen opvallen (zoals rpc retransmissions) en eventuele UDP
>>> fragmentatie,
>>> als je UDP gebruikt. Als je TCP gebruikt is het sowieso interessant om
>>> te weten hoeveel retransmissions je hebt, en in hoeverre je TCP
>>> windows worden gebruikt.
>> Dat is inderdaad een goede tip. Alleen schiet mijn kennis daar wellicht
>> wat tekort...
>
> Wat mij vrij goed bevalt, is met tcpdump remote een dump maken en die
> dan lokaal met wireshark openen. Zeker als je niet erg bedreven bent in
> het lezen 'raw' lezen data of van te voren niet goed weet waar je naar
> op zoek bent, maken de filters en de highlighting van wireshark het
> spitten in pakketten een stuk aangenamer.

Seconded! Ik gebruik alleen dumpcap ipv tcpdump, nog iets lichter.

Vergeet ook niet -s 0 te gebruiken, anders worden je pakketten afgekapt
tot 64 bytes. Om dit specifieke probleem op te lossen is afgekapt
waarschijnlijk niet erg, maar complete paketten maakt de dumps meestal
makkelijker te lezen.

Als je de dumps hebt, wil ik best even meekijken, mail me op m
aartstaartje rtij punt nl.

M4