SCIENTIFIC-LINUX-USERS Archives

February 2012

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Chris Schanzle <[log in to unmask]>
Reply To:
Chris Schanzle <[log in to unmask]>
Date:
Wed, 29 Feb 2012 01:48:51 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (31 lines)
On 02/28/2012 05:05 PM, Chris Schanzle wrote:
> On 02/28/2012 02:25 PM, Vladimir Mosgalin wrote:
>>    On 2012.02.28 at 11:32:17 -0500, Wayne Betts wrote next:
>>
>>> We have a couple of Scientific Linux 6.1 NFS servers.  I looked at
>>> /proc/net/rpc/nfsd and was surprised to see on both of them that
>>> the thread histogram is all zero:
>>>
>>> # cat /proc/net/rpc/nfsd | grep th
>>> th 8 0 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
>>
>> It is the same for me on nfs4 server on SL6.2
>>
>> What statistics are you trying to get? What's wrong with standard way of
>> querying nfs server, "nfsstat -s" command?
>> It's much better than looking in proc, because the file you see there is
>> specific only to current linux kernel-mode nfs implementation, while
>> nfsstat -s *is* the correct and portable way across various systems.
>
>
> The "th" statistics are unique to monitoring if you have the proper # of nfsd threads running; 'nfsstat -s' can't show that.
>
> I looked at this issue several months ago and I recall, but cannot find reference today, that the kernel developers decided the code to collect statistics was broken and they've disabled it.


Dug some more and got lucky...found the git commit message about the code removal and explains the rationale (missed counts, performance):

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=8bbfa9f3889b643fc7de82c0c761ef17097f8faf

I see the logic in 'bad statistics are worse than no statistics', but it's a shame they didn't leave it in as a tunable to enable/disable.  Maybe if you are adventurous you could reverse-apply the patch and build your own kernel; it's quite short, and building custom kernels is something everyone should try at some point.  :-)

ATOM RSS1 RSS2