Hi Duy:
The compound partition key seems perfect, but you say that pagination isn't
possible with it: why is that?
Regards,
James
On Sat, Mar 22, 2014 at 10:40 AM, DuyHai Doan wrote:
> Ben
>
>
> > When you say beware of the cardinality, do you think that the
> cardinality is too low in this
Sorry, my finger slipped on "enter"
So as I said,
http://www.datastax.com/documentation/cql/3.1/cql/ddl/ddl_when_use_index_c.html
*Problems using an index on a frequently updated or deleted column*
Cassandra stores tombstones in the index until the tombstone limit reaches
*100K* cells. After exc
Hello
I've read the documentation about secondary index and among the use-cases
to avoid, there is the case of frequenty updated/deleted columns:
You might want to look at:
http://www.opensourceconnections.com/2013/08/31/building-the-perfect-cassandra-test-environment/
On Sat, Mar 22, 2014 at 4:38 PM, Brian Flad wrote:
> Is there anything else running on the boxes? Can you show us the output of
> ps aux for the Cassandra process so we c
Also we use datastax. The version cassandra-1.1.9 doesn't work with java 7
On Sat, Mar 22, 2014 at 9:09 PM, prem yadav wrote:
> The output of ps waux . Also there is no load on cluster. None
>
> USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
> root 1 0.0 0.0
The output of ps waux . Also there is no load on cluster. None
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 19224 1076 ?Ss Mar19 0:01 /sbin/init
root 2 0.0 0.0 0 0 ?SMar19 0:00 [kthreadd]
root
Is there anything else running on the boxes? Can you show us the output of
ps aux for the Cassandra process so we can see the -xmx, etc? JDK 7 may
help, even if you cannot upgrade Cassandra yet (which I would really
recommend since it moves items off-heap).
On Sat, Mar 22, 2014 at 4:01 PM, prem y
Upgrading is not possible right now. Any other suggestions guys?
I have already tried reducing the number of rpc threads. Also tried
reducing the linux kernel overcommit.
On Sat, Mar 22, 2014 at 5:44 PM, Laing, Michael
wrote:
> I ran into the same problem some time ago.
>
> Upgrading to Cassandr
I ran into the same problem some time ago.
Upgrading to Cassandra 2, jdk 1.7, and default parameters fixed it.
I think the jdk change was the key for my similarly small memory cluster.
ml
On Sat, Mar 22, 2014 at 1:36 PM, prem yadav wrote:
> Michael, no memory constraints. System memory is 4
Ben
> When you say beware of the cardinality, do you think that the cardinality
is too low in this instance?
Secondary indexes in C* are distributed across all the nodes containing
actual data so somehow it helps avoiding hot spots. However, since there
are only 2 values for your boolean flag, e
Michael, no memory constraints. System memory is 4 GB and Cassandra run on
default.
On Sat, Mar 22, 2014 at 5:32 PM, prem yadav wrote:
> Its Oracle jdk 1.6.
> Robert, any fix that you know of which went into 1.2.15 for this
> particular issue?
>
>
> On Sat, Mar 22, 2014 at 4:50 PM, Robert Coli
Its Oracle jdk 1.6.
Robert, any fix that you know of which went into 1.2.15 for this particular
issue?
On Sat, Mar 22, 2014 at 4:50 PM, Robert Coli wrote:
> On Sat, Mar 22, 2014 at 7:48 AM, prem yadav wrote:
>
>> But, the cassandra process keeps getting killed due to OOM. Cassandra
>> version
On Sat, Mar 22, 2014 at 7:48 AM, prem yadav wrote:
> But, the cassandra process keeps getting killed due to OOM. Cassandra
> version in use is 1.1.9.
>
Try using 1.2.15, instead?
=Rob
What JVM are you running on? What, if any, memory constraints are you
passing to the process?
On Mar 22, 2014 10:48 AM, "prem yadav" wrote:
> Hi,
> I have a 3 node cassandra test cluster. The nodes have 4 GB total memory/2
> cores. Cassndra run with all default settings.
> But, the cassandra pro
Hi,
I have a 3 node cassandra test cluster. The nodes have 4 GB total memory/2
cores. Cassndra run with all default settings.
But, the cassandra process keeps getting killed due to OOM. Cassandra
version in use is 1.1.9.
here are the settings in use:
compaction_throughput_mb_per_sec: 16
row_cache_
16 matches
Mail list logo
