All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aleksei Gutikov <aleksey.gutikov@synesis.ru>
To: Ceph Development <ceph-devel@vger.kernel.org>
Subject: luminous OSD memory usage
Date: Wed, 30 Aug 2017 13:00:55 +0300	[thread overview]
Message-ID: <d3b8007f-4bdf-65c5-f4e9-7d1d9c85e019@synesis.ru> (raw)

Hi.

I'm trying to synchronize osd daemons memory limits and bluestore cache 
settings.
For 12.1.4 we have hdd osds usage about 4G with default settings.
For ssds we have limit 6G and they are been oom killed periodically.

While
osd_op_num_threads_per_shard_hdd=1
osd_op_num_threads_per_shard_ssd=2
and
bluestore_cache_size_hdd=1G
bluestore_cache_size_ssd=3G
and
osd_op_num_shards_hdd=5
osd_op_num_shards_ssd=8

Does it mean that ssd osds will use 4G*2*3*8/5, or 3G*2*8/5, or other?
Does anybody have an idea about the equation for upper bound of memory 
consumption?
Can bluestore_cache_size be decreased safely for example to 2G, or to 1G?

I want to calculate the maximum expected size of bluestore metadata 
(that must be definitely fit into cache) using size of raw space, 
average size of objects, rocksdb space amplification.
I thought it should be something simple like 
raw_space/avg_obj_size*obj_overhead*rocksdb_space_amp.
For example if obj_overhead=1k, hdd size=1T, rocksdb space amplification 
is 2 and avg obj size=4M then 1T/4M*1k*2=500M so I need at least 512M 
for cache.
But wise guys said that I have to take into account number of extents also.
But bluestore_extent_map_shard_max_size=1200, I hope this number is not 
a multiplicator...
What would be correct approach for calculation of this minimum cache size?
What can be expected size of key-values stored in rocksdb per rados object?

Default bluestore_cache_kv_ratio*bluestore_cache_size_ssd=0.99*3G
while default bluestore_cache_kv_max=512M
Looks like BlueStore::_set_cache_sizes() will set cache_kv_ratio to 1/6 
in default case. Is 512M enough for bluestore metadata?


Thanks!
Aleksei

             reply	other threads:[~2017-08-30 10:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-30 10:00 Aleksei Gutikov [this message]
2017-08-30 15:17 ` luminous OSD memory usage Sage Weil
2017-09-01  2:00   ` xiaoyan li
2017-09-01 12:51     ` Mark Nelson
2017-09-01 13:10     ` Sage Weil
2017-10-20  8:52   ` Aleksei Gutikov
2017-10-20 12:12     ` 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=d3b8007f-4bdf-65c5-f4e9-7d1d9c85e019@synesis.ru \
    --to=aleksey.gutikov@synesis.ru \
    --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 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.