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.