<div dir="ltr">This is the only thing related to AAE that exists in my app.config. I haven't changed any default values...<div><br></div><div><div>            %% Enable active anti-entropy subsystem + optional debug messages:</div>

<div>            %%   {anti_entropy, {on|off, []}},</div><div>            %%   {anti_entropy, {on|off, [debug]}},</div><div>            {anti_entropy, {on, []}},</div><div><br></div><div>            %% Restrict how fast AAE can build hash trees. Building the tree</div>

<div>            %% for a given partition requires a full scan over that partition's</div><div>            %% data. Once built, trees stay built until they are expired.</div><div>            %% Config is of the form:</div>

<div>            %%   {num-builds, per-timespan-in-milliseconds}</div><div>            %% Default is 1 build per hour.</div><div>            {anti_entropy_build_limit, {1, 3600000}},</div><div><br></div><div>            %% Determine how often hash trees are expired after being built.</div>

<div>            %% Periodically expiring a hash tree ensures the on-disk hash tree</div><div>            %% data stays consistent with the actual k/v backend data. It also</div><div>            %% helps Riak identify silent disk failures and bit rot. However,</div>

<div>            %% expiration is not needed for normal AAE operation and should be</div><div>            %% infrequent for performance reasons. The time is specified in</div><div>            %% milliseconds. The default is 1 week.</div>

<div>            {anti_entropy_expire, 604800000},</div><div><br></div><div>            %% Limit how many AAE exchanges/builds can happen concurrently.</div><div>            {anti_entropy_concurrency, 2},</div><div><br></div>

<div>            %% The tick determines how often the AAE manager looks for work</div><div>            %% to do (building/expiring trees, triggering exchanges, etc).</div><div>            %% The default is every 15 seconds. Lowering this value will</div>

<div>            %% speedup the rate that all replicas are synced across the cluster.</div><div>            %% Increasing the value is not recommended.</div><div>            {anti_entropy_tick, 15000},</div><div><br></div>

<div>            %% The directory where AAE hash trees are stored.</div><div>            {anti_entropy_data_dir, "/var/lib/riak/anti_entropy"},</div><div><br></div><div>            %% The LevelDB options used by AAE to generate the LevelDB-backed</div>

<div>            %% on-disk hashtrees.</div><div>            {anti_entropy_leveldb_opts, [{write_buffer_size, 4194304},</div><div>                                         {max_open_files, 20}]},</div></div><div><br></div>

<div>I'll update the bloom filters value and see what happens... </div><div><br></div><div>It's thursday again, and the regeneration process has started again. Since I've updated to 1.4.6, I have another thing different. The get/put values for each cluster node now have a "random" behaviour. Take a look at the next screenshot</div>

<div><br></div><div><a href="https://cloudup.com/cgbu9VNhSo1">https://cloudup.com/cgbu9VNhSo1</a><br></div><div><br></div><div>Best regards</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 31 December 2013 21:16, Charlie Voiselle <span dir="ltr"><<a href="mailto:cvoiselle@basho.com" target="_blank">cvoiselle@basho.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Edgar:<div><br></div><div>Could you attach the AAE section of your app.config?  I’d like to look into this issue further for you.  Something I think you might be running into is <a href="https://github.com/basho/riak_core/pull/483" target="_blank">https://github.com/basho/riak_core/pull/483</a>.</div>

<div><br></div><div>The issue of concern is that the LevelDB bloom filter is not enabled properly for the instance into which the AAE data is stored.  You can mitigate this particular issue by adding <b>{use_bloomfilter, true}</b> as shown below:</div>

<div><br></div><div><pre style="font-family:Consolas,'Liberation Mono',Courier,monospace;margin-top:0px;margin-bottom:0px;color:rgb(51,51,51);line-height:18px"><div style="padding-left:10px">            %% The LevelDB options used by AAE to generate the LevelDB-backed</div>

<div style="padding-left:10px">            %% on-disk hashtrees.</div><div style="padding-left:10px">            {anti_entropy_leveldb_opts, [{write_buffer_size, 4194304},</div><div style="padding-left:10px">                                         {max_open_files, 20}]},</div>

</pre><div><br></div></div><div>Becomes:</div><div><br></div><div><pre style="font-family:Consolas,'Liberation Mono',Courier,monospace;margin-top:0px;margin-bottom:0px;line-height:18px"><div style="color:rgb(51,51,51);padding-left:10px">

            %% The LevelDB options used by AAE to generate the LevelDB-backed</div><div style="color:rgb(51,51,51);padding-left:10px">            %% on-disk hashtrees.</div><div style="color:rgb(51,51,51);padding-left:10px">

            {anti_entropy_leveldb_opts, [{write_buffer_size, 4194304},</div><div style="padding-left:10px"><span style="color:rgb(51,51,51);white-space:pre-wrap">                                        </span><font color="#e32400"> {use_bloomfilter, true},</font></div>

<div style="color:rgb(51,51,51);padding-left:10px">                                         {max_open_files, 20}]},</div></pre><div><br></div></div><div>This might not solve your specific problem, but it will certainly improve your AAE performance.</div>

<div><br></div><div>Thanks,</div><div>Charlie Voiselle</div><div><div class="h5"><div><br><div><div>On Dec 31, 2013, at 12:04 PM, Edgar Veiga <<a href="mailto:edgarmveiga@gmail.com" target="_blank">edgarmveiga@gmail.com</a>> wrote:</div>

