All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jasper Mackenzie" <jasper.mackenzie@gmail.com>
To: "Trond Myklebust" <trond.myklebust@fys.uio.no>
Cc: linux-nfs@vger.kernel.org
Subject: Re: Problem: Clients freeze on transfer of large files, w gigabit lan
Date: Tue, 29 Jun 2010 08:27:54 +1200	[thread overview]
Message-ID: <op.ve01ssl6o2qfwp@foundation> (raw)
In-Reply-To: <1277755997.4433.8.camel@heimdal.trondhjem.org>


>> >>     I and many others have been plagued by a problem that can be
>> >> summarised
>> >> as follows:
>> >>
>> >> Client hangs upon copying of large files TO the server. Transfer  
>> begins
>> >> quickly then hangs, sometimes taking the client o/s with it, until
>> >> transfer starts again. In less extreme cases transfer is sporadic.
>> >>     I am using nfs4 w gigabit nics.
>> >> http://ubuntuforums.org/showthread.php?p=9269703
>> >>     It appears that this problem is not restricted to ubuntu and  
>> exists
>> >
>> > Could this perhaps be related to the following bugzilla entry?
>> >     https://bugzilla.kernel.org/show_bug.cgi?id=16213
>> >
>> > If so, then could you please try the proposed fix and see if it helps.
>> >
>> > Cheers
>> >   Trond
>>   Thanks Trond,
>> The patch solved the client lockups with a patched vanilla kernel (will
>> keep trying with an ubuntu kernel, as it should do the same, but didnt)
>>
>> Unfortunatley it dousnt fix the other problem, as it seems they are
>> separate, of the transfer happening in bursts, reducing the actual
>> throughput dramatically. i.e transfer starts at 16mb/s (according to
>> nautilus), then 3 or 4 seconds later the progress bar stops, the hdd
>> activity also stops (its the same with cp of course, nautilus just gives
>> me a good indication of xfer speed), then 4 or 5 seconds later it starts
>> again for 3 or 4 seconds.... repeat ad nausium...
>>   Refer to the forum thread for graphs etc. of throughput if nesc.
>
> That is usually because the server is caching too much data instead of
> progressively writing it out. When the client calls 'commit' (the NFS
> equivalent of fsync()) then the disk on the server goes into a frenzy of
> writing, and the client does the RPC equivalent of twiddling its thumbs
> until the server is done...
>
> I'd suggest trying to lower the values
> of /proc/sys/vm/dirty_expire_centisecs
> and /proc/sys/vm/dirty_background_ratio on the server. You might also
> try lowering /proc/sys/vm/dirty_writeback_centisecs...
>
> Cheers
>   Trond
  I reduced them to 10% of the value I found them at to 40,1,20  
respectivly, with no improvement.
I think I need to play with it more to see if the lockups are gone. Ime  
not sure if the original problem is quite fixed...
dammit. was too easy !

  When tested with ubuntu more, I will see how the ppl on the above forum  
go.

any other ideas?

Thanks

Jasper

      reply	other threads:[~2010-06-28 20:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-25  4:44 Problem: Clients freeze on transfer of large files, w gigabit lan Jasper Mackenzie
2010-06-25 18:51 ` Trond Myklebust
     [not found]   ` <1277491873.6141.23.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2010-06-28 19:45     ` Jasper Mackenzie
2010-06-28 20:13       ` Trond Myklebust
2010-06-28 20:27         ` Jasper Mackenzie [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=op.ve01ssl6o2qfwp@foundation \
    --to=jasper.mackenzie@gmail.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@fys.uio.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.