All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Hari Subramanian <hari@vmware.com>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: Adaptive throttling for RAID1 background resync
Date: Sat, 19 Mar 2011 09:11:37 +1100	[thread overview]
Message-ID: <20110319091137.2eda1c91@notabene.brown> (raw)
In-Reply-To: <10FC03A59E498D4A90A45E4A105AD3ED02EE70F539@EXCH-MBX-2.vmware.com>

On Fri, 18 Mar 2011 13:26:52 -0700 Hari Subramanian <hari@vmware.com> wrote:

> I am hitting an issue when performing RAID1 resync from a replica hosted on a fast disk to one on a slow disk. When resync throughput is set at 20Mbps min and 200Mbps max and we have enough data to resync, I see the kernel running out of memory quickly (within a minute). From the crash dumps, I see that a whole lot (12,000+) of biovec-64s that are active on the slab cache.
> 
> Our guess is that MD is allowing data to be read from the fast disk at a frequency much higher than what the slow disk is able to write to. This continues for a long time (> 1 minute) in an unbounded fashion resulting in buildup of IOs that are waiting to be written to the disk. This eventually causes the machine to panic (we have panic on OOM selected)
> 
> >From reading the MD and RAID1 resync code, I don't see anything that would prevent something like this from happening. So, we would like to implement something to this effect that adaptively throttles the background resync.
> 
> Can someone confirm or deny these claims and also the need for a new solution. Maybe I'm missing something that already exists that would give me the adaptive throttling. We cannot make do with the static throttling (sync_speed_max and min) since that would be too difficult to get right for varying IO throughputs form the different RAID1 replicas.

The thing you are missing that already exists is 

#define RESYNC_DEPTH 32

which is a limit places on conf->barrier, where conf->barrier is incremented
before submitting a resync IO, and decremented after completing a resync IO.

So there can never be more than 32 bios per device in use for resync.


12,000 active biovec-64s sounds a lot like a memory leak - something isn't
freeing them.
Is there some 'bio-XXX' slab with a similar count.  If there isn't, then the
bio was released without releasing the biovec, which would be bad.
If there is - that information would help.

NeilBrown

  parent reply	other threads:[~2011-03-18 22:11 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-18 14:49 disk order problem in a raid 10 array Xavier Brochard
2011-03-18 17:22 ` hansbkk
2011-03-18 20:09   ` Xavier Brochard
2011-03-18 20:12   ` Xavier Brochard
2011-03-18 22:22     ` NeilBrown
2011-03-18 20:26 ` Adaptive throttling for RAID1 background resync Hari Subramanian
2011-03-18 20:28   ` Roberto Spadim
2011-03-18 20:31     ` Hari Subramanian
2011-03-18 20:36       ` Roberto Spadim
2011-03-18 20:54         ` Hari Subramanian
2011-03-18 21:02           ` Roberto Spadim
2011-03-18 22:11   ` NeilBrown [this message]
2011-03-21 21:02     ` Hari Subramanian
2011-03-18 22:14 ` disk order problem in a raid 10 array NeilBrown
     [not found] ` <201103182350.19281.xavier@alternatif.org>
     [not found]   ` <20110319102039.52cc2282@notabene.brown>
2011-03-18 23:59     ` Xavier Brochard
2011-03-19  0:05       ` Xavier Brochard
2011-03-19  0:07         ` Roberto Spadim
2011-03-19  0:25           ` Xavier Brochard
2011-03-19  1:42       ` NeilBrown
2011-03-19 13:44         ` Xavier Brochard
2011-03-19 15:14           ` Xavier Brochard
2011-03-20  3:53           ` NeilBrown
2011-03-20 10:40             ` Xavier Brochard
2011-03-19 12:01     ` Xavier Brochard

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=20110319091137.2eda1c91@notabene.brown \
    --to=neilb@suse.de \
    --cc=hari@vmware.com \
    --cc=linux-raid@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.