From: "Gary L. Grobe" <gary@grobe.net>
To: "J. Bruce Fields" <bfields@fieldses.org>,
"Gary L. Grobe" <gary@grobe.net>
Cc: linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org,
"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: processes in D state too long too often
Date: Tue, 10 Feb 2009 01:04:10 +0000 [thread overview]
Message-ID: <W27744109726791234227850@webmail24> (raw)
>Presumably that's the msleep(10) in nfsd_vfs_write().
>
>That wouldn't explain the same nfsd thread waiting for several seconds,
>though. Or was it just that that several seconds during which different
>nfsd threads were stuck in D, not necessarily the same ones?
>
>What does your /etc/exports file look like on the server, and what are
>the mount options on the client?
>
>You could try turning off that msleep() with no_wdelay, but it may not
>help.
>
>The more likely explanation is that you just switched to a more recent
>distro where "sync" (as opposed to "async") is the option. Depending on
>workload, "async" may improve performance a great deal, at the expense
>of possible data corruption on server reboot!
>
>If you're doing a lot of writing and using NFSv2, then switching to
>NFSv3 may give you performance close to the "async" performance without
>the corruption worries.
Apologies for the unintentional separate thread.
I really think I'm seeing the same nfsd threads going into D for a very short time. Here's what's in /etc/exports ...
/diskless/10.0.1.1 10.0.1.1(sync,rw,no_root_squash,no_all_squash,no_subtree_check)
/diskless/10.0.1.2 10.0.1.2(sync,rw,no_root_squash,no_all_squash,no_subtree_check)
/diskless/10.0.1.3 10.0.1.3(sync,rw,no_root_squash,no_all_squash,no_subtree_check)
# ... same lines above for another 80+ nodes
# Common to all slave nodes.
/usr 10.0.0.0/16(sync,ro,subtree_check,no_root_squash,no_all_squash)
/opt 10.0.0.0/16(sync,rw,no_subtree_check,no_root_squash,no_all_squash)
/home 10.0.0.0/16(sync,rw,no_subtree_check,no_root_squash,no_all_squash)
#/var/log 10.0.0.0/16(sync,rw,subtree_check,no_root_squash,no_all_squash)
Mount options on each client are as follows ...
10.0.0.10:/diskless/10.0.1.1 / nfs sync,hard,intr,rw,rsize=8192,wsize=8192 0 0
10.0.0.10:/opt /opt nfs sync,hard,intr,rw,rsize=8192,wsize=8192 0 0
10.0.0.10:/usr /usr nfs sync,hard,intr,ro,rsize=8192,wsize=8192 0 0
10.0.0.10:/home /home nfs sync,hard,intr,rw,rsize=8192,wsize=8192 0 0
none /proc proc defaults 0 0
#10.0.0.10:/var/log /var/log nfs sync,hard,intr,rw 0 0
I'm not following turning off the msleep() option. Where are you referring to this from?
I've got NFSv3 enabled and have used this in a previous installation (using the same distro, gentoo) on this same hardware with no issues, and 'sync', and the performance was much better. Something worth noting, I've rolled back my kernel several times now and each time I go back (w/ same vers on master and slave node), the D state time in simulation processes keeps getting better (cut down). I went from 2.6.27-r7 to 2.6.24-r8 and now I'm running 2.6.20-r10, and each one better than the previous (and later) kernel. I was running 2.6.18-r2 in the past, which I'm having difficulties getting at the moment.
next reply other threads:[~2009-02-10 1:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-10 1:04 Gary L. Grobe [this message]
2009-02-10 16:02 ` processes in D state too long too often J. Bruce Fields
-- strict thread matches above, loose matches on Subject: below --
2009-02-10 2:18 Gary L. Grobe
2009-02-10 16:02 ` J. Bruce Fields
2009-02-07 20:49 Gary L. Grobe
2009-02-09 21:27 ` J. Bruce Fields
2009-02-07 6:30 processes in D State " Gary L. Grobe
2009-02-07 6:45 ` Andrew Morton
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=W27744109726791234227850@webmail24 \
--to=gary@grobe.net \
--cc=akpm@linux-foundation.org \
--cc=bfields@fieldses.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox