nfsd server cache flooded, try to increase nfsrc_floodlevel

[Rick Macklem]

Harald Schmalzbauer wrote:
> Bezüglich Rick Macklem's Nachricht vom 25.07.2014 13:14 (localtime):
> > Harald Schmalzbauer wrote:
> >> Bezüglich Rick Macklem's Nachricht vom 25.07.2014 02:14
> >> (localtime):
> >>> Harald Schmalzbauer wrote:
> >>>> Bezüglich Rick Macklem's Nachricht vom 08.08.2013 14:20
> >>>> (localtime):
> >>>>> Lars Eggert wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> every few days or so, my -STABLE NFS server (v3 and v4) gets
> >>>>>> wedged
> >>>>>> with a ton of messages about "nfsd server cache flooded, try
> >>>>>> to
> >>>>>> increase nfsrc_floodlevel" in the log, and nfsstat shows
> >>>>>> TCPPeak
> >>>>>> at
> >>>>>> 16385. It requires a reboot to unwedge, restarting the server
> >>>>>> does
> >>>>>> not help.
> >>>>>>
> >>>>>> …
> >> IMHO such a setup shouldn't require manual tuning and I consider
> >> this
> >> as
> >> a really urgent problem!
> >> Whatever causes the server to lock up is strongly required to be
> >> fixed
> >> for next release,
> >> otherwise the shipped implementation of NFS is not really suitable
> >> for
> >> production environment and needs a warning message when enabled.
> >> The impact of this failure forces admins to change the operation
> >> system
> >> in order to get a core service back into operation.
> >> The importance is, that I don't suffer from weaker performance or
> >> lags/delays, but my server stops NFS completely and only a reboot
> >> solves
> >> this situation.
> >>
> > Btw, you can increase vfs.nfsd.tcphighwater on the fly when it
> > wedges
> > and avoid having to reboot.
> One suggestion: If raising vfs.nfsd.tcphighwater at runtime solves
> the
> locked nfsserver (which I thought I have tried, but I'm not sure any
> more), maybe the log message should reflect that. My first guess was
> to
> look for a systcl named 'nfsrc_floodlevel'. If the log message makes
> more sense to contain nfsrc_floodlevel instead of tcphighwater, the
> latter should be metioned in the man page anyway.
> 
Yes, I'll admit I had intended to do that, but it slipped through the
cracks. I will also try and make sure that bumping it up will allow the
server to get working again without a reboot.

> If the problem is solvable without rebooting, it's a cosmetic problem
> IMHO, not that serious show stopper I considered at first.
> Evereything
> but a reboot is fine ;-)
> 
I would like to come up with a way to tune this based on server size
(RAM + 32 vs 64bit arch or similar), but it may take a while to gather
enough knowledge to do so.

rick

> Thanks,
> 
> -Harry
> 
> 
> 
> 
>