date:20151223

Re: What is the ideal way to merge two Cassandra clusters with same keyspace into one?

2015-12-23 Thread Noorul Islam Kamal Malmiyoda

Is there a way to keep writetime and ttl of each record as it is in new cluster?

Thanks and Regards
Noorul

On Mon, Dec 21, 2015 at 5:46 PM, DuyHai Doan  wrote:
> For cross-cluster operation with the Spark/Cassandra connector, you can look
> at this trick:
> http://www.slideshare.net/doanduyhai/fast-track-to-getting-started-with-dse-max-ing/64
>
> On Mon, Dec 21, 2015 at 1:14 PM, George Sigletos 
> wrote:
>>
>> Roughly half TB of data.
>>
>> There is a timestamp column in the tables we migrated and we did use that
>> to achieve incremental updates.
>>
>> I don't know anything about kairosdb, but I can see from the docs that
>> there exists a row timestamp column. Could you maybe use that one?
>>
>> Kind regards,
>> George
>>
>> On Mon, Dec 21, 2015 at 12:53 PM, Noorul Islam K M 
>> wrote:
>>>
>>> George Sigletos  writes:
>>>
>>> > Hello,
>>> >
>>> > We had a similar problem where we needed to migrate data from one
>>> > cluster
>>> > to another.
>>> >
>>> > We ended up using Spark to accomplish this. It is fast and reliable but
>>> > some downtime was required after all.
>>> >
>>> > We minimized the downtime by doing a first run, and then run
>>> > incremental
>>> > updates.
>>> >
>>>
>>> How much data are you talking about?
>>>
>>> How did you achieve incremental run? We are using kairosdb and some of
>>> the other schemas does not have a way to filter based on date.
>>>
>>> Thanks and Regards
>>> Noorul
>>>
>>> > Kind regards,
>>> > George
>>> >
>>> >
>>> >
>>> > On Mon, Dec 21, 2015 at 10:12 AM, Noorul Islam K M 
>>> > wrote:
>>> >
>>> >>
>>> >> Hello all,
>>> >>
>>> >> We have two clusters X and Y with same keyspaces but distinct data
>>> >> sets.
>>> >> We are planning to merge these into single cluster. What would be
>>> >> ideal
>>> >> steps to achieve this without downtime for applications? We have time
>>> >> series data stream continuously writing to Cassandra.
>>> >>
>>> >> We have ruled out export/import as that will make us loose data during
>>> >> the time of copy.
>>> >>
>>> >> We also ruled out sstableloader as that is not reliable. It fails
>>> >> often
>>> >> and there is not way to start from where it failed.
>>> >>
>>> >> Any suggestions will help.
>>> >>
>>> >> Thanks and Regards
>>> >> Noorul
>>> >>
>>
>>
>

Re: Cassandra 3.1 - Aggregation query failure

2015-12-23 Thread Dinesh Shanbhag



Even if aggregation that forces a full table scan across partitions is 
not recommended, the message/exception does seems unrelated to partitioning:


   cqlsh:flightdata> select late_flights(uniquecarrier, depdel15) from
   flightsbydate in ('2015-09-15', '2015-09-16',
   '2015-09-17', '2015-09-18', '2015-09-19', '2015-09-20', '2015-09-21');

   Traceback (most recent call last):
  File "CassandraInstall-3.1/bin/cqlsh.py", line 1258, in
   perform_simple_statement
result = future.result()
  File
   
"/home/wpl/CassandraInstall-3.1/bin/../lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/cluster.py", 


   line 3122, in result
raise self._final_exception
   FunctionFailure: code=1400 [User Defined Function failure]
   message="execution of 'flightdata.state_late_flights[map>>, text, decimal]' failed:
   java.security.AccessControlException: access denied
   ("java.io.FilePermission"
   "/home/wpl/CassandraInstall-3.1/conf/logback.xml" "read")"

Is that right?

And note that this same aggregation query (on a subset of the month's 
days) does complete successfully sometimes.


