1. bitcask
2. memory
3. leveldb
4. multi
My recent project required me to use memory backend. I have a test server with 24GB memory. I tried to use 4GB as the max_memory. It seems quite easy at beginning, and I just followed the doc from basho.com. I just replace riak_kv_bitcask_backend with riak_kv_memory_backend:
{riak_kv, [
{storage_backend, riak_kv_memory_backend},
Then I want to see how much data I can load with default configuration. I loaded a little over 11 million records, then riak crashed. Then I set max_memory to 4GB to add the following right under {eleveldb ... configuration:
{memory_backend, [ ..., {max_memory, 4096}, %% 4GB in megabytes ... ]}
Note that the following is copied from riak's doc. Then interesting, riak crashed with same number of records (11M+). I then changed it to 8192, but riak still crashed with the same number of records. I spent a couple days, and couldn't figure out the reason. I went to #riak IRC and asked the following question, and those folks were very responsive and solved my problem right away:
<zhentao> hi folks, how to configure the max_memory for memory_backend?
<@alexmoore> Hi zhentao<zhentao> Hi<zhentao> I added the following to config file:<zhentao> {memory_backend, [ {max_memory, 8192} %% 8GB in megabytes ]},<zhentao> but it didn't work<@alexmoore> In regards to your earlier question, if you don't specify a max_memory, or a TTL, the memory backend will continue to grow until it runs out of memory.<@alexmoore> Let me look at your config here<zhentao> it seems like that<zhentao> the node crashed after I loaded some data<zhentao> then I specify the max_memory to 8gb, and it still crashed with same amount of data<@alexmoore> How much RAM does the machine have?<sully_> Cluster health seems like it's degrading again. We're starting to see the same errors as before.<zhentao> 24 GB<sully_> We are planning to add 3 more nodes.<@evanmcc> zhentao: that's 8GB per vnode<@rzezeski> sully_ ok, can you tar.gz the latest log files again, that might allow me to find the cause before it gets rotated out by the logger<@jcaprice> zhentao: did you restart the node after adding the memory constraint?<sully_> Getting you the latest logs.<zhentao> yes, I restarted it<@evanmcc> zhentao: how many nodes, and what is your ring size?<@alexmoore> zhentao, how many physical machines do you have in your cluster, and what is your ring size?<zhentao> it is a test server and just one machine<@jcaprice> ring size?<zhentao> i am new to riak, and where to find th ring size?<@evanmcc> if you didn't set it, it's 64<@alexmoore> In your vm.args file<@evanmcc> so you're limiting memory to 8GB * 64<zhentao> let me check<@evanmcc> alexmoore: it's in app.config under riak_core<@evanmcc> ring_creation_size<@alexmoore> Whoops, make that the app.config<zhentao> it is 64<zhentao> {ring_creation_size, 64},<@evanmcc> so you want to change max memory to 128<@evanmcc> if you want to limit it at 8GB<@jcaprice> zhentao: max_memory limits the amount of memory used per vnode, not for the node itself<zhentao> @jcaprice, so what number I should use for max_memory for my test server?<@evanmcc> 128, like I said above<zhentao> 128 mb?<@evanmcc> yes<@jcaprice> as evanmcc said, you'll want 8192 / 64<zhentao> thx, let me try it
So in summary, {max_memory, 4096} is for each vnode, not for each machine. Since I wanted to limit the memory usage for one machine to 4GB, I should use the following:
{max_memory, 64}
The reason is that the ring_creattion_size is 64 which means there are 64 vnodes on my single test server.
64MB * 64 = 4096MB
After I changed max_memory to 64, riak is happy, and it didn't crash when I tried to load 20MM records.
Some interesting things I noticed:
1. since Riak use LRU for memory_backend, the old records are evicted if max_memory can't hold all records.
2. With the key as "70f21766-1cde-38d4-5920-a380003723b3", and value as "1365720608095#TQB:1.4:2:1",
4GB memory with 64 vnodes can hold about 2.5MM records
4GB memory with 4 vnodes can hold about 7MM records
Seems the number of vnodes/machine has big overhead
No comments:
Post a Comment