From: Filippos Giannakos <philipgian@grnet.gr>
To: Sage Weil <sage@inktank.com>
Cc: Kyle Bader <kyle.bader@gmail.com>,
"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>,
synnefo-devel@googlegroups.com
Subject: Re: RADOS + deep scrubbing performance issues in production environment
Date: Tue, 28 Jan 2014 20:13:06 +0200 [thread overview]
Message-ID: <20140128181306.GC11532@philipgian-mac> (raw)
In-Reply-To: <alpine.DEB.2.00.1401271045160.2149@cobra.newdream.net>
On Mon, Jan 27, 2014 at 10:45:48AM -0800, Sage Weil wrote:
> There is also
>
> ceph osd set noscrub
>
> and then later
>
> ceph osd unset noscrub
>
> I forget whether this pauses an in-progress PG scrub or just makes it stop
> when it gets to the next PG boundary.
>
> sage
I bumped into those settings but I couldn't find any documentation about them.
When I first tried them, they didn't do anything immediately, so I thought they
weren't the answer. After your mention, I tried them again, and after a while
the deep-scrubbing stopped. So I'm guessing they stop scrubbing on the next PG
boundary.
I see from this thread and others before, that some people think it is a spindle
issue. I'm not sure that it is just that. Replicating it to an idle cluster that
can do more than 250MiB/seconds and pausing for 4-5 seconds on a single request,
sounds like an issue by itself. Maybe there is too much locking or not enough
priority to the actual I/O ? Plus, that idea of throttling deep scrubbing based
on the iops sounds appealing.
Kind Regards,
--
Filippos
<philipgian@grnet.gr>
next prev parent reply other threads:[~2014-01-28 18:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-27 15:13 RADOS + deep scrubbing performance issues in production environment Filippos Giannakos
2014-01-27 18:10 ` Kyle Bader
2014-01-27 18:45 ` Sage Weil
2014-01-28 6:30 ` Mike Dawson
2014-01-28 18:13 ` Filippos Giannakos
2014-01-28 18:13 ` Filippos Giannakos [this message]
[not found] ` <066498EC-D137-472A-85DB-93751E85C753@yahoo.com>
[not found] ` <066498EC-D137-472A-85DB-93751E85C753-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
2014-02-03 13:40 ` Guang
2015-07-10 13:52 ` icq2206241
2014-01-28 18:12 ` Filippos Giannakos
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=20140128181306.GC11532@philipgian-mac \
--to=philipgian@grnet.gr \
--cc=ceph-devel@vger.kernel.org \
--cc=kyle.bader@gmail.com \
--cc=sage@inktank.com \
--cc=synnefo-devel@googlegroups.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 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.