Re: Re: Yokozuna indexes too slow

2015-10-01 Thread ilyas
It looks like this issues https://github.com/basho/yokozuna/issues/320 I try to set * |maxThreads| to |150| * |Acceptors| to |10| * |lowResourcesMaxIdleTime| to |5| in /usr/lib/riak/lib/yokozuna/priv/solr/etc/jetty.xml as recommended in https://github.com/basho/yokozuna/issues/330 b

Re: riak 2.1.1 : Erlang crash dump

2015-10-01 Thread Jon Meredith
It looks like Riak was unable to allocate 4Gb of memory. You may have to reduce the amount of memory allocated for leveldb from the default 70%, try setting this in your /etc/riak/riak.conf file leveldb.maximum_memory.percent = 50 The memory footprint for Riak should stabilize after a few hours

Re: Yokozuna indexes too slow

2015-10-01 Thread Fred Dushin
Is there any more information in these logs that you can share? For example, is this the only entry with this exception? Or are there more? Are there any associated stack traces? An EOF exception can come from many different scenarios. Is there anything in the Riak console.log that looks su

Re: Yokozuna indexes too slow

2015-10-01 Thread Jason Voegele
Hello Ilyas, According to this Stack Overflow post, that error message might be a symptom of low memory conditions: http://stackoverflow.com/questions/21180596/solr-error-when-doing-full-import-25-rows-org-apache-solr-common-solrexcepti

Re: Yokozuna indexes too slow

2015-10-01 Thread ilyas
upd: There are errors in in solr log: org.apache.solr.common.SolrException;null:org.eclipse.jetty.io.EofException ___ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Problem with Vector Clocks - inconsistencies encountered in cluster with shifted real local clocks

2015-10-01 Thread Russell Brown
You can get that level of consistency from Riak if you use strong consistency. By default riak is eventually consistent. I might be missing something still, ‘cos I’ve still not had time to step through your example but it looks like nothing more than the case that if you use clocks to decide th

Re: Problem with Vector Clocks - inconsistencies encountered in cluster with shifted real local clocks

2015-10-01 Thread Zuzana Zatrochova
More likely not what I expected - I use the definition of the strongest consistency guarantees = linearizability (from source - https://cs.brown.edu/~mph/HerlihyW90/p463-herlihy.pdf) or in other words if a user sends read request, the value obtained should be at least that of the last write acknow

Re: Problem with Vector Clocks - inconsistencies encountered in cluster with shifted real local clocks

2015-10-01 Thread Russell Brown
On 1 Oct 2015, at 15:45, Zuzana Zatrochova wrote: > Thank you for fast reply, > > Could you please specify what do you mean by context sent by client? When a client reads a value it gets an opaque context too, it must return this to riak when it performs an update. In the absence of a context

Re: Problem with Vector Clocks - inconsistencies encountered in cluster with shifted real local clocks

2015-10-01 Thread Zuzana Zatrochova
Thank you for fast reply, Could you please specify what do you mean by context sent by client? Do you mean update on the existing object in database? I see exactly that when allow_mult=false, only the highest timestamp value is stored. For me the results are unexpected because the client sees in

Yokozuna indexes too slow

2015-10-01 Thread ilyas
Hello Ilyas, I’ve got a few questions for you to help diagnose the performance problem. Hi and thank you for the answer * What Riak version are you running? 2.1.1 from debian package * Are you using the default solrconfig on the index, or a custom configuration? default solrconfig *

Re: Yokozuna indexes too slow

2015-10-01 Thread Jason Voegele
Hello Ilyas, I’ve got a few questions for you to help diagnose the performance problem. * What Riak version are you running? * Are you using the default solrconfig on the index, or a custom configuration? * You say that there is a 200x slow down when Yokozuna indexing is enabled. Do you have a

Re: Problem with Vector Clocks - inconsistencies encountered in cluster with shifted real local clocks

2015-10-01 Thread Russell Brown
I need more time to examine the diagram, but this all looks as expected so far. If a client sends no context then it’s write will be a sibling of whatever is stored at the coordinator, as you rightly point out riak treats an incoming clock that is less than a local clock as a sibling. If the coo

Re: Riak CS - Unable to create/view bucket details using dragon disk

2015-10-01 Thread Johan Sommerfeld
Haven't used S3 or Dragon disk, but looking at the python stacktrace and the code at github suggests some things. First the actuall from riak is caught correctly: File "/usr/share/s3cmd/S3/S3.py", line 624, in send_request raise S3Error(response) and its later when it tries to parse