On 25 January 2017 at 21:09, Arun Rajagopalan
wrote:
> Thanks Luke. Sorry it took me some time to experiment ...
>
> I am not sure what happens in a couple of scenarios. Maybe you can explain
>
> Lets say I lose a node completely and want to replace it. Will the keys
> yet to be "anti-entropied"
Hi,
We have a cluster of 5 nodes, which are continuously being queried for
new data through solr. We have been having some issues with riak/solr
which seems to be happening after longer periods of operation. It starts
off with one node and it seems to be happening on all node after a
while.
We tr
Hi Riak Users,
One of my riak nodes, it has 4G memory, when I check the memory usage with
"free -m", I can see there are only around 150M left. Then I check the
command "riak-admin status", it shows around 415M(415594432) consumed by
Erlang. But with "top" command, it shows Erlang takes 52.1% me
Hi Steven,
Based on that log output, it looks like you're running into issues with
system limits, probably open file limits. You can check the value that
Riak has available by connecting to one of the nodes with riak attach, then
executing:
```
os:cmd("ulimit -n").
```
(After, disconnect with c
Hi Shaun,
I have already set this to a very high value
(r...@hawk1.streethawk.com)1> os:cmd("ulimit -n").
"2500\n"
(r...@hawk1.streethawk.com)2>
So the issue is not that the limit is low, but maybe a resource leak ? As I
mentioned our application processes continuously run queries on the cl
Alex,
Which backend are you using? Leveldb's memory usage does not show up within
Erlang. Maybe that is what you are experiencing?
Matthew
Sent from my iPad
> On Jan 26, 2017, at 5:47 AM, Alex Feng wrote:
>
> Hi Riak Users,
>
> One of my riak nodes, it has 4G memory, when I check the memo
Steven,
You may be able to get information via the lsof command as to what
process(es) are using many file handles (if that is the cause).
I searched for that particular error and found this GH issue:
https://github.com/emqtt/emqttd/issues/426
Which directed me to this page:
https://github.com/e
FYI: this is the function that is crashing:
get_uint32_measurement(Request, #internal{os_type = {unix, linux}}) ->
{ok,F} = file:open("/proc/loadavg",[read,raw]), %% <---
crash line
{ok,D} = file:read(F,24),
ok = file:close(F),
{ok,[Load1,Load5,Load15,_PRun,PTota
HI Mattew,
Thank you for the help.
I got answer from Shaun already, seems LevelDB and Bitcask, they are same,
memory usage does not show up in Erlang.
Br,
Alex
2017-01-26 14:47 GMT+01:00 Matthew Von-Maszewski :
> Alex,
>
> Which backend are you using? Leveldb's memory usage does not show up
>
Hi,
I am wondering if there are some best practice or recommendation for how
many keys inside a single bucket?
Let's say I have some sensors reporting data every 5 seconds, I can put all
these data under one single bucket, or I can dynamically generate a bucket
every day.
My question is, is th
Hi Riak Users,
I am in the process of migrating a few Riak CS clusters from mutli to
leveldb backend. I am aware this is not an officially supported
configuration, but I feel it will be better for my (very limited) hardware
constraints, especially RAM, and I am not too concerned about the lower
pe
Riak CS stores data chunks in bitcask and the index/metadata file in leveldb.
Bitcask, as noted, has no compression. When you force Riak to use level for the
data chunks you get compression for that data which may or may not be good for
your use case. If it's not good for your use case I believe
Hi, you should consider using Riak TS for this use case.
-Alexander
@siculars
http://siculars.posthaven.com
Sent from my iRotaryPhone
> On Jan 27, 2017, at 01:54, Alex Feng wrote:
>
> Hi,
>
> I am wondering if there are some best practice or recommendation for how many
> keys inside a si
Hi Alexander,
Yes, I should consider the possibility of switching to Riak TS.
But I guess the question still valid, does it ? Should I divide millions
of keys to different buckets, does it make any difference in performance,
memory, space ?
Br,
Alex
2017-01-27 2:50 GMT+01:00 Alexander Sicular
14 matches
Mail list logo