On 2019-07-17T11:56:25, Robert LeBlanc <[email protected]> wrote:
> So, I see the recommendation for 4% of OSD space for blocks.db/WAL and the
> corresponding discussion regrading the 3/30/300GB vs 6/60/600GB allocation.
>
> How does this change when WAL is seperate from blocks.db?
>
> Reading [0] it seems that 6/60/600 is not correct. It seems that to compact
> a 300GB DB, you taking values from the above layer (which is only 10% of
> the lower layer and only some percentage that exceeds the trigger point of
> that will be merged down) and merging that in, so at worse case you would
> need 333GB (300+30+3) plus some headroom.
I think the doubling of values is mainly used to leave sufficient
headroom for all possible overhead.
The most common choice we see here is the 60/64 GB scenario. (Computer
folks tend to think in powers of two. ;-)
It's not cost effective to haggle too much; at any given 1:n ratio, the
60 GB * n on the shared device is not the significant cost factor. Going
too low however would likely be rather annoying in the future, so why
not play it safe?
The 4% general advice seems incomplete; if anything, one should possibly
then round up to the next sensible value. But this heavily depends on
the workload - if the cluster only hosts RBDs, you'll see much less
metadata, for example. Unfortunately, we don't seem to have
significantly better recommendations yet.
Regards,
Lars
--
SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG
Nürnberg)
"Architects should open possibilities and not determine everything." (Ueli
Zbinden)
_______________________________________________
ceph-users mailing list
[email protected]
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