<br><blockquote type="cite"><div dir="ltr">Hey guys! <div><br></div><div>Nothing on this one?</div><div><br></div><div>Btw: Happy new year :)</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 27 December 2013 22:35, Edgar Veiga <span dir="ltr"><<a href="mailto:edgarmveiga@gmail.com" target="_blank">edgarmveiga@gmail.com</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This is a du -hs * of the riak folder:<div><br></div><div><div>44G<span style="white-space:pre-wrap">      </span>anti_entropy</div>



<div>1.1M<span style="white-space:pre-wrap">      </span>kv_vnode</div><div>252G<span style="white-space:pre-wrap">     </span>leveldb</div>
<div>124K<span style="white-space:pre-wrap">      </span>ring</div></div><div><br></div><div>It's a 6 machine cluster, so ~1512G of levelDB.</div><div><br></div><div>Thanks for the tip, I'll upgrade in a near future!</div>




<div><br></div><div>Best regards</div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On 27 December 2013 21:41, Matthew Von-Maszewski <span dir="ltr"><<a href="mailto:matthewv@basho.com" target="_blank">matthewv@basho.com</a>></span> wrote:<br>




<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I have a query out to the developer that can better respond to your follow-up questions.  It might be Monday before we get a reply due to the holidays.<div>




<br></div><div>Do you happen to know how much data is in the leveldb dataset and/or one vnode?  Not sure it will change the response, but might be nice to have that info available.</div><span><font color="#888888"><div>
<br></div><div>Matthew</div></font></span><div><br></div><div>P.S.  Unrelated to your question:  Riak 1.4.4 is available for download.  It has a couple of nice bug fixes for leveldb.</div><div><div><br></div>
<div><br><div><div>On Dec 27, 2013, at 2:08 PM, Edgar Veiga <<a href="mailto:edgarmveiga@gmail.com" target="_blank">edgarmveiga@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">Ok, thanks for confirming!<div>




<br></div><div>Is it normal, that this action affects the overall state of the cluster? On the 26th It started the regeneration and the the response times of the cluster raised to never seen values. It was a day of heavy traffic but everything was going quite ok until it started the regeneration process..</div>






<div><br></div><div>Have you got any advices about changing those app.config values? My cluster is running smoothly for the past 6 months and I don't want to start all over again :) </div><div><br></div><div>Best Regards</div>






</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 27 December 2013 18:56, Matthew Von-Maszewski <span dir="ltr"><<a href="mailto:matthewv@basho.com" target="_blank">matthewv@basho.com</a>></span> wrote:<br>






<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF"><div>Yes.  Confirmed.</div><div><br></div><div>There are options available in app.config to control how often this occurs and how many vnodes rehash at once:  defaults are every 7 days and two vnodes per server at a time.</div>






<div><br>Matthew Von-Maszewski<div><br></div></div><div><div><br>On Dec 27, 2013, at 13:50, Edgar Veiga <<a href="mailto:edgarmveiga@gmail.com" target="_blank">edgarmveiga@gmail.com</a>> wrote:<br><br>

</div><div></div><blockquote type="cite"><div dir="ltr">Hi!<div><br></div><div>I've been trying to find what may be the cause of this.</div><div><br></div><div>Every once in a week, all the nodes in my riak cluster start to do some kind of operation that lasts at least for two days. </div>








<div><br></div><div>You can watch a sample of my munin logs regarding the last week in here:</div><div><br></div><div><a href="https://cloudup.com/imWiBwaC6fm" target="_blank">https://cloudup.com/imWiBwaC6fm</a><br></div>






<div>Take a look at the days 19 and 20, and now it has started again on the 26...</div>

<div><br></div><div>I'm suspecting that this may be caused by the aae hash trees being regenerated, as you say in your documentation:</div><div><span style="color:rgb(91,91,91);font-family:gandhi_serifregular,helvetica,sans-serif;font-size:16px;line-height:27px">For added protection, Riak periodically (default: once a week) clears and regenerates all hash trees from the on-disk K/V data.</span></div>








<div>Can you confirm me that this may be the root of the "problem" and if it's normal for the action to last for two days?<span style="color:rgb(91,91,91);font-family:gandhi_serifregular,helvetica,sans-serif;font-size:16px;line-height:27px"><br>








</span></div><div><br></div><div>I'm using riak 1.4.2 on 6 machines, with centOS. The backend is levelDB.</div><div><br></div><div>Best Regards,</div><div>Edgar Veiga</div></div>
</blockquote></div><blockquote type="cite"><span>_______________________________________________</span><br><span>riak-users mailing list</span><br><span><a href="mailto:riak-users@lists.basho.com" target="_blank">riak-users@lists.basho.com</a></span><br>






<span><a href="http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com" target="_blank">http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com</a></span><br></blockquote></div></blockquote></div>

<br></div>
</blockquote></div><br></div></div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
_______________________________________________<br>riak-users mailing list<br><a href="mailto:riak-users@lists.basho.com" target="_blank">riak-users@lists.basho.com</a><br><a href="http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com" target="_blank">http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com</a><br>

</blockquote></div><br></div></div></div></div></blockquote></div><br></div>