It would be sufficient if I could have two eleveldb instances in
riak_kv_multi_backend and if I could drop one of them with
riak_kv_eleveldb_backend:drop/1 while the other instance is used. After another
interval I would drop the second instance etc.
Jan
-- Původní zpráva --
Od
-- Původní zpráva --
> Od: Matthew Von-Maszewski
> Datum: 22. 10. 2012
> Předmět: Re: Riak performance problems when LevelDB database grows beyond 16GB
> Jan,
>
> ...
> The next question from me is whether the drive / disk array problems are your
> only problem at this point. Th
You are right! Riak was killed by the oom killer on all nodes except the one I
was looking at.
Oct 14 18:34:01 gr-node03 kernel: [ pid ] uid tgid total_vm rss cpu
oom_adj oom_score_adj name
Oct 14 18:34:01 gr-node03 kernel: [31808] 106 31808 5178811 3884730 0
0 0
://janevangelista.rajce.idnes.cz/nastenka/#4Riak_2K_2.1RC2_3d_edited.jpg ).
All the nodes crashed silently, there is nothing interesting in Riak logs.
Thanks, Jan
-- Původní zpráva --
Od: Evan Vigil-McClanahan
Datum: 12. 10. 2012
Předmět: Re: Re: Riak performance problems when LevelDB
Hi there, Jan,
The lsof issue is that max_open_files is per backend, iirc, so if
you're maxed out you'll see vnode count * max_open_files.
I think on the second try, you may have set the cache too high. I'd
drop it back to 8 or 16 MB, and possibly up the open files a bit more,
but you don't see
> Can you attach the eleveldb portion of your app.config file?
> Configuration problems, especially max_open_files being too low, can
> often cause issues like this.
>
> If it isn't sensitive, the whole app.config and vm.args files are also
> often helpful.
Hello Evan,
thanks for responding.
I o