You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Oleg Kibirev (JIRA)" <ji...@apache.org> on 2012/09/18 22:53:08 UTC

[jira] [Updated] (CASSANDRA-4681) SlabAllocator spends a lot of time in Thread.yield

     [ https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleg Kibirev updated CASSANDRA-4681:
------------------------------------

    Description: 
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 allocated unneeded ByteBuffer instances has a measurable effect on performance


  was:
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. 


    
> SlabAllocator spends a lot of time in Thread.yield
> --------------------------------------------------
>
>                 Key: CASSANDRA-4681
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4681
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.1.5
>         Environment: OEL Linux
>            Reporter: Oleg Kibirev
>
> 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 allocated unneeded 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: http://www.atlassian.com/software/jira