[
https://issues.apache.org/jira/browse/CASSANDRA-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13782230#comment-13782230
]
Vijay commented on CASSANDRA-4681:
----------------------------------
Hi Jonathan, Doesn't showing any changes in TPS, please see the attached (tried
with stress 50/200 threads and concurrent_writes 32/256... all the runs are
attached). http://pastebin.com/JDFqgcZN
> 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
> Assignee: Jonathan Ellis
> Priority: Minor
> Labels: performance
> Attachments: 4681-v3.txt, 4691-short-circuit.txt,
> 4691-v3-rebased.txt, SlabAllocator.java, SlabAllocator.java.list,
> slab-list.patch
>
>
> 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 was sent by Atlassian JIRA
(v6.1#6144)
