From: "Roger Heflin" <rheflin@atipa.com>
To: "'Steven Timm'" <timm@fnal.gov>, <linux-kernel@vger.kernel.org>
Subject: RE: rpc-srv/tcp: nfsd: sent only -107 bytes (fwd)
Date: Mon, 7 Nov 2005 09:47:18 -0600 [thread overview]
Message-ID: <EXCHG2003o4lB4BwOZx000005bd@EXCHG2003.microtech-ks.com> (raw)
In-Reply-To: <Pine.LNX.4.62.0511021405430.20925@snowball.fnal.gov>
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Steven Timm
> Sent: Wednesday, November 02, 2005 2:06 PM
> To: linux-kernel@vger.kernel.org
> Subject: rpc-srv/tcp: nfsd: sent only -107 bytes (fwd)
>
>
>
> I am seeing repeated errors of rpc-srv/tcp: nfsd: sent only
> -107 bytes in the /var/log/messages of my machine. Full
> configuration info is below. Only suggestion I have seen
> thus far increase the number of nfsd that are running. we
> have done this, raising from 8 to 64, the problem persists.
> Are there any other suggestions that could help this problem?
>
> Thanks
>
I have only seen this problem with large numbers of NFS clients, given
your address I suspect that would be the issue.
What kernel are you running? I saw this issue on the 2.4 series, the
large 2.6 things we have built avoided using TCP given that we had
seen this issue.
There is a calculation someplace in nfs that determines how many of these
things exist, is is some base + so many per nfs thread. If you
search for message you have there are some posts on the NFS lists
about it that I made last year.
On the client side each separate mount against a server counts as
one, so if each client is mounting /opt and /home and /data and
you have 100 machines you need at least 300.
The solution that I came to was to use UDP mounts, as this limit
is not there. In the situation I had we would have had to change
the number of nfsd to 256 and even that was going to be close,
and the 256 caused some other failures. To not have the issue you
will need to use UDP mounts everywere if you have enough tcp mounts
to cause the error it will affect the udp mounts in a similar bad way.
We also could have changed the thread to resource count, but we had
some other process starvation issue with TCP that seemed to not be
duplicatable with UDP.
Roger
Atipa Technologies
next prev parent reply other threads:[~2005-11-07 15:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-02 20:06 Steven Timm
2005-11-07 15:47 ` Roger Heflin [this message]
2005-11-07 15:59 ` Steven Timm
2005-11-07 16:41 ` Roger Heflin
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=EXCHG2003o4lB4BwOZx000005bd@EXCHG2003.microtech-ks.com \
--to=rheflin@atipa.com \
--cc=linux-kernel@vger.kernel.org \
--cc=timm@fnal.gov \
/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
all inboxes | Powered by JetHome®