You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Dmitry Konstantinov (Jira)" <ji...@apache.org> on 2025/01/03 18:38:00 UTC
[jira] [Comment Edited] (CASSANDRA-20173) Avoid new ByteBuffer allocation for each NativeCell/NativeClustering during flushing of offheap_objects memtable
[ https://issues.apache.org/jira/browse/CASSANDRA-20173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17909644#comment-17909644 ]
Dmitry Konstantinov edited comment on CASSANDRA-20173 at 1/3/25 6:37 PM:
-------------------------------------------------------------------------
I am in progress of addressing the review comments, hopefully in few days get an updated version.
As a side effect: I have found a bug in the existing FastByteOperations logic.
https://github.com/apache/cassandra/blob/cassandra-5.0/src/java/org/apache/cassandra/utils/FastByteOperations.java#L265
{code:java}
public void copy(byte[] src, int srcPosition, ByteBuffer trg, int trgPosition, int length)
{
if (trg.hasArray())
System.arraycopy(src, srcPosition, trg.array(), trg.arrayOffset() + trgPosition, length);
else
copy(null, srcPosition + theUnsafe.getLong(src, Unsafe.ARRAY_BYTE_BASE_OFFSET), trg, trgPosition, length);
} {code}
srcPosition + theUnsafe.getLong(src, Unsafe.ARRAY_BYTE_BASE_OFFSET) - it is too optimistic to expect a static address for a java heap byte array :-)
I will create a separate defect ticket with a patch.
was (Author: dnk):
I am in progress of addressing the review comments, hopefully in few days get an updated version.
As a side effect: I have found a bug in the existing FastByteOperations logic.
[https://github.com/netudima/cassandra/blob/cassandra-5.0/src/java/org/apache/cassandra/utils/FastByteOperations.java#L265]
{code:java}
public void copy(byte[] src, int srcPosition, ByteBuffer trg, int trgPosition, int length)
{
if (trg.hasArray())
System.arraycopy(src, srcPosition, trg.array(), trg.arrayOffset() + trgPosition, length);
else
copy(null, srcPosition + theUnsafe.getLong(src, Unsafe.ARRAY_BYTE_BASE_OFFSET), trg, trgPosition, length);
} {code}
srcPosition + theUnsafe.getLong(src, Unsafe.ARRAY_BYTE_BASE_OFFSET) - it is too optimistic to expect a static address for a java heap byte array :-)
I will create a separate defect ticket with a patch.
> Avoid new ByteBuffer allocation for each NativeCell/NativeClustering during flushing of offheap_objects memtable
> ----------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-20173
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20173
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Local/Memtable
> Reporter: Dmitry Konstantinov
> Assignee: Dmitry Konstantinov
> Priority: Normal
> Fix For: 5.0.x
>
> Attachments: image-2024-12-29-13-06-13-115.png, native_clustering_byte_buffer_alloc.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently for memtable_allocation_type: offheap_objects when we flush a memtable we allocate new ByteBuffer object for each NativeCell and NativeClustering to write it to disk. It is one of the main contributors (together with CASSANDRA-20162) to memory allocation for MemtableFlushWriter thread:
> !image-2024-12-29-13-06-13-115.png|width=570!
> !native_clustering_byte_buffer_alloc.png|width=570!
> Instead of retrieving of the value() as ByteBuffer we can introduce NativeValueAccessor to not expose ByteBuffer + keep it inside NativeCell as a thread-local to re-use. Same idea is applicable for NativeClustering
> Note: for Cassandra 4.x the situation is even worse because we clone very BTreeRow from off-heap to heap due to using the same iterator as for usual reads (where we need to protect against memtable lifecycle changes). In case of flushing such protection is not needed. For TrieMemtable we skip such cloning (CASSANDRA-17240, [https://github.com/apache/cassandra/blob/cassandra-5.0/src/java/org/apache/cassandra/db/memtable/TrieMemtable.java#L393]). It makes sense to consider such skipping for over types of memtable too..
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org