From: Mark Nelson <mnelson@redhat.com>
To: ceph-devel <ceph-devel@vger.kernel.org>
Subject: Fun probably useless QMC PG distribution simulation
Date: Fri, 12 Feb 2016 16:46:45 -0600 [thread overview]
Message-ID: <56BE60D5.1050300@redhat.com> (raw)
Hi All,
In my spare time I've started playing around with an idea I've been
kicking around since the Inktank days. Basically I wanted to see what
would happen if I tried to use a quasi-monte-carlo method like a Halton
Sequence for distributing PGs.
The current toy code is here:
https://github.com/markhpc/pghalton
So the good news is that as expected, the distribution quality is
fantastic, even at low PG counts. Remapping is inexpensive so long as
the bucket count is near what was specified in the original mapping, but
every bucket removal (or reinsertion) increases the remapping cost by
1/<bucket count>. IE if you have 70/100 OSDs out, and 1 comes back up,
you have ~30% data movement, the same cost in fact if 30 OSDs came back
up. Adding new buckets is also going to be difficult, probably
requiring a doubling of the buckets and then marking some of them out to
avoid remapping the entire sequence.
I think it would be fairly easy to re-partition the space in this
approach to allow for arbitrary weighting and you could probably do
something vaguely crush like with hierarchical placement. The data
movement problem is the big issue. I suspect you could do some kind of
fancy tree structure to reduce the remapping cost, but I don't think it
would every be as good as crush.
Anyway, thought people might interesting in playing with it and maybe it
will get someone's noodle going to think up other exotic ideas. :)
Mark
next reply other threads:[~2016-02-12 22:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-12 22:46 Mark Nelson [this message]
2016-02-12 22:52 ` Fun probably useless QMC PG distribution simulation Mark Nelson
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=56BE60D5.1050300@redhat.com \
--to=mnelson@redhat.com \
--cc=ceph-devel@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