From: Dave Chinner <david@fromorbit.com>
To: Mark Seger <mjseger@gmail.com>
Cc: Nathan Scott <nathans@redhat.com>, xfs@oss.sgi.com
Subject: Re: definitions for /proc/fs/xfs/stat
Date: Sun, 16 Jun 2013 10:00:49 +1000 [thread overview]
Message-ID: <20130616000049.GD29338@dastard> (raw)
In-Reply-To: <CAC2B=ZEUkd+ADnQLUKj9S-3rdo2=93WbW0tbLbwwHUvkh6v7Rw@mail.gmail.com>
On Sat, Jun 15, 2013 at 06:35:02AM -0400, Mark Seger wrote:
> Basically everything do it with collectl, a tool I wrote and opensourced
> almost 10 years ago. it's numbers are very accurate - I've compared with
> iostat on numerous occasions whenever I might have had doubts and they
> always agree. Since both tools get their data from the same place,
> /proc/diskstats, it's hard for them not to agree AND its numbers also agree
> with /proc/fs/xfs.
Ok, that's all I wanted to know.
> happening?
>
> To restate what's going on, I have a very simple script that I'm
> duplicating what openstack swift is doing, namely to create a file with
> mkstmp and than running an falloc against it. The files are being created
> with a size of zero but it seems that xfs is generating a ton of logging
> activity. I had read your posted back in 2011 about speculative
> preallocation and can't help but wonder if that's what hitting me here. I
> also saw where system memory can come into play and this box has 192GB and
> 12 hyperthreaded cores.
>
> I also tried one more run without falloc, this is creating 10000 1K files,
> which should be about 10MB and it looks like it's still doing 140MB of I/O
> which still feels like a lot but at least it's less than the
1k files will still write 4k filesystem blocks, so there's going to
be 40MB/s there at least.
As it is, I ran a bunch of tests yesterday writing 4k files, and I
got 180MB/s @ 32,000 files/s. That's roughly 130MB/s for data, and
another 50MB/s for log and metadata traffic. But without knowing
your test configuration and using your test script, I can't compare
those results to yours. Can you provide the information in:
http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F
> If there is anything more I can provide I'll be happy to do so. Actually I
> should point out I can easily generate graphs and if you'd like to see some
> examples I can provide those too.
PCP generates realtime graphs, which is what I use ;)
> Also, if there is anything I can report
> from /proc/fs/xfs I can relatively easily do that as well and display it
> side by side with the disk I/O.
Let's see if there is something unusual in your setup that might
explain it first...
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:[~2013-06-16 0:00 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-14 16:37 definitions for /proc/fs/xfs/stat Mark Seger
2013-06-14 22:16 ` Nathan Scott
2013-06-14 22:37 ` Mark Seger
2013-06-15 0:17 ` Nathan Scott
2013-06-15 1:55 ` Mark Seger
2013-06-15 2:04 ` Dave Chinner
2013-06-15 10:35 ` Mark Seger
2013-06-15 16:22 ` Mark Seger
2013-06-16 0:11 ` Dave Chinner
2013-06-16 12:58 ` Mark Seger
2013-06-16 22:06 ` Dave Chinner
2013-06-16 22:31 ` Mark Seger
2013-06-16 23:14 ` Dave Chinner
2013-06-16 23:31 ` Mark Seger
2013-06-17 1:11 ` Nathan Scott
2013-06-17 2:46 ` Dave Chinner
2013-06-17 5:41 ` Nathan Scott
2013-06-17 10:57 ` Mark Seger
2013-06-17 11:13 ` Dave Chinner
2013-06-17 14:57 ` Mark Seger
2013-06-17 20:28 ` Stefan Ring
2013-06-18 0:15 ` Dave Chinner
2013-06-18 10:17 ` Mark Seger
2013-06-19 23:02 ` Useful stats (was Re: definitions for /proc/fs/xfs/stat) Nathan Scott
2013-06-17 11:19 ` definitions for /proc/fs/xfs/stat Dave Chinner
2013-06-17 13:18 ` Stan Hoeppner
2013-06-18 0:13 ` Mark Goodwin
2013-06-16 0:00 ` 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=20130616000049.GD29338@dastard \
--to=david@fromorbit.com \
--cc=mjseger@gmail.com \
--cc=nathans@redhat.com \
--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 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.