[
https://issues.apache.org/jira/browse/CASSANDRA-20176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17909246#comment-17909246
]
Benedict Elliott Smith commented on CASSANDRA-20176:
----------------------------------------------------
My suggestion would be testing whether a plain executor pool would be fine on a
modern system, so we can disable the shared executor pool by default.
Regarding the allocation rate of 8.5%, this is likely to have been under _low_
load; as you approach saturation (even say 50% of cpu time) you would expect
time (and hence memory) spent managing this pool to decline dramatically. With
a low steady trickle you would also not expect to see lots of memory spent
here, as the number of threads spinning up and down should not be large. You
see lots of memory used if all threads get spun up, and then go unused for a
period.
I agree that virtual threads will be very useful for the evolution of
Cassandra, although the present-day API makes it hard to cleanly slot it in to
all places (due to its reliance on the global FJP), but at the very least
request threads could be migrated quite easily. But, this is a much bigger
piece of work to explore later.
> Reduce memory allocation in SEP Worker spin wait logic
> ------------------------------------------------------
>
> Key: CASSANDRA-20176
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20176
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Local/Other
> Reporter: Dmitry Konstantinov
> Assignee: Dmitry Konstantinov
> Priority: Normal
> Attachments: image-2025-01-01-13-14-02-562.png,
> image-2025-01-01-13-15-16-767.png
>
>
> There is a visible memory allocation within spin waiting logic in SEP
> Executor: org.apache.cassandra.concurrent.SEPWorker#doWaitSpin for some
> workloads. For example it is observed for a writing test described in
> CASSANDRA-20165 where ~8.5% of total allocations are from this logic:
> !image-2025-01-01-13-14-02-562.png|width=570!
> !image-2025-01-01-13-15-16-767.png|width=570!
> The idea of this parking is to avoid unpark signalling costs. The logic
> selects a random time period to park a thread by LockSupport.parkNanos and
> put the thread into a ConcurrentSkipListMap using wake up time as a key, so
> the map is used as a concurrent priority queue. Once the parking is finished
> - the thread removes itself from the map. When we neede to schedule a task -
> we take a spinning thread with the smallest wake up time from the map.
> We can try to implement another algorithm for this logic without memory
> allocation overheads, for example based on a Timing Wheel data structure.
> Note: it also makes sense to check granularity of actual parking time
> (https://hazelcast.com/blog/locksupport-parknanos-under-the-hood-and-the-curious-case-of-parking/)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
