From: Dave Chinner <david@fromorbit.com>
To: linux-xfs@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH] [RFC] xfs: make xfs btree stats less huge
Date: Wed, 14 Sep 2016 07:15:02 +1000 [thread overview]
Message-ID: <20160913211502.GH30497@dastard> (raw)
In-Reply-To: <20160913090657.gz75xuhjhb6645sd@redhat.com>
On Tue, Sep 13, 2016 at 11:06:57AM +0200, Carlos Maiolino wrote:
> On Tue, Sep 13, 2016 at 06:28:42PM +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> >
> > Embedding a switch statement in every btree stats inc/add adds a lot
> > of code overhead to the core btree infrastructure paths. Stats are
> > supposed to be small and lightweight, but the btree stats have
> > become big and bloated as we've added more btrees. It needs fixing
> > because the reflink code will just add more overhead again.
>
> Talking about stats, is there any documentation for that? I was using the log
> stats while working on the fail_at_unmount hang, and I couldn't find anything
> other than looking into the code to see what each number means.
Most XFS stats are documented in PCP. IIRC, this page was originally
pulled from the PCP metric info but is now (like most stuff in
wikis) is out of date: http://xfs.org/index.php/Runtime_Stats
$ pminfo -T xfs.log
xfs.log.writes
Help:
This variable counts the number of log buffer writes going to the
physical log partitions of all XFS filesystems. Log data traffic is
proportional to the level of meta-data updating. Log buffer writes
get generated when they fill up or external syncs occur.
xfs.log.blocks
Help:
This variable counts the number of Kbytes of information being
written to the physical log partitions of all XFS filesystems. Log
data traffic is proportional to the level of meta-data updating. The
rate with which log data gets written depends on the size of
internal log buffers and disk write speed. Therefore, filesystems
with very high meta-data updating may need to stripe the log
partition or put the log partition on a separate drive.
xfs.log.write_ratio
Help:
The ratio of log blocks written to log writes. If block count isn't
a "reasonable" multiple of writes, then many small log writes are
being performed - this is suboptimal. Perfection is 64. Fine-grain
control can be obtained when this metric is used in conjuntion with
pmstore(1) and the xfs.control.reset metric.
xfs.log.noiclogs
Help:
This variable keeps track of times when a logged transaction can not
get any log buffer space. When this occurs, all of the internal log
buffers are busy flushing their data to the physical on-disk log.
xfs.log.force
Help:
The number of times the in-core log is forced to disk. It is
equivalent to the number of successful calls to the function
xfs_log_force().
xfs.log.force_sleep
Help:
This metric is exported from the xs_log_force_sleep field of struct
xfsstats
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2016-09-13 21:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-13 8:28 [PATCH] [RFC] xfs: make xfs btree stats less huge Dave Chinner
2016-09-13 9:06 ` Carlos Maiolino
2016-09-13 21:15 ` Dave Chinner [this message]
2016-09-19 23:49 ` Dave Chinner
2016-09-20 4:16 ` Darrick J. Wong
2016-09-20 5:59 ` Dave Chinner
2016-09-20 6:10 ` Darrick J. Wong
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=20160913211502.GH30497@dastard \
--to=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).