The behavior is similar with Cassandra 3.0 as well: on the same set of 
days, the query sometimes succeeds, fails most times.  Would trying the 
Datastax distribution offer any better chances?


Thanks,
Dinesh.


On 12/24/2015 2:59 AM, DuyHai Doan wrote:
Thanks for the pointer on internal paging Tyler, I missed this one. 
But then it raises some questions:


1. Is it possible to "tune" the page size or is it hard-coded internally ?
2. Is read-repair performed on EACH page or is it done on the whole 
requested rows once they are fetched ?


Question 2. is relevant in some particular scenarios when the user is 
using CL QUORUM (or more) and some replicas are out-of-sync. Even in 
the case of aggregation over a single partition, if this partition is 
wide and spans many fetch pages, the time the coordinator performs all 
the read-repair and reconcile over QUORUM replicas, the query may 
timeout very quickly.



On Fri, Dec 18, 2015 at 5:26 PM, Tyler Hobbs > wrote:



On Fri, Dec 18, 2015 at 9:17 AM, DuyHai Doan mailto:doanduy...@gmail.com>> wrote:

Cassandra will perform a full table scan and fetch all the
data in memory to apply the aggregate function.


Just to clarify for others on the list: when executing aggregation
functions, Cassandra /will/ use paging internally, so at most one
page worth of data will be held in memory at a time.  However, if
your aggregation function retains a large amount of data, this may
contribute to heap pressure.


-- 
Tyler Hobbs

DataStax

Re: Write/read heavy usecase in one cluster

2015-12-23 Thread Jonathan Haddad

While I would normally suggest splitting different systems to different
hardware, you can easily get away with using 3 rather small machines for
this workload.  Just be sure to not use SimpleStrategy so you can split the
keyspaces out to different clusters later if you need to.

On Wed, Dec 23, 2015 at 2:21 PM Robert Wille  wrote:

> I would personally classify both of those use cases as light, and I
> wouldn’t have any qualms about using a single cluster for both of those.
>
> On Dec 23, 2015, at 3:06 PM, cass savy  wrote:
>
> > How do you determine if we can share cluster in prod for 2 different
> applications
> >
> >  1. Has anybody shared cluster in prod a write heavy use case that
> captures user login info (few 100 rpm)  and hardly performs few reads per
> day
> > and
> >  Use case that is read heavy use case that is 92% read with 10k requests
> per min,higher consistency level of quorum
> >
> >
> > 2. Use of  in-memory tables for lookup tables  that will be referred to
> for every request prior to writing to transactional tables. Has anyone ised
> it in prod and what were the issues encountered. what will be tuning/reco
> to follow for prod
> >
> > 3. Use of multiple data directories for different applications like
> having different data partitions for write/read heavy and one separate for
> commitlog/caches
> >
> > 4. plan to use C* 2.1 with vnodes/murmur for above usecases. Need
> feedback of if people have tried tuning heap size, off-heap parameters in
> c* 2.0 and above. in prod
> >
> > 5. Java 8 with c* 2.0 and higher pros/cons especially with G1GC garbage
> collection
>
>

Re: Write/read heavy usecase in one cluster

2015-12-23 Thread Robert Wille

I would personally classify both of those use cases as light, and I wouldn’t 
have any qualms about using a single cluster for both of those.

On Dec 23, 2015, at 3:06 PM, cass savy  wrote:

> How do you determine if we can share cluster in prod for 2 different 
> applications
> 
>  1. Has anybody shared cluster in prod a write heavy use case that captures 
> user login info (few 100 rpm)  and hardly performs few reads per day
> and
>  Use case that is read heavy use case that is 92% read with 10k requests per 
> min,higher consistency level of quorum
> 
> 
> 2. Use of  in-memory tables for lookup tables  that will be referred to for 
> every request prior to writing to transactional tables. Has anyone ised it in 
> prod and what were the issues encountered. what will be tuning/reco to follow 
> for prod 
> 
> 3. Use of multiple data directories for different applications like having 
> different data partitions for write/read heavy and one separate for 
> commitlog/caches
>  
> 4. plan to use C* 2.1 with vnodes/murmur for above usecases. Need feedback of 
> if people have tried tuning heap size, off-heap parameters in c* 2.0 and 
> above. in prod
> 
> 5. Java 8 with c* 2.0 and higher pros/cons especially with G1GC garbage 
> collection

Write/read heavy usecase in one cluster

2015-12-23 Thread cass savy

How do you determine if we can share cluster in prod for 2 different
applications

 1. Has anybody shared cluster in prod a write heavy use case that captures
user login info (few 100 rpm)  and hardly performs few reads per day
and
 Use case that is read heavy use case that is 92% read with 10k requests
per min,higher consistency level of quorum


2. Use of  in-memory tables for lookup tables  that will be referred to for
every request prior to writing to transactional tables. Has anyone ised it
in prod and what were the issues encountered. what will be tuning/reco to
follow for prod

3. Use of multiple data directories for different applications like having
different data partitions for write/read heavy and one separate for
commitlog/caches

4. plan to use C* 2.1 with vnodes/murmur for above usecases. Need feedback
of if people have tried tuning heap size, off-heap parameters in c* 2.0 and
above. in prod

5. Java 8 with c* 2.0 and higher pros/cons especially with G1GC garbage
collection

Re: Cassandra 3.1 - Aggregation query failure

2015-12-23 Thread DuyHai Doan

Thanks for the pointer on internal paging Tyler, I missed this one. But
then it raises some questions:

1. Is it possible to "tune" the page size or is it hard-coded internally ?
2. Is read-repair performed on EACH page or is it done on the whole
requested rows once they are fetched ?

Question 2. is relevant in some particular scenarios when the user is using
CL QUORUM (or more) and some replicas are out-of-sync. Even in the case of
aggregation over a single partition, if this partition is wide and spans
many fetch pages, the time the coordinator performs all the read-repair and
reconcile over QUORUM replicas, the query may timeout very quickly.

On Fri, Dec 18, 2015 at 5:26 PM, Tyler Hobbs  wrote:

>
> On Fri, Dec 18, 2015 at 9:17 AM, DuyHai Doan  wrote:
>
>> Cassandra will perform a full table scan and fetch all the data in memory
>> to apply the aggregate function.
>
>
> Just to clarify for others on the list: when executing aggregation
> functions, Cassandra *will* use paging internally, so at most one page
> worth of data will be held in memory at a time.  However, if your
> aggregation function retains a large amount of data, this may contribute to
> heap pressure.
>
>
> --
> Tyler Hobbs
> DataStax 
>

RE: Cassandra 3.1 - Aggregation query failure

2015-12-23 Thread SEAN_R_DURITY

It shouldn’t be called an aggregate. That is more like a user defined function. 
If you are correct, the term “aggregate” will lead people to do “bad things” – 
just like secondary indexes. I think the dev team needs a naming expert.


Sean Durity – Lead Cassandra Admin

From: Robert Stupp [mailto:sn...@snazy.de]
Sent: Wednesday, December 23, 2015 12:15 PM
To: user@cassandra.apache.org
Cc: dinesh.shanb...@isanasystems.com
Subject: Re: Cassandra 3.1 - Aggregation query failure

Well, the usual access goal for queries in C* is “one partition per query” - 
maybe a handful partitions in some cases.
That does not differ for aggregates since the read path is still the same.

Aggregates in C* are meant to move some computation (for example on the data in 
a time-frame materialized in a partition) to the coordinator and reduce the 
amount of data pumped through the wire.

For queries that span huge datasets, Spark is the easiest way to go.


On 23 Dec 2015, at 18:02, 
mailto:sean_r_dur...@homedepot.com>> 
mailto:sean_r_dur...@homedepot.com>> wrote:

An aggregate only within a partition? That is rather useless and shouldn’t be 
called an aggregate.

I am hoping the functionality can be used to support at least “normal” types of 
aggregates like count, sum, avg, etc.


