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
next prev 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 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).