Hi Guys,

I have 3 more queries, I hope I am not troubling you guys much.

1. As LevelDB keeps keys and values in a block cache, how it does the
management of key spaces that are larger than available memory? like in
memcached/redis LRU is used for memory management, here in leveldb how
block cache gets managed?

2. if at start i have 2 nodes and i set n_val of 2, can I change n_val to 3
after adding 3rd node without making cluster down?

3. What are the chances/probability of cluster failure for 2 node cluster
with n_val of 2? I will be increasing cluster size on the availability of
new nodes and n_val as well.

Thanks for the help guys.
Amol Rajoba


On Wed, Jun 20, 2012 at 8:46 PM, Amol Rajoba <amolraj...@gmail.com> wrote:

> Thanks Guys.
>
> And I did try with default eleveldb configuration and it worked very well,
> Thanks. I am now thinking of migration from cassandra to riak.
> At start I thought that giving more write_buffer_size will help in write
> performance like it happens in cassandra.
>
> I have 3 more queries, I hope I am not troubling you guys much:
>
> 1. As LevelDB keeps keys and values in a block cache, how it does the
> management of key spaces that are larger than available memory? like in
> memcached/redis LRU is used for memory management, here in leveldb how
> block cache gets managed?
>
> 2. if at start i have 2 nodes and i set n_val of 2, can I change n_val to
> 3 after adding 3rd node without making cluster down?
>
> 3. What are the chances/probability of cluster failure for 2 node cluster
> with n_val of 2? I will be increasing cluster size on the availability of
> new nodes and n_val as well.
>
> Thanks for the help guys.
> Amol Rajoba
>
>
> On Wed, Jun 20, 2012 at 12:23 AM, Daniel Reverri <d...@basho.com> wrote:
>
>>  Hi Amol,
>>
>> What motivated the eleveldb configuration changes in app.config? Have you
>> evaluated performance using the default configuration values?
>>
>> The settings you modified are per vnode. A 2 node cluster, using the
>> default ring size of 64, has 32 vnodes per node. The chosen
>> write_buffer_size seems quite large. Can you retry your test using the
>> default configuration values?
>>
>> Thanks,
>> Dan
>>
>> --
>> Daniel Reverri
>> Architect
>> Basho Technologies, Inc.
>> d...@basho.com
>>
>>  On Tuesday, June 19, 2012 at 10:51 AM, Mark Phillips wrote:
>>
>> Hi Amol,
>>
>> It looks like you're out of RAM. One of the offending entries from your
>> log:
>>
>> 2012-06-15 19:09:31.777 [error] <0.20970.188> gen_server <0.20970.188>
>> terminated with reason:
>> {mem_error,[{zlib,call,3},{zlib,zip,1},{riak_kv_pb_socket,process_message,2},{riak_kv_pb_socket,handle_info,2},{gen_server2,handle_msg,7},{proc_lib,init_p_do_apply,3}]}
>>
>> Is there any any chance you could add a machine or two and to the cluster
>> and run the test gain?
>>
>> Mark
>>
>>
>>
>>
>> On Mon, Jun 18, 2012 at 11:34 PM, Amol Rajoba <amolraj...@gmail.com>wrote:
>>
>> Hi Guys,
>>
>> Can anybody help here?
>>
>> Also found that due to continuous put operation beam.smp taking 2.9G RAM,
>> what could be reason of this?
>>
>> Thanks.
>> Amol Rajoba
>>
>>
>> _______________________________________________
>> riak-users mailing list
>> riak-users@lists.basho.com
>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>
>>
>>
>
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Reply via email to