Sean Durity – Lead Cassandra Admin

From: Jonathan Haddad [mailto:j...@jonhaddad.com]
Sent: Monday, December 21, 2015 2:50 PM
To: user@cassandra.apache.org; 
dinesh.shanb...@isanasystems.com
Subject: Re: Cassandra 3.1 - Aggregation query failure

Even if you get this to work for now, I really recommend using a different 
tool, like Spark.  Personally I wouldn't use UDAs outside of a single partition.

On Mon, Dec 21, 2015 at 1:50 AM Dinesh Shanbhag 
mailto:dinesh.shanb...@isanasystems.com>> 
wrote:

Thanks for the pointers!  I edited jvm.options in
$CASSANDRA_HOME/conf/jvm.options to increase -Xms and -Xmx to 1536M.
The result is the same.

And in $CASSANDRA_HOME/logs/system.log, grep GC system.log produces this
(when jvm.options had not been changed):

INFO  [Service Thread] 2015-12-18 15:26:31,668 GCInspector.java:284 -
ConcurrentMarkSweep GC in 296ms.  CMS Old Gen: 18133664 -> 15589256;
Code Cache: 5650880 -> 8122304; Compressed Class Space: 2530064 ->
3345624; Metaspace: 21314000 -> 28040984; Par Eden Space: 7019256 ->
164070848;
INFO  [Service Thread] 2015-12-18 15:48:39,736 GCInspector.java:284 -
ConcurrentMarkSweep GC in 379ms.  CMS Old Gen: 649257416 -> 84190176;
Code Cache: 20772224 -> 20726848; Par Eden Space: 2191408 -> 52356736;
Par Survivor Space: 2378448 -> 2346840
INFO  [Service Thread] 2015-12-18 15:58:35,118 GCInspector.java:284 -
ConcurrentMarkSweep GC in 406ms.  CMS Old Gen: 648847808 -> 86954856;
Code Cache: 21182080 -> 21188032; Par Eden Space: 1815696 -> 71525744;
Par Survivor Space: 2388648 -> 2364696
INFO  [Service Thread] 2015-12-18 16:13:45,821 GCInspector.java:284 -
ConcurrentMarkSweep GC in 211ms.  CMS Old Gen: 648343768 -> 73135720;
Par Eden Space: 3224880 -> 7957464; Par Survivor Space: 2379912 -> 2414520
INFO  [Service Thread] 2015-12-18 16:32:46,419 GCInspector.java:284 -
ConcurrentMarkSweep GC in 387ms.  CMS Old Gen: 648476072 -> 6832;
Par Eden Space: 2006624 -> 64263360; Par Survivor Space: 2403792 -> 2387664
INFO  [Service Thread] 2015-12-18 16:42:38,648 GCInspector.java:284 -
ConcurrentMarkSweep GC in 365ms.  CMS Old Gen: 649126336 -> 137359384;
Code Cache: 22972224 -> 22979840; Metaspace: 41374464 -> 41375104; Par
Eden Space: 4286080 -> 154449480; Par Survivor Space: 1575440 -> 2310768
INFO  [Service Thread] 2015-12-18 16:51:57,538 GCInspector.java:284 -
ConcurrentMarkSweep GC in 322ms.  CMS Old Gen: 648338928 -> 79783856;
Par Eden Space: 2058968 -> 56931312; Par Survivor Space: 2342760 -> 2400336
INFO  [Service Thread] 2015-12-18 17:02:49,543 GCInspector.java:284 -
ConcurrentMarkSweep GC in 212ms.  CMS Old Gen: 648702008 -> 122954344;
Par Eden Space: 3269032 -> 61433328; Par Survivor Space: 2395824 -> 3448760
INFO  [Service Thread] 2015-12-18 17:11:54,090 GCInspector.java:284 -
ConcurrentMarkSweep GC in 306ms.  CMS Old Gen: 648748576 -> 70965096;
Par Eden Space: 2174840 -> 27074432; Par Survivor Space: 2365992 -> 2373984
INFO  [Service Thread] 2015-12-18 17:22:28,949 GCInspector.java:284 -
ConcurrentMarkSweep GC in 350ms.  CMS Old Gen: 648243024 -> 90897272;
Par Eden Space: 2150168 -> 43487192; Par Survivor Space: 2401872 -> 2410728


