<div dir="ltr">Hi Luke,<div><br></div><div>Indeed, when removed the thousands of requests, the memory is stabilized. However the memory consumption is still very high:</div><div><br></div><div><div>riak-admin status |grep memory</div><div>memory_total : 18494760128</div><div>memory_processes : 145363184</div><div>memory_processes_used : 142886424</div><div>memory_system : 18349396944</div><div>memory_atom : 561761</div><div>memory_atom_used : 554496</div><div>memory_binary : 7108243240</div><div>memory_code : 13917820</div><div>memory_ets : 11200328880</div></div><div><br></div><div>I have test also with Riak 1.4.10 and the performance is the same. </div><div><br></div><div>Is it normal that the "memory_ets" has more than 10GB when we have a "ring_size" of 16 and a max_memory_per_vnode = 250MB?</div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-10-15 20:50 GMT+02:00 Lucas Grijander <span dir="ltr"><<a href="mailto:lucasgrinjander69@gmail.com" target="_blank">lucasgrinjander69@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Luke.<div><br></div><div>About the first issue:</div><div><br></div><div>- From the beginning, the servers are all running ntpd. They are Ubuntu 14.04 and the ntpd service is installed and running by default. </div><div>- Anti-entropy was also disabled from the beginning:</div><div><br></div><div>{anti_entropy,{off,[]}},<br></div><div><br></div><div><br></div><div>About the second issue, I am perplex because, after 2 restarts of the Riak server, just now there is a big memory consumption but is not growing like the previous days. The only change was to remove this code (it was used thousands of times/s). It was a possible workaround about the previous problem with the TTL but this code now is useless because the TTL is working fine with this node alone:</div><div><br></div><div><div>self.db.delete((key)</div><div>self.db.get(key, r=1)</div></div><div><br></div><div><br></div><div><span class=""><div># riak-admin status|grep memory</div></span><div>memory_total : 18617871264</div><div>memory_processes : 224480232</div><div>memory_processes_used : 222700176</div><div>memory_system : 18393391032</div><div>memory_atom : 561761</div><div>memory_atom_used : 552862</div><div>memory_binary : <a href="tel:7135206080" value="+17135206080" target="_blank">7135206080</a></div><div>memory_code : 13779729</div><div>memory_ets : 11209256232</div></div><div><br></div><div>The problem is that I don't remember if the code change was after or before the second restart. I am going to restart the riak server again and I will report you about if the "possible memory leak" is reproduced.</div><div><br></div><div>This is the props of the bucket:</div><div>{"props":{"allow_mult":false,"backend":"ttl_stg","basic_quorum":false,"big_vclock":50,"chash_keyfun":{"mod":"riak_core_util","fun":"chash_std_keyfun"},"dvv_enabled":false,"dw":"quorum","last_write_wins":true,"linkfun":{"mod":"riak_kv_wm_link_walker","fun":"mapreduce_linkfun"},"n_val":1,"name":"ttl_stg","notfound_ok":true,"old_vclock":86400,"postcommit":[],"pr":0,"precommit":[],"pw":0,"r":1,"rw":"quorum","small_vclock":50,"w":1,"young_vclock":20}}<br></div><div><br></div><div>About the data that we put into the bucket are all with this schema:</div><div><br></div><div>KEY: Alphanumeric with a length of 47</div><div>DATA: Long integer.</div><div><br></div><div><div># riak-admin status|grep puts</div><div>vnode_puts : 84708</div><div>vnode_puts_total : 123127430</div><div>node_puts : 83169</div><div>node_puts_total : 123128062</div></div><div><br></div><div><div># riak-admin status|grep gets</div><div>vnode_gets : 162314</div><div>vnode_gets_total : 240433213</div><div>node_gets : 162317</div><div>node_gets_total : 240433216</div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2014-10-14 16:26 GMT+02:00 Luke Bakken <span dir="ltr"><<a href="mailto:lbakken@basho.com" target="_blank">lbakken@basho.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Lucas,<br>
<br>
With regard to the mysterious key deletion / resurrection, please do<br>
the following:<br>
<br>
* Ensure your servers are all running ntpd and have their time<br>
synchronized as closely as possible.<br>
* Disable anti-entropy. I suspect this is causing the strange behavior<br>
you're seeing with keys.<br>
<br>
Your single node cluster memory consumption issue is a bit of a<br>
puzzler. I'm assuming you're using default bucket settings and not<br>
using bucket types based on your previous emails, and that allow_mult<br>
is still false for your ttl_stg bucket. Can you tell me more about the<br>
data you're putting into that bucket for testing? I'll try and<br>
reproduce it with my single node cluster.<br>
<span><br>
--<br>
Luke Bakken<br>
Engineer / CSE<br>
<a href="mailto:lbakken@basho.com" target="_blank">lbakken@basho.com</a><br>
<br>
<br>
</span><div><div>On Mon, Oct 13, 2014 at 5:02 PM, Lucas Grijander<br>
<<a href="mailto:lucasgrinjander69@gmail.com" target="_blank">lucasgrinjander69@gmail.com</a>> wrote:<br>
> Hi Luke.<br>
><br>
> I really appreciate your efforts to attempt to reproduce the problem. I<br>
> think that the configs are right. I have been doing also a lot of tests and<br>
> with 1 server/node, the memory bucket works flawlessly, as your test. The<br>
> Riak cluster where we have the problem has a multi_backend with 1 memory<br>
> backend, 2 bitcask backends and 2 leveldb backends. I have only changed the<br>
> parameter connection of the memory backend in our production code to another<br>
> new "cluster" with only 1 node, with the same config of Riak but with only 1<br>
> memory backend under the multi configuration and, as I said, all fine, the<br>
> problem vanished. I deduce that the problem appears only with more than 1<br>
> node and with a lot of requests.<br>
><br>
> In my tests with the production cluster with the problem ( 4 nodes), finally<br>
> I realized that the TTL is working but, randomly and suddenly, KEYS already<br>
> deleted appear, and KEYS with correct TTL disappear :-? (Maybe something<br>
> related with the some ETS internal table? ) This is the moment when I can<br>
> obtain KEYS already expired.<br>
><br>
> In summary:<br>
><br>
> - With cluster with 4 nodes (config below): All OK for a while and suddenly<br>
> we lost the last 20 seconds approx. of keys and OLD keys appear in the list:<br>
> curl -X GET <a href="http://localhost:8098/buckets/ttl_stg/keys?keys=true" target="_blank">http://localhost:8098/buckets/ttl_stg/keys?keys=true</a><br>
><br>
> buckets.default.last_write_wins = true<br>
> bitcask.io_mode = erlang<br>
> multi_backend.ttl_stg.storage_backend = memory<br>
> multi_backend.ttl_stg.memory_backend.ttl = 90s<br>
> multi_backend.ttl_stg.memory_backend.max_memory_per_vnode = 25MB<br>
> anti_entropy = passive<br>
> ring_size = 256<br>
><br>
> - With 1 node: All OK<br>
><br>
> buckets.default.n_val = 1<br>
> buckets.default.last_write_wins = true<br>
> buckets.default.r = 1<br>
> buckets.default.w = 1<br>
> multi_backend. ttl_stg.storage_backend = memory<br>
> multi_backend. ttl_stg.memory_backend.ttl = 90s<br>
> multi_backend. ttl_stg.memory_backend.max_memory_per_vnode = 250MB<br>
> ring_size = 16<br>
><br>
><br>
><br>
> Another note: With this 1 node (32GB RAM) and only activated the memory<br>
> backend I have realized than the memory consumption grows without control:<br>
><br>
><br>
> # riak-admin  status|grep memory<br>
> memory_total : <a href="tel:17323130960" value="+17323130960" target="_blank">17323130960</a><br>
> memory_processes : 235043016<br>
> memory_processes_used : 233078456<br>
> memory_system : <a href="tel:17088087944" value="+17088087944" target="_blank">17088087944</a><br>
> memory_atom : 561761<br>
> memory_atom_used : 561127<br>
> memory_binary : 6737787976<br>
> memory_code : 14370908<br>
> memory_ets : 10295224544<br>
><br>
> # # riak-admin diag -d debug<br>
> [debug] Local RPC: os:getpid([]) [5000]<br>
> [debug] Running shell command: ps -o pmem,rss -p 17521<br>
> [debug] Shell command output:<br>
> %MEM   RSS<br>
> 60.5 19863800<br>
><br>
> Wow 18.9GB when the max_memory_per_vnode = 250MB. Is far away from the<br>
> value,  250*16vnodes = 4000MB. Is it that correct?<br>
><br>
> This is the riak-admin vnode-status of 1 vnode, the other 15 are with<br>
> similar data:<br>
><br>
> VNode: 1370157784997721485815954530671515330927436759040<br>
> Backend: riak_kv_multi_backend<br>
> Status:<br>
> [{<<"ttl_stg">>,<br>
>   [{mod,riak_kv_memory_backend},<br>
>    {data_table_status,[{compressed,false},<br>
>                        {memory,1156673},<br>
>                        {owner,<8343.9466.104>},<br>
>                        {heir,none},<br>
><br>
> {name,riak_kv_1370157784997721485815954530671515330927436759040},<br>
>                        {size,29656},<br>
>                        {node,'riak@xxxxxxxx'},<br>
>                        {named_table,false},<br>
>                        {type,ordered_set},<br>
>                        {keypos,1},<br>
>                        {protection,protected}]},<br>
>    {index_table_status,[{compressed,false},<br>
>                         {memory,89},<br>
>                         {owner,<8343.9466.104>},<br>
>                         {heir,none},<br>
><br>
> {name,riak_kv_1370157784997721485815954530671515330927436759040_i},<br>
>                         {size,0},<br>
>                         {node,'riak@xxxxxxxxx'},<br>
>                         {named_table,false},<br>
>                         {type,ordered_set},<br>
>                         {keypos,1},<br>
>                         {protection,protected}]},<br>
>    {time_table_status,[{compressed,false},<br>
>                        {memory,75968936},<br>
>                        {owner,<8343.9466.104>},<br>
>                        {heir,none},<br>
><br>
> {name,riak_kv_1370157784997721485815954530671515330927436759040_t},<br>
>                        {size,2813661},<br>
>                        {node,'riak@xxxxxxxxx'},<br>
>                        {named_table,false},<br>
>                        {type,ordered_set},<br>
>                        {keypos,1},<br>
>                        {protection,protected}]}]}]<br>
><br>
> Thanks!<br>
><br>
> 2014-10-13 22:30 GMT+02:00 Luke Bakken <<a href="mailto:lbakken@basho.com" target="_blank">lbakken@basho.com</a>>:<br>
>><br>
>> Hi Lucas,<br>
>><br>
>> I've tried reproducing this using a local Riak 2.0.1 node, however TTL<br>
>> is working as expected.<br>
>><br>
>> Here is the configuration I have in /etc/riak/riak.conf:<br>
>><br>
>> storage_backend = multi<br>
>> multi_backend.default = bc_default<br>
>><br>
>> multi_backend.ttl_stg.storage_backend = memory<br>
>> multi_backend.ttl_stg.memory_backend.ttl = 90s<br>
>> multi_backend.ttl_stg.memory_backend.max_memory_per_vnode = 4MB<br>
>><br>
>> multi_backend.bc_default.storage_backend = bitcask<br>
>> multi_backend.bc_default.bitcask.data_root = /var/lib/riak/bc_default<br>
>> multi_backend.bc_default.bitcask.io_mode = erlang<br>
>><br>
>> This translates to the following in<br>
>> /var/lib/riak/generated.configs/app.2014.10.13.13.13.29.config:<br>
>><br>
>> {multi_backend_default,<<"bc_default">>},<br>
>> {multi_backend,<br>
>>     [{<<"ttl_stg">>,riak_kv_memory_backend,[{ttl,90},{max_memory,4}]},<br>
>>     {<<"bc_default">>,riak_kv_bitcask_backend,<br>
>>     [{io_mode,erlang},<br>
>>         {expiry_grace_time,0},<br>
>>         {small_file_threshold,10485760},<br>
>>         {dead_bytes_threshold,134217728},<br>
>>         {frag_threshold,40},<br>
>>         {dead_bytes_merge_trigger,536870912},<br>
>>         {frag_merge_trigger,60},<br>
>>         {max_file_size,<a href="tel:2147483648" value="+12147483648" target="_blank">2147483648</a>},<br>
>>         {open_timeout,4},<br>
>>         {data_root,"/var/lib/riak/bc_default"},<br>
>>         {sync_strategy,none},<br>
>>         {merge_window,always},<br>
>>         {max_fold_age,-1},<br>
>>         {max_fold_puts,0},<br>
>>         {expiry_secs,-1},<br>
>>         {require_hint_crc,true}]}]}]},<br>
>><br>
>> I set the bucket properties to use the ttl_stg backend:<br>
>><br>
>> root@UBUNTU-12-1:~# cat ttl_stg-props.json<br>
>> {"props":{"name":"ttl_stg","backend":"ttl_stg"}}<br>
>><br>
>> root@UBUNTU-12-1:~# curl -XPUT -H'Content-type: application/json'<br>
>> localhost:8098/buckets/ttl_stg/props --data-ascii @ttl_stg-props.json<br>
>><br>
>> root@UBUNTU-12-1:~# curl -XGET localhost:8098/buckets/ttl_stg/props<br>
>><br>
>> {"props":{"allow_mult":false,"backend":"ttl_stg","basic_quorum":false,"big_vclock":50,"chash_keyfun":{"mod":"riak_core_util","fun":"chash_std_keyfun"},"dvv_enabled":false,"dw":"quorum","last_write_wins":false,"linkfun":{"mod":"riak_kv_wm_link_walker","fun":"mapreduce_linkfun"},"n_val":3,"name":"ttl_stg","notfound_ok":true,"old_vclock":86400,"postcommit":[],"pr":0,"precommit":[],"pw":0,"r":"quorum","rw":"quorum","small_vclock":50,"w":"quorum","young_vclock":20}}<br>
>><br>
>><br>
>> And used the following statement to PUT test data:<br>
>><br>
>> curl -XPUT localhost:8098/buckets/ttl_stg/keys/1 -d "TEST $(date)"<br>
>><br>
>> After 90 seconds, this is the response I get from Riak:<br>
>><br>
>> root@UBUNTU-12-1:~# curl -XGET localhost:8098/buckets/ttl_stg/keys/1<br>
>> not found<br>
>><br>
>> I would carefully check all of the app.config / riak.conf files in<br>
>> your cluster, the output of "riak config effective" and the bucket<br>
>> properties for those buckets you expect to be using the memory backend<br>
>> with TTL. I also recommend using the localhost:8098/buckets/ endpoint<br>
>> instead of the deprecated riak/ endpoint.<br>
>><br>
>> Please let me know if you have additional questions.<br>
>> --<br>
>> Luke Bakken<br>
>> Engineer / CSE<br>
>> <a href="mailto:lbakken@basho.com" target="_blank">lbakken@basho.com</a><br>
>><br>
>><br>
>> On Fri, Oct 3, 2014 at 11:32 AM, Lucas Grijander<br>
>> <<a href="mailto:lucasgrinjander69@gmail.com" target="_blank">lucasgrinjander69@gmail.com</a>> wrote:<br>
>> > Hello,<br>
>> ><br>
>> > I have a memory backend in production with Riak 2.0.1, 4 servers and 256<br>
>> > vnodes. The servers have the same date and time.<br>
>> ><br>
>> > I have seen an odd performance with the ttl.<br>
>> ><br>
>> > This is the config:<br>
>> ><br>
>> >            {<<"ttl_stg">>,riak_kv_memory_backend,<br>
>> >             [{ttl,90},{max_memory,25}]},<br>
>> ><br>
>> > For example, see this GET response in one of the riak servers:<br>
>> ><br>
>> > < HTTP/1.1 200 OK<br>
>> > < X-Riak-Vclock: a85hYGBgzGDKBVIc4otdfgR/7bfIYEpkzGNlKI1efJYvCwA=<br>
>> > < Vary: Accept-Encoding<br>
>> > * Server MochiWeb/1.1 WebMachine/1.10.5 (jokes are better explained) is<br>
>> > not<br>
>> > blacklisted<br>
>> > < Server: MochiWeb/1.1 WebMachine/1.10.5 (jokes are better explained)<br>
>> > < Link: </riak/ttl_stg>; rel="up"<br>
>> > < Last-Modified: Fri, 03 Oct 2014 17:40:05 GMT<br>
>> > < ETag: "3c8bGoifWcOCSVn0otD5nI"<br>
>> > < Date: Fri, 03 Oct 2014 17:47:50 GMT<br>
>> > < Content-Type: application/json<br>
>> > < Content-Length: 17<br>
>> ><br>
>> > If the TTL is 90 seconds, Why the GET doesn't return "not found" if the<br>
>> > difference between "Last-Modified" and "Date" (of the curl request) is<br>
>> > greater than the TTL?<br>
>> ><br>
>> > Thanks in advance!<br>
>> ><br>
>> ><br>
>> > _______________________________________________<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>
>> ><br>
><br>
><br>
><br>
> _______________________________________________<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>
><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>