All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Francke <Oliver.Francke@filoo.de>
To: Wido den Hollander <wido@widodh.nl>
Cc: ceph-devel@vger.kernel.org
Subject: Re: Recommended number of pools, one Q. ever wanted to ask
Date: Tue, 28 Feb 2012 10:50:56 +0100	[thread overview]
Message-ID: <4F4CA380.2010004@filoo.de> (raw)
In-Reply-To: <4F4CA17F.4070007@widodh.nl>

Well,

On 02/28/2012 10:42 AM, Wido den Hollander wrote:
> Hi,
>
> On 02/28/2012 10:35 AM, Oliver Francke wrote:
>> Hi *,
>>
>> well, there was once a comment on our layout in means of "too many 
>> pools".
>> Our setup is to have a pool per customer, to simplify the view on used
>> storage
>> capacity.
>> So, if we have - in a couple of months, we hope - more then some hundred
>> customers, this setup was not recommended, cause the whole system is not
>> designed for handling that. ( Sage)
>>
>> What does "not recommended" mean? Is it, that per OSD the used memory
>> will be
>> too high?
>
> Yes. Every new pool you create will consume some memory on the OSD. So 
> if you start creating a lot of pools, you will also start consuming 
> more and more memory.
>
> I haven't followed this lately, but that is the current information I 
> have.
>
> The number of objects in a pool is also not a problem, you can have 
> millions without any issues. It's the number of pools which will haunt 
> you later on.

thnx for the quick reply, so if we can imagine, that the number of pool 
per OSD is
the limiting factor, we shall not have more than let's say ~100, means, 
we shall be
safe.

>
> Wido

best regards,

Oliver.

>
>> Is this a general performance issue?
>>
>> Well, if we read "pool", this gave us the basic idea/concept to put all
>> per-customers
>> data into it.
>>
>> Please sched some light in 8-)
>>
>> Kind regards,
>>
>> Oliver.
>>
>


-- 

Oliver Francke

filoo GmbH
Moltkestraße 25a
33330 Gütersloh
HRB4355 AG Gütersloh

Geschäftsführer: S.Grewing | J.Rehpöhler | C.Kunz

Folgen Sie uns auf Twitter: http://twitter.com/filoogmbh

--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2012-02-28  9:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-28  9:35 Recommended number of pools, one Q. ever wanted to ask Oliver Francke
2012-02-28  9:42 ` Wido den Hollander
2012-02-28  9:50   ` Oliver Francke [this message]
2012-02-28 15:51     ` Wido den Hollander
2012-02-28 17:14       ` Sage Weil

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=4F4CA380.2010004@filoo.de \
    --to=oliver.francke@filoo.de \
    --cc=ceph-devel@vger.kernel.org \
    --cc=wido@widodh.nl \
    /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.