After modifying jvm.options to increase -Xms & -Xmx (to 1536M):

INFO  [Service Thread] 2015-12-21 11:39:24,918 GCInspector.java:284 -
ConcurrentMarkSweep GC in 342ms.  CMS Old Gen: 18579136 -> 16305144;
Code Cache: 8600128 -> 10898752; Compressed Class Space: 3431288 ->
3761496; Metaspace: 29551832 -> 33307352; Par Eden Space: 4822000 ->
94853272;
INFO  [Service Thread] 2015-12-21 11:39:30,710 GCInspector.java:284 -
ParNew GC in 206ms.  CMS Old Gen: 22932208 -> 41454520; Par Eden Space:
167772160 -> 0; Pa

Re: Cassandra 3.1 - Aggregation query failure

2015-12-23 Thread Robert Stupp

Well, the usual access goal for queries in C* is “one partition per query” - 
maybe a handful partitions in some cases.
That does not differ for aggregates since the read path is still the same.

Aggregates in C* are meant to move some computation (for example on the data in 
a time-frame materialized in a partition) to the coordinator and reduce the 
amount of data pumped through the wire.

For queries that span huge datasets, Spark is the easiest way to go.


> On 23 Dec 2015, at 18:02,  
>  wrote:
> 
> An aggregate only within a partition? That is rather useless and shouldn’t be 
> called an aggregate.
> 
> I am hoping the functionality can be used to support at least “normal” types 
> of aggregates like count, sum, avg, etc.
> 
> 
> Sean Durity – Lead Cassandra Admin
> 
> From: Jonathan Haddad [mailto:j...@jonhaddad.com ]
> Sent: Monday, December 21, 2015 2:50 PM
> To: user@cassandra.apache.org ; 
> dinesh.shanb...@isanasystems.com 
> Subject: Re: Cassandra 3.1 - Aggregation query failure
> 
> Even if you get this to work for now, I really recommend using a different 
> tool, like Spark.  Personally I wouldn't use UDAs outside of a single 
> partition.
> 
> On Mon, Dec 21, 2015 at 1:50 AM Dinesh Shanbhag 
> mailto:dinesh.shanb...@isanasystems.com>> 
> wrote:
> 
> Thanks for the pointers!  I edited jvm.options in
> $CASSANDRA_HOME/conf/jvm.options to increase -Xms and -Xmx to 1536M.
> The result is the same.
> 
> And in $CASSANDRA_HOME/logs/system.log, grep GC system.log produces this
> (when jvm.options had not been changed):
> 
> INFO  [Service Thread] 2015-12-18 15:26:31,668 GCInspector.java:284 -
> ConcurrentMarkSweep GC in 296ms.  CMS Old Gen: 18133664 -> 15589256;
> Code Cache: 5650880 -> 8122304; Compressed Class Space: 2530064 ->
> 3345624; Metaspace: 21314000 -> 28040984; Par Eden Space: 7019256 ->
> 164070848;
> INFO  [Service Thread] 2015-12-18 15:48:39,736 GCInspector.java:284 -
> ConcurrentMarkSweep GC in 379ms.  CMS Old Gen: 649257416 -> 84190176;
> Code Cache: 20772224 -> 20726848; Par Eden Space: 2191408 -> 52356736;
> Par Survivor Space: 2378448 -> 2346840
> INFO  [Service Thread] 2015-12-18 15:58:35,118 GCInspector.java:284 -
> ConcurrentMarkSweep GC in 406ms.  CMS Old Gen: 648847808 -> 86954856;
> Code Cache: 21182080 -> 21188032; Par Eden Space: 1815696 -> 71525744;
> Par Survivor Space: 2388648 -> 2364696
> INFO  [Service Thread] 2015-12-18 16:13:45,821 GCInspector.java:284 -
> ConcurrentMarkSweep GC in 211ms.  CMS Old Gen: 648343768 -> 73135720;
> Par Eden Space: 3224880 -> 7957464; Par Survivor Space: 2379912 -> 2414520
> INFO  [Service Thread] 2015-12-18 16:32:46,419 GCInspector.java:284 -
> ConcurrentMarkSweep GC in 387ms.  CMS Old Gen: 648476072 -> 6832;
> Par Eden Space: 2006624 -> 64263360; Par Survivor Space: 2403792 -> 2387664
> INFO  [Service Thread] 2015-12-18 16:42:38,648 GCInspector.java:284 -
> ConcurrentMarkSweep GC in 365ms.  CMS Old Gen: 649126336 -> 137359384;
> Code Cache: 22972224 -> 22979840; Metaspace: 41374464 -> 41375104; Par
> Eden Space: 4286080 -> 154449480; Par Survivor Space: 1575440 -> 2310768
> INFO  [Service Thread] 2015-12-18 16:51:57,538 GCInspector.java:284 -
> ConcurrentMarkSweep GC in 322ms.  CMS Old Gen: 648338928 -> 79783856;
> Par Eden Space: 2058968 -> 56931312; Par Survivor Space: 2342760 -> 2400336
> INFO  [Service Thread] 2015-12-18 17:02:49,543 GCInspector.java:284 -
> ConcurrentMarkSweep GC in 212ms.  CMS Old Gen: 648702008 -> 122954344;
> Par Eden Space: 3269032 -> 61433328; Par Survivor Space: 2395824 -> 3448760
> INFO  [Service Thread] 2015-12-18 17:11:54,090 GCInspector.java:284 -
> ConcurrentMarkSweep GC in 306ms.  CMS Old Gen: 648748576 -> 70965096;
> Par Eden Space: 2174840 -> 27074432; Par Survivor Space: 2365992 -> 2373984
> INFO  [Service Thread] 2015-12-18 17:22:28,949 GCInspector.java:284 -
> ConcurrentMarkSweep GC in 350ms.  CMS Old Gen: 648243024 -> 90897272;
> Par Eden Space: 2150168 -> 43487192; Par Survivor Space: 2401872 -> 2410728
> 
> 
> After modifying jvm.options to increase -Xms & -Xmx (to 1536M):
> 
> INFO  [Service Thread] 2015-12-21 11:39:24,918 GCInspector.java:284 -
> ConcurrentMarkSweep GC in 342ms.  CMS Old Gen: 18579136 -> 16305144;
> Code Cache: 8600128 -> 10898752; Compressed Class Space: 3431288 ->
> 3761496; Metaspace: 29551832 -> 33307352; Par Eden Space: 4822000 ->
> 94853272;
> INFO  [Service Thread] 2015-12-21 11:39:30,710 GCInspector.java:284 -
> ParNew GC in 206ms.  CMS Old Gen: 22932208 -> 41454520; Par Eden Space:
> 167772160 -> 0; Par Survivor Space: 13144872 -> 20971520
> INFO  [Service Thread] 2015-12-21 13:08:14,922 GCInspector.java:284 -
> ConcurrentMarkSweep GC in 468ms.  CMS Old Gen: 21418016 -> 16146528;
> Code Cache: 11693888 -> 11744704; Compressed Class Space: 4331224 ->
> 4344192; Metaspace: 37191144 -> 37249960; Par Eden Space: 146089224 ->
> 148476848;
> INFO  [Service Thread]

