Hello, until Bluestore gets caching that is a) self-tuning (within definable limits) so that a busy OSD can consume more cache than ones that are idle AND b) the cache will be as readily evicted as pagecache in low memory situations you're essential SoL, having the bad choices of increasing performance with the risk of OOM when things get busy as David mentioned or wasting all that RAM you paid so much gold for. search for "Bluestore caching, flawed by design?" in the archives. That all being said, depending on your OSD size and usage (how much data and PGs) I'd guess 3GB could be on the safe side. Christian On Thu, 30 Aug 2018 16:31:37 -0700 David Turner wrote: > Be very careful trying to utilize more RAM while your cluster is healthy. > When you're going to need the extra RAM is when you're closer is unhealthy > and your osds are peering, recovering, backfilling, etc. That's when the > osd daemons start needing the RAM that is recommended in the docs. > > On Thu, Aug 30, 2018, 4:21 PM Tyler Bishop <tyler.bishop@xxxxxxxxxxxxxxxxx> > wrote: > > > Hi, > > > > My OSD host has 256GB of ram and I have 52 OSD. Currently I have the > > cache set to 1GB and the system only consumes around 44GB of ram and the > > other ram sits as unallocated because I am using bluestore vs filestore. > > > > The documentation: > > http://docs.ceph.com/docs/master/rados/configuration/bluestore-config-ref/ > > list the defaults of ram to be used almost exclusively for the KV cache. > > > > With a system like mine do you think It would be safe to allow 3GB cache > > and change the KV ratio to 0.60? > > > > Thanks > > _____________________________________________ > > > > *Tyler Bishop* > > EST 2007 > > > > > > O: 513-299-7108 x1000 > > M: 513-646-5809 > > http://BeyondHosting.net <http://beyondhosting.net/> > > > > > > This email is intended only for the recipient(s) above and/or > > otherwise authorized personnel. The information contained herein and > > attached is confidential and the property of Beyond Hosting. Any > > unauthorized copying, forwarding, printing, and/or disclosing > > any information related to this email is prohibited. If you received this > > message in error, please contact the sender and destroy all copies of this > > email and any attachment(s). > > _______________________________________________ > > ceph-users mailing list > > ceph-users@xxxxxxxxxxxxxx > > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > -- Christian Balzer Network/Systems Engineer chibi@xxxxxxx Rakuten Communications _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |