cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4681) SlabAllocator spends a lot of time in Thread.yield
Date Wed, 19 Sep 2012 02:45:07 GMT


Jonathan Ellis commented on CASSANDRA-4681:

The "fix" here defeats the purpose of the SlabAllocator, and you will pay a penalty in STW
GC for non-uniform value sizes.  So I'm unenthusiastic about adopting this for general use.

Instead you might try preallocating a queue of buffers or regions to reduce init time.

(Note that we never allocate unneeded bytebuffers, that is the point of the UNINITIALIZED
dance instead of just each thread creating the BB and CASing to see who wins.)
> SlabAllocator spends a lot of time in Thread.yield
> --------------------------------------------------
>                 Key: CASSANDRA-4681
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.1.5
>         Environment: OEL Linux
>            Reporter: Oleg Kibirev
>         Attachments:
> When profiling high volume inserts into Cassandra running on a host with fast SSD and
CPU, Thread.yield() invoked by SlabAllocator appeared as the top item in CPU samples. The
fix is to return a regular byte buffer if current slab is being initialized by another thread.
So instead of:
>                if (oldOffset == UNINITIALIZED)
>                 {
>                     // The region doesn't have its data allocated yet.
>                     // Since we found this in currentRegion, we know that whoever
>                     // CAS-ed it there is allocating it right now. So spin-loop
>                     // shouldn't spin long!
>                     Thread.yield();
>                     continue;
>                 }
> do:
> if (oldOffset == UNINITIALIZED)
>     return ByteBuffer.allocate(size);
> I achieved 4x speed up in my (admittedly specialized) benchmark by using an optimized
version of SlabAllocator attached. Since this code is in the critical path, even doing excessive
atomic instructions or allocating unneeded extra ByteBuffer instances has a measurable effect
on performance

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message