RE: Cassandra 3.1 - Aggregation query failure

2015-12-23 Thread SEAN_R_DURITY

An aggregate only within a partition? That is rather useless and shouldn’t be 
called an aggregate.

I am hoping the functionality can be used to support at least “normal” types of 
aggregates like count, sum, avg, etc.


Sean Durity – Lead Cassandra Admin

From: Jonathan Haddad [mailto:j...@jonhaddad.com]
Sent: Monday, December 21, 2015 2:50 PM
To: user@cassandra.apache.org; dinesh.shanb...@isanasystems.com
Subject: Re: Cassandra 3.1 - Aggregation query failure

Even if you get this to work for now, I really recommend using a different 
tool, like Spark.  Personally I wouldn't use UDAs outside of a single partition.

On Mon, Dec 21, 2015 at 1:50 AM Dinesh Shanbhag 
mailto:dinesh.shanb...@isanasystems.com>> 
wrote:

Thanks for the pointers!  I edited jvm.options in
$CASSANDRA_HOME/conf/jvm.options to increase -Xms and -Xmx to 1536M.
The result is the same.

And in $CASSANDRA_HOME/logs/system.log, grep GC system.log produces this
(when jvm.options had not been changed):

INFO  [Service Thread] 2015-12-18 15:26:31,668 GCInspector.java:284 -
ConcurrentMarkSweep GC in 296ms.  CMS Old Gen: 18133664 -> 15589256;
Code Cache: 5650880 -> 8122304; Compressed Class Space: 2530064 ->
3345624; Metaspace: 21314000 -> 28040984; Par Eden Space: 7019256 ->
164070848;
INFO  [Service Thread] 2015-12-18 15:48:39,736 GCInspector.java:284 -
ConcurrentMarkSweep GC in 379ms.  CMS Old Gen: 649257416 -> 84190176;
Code Cache: 20772224 -> 20726848; Par Eden Space: 2191408 -> 52356736;
Par Survivor Space: 2378448 -> 2346840
INFO  [Service Thread] 2015-12-18 15:58:35,118 GCInspector.java:284 -
ConcurrentMarkSweep GC in 406ms.  CMS Old Gen: 648847808 -> 86954856;
Code Cache: 21182080 -> 21188032; Par Eden Space: 1815696 -> 71525744;
Par Survivor Space: 2388648 -> 2364696
INFO  [Service Thread] 2015-12-18 16:13:45,821 GCInspector.java:284 -
ConcurrentMarkSweep GC in 211ms.  CMS Old Gen: 648343768 -> 73135720;
Par Eden Space: 3224880 -> 7957464; Par Survivor Space: 2379912 -> 2414520
INFO  [Service Thread] 2015-12-18 16:32:46,419 GCInspector.java:284 -
ConcurrentMarkSweep GC in 387ms.  CMS Old Gen: 648476072 -> 6832;
Par Eden Space: 2006624 -> 64263360; Par Survivor Space: 2403792 -> 2387664
INFO  [Service Thread] 2015-12-18 16:42:38,648 GCInspector.java:284 -
ConcurrentMarkSweep GC in 365ms.  CMS Old Gen: 649126336 -> 137359384;
Code Cache: 22972224 -> 22979840; Metaspace: 41374464 -> 41375104; Par
Eden Space: 4286080 -> 154449480; Par Survivor Space: 1575440 -> 2310768
INFO  [Service Thread] 2015-12-18 16:51:57,538 GCInspector.java:284 -
ConcurrentMarkSweep GC in 322ms.  CMS Old Gen: 648338928 -> 79783856;
Par Eden Space: 2058968 -> 56931312; Par Survivor Space: 2342760 -> 2400336
INFO  [Service Thread] 2015-12-18 17:02:49,543 GCInspector.java:284 -
ConcurrentMarkSweep GC in 212ms.  CMS Old Gen: 648702008 -> 122954344;
Par Eden Space: 3269032 -> 61433328; Par Survivor Space: 2395824 -> 3448760
INFO  [Service Thread] 2015-12-18 17:11:54,090 GCInspector.java:284 -
ConcurrentMarkSweep GC in 306ms.  CMS Old Gen: 648748576 -> 70965096;
Par Eden Space: 2174840 -> 27074432; Par Survivor Space: 2365992 -> 2373984
INFO  [Service Thread] 2015-12-18 17:22:28,949 GCInspector.java:284 -
ConcurrentMarkSweep GC in 350ms.  CMS Old Gen: 648243024 -> 90897272;
Par Eden Space: 2150168 -> 43487192; Par Survivor Space: 2401872 -> 2410728


