except Cassandra binaries have been unchanged in our loadtest
environment.
Thanks,
Thomas
From: Alexander Dejanovski [mailto:a...@thelastpickle.com]
Sent: Dienstag, 26. September 2017 11:14
To: user@cassandra.apache.org
Subject: Re: GC/CPU increase after upgrading to 3.0.14 (from 2.1.18)
Hi
Hi,
in our experience CMS is doing much better with smaller heaps.
Regards,
Thomas
From: Matope Ono [mailto:matope@gmail.com]
Sent: Dienstag, 26. September 2017 10:58
To: user@cassandra.apache.org
Subject: Re: GC/CPU increase after upgrading to 3.0.14 (from 2.1.18)
Hi. We met similar
>>
>>
>>
>> Regarding compression metadata memory usage drop. Right, storage engine
>> re-write could be a reason. Thanks.
>>
>>
>>
>> Still wondering about the GC/CPU increase.
>>
>>
>>
>> Thanks!
>>
&
Thanks for your attention.
>
>
>
> Thomas
>
>
>
> *From:* Steinmaurer, Thomas [mailto:thomas.steinmau...@dynatrace.com]
> *Sent:* Freitag, 15. September 2017 13:51
> *To:* user@cassandra.apache.org
> *Subject:* RE: GC/CPU increase after upgrading to 3.0.14 (from 2.1.18)
>
>
: Freitag, 15. September 2017 13:51
To: user@cassandra.apache.org
Subject: RE: GC/CPU increase after upgrading to 3.0.14 (from 2.1.18)
Hi Jeff,
we are using native (CQL3) via Java DataStax driver (3.1). We also have
OpsCenter running (to be removed soon) via Thrift, if I remember correctly.
As said
3.0 in context of CPU/GC and not disk savings?
Thanks,
Thomas
From: Steinmaurer, Thomas [mailto:thomas.steinmau...@dynatrace.com]
Sent: Freitag, 15. September 2017 13:51
To: user@cassandra.apache.org
Subject: RE: GC/CPU increase after upgrading to 3.0.14 (from 2.1.18)
Hi Jeff,
we are using
wondering about the GC/CPU increase.
Thanks!
Thomas
From: Jeff Jirsa [mailto:jji...@gmail.com]
Sent: Freitag, 15. September 2017 13:14
To: user@cassandra.apache.org
Subject: Re: GC/CPU increase after upgrading to 3.0.14 (from 2.1.18)
Most people find 3.0 slightly slower than 2.1. The only thing that
Most people find 3.0 slightly slower than 2.1. The only thing that really
stands out in your email is the huge change in 95% latency - that's atypical.
Are you using thrift or native 9042)? The decrease in compression metadata
offheap usage is likely due to the increased storage efficiency of t