I added logging into the resolvers to see how frequently I am received siblings, and how many I get when its called.
Almost every call has only two siblings, and, although I am definitely creating them, about 10 or so per minute, it seems to be handling that ok. Its not a perfect test though as my throughput is shot since I restarted the cluster after the last crash… Paul Paul Ingalls Founder & CEO Fanzo [email protected] @paulingalls http://www.linkedin.com/in/paulingalls On Aug 5, 2013, at 9:50 PM, Paul Ingalls <[email protected]> wrote: > I'm currently using the java client and its ConflictResolver and Mutator > interfaces. In some cases I am just doing a store, and letting the client do > an implicit fetch and the mutator to make the actual change. In other cases > I'm doing an explicit fetch, modify the result, and then a store without > fetch. For both, I am using a ConflictResolver and I have added a field for > the vclock and used the annotation in my beans. > > I'll try pointing a local client at the cluster to see if I can see how many > siblings there are. That is, if I can get the cluster running again...:) > > Paul > > Paul Ingalls > Founder & CEO Fanzo > [email protected] > @paulingalls > http://www.linkedin.com/in/paulingalls > > On Aug 5, 2013, at 9:36 PM, Jeremy Ong <[email protected]> wrote: > >> On the client you could extract the value_count of the objects you >> read and just log them. Feel free to post code too, in particular, how >> you are writing out updated values. >> >> On Mon, Aug 5, 2013 at 9:20 PM, Paul Ingalls <[email protected]> wrote: >>> Interesting. I have sibling resolution code on the client side. Would >>> sibling explosion take out the entire cluster all at once? Within 5 minutes >>> of my last email, the rest of the cluster died. >>> >>> Is there a way to quickly figure out whether the cluster is full of >>> siblings? >>> >>> Paul Ingalls >>> Founder & CEO Fanzo >>> [email protected] >>> @paulingalls >>> http://www.linkedin.com/in/paulingalls >>> >>> On Aug 5, 2013, at 8:07 PM, Evan Vigil-McClanahan <[email protected]> >>> wrote: >>> >>> Given your leveldb settings, I think that compaction is an unlikely >>> culprit. But check this out: >>> >>> 2013-08-05 18:01:15.878 [info] <0.83.0>@riak_core_sysmon_ >>> handler:handle_event:92 monitor large_heap <0.14832.557> >>> [{initial_call,{riak_kv_get_fsm,init,1}},{almost_current_function,{riak_object,encode_maybe_binary,1}},{message_queue_len,1}] >>> [{old_heap_block_size,0},{heap_block_size,116769640},{mbuf_size,0},{stack_size,52},{old_heap_size,0},{heap_size,81956791}] >>> >>> That's a 78MB heap in encode object... Unless your objects are big, I >>> would suspect sibling explosion caused by rapid updates at w = 1. >>> >>> >>> >>> _______________________________________________ >>> riak-users mailing list >>> [email protected] >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>> >
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