After modifying jvm.options to increase -Xms & -Xmx (to 1536M):

INFO  [Service Thread] 2015-12-21 11:39:24,918 GCInspector.java:284 -
ConcurrentMarkSweep GC in 342ms.  CMS Old Gen: 18579136 -> 16305144;
Code Cache: 8600128 -> 10898752; Compressed Class Space: 3431288 ->
3761496; Metaspace: 29551832 -> 33307352; Par Eden Space: 4822000 ->
94853272;
INFO  [Service Thread] 2015-12-21 11:39:30,710 GCInspector.java:284 -
ParNew GC in 206ms.  CMS Old Gen: 22932208 -> 41454520; Par Eden Space:
167772160 -> 0; Par Survivor Space: 13144872 -> 20971520
INFO  [Service Thread] 2015-12-21 13:08:14,922 GCInspector.java:284 -
ConcurrentMarkSweep GC in 468ms.  CMS Old Gen: 21418016 -> 16146528;
Code Cache: 11693888 -> 11744704; Compressed Class Space: 4331224 ->
4344192; Metaspace: 37191144 -> 37249960; Par Eden Space: 146089224 ->
148476848;
INFO  [Service Thread] 2015-12-21 13:08:53,068 GCInspector.java:284 -
ParNew GC in 216ms.  CMS Old Gen: 16146528 -> 26858568; Par Eden Space:
167772160 -> 0;


