All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: dramatic I/O slowdown after upgrading 2.6.32->3.0
Date: Fri, 6 Apr 2012 01:29:13 +0200	[thread overview]
Message-ID: <20120405232913.GA6640@quack.suse.cz> (raw)
In-Reply-To: <4F75E46E.2000503@msgid.tls.msk.ru>

  Hello,

On Fri 30-03-12 20:50:54, Michael Tokarev wrote:
> I'm observing a dramatic slowdown of several hosts after upgrading
> from 2.6.32.y to 3.0.x i686 kernels (in both cases from kernel.org,
> on both cases the last version is relatively latest).
> 
> On 2.6.32 everything is fast.  On 3.0 the same operations which goes
> instantly takes ages to complete.
> 
> For example, out of observed actual differences, munin-graph process
> on 2.6.32 completes in a few secs writing to a ext4 /var filesystem.
> On 3.0, the same process takes about a minute and keeps all 5 hard
> drives (md raid5) 99% busy all this time.
> 
> apt-get upgrade (from debian/ubuntu) first reads current package
> status database.  This process takes about 3 secs on a freshly
> booted 2.6.32, and about 40 seconds on a freshly booted 3.0,
> again, keeping all 5 hdds 99% busy (according to iostat).
> 
> Only the kernel is different, all the rest is exactly the same.
> I can reboot into 2.6.32 again after running 3.0, and the system
> is fast again.
> 
> The machine is relatively old, it is an IBM xSeries 345 server
> with some 2.66GHz Xeon (stepping 9) CPU, a Broadcom chipset, an
> LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320
> SCSI controller and 5x74Gb pSCSI drives.  But it is obviously not
> a reason for it to run _this_ slow... ;)
> 
> There's another machine here, with an AMD BE-2400 CPU, nVidia MCP55
> chipset, AHA-3940U2x pSCSI controller and a set of 74Gb HDDs.  It
> shows similar sympthoms after upgrading from 2.6.32 to 3.0 -- every
> I/O becomes very slow with all HDDs being busy for long periods.
> 
> What's the way to debug this issue?
  Identifying a particular kernel where things regresses might help as Jon
wrote. Just from top of my head, 3.0 had a bug in device plugging so
readahead was broken. I think it was addressed in -stable series so you
might want to check out latest 3.0-stable.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

  parent reply	other threads:[~2012-04-05 23:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-30 16:50 dramatic I/O slowdown after upgrading 2.6.32->3.0 Michael Tokarev
2012-04-02 16:58 ` Jonathan Corbet
2012-04-05 23:29 ` Jan Kara [this message]
2012-04-06  4:45   ` Michael Tokarev
2012-04-10  2:26     ` Dave Chinner
2012-04-10  6:00       ` dramatic I/O slowdown after upgrading 2.6.38->3.0+ Michael Tokarev
2012-04-10 15:13         ` Jan Kara
2012-04-10 19:25           ` Suresh Jayaraman
2012-04-10 19:51             ` Jan Kara
2012-04-11  0:20           ` Henrique de Moraes Holschuh
2012-04-11  9:40           ` Michael Tokarev
2012-04-11 17:19             ` Mike Christie
2012-04-11 17:55               ` Michael Tokarev
2012-04-11 18:28               ` Jan Kara

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=20120405232913.GA6640@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjt@tls.msk.ru \
    /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.