From: "J. Bruce Fields" <bfields@fieldses.org>
To: Steve Dickson <SteveD@redhat.com>
Cc: Linux NFS Mailing List <nfs@lists.sourceforge.net>
Subject: Re: [PATCH] NFS: Zeroing NFS and kNFSD stats
Date: Tue, 13 Jul 2004 14:01:08 -0400 [thread overview]
Message-ID: <20040713180108.GF3023@fieldses.org> (raw)
In-Reply-To: <20040713151759.GC3023@fieldses.org>
On Tue, Jul 13, 2004 at 11:17:59AM -0400, J. Bruce Fields wrote:
> On Tue, Jul 13, 2004 at 11:08:08AM -0400, Steve Dickson wrote:
> > Starting up a test run, zeroing out the stats give you a very clear
> > picture of what exactly is going on...
>
> But you could exactly the same thing by recording the values at the
> beginning of the test run and then subtracting. In practice this is
> likely to be annoying, so you'd want to write utilities that did this
> for you, like say
>
> checkpoint_stats stats.txt
> display_stats --since stats.txt
>
> That'd do what you want, right?
The problem I have, by the way, is that zeroing is going to cause
confusing problems whenever there are two simultaneous attempts to
collect statistics.
For example, imagine that your NFS server has a persistent
performance-monitoring daemon that checks the statistics every now and
then and emails the adminstrator a summary once a week.
Then imagine that one day you have a problem with the server, so you log
in and do a quick check of some statistics, zeroing them in the process.
Now the daemon has no more hope of getting its numbers right. Murphy's
law being what it is, you and the adminstrator that gets the summary
email are probably different people, and by the time he/she gets the
very odd-looking end-of-week report you've forgotten that you zeroed the
statistics once. Head-scratching ensues.
Writing a script to do the subtraction is just as simple and avoids any
such problems.
--b.
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2004-07-13 18:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-13 12:24 [PATCH] NFS: Zeroing NFS and kNFSD stats Steve Dickson
2004-07-13 14:30 ` J. Bruce Fields
2004-07-13 15:08 ` Steve Dickson
2004-07-13 15:17 ` J. Bruce Fields
2004-07-13 18:01 ` J. Bruce Fields [this message]
2004-07-13 20:16 ` Steve Dickson
2004-07-14 23:20 ` J. Bruce Fields
2004-07-16 0:39 ` Ben Woodard
2004-07-13 21:09 ` Garrick Staples
2004-07-14 23:24 ` J. Bruce Fields
2004-08-02 10:39 ` Olaf Kirch
2004-08-04 20:14 ` J. Bruce Fields
2004-08-05 5:26 ` Greg Banks
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=20040713180108.GF3023@fieldses.org \
--to=bfields@fieldses.org \
--cc=SteveD@redhat.com \
--cc=nfs@lists.sourceforge.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.