From: "Alan D. Brunelle" <Alan.Brunelle@hp.com>
To: linux-btrace@vger.kernel.org
Subject: Re: lots of unplugged by timer normal or abnormal?
Date: Tue, 06 Oct 2009 20:20:32 +0000 [thread overview]
Message-ID: <1254860432.4852.91.camel@cail> (raw)
In-Reply-To: <20091006185337.GF26949@hostway.ca>
[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]
On Tue, 2009-10-06 at 13:08 -0700, Simon Kirby wrote:
> On Tue, Oct 06, 2009 at 03:50:45PM -0400, Alan D. Brunelle wrote:
>
> > This looks pretty bad - could you tell me what distro you are running on
> > as a base? And did this happen before 2.6.30.5 (the poor performance)?
> > And could you provide a more complete snippet of blktrace output
> > (showing a handful of complete ops)?
>
> Hi, Alan!
>
> The poor performance has been ongoing for some time (these boxes were
> built circa 2.6.26, and we hit a number of issues along the way -- 2.6.30
> was the first stable kernel for serving files via nfsd, even with EXT3).
>
> I'm figuring the majority of the performance issue are actually with the
> AOE driver or the Coraid queue scheduling or RAID implementation, but I
> figured that unplugging by timer maybe shouldn't happen even regardless
> of how slow the underlying "device" is, hence my email.
>
> It's amd64 Debian lenny (not sure why that matters), 16 GB of RAM, about
> and a whole bunch of AOE storage, chopped up via DM, mostly using XFS as
> a file system, served via knfsd. "iostat -x -k 1" shows 100% utilization
> fairly often for this particular device.
Coincidentally I was investigating something similar w/ RHEL 5.4 at this
very moment - just wanted to know if that was a common denominator.
Could you run the attached SystemTap script and send out the output?
[You may have to get `systemtap' though...]
I'll try to get some time to look at your traces - might not be until
tomorrow though...
Thanks,
Alan
[-- Attachment #2: bpd.stp --]
[-- Type: text/plain, Size: 420 bytes --]
#! /usr/bin/env stap
global n, plug_stacks
probe kernel.function("blk_plug_device") {
if ((n ++ % 0xff) == 0) {
plug_stacks[backtrace()] ++
}
}
probe begin {
printf("Collecting traces\n")
}
probe timer.sec(20) {
foreach (stack in plug_stacks- limit 5) {
printf("%d:\n", plug_stacks[stack])
print_stack(stack)
}
exit()
}
next prev parent reply other threads:[~2009-10-06 20:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-06 18:53 lots of unplugged by timer normal or abnormal? Simon Kirby
2009-10-06 19:50 ` Alan D. Brunelle
2009-10-06 20:08 ` Simon Kirby
2009-10-06 20:20 ` Alan D. Brunelle [this message]
2009-10-11 16:44 ` Simon Kirby
2009-10-11 18:35 ` Jens Axboe
2009-10-11 20:58 ` Simon Kirby
2009-10-12 7:18 ` Jens Axboe
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=1254860432.4852.91.camel@cail \
--to=alan.brunelle@hp.com \
--cc=linux-btrace@vger.kernel.org \
/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.