From: Dave Chinner <david@fromorbit.com>
To: Yannis Klonatos <klonatos@ics.forth.gr>
Cc: xfs@oss.sgi.com
Subject: Re: Metadata hit ratio
Date: Fri, 25 Jun 2010 11:15:47 +1000 [thread overview]
Message-ID: <20100625011547.GU6590@dastard> (raw)
In-Reply-To: <4C23C074.5080100@ics.forth.gr>
On Thu, Jun 24, 2010 at 11:30:44PM +0300, Yannis Klonatos wrote:
> Hello all,
>
> Along with my other (yet pending :-( ) question/issue, I
> have another question (i hope this is the last :-) )
> now.
> I would like to measure the hit ratio of the metadata
> accesses of XFS (inode+internal buffers). It is my
> understanding that XFS uses its own data structures, and does not
> rely on the buffercache mechanisms of
> the Linux kernel. However, even doing so, there may be cases that
> the metadata may not fit in the RAM,
> and I/O operations are required to fetch them from the underlying
> storage. I have found out that there are
> two places that XFS uses the submit_bio function. If i add some
> counters there, would it suffice to measure all
> the metadata misses?
> Or is this information available in one (or more) of the
> xfs_stats counters? And if so, what do i need to sum
> up in order to get the total metadata hit and miss ratio?
Start by looking here:
http://xfs.org/index.php/Runtime_Stats
But you probably want some of the buf counters which are
undocumented on that page, so a rough description of them is
(from PCP):
$ pminfo -t xfs.buffer
xfs.buffer.get [number of request buffer calls]
xfs.buffer.create [number of buffers created]
xfs.buffer.get_locked [number of requests for a locked buffer which succeeded]
xfs.buffer.get_locked_waited [number of requests for a locked buffer which waited]
xfs.buffer.busy_locked [number of non-blocking requests for a locked buffer which failed]
xfs.buffer.miss_locked [number of requests for a locked buffer which failed due to no buffer]
xfs.buffer.page_retries [number of retry attempts when allocating a page for insertion in a buffer]
xfs.buffer.page_found [number of hits in the page cache when looking for a page]
xfs.buffer.get_read [number of buffer get calls requiring immediate device reads]
So you might be able to get something from those stats.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2010-06-25 1:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-24 20:30 Metadata hit ratio Yannis Klonatos
2010-06-25 1:15 ` Dave Chinner [this message]
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=20100625011547.GU6590@dastard \
--to=david@fromorbit.com \
--cc=klonatos@ics.forth.gr \
--cc=xfs@oss.sgi.com \
/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