[
https://issues.apache.org/jira/browse/CASSANDRA-7030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13969419#comment-13969419
]
Benedict commented on CASSANDRA-7030:
-------------------------------------
bq. This leads to the CLHM not obeying its limits as readily as it is asked to
Confirmed that the problem I am seeing with concurrent execution (and that I
would guess is leading to your test results) is down to CLHM. By replacing the
CLHM with an AtomicReferenceArray to guarantee the bounds I get:
{noformat}
concurrent malloc:
Total Elapsed: 9.708s
Allocate Elapsed: 21.271s
Free Elapsed: 26.023s
Total Allocated: 62483Mb
Rate: 1.290Gb/s
Live Allocated: 1020Mb
VM total:117
vsz: 3149
rsz: 1280
synchronized malloc:
Total Elapsed: 36.526s
Allocate Elapsed: 134.114s
Free Elapsed: 128.416s
Total Allocated: 62483Mb
Rate: 0.232Gb/s
Live Allocated: 1020Mb
VM total:117
vsz: 3213
rsz: 1427
synchronized jemalloc:
Total Elapsed: 217.113s
Allocate Elapsed: 162.753s
Free Elapsed: 1531.215s
Total Allocated: 62483Mb
Rate: 0.036Gb/s
Live Allocated: 1020Mb
VM total:70
vsz: 4084
rsz: 1410
{noformat}
Can you rerun your test with either synchronised malloc, or with an
AtomicReferenceArray instead of the CLHM, to confirm?
Note I have reverted my position back to "let's get rid of jemalloc" - without
more evidence to the contrary: the test I was running that initiated the
creation of this ticket was measuring elapsed time for both allocate() *and*
free(), and I dropped the latter from the tests based on your benchmark because
it's difficult to time the free() calls (as they live in the eviction
listener). Now I am timing both, and you can see the real-elapsed time and
per-CPU elapsed times are dramatically higher for jemalloc once both are
included. The cost of calling free() appears to be disproportionately higher
for jemalloc.
Note the throughput rate for jemalloc: 36Mb/s. This is really really pathetic!
> Remove JEMallocAllocator
> ------------------------
>
> Key: CASSANDRA-7030
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7030
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Priority: Minor
> Labels: performance
> Fix For: 2.1 beta2
>
> Attachments: 7030.txt
>
>
> JEMalloc, whilst having some nice performance properties by comparison to
> Doug Lea's standard malloc algorithm in principle, is pointless in practice
> because of the JNA cost. In general it is around 30x more expensive to call
> than unsafe.allocate(); malloc does not have a variability of response time
> as extreme as the JNA overhead, so using JEMalloc in Cassandra is never a
> sensible idea. I doubt if custom JNI would make it worthwhile either.
> I propose removing it.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
