Prince Nana Owusu Boateng created CASSANDRA-13896:
-----------------------------------------------------
Summary: Improving Cassandra write performance
Key: CASSANDRA-13896
URL: https://issues.apache.org/jira/browse/CASSANDRA-13896
Project: Cassandra
Issue Type: Improvement
Components: Local Write-Read Paths
Environment: Skylake server with 2 sockets, 192GB RAM, 3xPCIe SSDs
OS: Centos 7.3
Java: Oracle JDK1.8.0_121
Reporter: Prince Nana Owusu Boateng
Fix For: 3.10
Attachments: Screen Shot 2017-09-22 at 11.22.43 AM.png
During our Cassandra performance testing, we see high percentage of the CPU
spent in *org.apache.cassandra.utils.memory.SlabAllocator.allocate(int, OpOrder
Group) * method. Appears to be high contention of the *<nextFreeOffset>*
atomic Integer in write workloads. This structure is used by the threads for
keeping track of the region bytebuffer allocation. When the contention
appears, adding more clients, modifications of write specific parameters does
not change write throughput performance. Attached are the details of Java
Flight Recorder (JFR), showing hot functions. When we see this contention, we
still have plenty of CPU and throughput left ( *<20%* Total average CPU
utilization and * <11%* of the storage write total throughput). This occurs
on Cassandra 3.10.0-src version using the Cassandra-Stress.
Proposal:
We will like to introduce a solution which eliminates the atomic operations on
the *<nextFreeOffset>* atomic Integer. This implementation will allow
concurrent allocation of bytebuffers without an atomic compareAndSet and
incrementAndGet operations. The solution is expected to increase overall write
performance while improving CPU utilization.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
