cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7030) Remove JEMallocAllocator
Date Mon, 14 Apr 2014 17:04:15 GMT


Benedict commented on CASSANDRA-7030:

Hmm. Interesting, I didn't expect there to be such a dramatic difference in actual memory
utilisation (some, but not much), only in allocation speed.

That is quite problematic for use-cases where you want to allocate small and often - 3 micros
per call makes it much too expensive for per-cell operations. However for the row cache it's
probably quite acceptable.

Do you still have the benchmark that you were running? Would be nice to see if we could figure
out why it was wasting so much memory - fragmentation doesn't seem an adequate explanation
for so many GBs (not saying it's not, just seems quite extreme without specifically trying
to break the algorithm).

> Remove JEMallocAllocator
> ------------------------
>                 Key: CASSANDRA-7030
>                 URL:
>             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

View raw message