Date:	Thu, 31 Jul 2008 17:03:05 +1000
From:	Neil Brown <neilb@...e.de>
To:	"J. Bruce Fields" <bfields@...ldses.org>
Cc:	Michael Shuey <shuey@...due.edu>,
	Shehjar Tikoo <shehjart@....unsw.edu.au>,
	linux-kernel@...r.kernel.org, linux-nfs@...r.kernel.org,
	rees@...i.umich.edu, aglo@...i.umich.edu
Subject: Re: high latency NFS

On Wednesday July 30, bfields@...ldses.org wrote:
> > 
> > I was only using the default 8 nfsd threads on the server.  When I raised 
> > this to 256, the read bandwidth went from about 6 MB/sec to about 95 
> > MB/sec, at 100ms of netem-induced latency.
> 
> So this is yet another reminder that someone needs to implement some
> kind of automatic tuning of the number of threads.
> 
> I guess the first question is what exactly the policy for that should
> be?  How do we decide when to add another thread?  How do we decide when
> there are too many?

Or should the first question be "what are we trying to achieve?"?

Do we want to:
    Automatically choose a number of threads that would match what a
      well informed sysadmin might choose
or
    regularly adjust the number of threads to find an optimal balance
      between prompt request processing (minimal queue length),
      minimal resource usage (idle threads waste memory)
    and not overloading the filesystem (how much concurrency does the
        filesystem/storage subsystem realistically support.

And then we need to think about how this relates to NUMA situations
where we have different numbers of threads on each node.


I think we really want to aim for the first of the above options, but
that the result will end up looking a bit like a very simplistic
attempt at the second.  "simplicitic" is key - we don't want
"complex".

I think that in the NUMA case we probably want to balance each node
independently.

The difficulties - I think - are:
  - make sure we can handle a sudden surge of requests, certainly a
    surge up to levels that we have previously seen.
    I think the means we either don't kill excess threads, or
    only kill them up to a limit: e.g. never fewer than 50% of
    the maximum number of threads
  - make sure we don't create too many threads if something clags up
    and nothing is getting through.  This means we need to monitor the
    number of requests dequeued and not make new threads when that is
    zero.
 

So how about:
  For each node we watch the length of the queue of
  requests-awaiting-threads and the queue of threads
  awaiting requests and maintain these values:
    - max number of threads ever concurrently running
    - number of requests dequeued
    - min length request queue
    - min length of thread queue

  Then every few (5?) seconds we sample these numbers and reset them
     (except the first).
     If 
        the min request queue length is non-zero and 
        the number of requests dequeued is non-zero
     Then
        start a new thread
     If
        the number of threads exceeds half the maximum and
        the min length of the thread queue exceeds 0
     Then
        stop one (idle) thread

You might want to track the max length of the request queue too and
start more threads if the queue is long, to allow a quick ramp-up.

We could try this allow by allowing you to write "auto" to the
'threads' file, so people can experiment.


NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists