[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: how to counteract slowdown

On Monday November 12, akpm zip com au wrote:
> > Under heavy NFS load, I get pauses of a few seconds every few minutes.
> > If I
> >    echo 40 0 0 0 60 300 60 0 0 > /proc/sys/vm/bdflush
> > 
> > the problem goes away.
> So how long have you been sitting on this info, you, you,
> you Australian, you?

Ever since
   Date: Thu, 12 Jul 2001 21:51:36 +1000 (EST)
when I first told you about it.... (non-list email to You, Stephen and

> Once the current transaction reaches 1/4 of the journal size
> we start a commit.   If we then see that there isnt enough
> free space in the journal (1/4 plus a bit) we force a checkpoint.
> That involves forcing writeback of all checkpointable data.  It's
> fairly savage.

Of course in my case with a "sync" export, you never get a single
transaction that big...  Lots of little transactions.  Each 8K NFS
write would become a transaction of 2 data blocks, one indirect block,
one inode block, one transaction descriptor block, and one commit
block at a guess. 6 blocks.  Does that sound right?  That's assuming
quotas aren't turned on.

> Could you please explain to me how knfsd threads map onto
> clients?  Does a user have their "own" thread on the server?
> If a particular thread were blocked for a long time, would
> a particular user see this, or would another thread serve their
> request?
> If a particular knfsd thread were to get blocked for some time in the
> underlying fs, would that affect the other threads?  Is some lock
> held?
> (Actually, if other threads call in and try to start transactions
> when the journal is out of space, they'll probably get blocked on the
> writeout as well).

Arriving NFS requests are fairly independant.  Each one goes to the
first available thread.  Normally the only inter-thread contention is
i_sem when they are both writing to the same file.  But yes, I think
they all end up either waiting on the journal, or waiting on i_sem
which is held by a thread which is waiting on the journal.

> However in this case, I'm theorising that the blockage is on
> checkpoint writeback: ie, the data which has already been
> written into the journal and which is now being written into
> the main fs - we can't recycle the journal space until this data
> has hit disk, and we write it _all_ out.

ahh.. so if the journal gets full, you wait until it is empty(*) and
then continue.  Definately room for some optimisation there.

(*) by "empty" I mean that all transactions in the journal have been
committed to non-journal storage.  Not that there aren't any
transactions in the journal.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]