<div dir="ltr"><div><div><div><div>Hi Alexander,<br><br></div>Thanks for responding.<br><br>> How many nodes?<br></div><br>We currently have 9 nodes in our cluster.<br><br>> How much ram per node?<br></div><br>Each node has 4GB of ram and 4GB of swap. The memory levels (ram + swap) on each node are currently between 4GB and 5.5GB.<br><br>> How many objects (files)? What is the average file size?<br><br>We currently have >30 million objects, and I analyzed the average object size before we migrated data into the cluster it was about 4KB/object, with some objects being much larger (multiple MB). Is there an easy way to get this information from a running cluster so I can give you more accurate information?<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 22, 2016 at 2:42 AM, Alexander Sicular <span dir="ltr"><<a href="mailto:siculars@gmail.com" target="_blank">siculars@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Daniel,<br>
<br>
How many nodes?<br>
-You should be using 5 minimum if you using the default config. There<br>
are reasons.<br>
<br>
How much ram per node?<br>
-As you noted, in Riak CS, 1MB file chunks are stored in bitcask.<br>
Their key names and some overhead consume memory.<br>
<br>
How many objects (files)? What is the average file size?<br>
-If your size distribution significantly skews < 1MB that means you<br>
will have a bunch of files in bitcask eating up ram.<br>
<br>
Kota was a former Basho engineer who worked on CS... That said, Basho<br>
may not support a non standard deployment.<br>
<br>
-Alexander<br>
<div><div class="h5"><br>
On Mon, Nov 21, 2016 at 2:45 PM, Daniel Miller <<a href="mailto:dmiller@dimagi.com">dmiller@dimagi.com</a>> wrote:<br>
> I found a similar question from over a year ago<br>
> (<a href="http://lists.basho.com/pipermail/riak-users_lists.basho.com/2015-July/017327.html" rel="noreferrer" target="_blank">http://lists.basho.com/<wbr>pipermail/riak-users_lists.<wbr>basho.com/2015-July/017327.<wbr>html</a>),<br>
> and it sounds like leveldb is the way to go, although possibly not well<br>
> tested. Has anything changed with regard to Basho's (or anyone else)<br>
> experience with using leveldb backend instead of the mutli backend for CS?<br>
><br>
> On Fri, Nov 4, 2016 at 11:48 AM, Daniel Miller <<a href="mailto:dmiller@dimagi.com">dmiller@dimagi.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> I have a Riak CS cluster up and running, and am anticipating exponential<br>
>> growth in the number of key/value pairs over the next few years. From<br>
>> reading the documentation and experience, I've concluded that the default<br>
>> configuration of CS (with riak_cs_kv_multi_backend) keeps all keys in RAM.<br>
>> The OOM killer strikes when Riak uses too much RAM, which is not good for my<br>
>> sanity or sleep. Because of the amount of growth I am anticipating, it seems<br>
>> unlikely that I can allocate enough RAM to keep up with the load. Disk, on<br>
>> the other hand, is less constrained.<br>
>><br>
>> A little background on the data set: I have a sparsely accessed key set.<br>
>> By that I mean after a key is written, the more time passes with that key<br>
>> not being accessed, the less likely it is to be accessed any time soon. At<br>
>> any given time, most keys will be dormant. However, any given key _could_ be<br>
>> accessed at any time, so should be possible to retrieve it.<br>
>><br>
>> I am currently running a smaller cluster (with smaller nodes: less RAM,<br>
>> smaller disks) than I expect to use eventually. I am starting to hit some<br>
>> growth-related issues that are prompting me to explore more options before<br>
>> it becomes a dire situation.<br>
>><br>
>> My question: Are there ways to tune Riak (CS) to support this scenario<br>
>> gracefully? That is, are there ways to make Riak not load all keys into RAM?<br>
>> It looks like leveldb is just what I want, but I'm a little nervous<br>
>> switching over to only leveldb when the default/recommended config uses the<br>
>> multi backend.<br>
>><br>
>> As a stop-gap measure, I enabled swap (with swappiness = 0), which I<br>
>> anticipated would kill performance, but was pleasantly surprised to see it<br>
>> return to effectively no-swap performance levels after a short period of<br>
>> lower performance. I'm guessing this is not a good long-term solution as my<br>
>> dataset grows. The problem with using large amounts of swap is that each<br>
>> time Riak starts it needs to read all keys into RAM. Long term, as our<br>
>> dataset grows, the amount of time needed to read keys into RAM will cause a<br>
>> very long restart time (and thus period of unavailability), which could<br>
>> endanger availability for a prolonged period if multiple nodes go down at<br>
>> once.<br>
>><br>
>> Thanks!<br>
>> Daniel Miller<br>
>> Dimagi, Inc.<br>
>><br>
><br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> riak-users mailing list<br>
> <a href="mailto:riak-users@lists.basho.com">riak-users@lists.basho.com</a><br>
> <a href="http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com" rel="noreferrer" target="_blank">http://lists.basho.com/<wbr>mailman/listinfo/riak-users_<wbr>lists.basho.com</a><br>
><br>
</blockquote></div><br></div>