[ 
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)

Reply via email to