h: size of disk space/(n_val * number of keys)
but that's not ideal because
we store different types of objects too...
Is there any way to do that from a bottom up approach with a map/reduce job?
Thanks!
--
*Got a blog? Make following it simple: https://www.subtome.com/
*
Julien Genesto
Hi,
We are running a cluster of 5 servers, or at least trying to, because nodes
seem to be dying 'randomly'
without us knowing any reason why. We don't have a great Erlang guy aboard,
and the error logs are not
that verbose.
So I've just .tgz the whole log directory and I was hoping somebody could
ter?
>
> How much data do you have in the cluster and how are you querying it?
>
> Best regards,
>
> Christian
>
>
>
> On 12 May 2013, at 19:11, Julien Genestoux
> wrote:
>
> Hi,
>
> We are running a cluster of 5 servers, or at least trying to, because
&g
fically look at node_get_fsm_objsize_* and node_get_fsm_siblings_*
> statistics in order to identify objects that are very large or have lots of
> siblings.
>
> Best regards,
>
> Christian
>
>
>
> On 13 May 2013, at 16:44, Julien Genestoux
> wrote:
>
> Chris
blog? Make following it simple: https://www.subtome.com/
*
Julien Genestoux,
http://twitter.com/julien51
+1 (415) 830 6574
+33 (0)9 70 44 76 29
On Tue, May 14, 2013 at 12:31 PM, Julien Genestoux <
julien.genest...@gmail.com> wrote:
> Thanks Christian.
> We do indeed use mapreduce
this be due to the "delete"
policy? It turns out that we delete a lot of items (is there a way to get
the list of commands sent to a node/cluster?)
Thanks!
On Wed, May 15, 2013 at 11:29 PM, Julien Genestoux <
julien.genest...@gmail.com> wrote:
> Christian, all,
>
> Not
smaller max file size in order to allow merging to occur more frequently.
>
> Best regards,
>
> Christian
>
>
>
> On 17 May 2013, at 13:06, Julien Genestoux
> wrote:
>
> Christian, All
>
> Our servers still have not died... but we see another strange behavior:
Hello,
We store the following in our Riak cluster:
- feeds as a list of 10 keys to entries. All the keys are like this:
feedKey-entryKey
- entries as a complex JSON object.
We try to avoid losing track of any entryKey by deleting it from the feed
object only when corresponding object has been del