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