On Thu, Mar 12, 2009 at 09:45:04AM -0700, Kevin Constantine wrote:
> J. Bruce Fields wrote:
>> On Thu, Mar 12, 2009 at 12:08:57PM -0400, Chuck Lever wrote:
>>> On Mar 12, 2009, at Mar 12, 2009, 11:50 AM, J. Bruce Fields wrote:
>>>> On Thu, Mar 12, 2009 at 10:00:34AM -0400, Chuck Lever wrote:
>>>>> Hi Kevin-
>>>>>
>>>>> man watch(1)
>>>> What would you watch?
>>> For example:
>>>
>>> watch -n3 nfsstat -c
>>>
>>> You can also use the "-d" option to highlight the differences between
>>> the current sample and the previous sample.
>>
>> He was asking for deltas; the above only gives cumulative totals.
>>
>> There's no accurate one-line solution using the existing nfsstat
>> commandline, but it should be easy to add.
>>
>
> Something like this sort of works:
> watch -n 1 'nfsstat --since /tmp/stats; nfsstat >/tmp/stats', but it
> feels more like a workaround than a feature.
It's also slightly inaccurate, since it misses any activity that
happened in the brief time between the two invocations.
> Using watch doesn't allow you to see what happened in the past either.
>
> Moving to a listed output format instead of the traditional nfsstat
> output (as seen below) makes it trivial with a simple grep to watch the
> stats that you really care about and ignore the rest.
I think we'd all be happy to take patches.--b.
> -kevin
>
>
>> --b.
>>
>>>> --b.
>>>>
>>>>> On Mar 11, 2009, at Mar 11, 2009, 9:37 PM, Kevin Constantine wrote:
>>>>>
>>>>>> I'd really like to have a way to output the nfsstat counters at
>>>>>> regular intervals (every 3 seconds) where the output is the
>>>>>> difference
>>>>>> between 3 seconds ago and now. Frequently I'll run a test and
>>>>>> want to
>>>>>> watch the nfs call profile throughout the course of the test.
>>>>>>
>>>>>> Does something like this already exist?
>>>>>> Are there objections to seeing a feature like this?
>>>>>>
>>>>>> I'm thinking something like:
>>>>>> nfsstat --sleep=1
>>>>>>
>>>>>> nfs v3 call: Server Client
>>>>>> total: 0 3476
>>>>>> null: 0 0
>>>>>> getattr: 0 1679
>>>>>> setattr: 0 0
>>>>>> lookup: 0 839
>>>>>> access: 0 839
>>>>>> readlink: 0 0
>>>>>> read: 0 0
>>>>>> write: 0 0
>>>>>> create: 0 0
>>>>>> mkdir: 0 0
>>>>>> symlink: 0 0
>>>>>> mknod: 0 0
>>>>>> remove: 0 0
>>>>>> rmdir: 0 0
>>>>>> rename: 0 0
>>>>>> link: 0 0
>>>>>> readdir: 0 0
>>>>>> readdirplus: 0 0
>>>>>> fsstat: 0 119
>>>>>> fsinfo: 0 0
>>>>>> pathconf: 0 0
>>>>>> commit: 0 0
>>>>>>
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs"
>>>>>> in
>>>>>> the body of a message to [email protected]
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>> --
>>>>> Chuck Lever
>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>> linux-nfs" in
>>>>> the body of a message to [email protected]
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> --
>>> Chuck Lever
>>> chuck[dot]lever[at]oracle[dot]com
>>>
>>>
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
J. Bruce Fields wrote:
> On Thu, Mar 12, 2009 at 09:45:04AM -0700, Kevin Constantine wrote:
>> J. Bruce Fields wrote:
>>> On Thu, Mar 12, 2009 at 12:08:57PM -0400, Chuck Lever wrote:
>>>> On Mar 12, 2009, at Mar 12, 2009, 11:50 AM, J. Bruce Fields wrote:
>>>>> On Thu, Mar 12, 2009 at 10:00:34AM -0400, Chuck Lever wrote:
>>>>>> Hi Kevin-
>>>>>>
>>>>>> man watch(1)
>>>>> What would you watch?
>>>> For example:
>>>>
>>>> watch -n3 nfsstat -c
>>>>
>>>> You can also use the "-d" option to highlight the differences between
>>>> the current sample and the previous sample.
>>> He was asking for deltas; the above only gives cumulative totals.
>>>
>>> There's no accurate one-line solution using the existing nfsstat
>>> commandline, but it should be easy to add.
>>>
>> Something like this sort of works:
>> watch -n 1 'nfsstat --since /tmp/stats; nfsstat >/tmp/stats', but it
>> feels more like a workaround than a feature.
>
> It's also slightly inaccurate, since it misses any activity that
> happened in the brief time between the two invocations.
>
>> Using watch doesn't allow you to see what happened in the past either.
>>
>> Moving to a listed output format instead of the traditional nfsstat
>> output (as seen below) makes it trivial with a simple grep to watch the
>> stats that you really care about and ignore the rest.
>
> I think we'd all be happy to take patches.--b.
>
Cool. I'll spend some time today then.
>
>> -kevin
>>
>>
>>> --b.
>>>
>>>>> --b.
>>>>>
>>>>>> On Mar 11, 2009, at Mar 11, 2009, 9:37 PM, Kevin Constantine wrote:
>>>>>>
>>>>>>> I'd really like to have a way to output the nfsstat counters at
>>>>>>> regular intervals (every 3 seconds) where the output is the
>>>>>>> difference
>>>>>>> between 3 seconds ago and now. Frequently I'll run a test and
>>>>>>> want to
>>>>>>> watch the nfs call profile throughout the course of the test.
>>>>>>>
>>>>>>> Does something like this already exist?
>>>>>>> Are there objections to seeing a feature like this?
>>>>>>>
>>>>>>> I'm thinking something like:
>>>>>>> nfsstat --sleep=1
>>>>>>>
>>>>>>> nfs v3 call: Server Client
>>>>>>> total: 0 3476
>>>>>>> null: 0 0
>>>>>>> getattr: 0 1679
>>>>>>> setattr: 0 0
>>>>>>> lookup: 0 839
>>>>>>> access: 0 839
>>>>>>> readlink: 0 0
>>>>>>> read: 0 0
>>>>>>> write: 0 0
>>>>>>> create: 0 0
>>>>>>> mkdir: 0 0
>>>>>>> symlink: 0 0
>>>>>>> mknod: 0 0
>>>>>>> remove: 0 0
>>>>>>> rmdir: 0 0
>>>>>>> rename: 0 0
>>>>>>> link: 0 0
>>>>>>> readdir: 0 0
>>>>>>> readdirplus: 0 0
>>>>>>> fsstat: 0 119
>>>>>>> fsinfo: 0 0
>>>>>>> pathconf: 0 0
>>>>>>> commit: 0 0
>>>>>>>
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs"
>>>>>>> in
>>>>>>> the body of a message to [email protected]
>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>> --
>>>>>> Chuck Lever
>>>>>> chuck[dot]lever[at]oracle[dot]com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>> linux-nfs" in
>>>>>> the body of a message to [email protected]
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> --
>>>> Chuck Lever
>>>> chuck[dot]lever[at]oracle[dot]com
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>> the body of a message to [email protected]
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
------------------------------------------------------------
Kevin Constantine
Systems Engineer t: 818.460.8221
Walt Disney Animation Studios e: kevin.constantine-P5ys19MLBK/[email protected]
Any sufficiently advanced technology is indistinguishable from magic.
- Arthur C. Clarke
On Mar 12, 2009, at Mar 12, 2009, 12:48 PM, J. Bruce Fields wrote:
> On Thu, Mar 12, 2009 at 09:45:04AM -0700, Kevin Constantine wrote:
>> J. Bruce Fields wrote:
>>> On Thu, Mar 12, 2009 at 12:08:57PM -0400, Chuck Lever wrote:
>>>> On Mar 12, 2009, at Mar 12, 2009, 11:50 AM, J. Bruce Fields wrote:
>>>>> On Thu, Mar 12, 2009 at 10:00:34AM -0400, Chuck Lever wrote:
>>>>>> Hi Kevin-
>>>>>>
>>>>>> man watch(1)
>>>>> What would you watch?
>>>> For example:
>>>>
>>>> watch -n3 nfsstat -c
>>>>
>>>> You can also use the "-d" option to highlight the differences
>>>> between
>>>> the current sample and the previous sample.
>>>
>>> He was asking for deltas; the above only gives cumulative totals.
>>>
>>> There's no accurate one-line solution using the existing nfsstat
>>> commandline, but it should be easy to add.
>>>
>>
>> Something like this sort of works:
>> watch -n 1 'nfsstat --since /tmp/stats; nfsstat >/tmp/stats', but it
>> feels more like a workaround than a feature.
>
> It's also slightly inaccurate, since it misses any activity that
> happened in the brief time between the two invocations.
>
>> Using watch doesn't allow you to see what happened in the past
>> either.
>>
>> Moving to a listed output format instead of the traditional nfsstat
>> output (as seen below) makes it trivial with a simple grep to watch
>> the
>> stats that you really care about and ignore the rest.
>
> I think we'd all be happy to take patches.--b.
Actually I would rather see the performance metrics scripts improved.
These tools give a lot more information than nfsstat ever will be able
to.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Thu, Mar 12, 2009 at 01:22:32PM -0400, Chuck Lever wrote:
> Actually I would rather see the performance metrics scripts improved.
> These tools give a lot more information than nfsstat ever will be able
> to.
Probably so, but those scripts are a bit hard to find, aren't they?
We should
- get distributions to install them by default
- write man pages?
- add references to them where possible (from the nfsstat man
page, from howto's/faq's/?)
Until then, unfortunately, improvements to nfsstat are more useful,
since nfsstat is the thing people are more likely to run across.
(Which might be an argument just for adding their functionality into
nfsstat--that would have the one benefit that there'd be only one
command name users have to know about.)
--b.
On Mar 12, 2009, at Mar 12, 2009, 3:32 PM, J. Bruce Fields wrote:
> On Thu, Mar 12, 2009 at 01:22:32PM -0400, Chuck Lever wrote:
>> Actually I would rather see the performance metrics scripts improved.
>> These tools give a lot more information than nfsstat ever will be
>> able
>> to.
>
> Probably so, but those scripts are a bit hard to find, aren't they?
>
> We should
> - get distributions to install them by default
> - write man pages?
> - add references to them where possible (from the nfsstat man
> page, from howto's/faq's/?)
Steve promised me Red Hat would take care of this when these were
added to nfs-utils last year.
> Until then, unfortunately, improvements to nfsstat are more useful,
> since nfsstat is the thing people are more likely to run across.
Again, I think improving nfsstat at this point (which is merely for
compatibility with Solaris) would be wasted work, if we already have
what is needed in another tool. The Python tools are much more
sophisticated, and it would be confusing to add their functionality to
nfsstat (e.g. why can I zero the legacy stats with the -z option, but
not the stats the come from /proc/self/mountstats?).
Let's spend the effort on the tools that give us deeper results.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
Chuck Lever wrote:
> On Mar 12, 2009, at Mar 12, 2009, 3:32 PM, J. Bruce Fields wrote:
>> On Thu, Mar 12, 2009 at 01:22:32PM -0400, Chuck Lever wrote:
>>> Actually I would rather see the performance metrics scripts improved.
>>> These tools give a lot more information than nfsstat ever will be able
>>> to.
>>
>> Probably so, but those scripts are a bit hard to find, aren't they?
>>
>> We should
>> - get distributions to install them by default
>> - write man pages?
>> - add references to them where possible (from the nfsstat man
>> page, from howto's/faq's/?)
>
> Steve promised me Red Hat would take care of this when these were added
> to nfs-utils last year.
Not sure what I exactly promised (that's usually not my style 8-) )
but those scripts definitely fell off my radar...
>
>> Until then, unfortunately, improvements to nfsstat are more useful,
>> since nfsstat is the thing people are more likely to run across.
>
> Again, I think improving nfsstat at this point (which is merely for
> compatibility with Solaris) would be wasted work, if we already have
> what is needed in another tool. The Python tools are much more
> sophisticated, and it would be confusing to add their functionality to
> nfsstat (e.g. why can I zero the legacy stats with the -z option, but
> not the stats the come from /proc/self/mountstats?).
>
> Let's spend the effort on the tools that give us deeper results.
I have to agree... I truly think there is a wealth of untapped information
in those mountstats... Just waiting for someone to dip them out...
steved.