cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kant Kodali <k...@peernova.com>
Subject Re: Java GC pauses, reality check
Date Sun, 27 Nov 2016 09:02:37 GMT
Yes I am well aware of Scyalldb. It might be well written in C++ but the
performance gain they are claiming has very little to do with moving from
Java to C++. They had major design changes such as moving away from SEDA to
TPC and so on. Moreover I would say it still needs to mature. Lot of users
had complained that they cannot get the benchmarks similar to the ones that
are posted online and I keep seeing comments stating that you need to use a
specific hardware and specific tuning mechanisms and so on (I don't mean to
say what scylladb is claiming is wrong I certainly haven't verified it but
I do know for the fact lot of people are having trouble to reach those
benchmarks).

SEDA to TPC is a very big change. Let's see how long it would take for
Apache C*

https://issues.apache.org/jira/browse/CASSANDRA-10989




On Sat, Nov 26, 2016 at 11:45 PM, Benjamin Roth <benjamin.roth@jaumo.com>
wrote:

> You are of course right. There is no solution and no language that is a
> perfect match for every situation and every solution and language has it's
> own pros, cons, pitfalls and drawbacks.
> Actually that article you posted points at some aspect of ARC, I wasn't
> aware of, yet.
> Nevertheless, GC is an issue for Cassandra, otherwise this thread would
> not exist, right? But we have to deal with it and get the best out of it.
>
> Another option, besides optimizing your GC: You could check if
> http://www.scylladb.com/ is an option for you.
> They rewrote CS from the scratch. The goal is to be completely compatible
> with CS but to be much, much faster. Check their benchmarks and their
> architecture.
> I really do not want do depreciate the work of all the Cassandra
> Developers - they did a great job - but what I have seen there looked very
> interesting and promising! By the way it's written in C++.
>
>
> 2016-11-27 7:06 GMT+01:00 Kant Kodali <kant@peernova.com>:
>
>> Automatic Reference counting sounds like college level idea that we all
>> have been hearing for since GC is born! There seem to be bunch of cons of
>> ARC as explained here
>>
>> https://www.quora.com/Why-doesnt-Apple-Swift-adopt-the-memor
>> y-management-method-of-garbage-collection-like-in-Java
>>
>> Maintaining C and C++ APPS are never a pain? How about versioning and
>> static time libraries? There is work there too. so its all pros and cons
>>
>> "gc is a pain in the ass". How about seg faults? they aren't any lesser
>> pain :)
>>
>> Not only Cassandra that runs on JVM. Majority of Apache projects do run
>> on JVM for a reason.
>>
>> Bottom line. My point here is there are pros and cons of every language.
>> It doesn't make much sense to target one language.
>>
>>
>>
>>
>>
>>
>> On Sat, Nov 26, 2016 at 9:31 PM, Benjamin Roth <benjamin.roth@jaumo.com>
>> wrote:
>>
>>> Arc means Automatic Reference counting which is done at compilen time.
>>> Eg Objektive c and Swift use this technique. There are absolutely No gc's.
>>> Its a completely different memory Management technique.
>>>
>>> Why i dont like Java on Server side? Because gc is a pain in the ass. I
>>> am doing this Business since over 15 years and running/maintaining Apps
>>> that are build in c or c++ has never been such a pain.
>>>
>>> On the other Hand Java is easier to handle for Developers. And coding
>>> plain c is also a pain.
>>>
>>> Thats why i Said its a philosophic discussion.
>>> Anyway Cassandra rund on Java so We have to Deal with it.
>>>
>>> Am 27.11.2016 05:28 schrieb "Kant Kodali" <kant@peernova.com>:
>>>
>>>> Benjamin Roth: How do you know Arc eliminates GC pauses completely? By
>>>> completely I mean no GC pauses whatsoever.
>>>>
>>>> When you say Java is NOT the First choice for Server Applications you
>>>> are generalizing it too much I would say since many of them fall under that
>>>> category. Either way the statement you made is purely subjective.
>>>>
>>>> On Fri, Nov 25, 2016 at 2:41 PM, Benjamin Roth <benjamin.roth@jaumo.com
>>>> > wrote:
>>>>
>>>>> Lol. The counter proof is to use another memory Model like Arc. Thats
>>>>> why i personally think Java is NOT the First choice for Server
>>>>> Applications. But thats a philosophic discussion.
>>>>>
>>>>> Am 25.11.2016 23:38 schrieb "Kant Kodali" <kant@peernova.com>:
>>>>>
>>>>>> +1 Chris Lohfink response
>>>>>>
>>>>>> I would also restate the following sentence "java GC pauses are
>>>>>> pretty much a fact of life" to "Any GC based system pauses are
>>>>>> pretty much a fact of life".
>>>>>>
>>>>>> I would be more than happy to see if someone can counter prove.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Nov 25, 2016 at 1:41 PM, Chris Lohfink <clohfink85@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> No tuning will eliminate gcs.
>>>>>>>
>>>>>>> 20-30 seconds is horrific and out of the ordinary. Most likely
>>>>>>> implementing antipatterns and/or poorly configured. Sub 1s is
realistic but
>>>>>>> with some workloads still may require some tuning to maintain.
Some
>>>>>>> workloads are very unfriendly to GCs though (ie heavy tombstones,
very wide
>>>>>>> partitions).
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>> On Fri, Nov 25, 2016 at 3:25 PM, S Ahmed <sahmed1020@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hello!
>>>>>>>>
>>>>>>>> From what I understand java GC pauses are pretty much a fact
of
>>>>>>>> life, but you can tune the jvm to reduce the likelihood of
the frequency
>>>>>>>> and length of GC pauses.
>>>>>>>>
>>>>>>>> When using Cassandra, how frequent or long have these pauses
known
>>>>>>>> to be?  Even with tuning, is it safe to assume they cannot
be eliminated?
>>>>>>>>
>>>>>>>> Would a 20-30 second pause be something out of the ordinary?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>
>
> --
> Benjamin Roth
> Prokurist
>
> Jaumo GmbH · www.jaumo.com
> Wehrstraße 46 · 73035 Göppingen · Germany
> Phone +49 7161 304880-6 · Fax +49 7161 304880-1
> AG Ulm · HRB 731058 · Managing Director: Jens Kammerer
>

Mime
View raw message