linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Larkin Lowrey <llowrey@nuclearwinter.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: James Candelaria <jc@whiptailtech.com>
Subject: Re: [linux-lvm] LVM commands extremely slow during raid check/resync
Date: Mon, 26 Mar 2012 12:49:42 -0500	[thread overview]
Message-ID: <4F70AC36.1050207@nuclearwinter.com> (raw)
In-Reply-To: <33016A114D6EF84EB47C507EA7AFCC5703FC8D@SN2PRD0802MB113.namprd08.prod.outlook.com>

Thank you for the reply.

I/O does slow down during the raid check and that's to be expected, but
two minutes to create  a snapshot seems excessive. I only experience a
few seconds delay when modifying and copying files. It is hard to
imagine how those operations can complete in seconds while lvs and
lvcreate take minutes. I suppose if lvm was issuing a lot of fsyncs then
a delay of that magnitude could be expected.

This phenomenon did not occur when I was still running Fedora 15 so
something changed.

--Larkin

On 3/26/2012 8:02 AM, James Candelaria wrote:
> Larkin,
>
> This is likely due to the way the scheduler and MD driver are interacting.  The MD driver has likely filled the queue of the devices pretty deep with read requests, then when you attempt to run a LVM command such as lvcreate your request gets inserted.  You must "wait-in-line" for this command (likely only a few sectors worth of IO) to get its turn on the media.  The MD driver realizes that there is another request to the media and slows itself briefly, but since there is no further IO after the LVM command it then goes back to its job of resyncing your array in earnest.
>
> James
>
>
> -----Original Message-----
> From: linux-lvm-bounces@redhat.com [mailto:linux-lvm-bounces@redhat.com] On Behalf Of Larkin Lowrey
> Sent: Sunday, March 25, 2012 3:56 AM
> To: linux-lvm@redhat.com
> Subject: [linux-lvm] LVM commands extremely slow during raid check/resync
>
> I've been suffering from an extreme slowdown of the various lvm commands
> during high I/O load ever since updating from Fedora 15 to 16.
>
> I notice this particularly Sunday AMs when Fedora kicks of a raid-check.
> What is normally near instantaneous, commands like lvs and lvcreate
> --snapshot take minutes to complete (literally). This causes my backup
> jobs to timeout and fail.
>
> While all this is going on, the various filesystems are reasonably
> responsive (considering the raid-check is running) and I can read/write
> to files without problems. It seems that this slow-down is unique to lvm.
>
> I have three raid 5 arrays of 8, 6, and 6 drives. The root fs sits
> entirely within the 8 disk array as does the spare area used for snapshots.
>
> Interestingly, perhaps, if I can coax a backup into running, the lvs
> command, for example, will complete in just 15-30 seconds instead of
> 120-180s. It would seem that the random I/O of the backup is able to
> break things up enough for the lvm commands to squeeze in.
>
> I'm at a loss for what to do about this or what data to scan for clues.
> Any suggestions?
>
> kernel 3.2.10-3.fc16.x86_64
>
> lvm> version
>   LVM version:     2.02.86(2) (2011-07-08)
>   Library version: 1.02.65 (2011-07-08)
>   Driver version:  4.22.0
>
> --Larkin
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

  reply	other threads:[~2012-03-26 17:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-25  7:56 [linux-lvm] LVM commands extremely slow during raid check/resync Larkin Lowrey
2012-03-26 13:02 ` James Candelaria
2012-03-26 17:49   ` Larkin Lowrey [this message]
2012-03-26 20:55 ` Ray Morris
2012-03-26 23:51   ` Larkin Lowrey
2012-03-27 14:34     ` Zdenek Kabelac
2012-03-27 21:24       ` Larkin Lowrey
2012-03-28  7:53         ` Zdenek Kabelac
2012-03-28 18:26           ` Stuart D Gathman
2012-03-29  0:27             ` Ray Morris
2012-03-29  9:48             ` Zdenek Kabelac
2012-03-27 14:31   ` Zdenek Kabelac
2012-03-27 18:11     ` Ray Morris
2012-03-27 20:36       ` Zdenek Kabelac

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=4F70AC36.1050207@nuclearwinter.com \
    --to=llowrey@nuclearwinter.com \
    --cc=jc@whiptailtech.com \
    --cc=linux-lvm@redhat.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).