Earlier the node had OpenJDK 8.  For today's tests I installed and used
Oracle Java 8.

Do the above messages provide any clue? Or any debug logging I can
enable to progress further?
Thanks,
Dinesh.

On 12/18/2015 9:56 PM, Tyler Hobbs wrote:
>
> On Fri, Dec 18, 2015 at 9:17 AM, DuyHai Doan 
> mailto:doanduy...@gmail.com>
> >> wrote:
>
> Cassandra will perform a full table scan and fetch all the data in
> memory to apply the aggregate function.
>
>
> Just to clarify for others on the list: when executing aggregation
> functions, Cassandra /will/ use paging internally, so at

Re: External authentication options for C* (no DSE)

2015-12-23 Thread Giampaolo Trapasso

Search a bit deeper in DSE docs, I've found this:
http://www.datastax.com/wp-content/themes/datastax-2014-08/files/FF-DataStax-AdvancedSecurity.pdf
.

Pratically no external authentication is available for Apache Cassandra.

giampaolo

2015-12-23 15:13 GMT+01:00 Giampaolo Trapasso <
giampaolo.trapa...@radicalbit.io>:

> Hi,
>
> while for DSE versions of C* it's quite clear what external authentication
> options are available, I'm not sure about DSC or Apache versions. Can
> anyone point me to the right documentation on or provide a list of
> possibilities?
>
> Thank you in advance.
>
> giampaolo
>

External authentication options for C* (no DSE)

2015-12-23 Thread Giampaolo Trapasso

Hi,

while for DSE versions of C* it's quite clear what external authentication
options are available, I'm not sure about DSC or Apache versions. Can
anyone point me to the right documentation on or provide a list of
possibilities?

Thank you in advance.

giampaolo

Re: What is the ideal way to merge two Cassandra clusters with same keyspace into one?

Re: Cassandra 3.1 - Aggregation query failure

Re: Write/read heavy usecase in one cluster

Re: Write/read heavy usecase in one cluster

Write/read heavy usecase in one cluster

Re: Cassandra 3.1 - Aggregation query failure

RE: Cassandra 3.1 - Aggregation query failure

Re: Cassandra 3.1 - Aggregation query failure

RE: Cassandra 3.1 - Aggregation query failure

Re: External authentication options for C* (no DSE)

External authentication options for C* (no DSE)

11 matches

Site Navigation

Mail list logo

Footer information