Re: Performance issue in 3.0.9

2017-02-01 Thread Jeff Jirsa
Can you quantify "major"?

Latency or throughput?
GC pauses? 
What did you see before? What do you see now?
Do you have a stack dump? 


-- 
Jeff Jirsa


> On Feb 1, 2017, at 4:23 PM, Shashank Joshi  
> wrote:
> 
> We are seeing major performance issues with about 100 GB of data in 
> 3.0.9-E001. The exact same app runs very well in 2.1.
> 
> 
> 
> It feels to us like something is wrong with our configuration because of the 
> severity of the issues. Thanks in advance for any recommendations or 
> suggestions.
> 
> 
> 
> Details:
> 
> Size of data: 100 GB+  all in one table, with a simple schema, couple of 
> bigints and a double
> 
> Cluster: 3 nodes with RF of 3
> 
> Client: App uses read and write CL of QUORUM and we have a lots of timeouts 
> due to inability to reach quorum
> 
> Compaction: Leveled
> 
> Nature of data usage: No updates/deletes, High reads, relatively low writes
> 
> 
> 
> 
> 
> JVM:
> 
> Using CMS GC and around 8 GB of max heap
> 


Performance issue in 3.0.9

2017-02-01 Thread Shashank Joshi
We are seeing major performance issues with about 100 GB of data in 3.0.9-E001. 
The exact same app runs very well in 2.1.



It feels to us like something is wrong with our configuration because of the 
severity of the issues. Thanks in advance for any recommendations or 
suggestions.



Details:

Size of data: 100 GB+  all in one table, with a simple schema, couple of 
bigints and a double

Cluster: 3 nodes with RF of 3

Client: App uses read and write CL of QUORUM and we have a lots of timeouts due 
to inability to reach quorum

Compaction: Leveled

Nature of data usage: No updates/deletes, High reads, relatively low writes





JVM:

Using CMS GC and around 8 GB of max heap



Re: quick question

2017-02-01 Thread Kant Kodali
Adding dev only for this thread.

On Wed, Feb 1, 2017 at 4:39 AM, Kant Kodali  wrote:

> What is the difference between accepting a value and committing a value?
>
>
>
> On Wed, Feb 1, 2017 at 4:25 AM, Kant Kodali  wrote:
>
>> Hi,
>>
>> Thanks for the response. I finished watching this video but I still got
>> few questions.
>>
>> 1) The speaker seems to suggest that there are different consistency
>> levels being used in different phases of paxos protocol. If so, what is
>> right consistency level to set on these phases?
>>
>> 2) Right now, we just set consistency level as QUORUM at the global level
>> and I dont think we ever change it so in this case what would be the
>> consistency levels being used in different phases.
>>
>> 3) The fact that one should think about reading before the commit phase
>> or after the commit phase (but not any other phase) sounds like there is
>> something special about commit phase and what is that? when I set the
>> QUORUM level consistency at global level Does the commit phase happen right
>> after accept  phase or no? or irrespective of the consistency level when
>> does the commit phase happen anyway? and what happens during the commit
>> phase?
>>
>>
>> Thanks,
>> kant
>>
>>
>> On Wed, Feb 1, 2017 at 3:30 AM, Alain RODRIGUEZ 
>> wrote:
>>
>>> Hi,
>>>
>>> I believe that this talk from Christopher Batey at the Cassandra Summit
>>> 2016 might answer most of your questions around LWT:
>>> https://www.youtube.com/watch?v=wcxQM3ZN20c
>>>
>>> He explains a lot of stuff including consistency considerations. My
>>> understanding is that the quorum read can only see the data written using
>>> LWT after the commit phase. A SERIAL Read would see it (video, around
>>> 23:40).
>>>
>>> Here are the slides as well: http://fr.slideshare.net
>>> /DataStax/light-weight-transactions-under-stress-christopher
>>> -batey-the-last-pickle-cassandra-summit-2016
>>>
>>> Let us know if you still have questions after watching this (about 35
>>> minutes).
>>>
>>> C*heers,
>>> ---
>>> Alain Rodriguez - @arodream - al...@thelastpickle.com
>>> France
>>>
>>> The Last Pickle - Apache Cassandra Consulting
>>> http://www.thelastpickle.com
>>>
>>> 2017-02-01 10:57 GMT+01:00 Kant Kodali :
>>>
 When you initiate a LWT(write) and do a QUORUM read is there a chance
 that one might not see the LWT write ? If so, can someone explain a bit
 more?

 Thanks!

>>>
>>>
>>
>


Re: [VOTE] Release Apache Cassandra 3.10 (Take 5)

2017-02-01 Thread Gary Dusbabek
+1

On Tue, Jan 31, 2017 at 3:29 PM, Michael Shuler 
wrote:

> I propose the following artifacts for release as 3.10.
>
> sha1: 3cf415279c171fe20802ad90f181eed7da04c58d
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.10-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1137/org/apache/cassandra/apache-cassandra/3.10/
> Staging repository:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1137/
>
> The Debian packages are available here: http://people.apache.org/~mshuler
>
> - All unit test variations passed on this sha.
> - 2 dtests failed on this sha with known failures:
>   - TestAuthUpgrade - CASSANDRA-11469
>   - TestReadFailures - CASSANDRA-13167 (passed on re-run)
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/XDn15n
> [2]: (NEWS.txt) https://goo.gl/tvmL8j
>
>


Re: [VOTE] Release Apache Cassandra 3.10 (Take 5)

2017-02-01 Thread Josh McKenzie
+1

On Tue, Jan 31, 2017 at 4:29 PM, Michael Shuler 
wrote:

> I propose the following artifacts for release as 3.10.
>
> sha1: 3cf415279c171fe20802ad90f181eed7da04c58d
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.10-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1137/org/apache/cassandra/apache-cassandra/3.10/
> Staging repository:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1137/
>
> The Debian packages are available here: http://people.apache.org/~mshuler
>
> - All unit test variations passed on this sha.
> - 2 dtests failed on this sha with known failures:
>   - TestAuthUpgrade - CASSANDRA-11469
>   - TestReadFailures - CASSANDRA-13167 (passed on re-run)
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/XDn15n
> [2]: (NEWS.txt) https://goo.gl/tvmL8j
>
>