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 21:24:18 GMT


Benedict commented on CASSANDRA-7030:

Nope, I copied that behaviour from your earlier ticket to make it as comparable as possible.
Your code:

       for (int i = 0; i < loops; i++)
            long size = rand.nextInt(100);
            if (size <= 0)
            tryMemory(size * 1024);

I played with various multipliers, and I also tried with a completely uniform size distribution.
I see no difference in results (uniform distribution of 64K sizes follow):

Items: 10M
Elapsed: 2.911s
Allocated: 2047Mb
VM total:187
vsz: 3717
rsz: 2307

Items: 10M
Elapsed: 23.869s
Allocated: 2047Mb
VM total:192
vsz: 4148
rsz: 2721

That said, it would be interesting to see how jemalloc performs with JNI, rather than JNA.
But as things stand, it doesn't seem a sensible option to offer, as it uses more memory and
is slower.

> 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