[
https://issues.apache.org/jira/browse/CASSANDRA-21144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18055436#comment-18055436
]
Sam Tunnicliffe commented on CASSANDRA-21144:
---------------------------------------------
Sample benchmark result:
{code}
[java] Result
"org.apache.cassandra.test.microbench.LocalRangesAllSettledBench.benchPlacementsAllSettled":
[java] 10532.014 ±(99.9%) 33.688 ms/op [Average]
[java] (min, avg, max) = (10526.497, 10532.014, 10547.070), stdev = 8.749
[java] CI (99.9%): [10498.327, 10565.702] (assumes normal distribution)
[java]
[java]
[java] # Run complete. Total time: 00:05:37
[java]
[java] REMEMBER: The numbers below are just data. To gain reusable
insights, you need to follow up on
[java] why the numbers are the way they are. Use profilers (see -prof,
-lprof), design factorial
[java] experiments, perform baseline and negative tests that provide
experimental control, make sure
[java] the benchmarking environment is safe on JVM/OS/HW level, ask for
reviews from the domain experts.
[java] Do not assume the numbers tell you what you want them to tell.
[java]
[java] Benchmark
Mode Cnt Score Error Units
[java] LocalRangesAllSettledBench.benchLocalRangesOnlyNoRelevantMSOs
avgt 5 16.548 ± 2.821 ms/op
[java] LocalRangesAllSettledBench.benchLocalRangesOnlyWithRelevantMSOs
avgt 5 252.840 ± 15.393 ms/op
[java] LocalRangesAllSettledBench.benchPlacementsAllSettled
avgt 5 10532.014 ± 33.688 ms/op
{code}
> writePlacementsAllSettled can perform poorly in large clusters with many
> ongoing range movements
> ------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-21144
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21144
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Transactional Cluster Metadata
> Reporter: Sam Tunnicliffe
> Assignee: Sam Tunnicliffe
> Priority: Normal
> Fix For: 6.x
>
> Attachments: ci_summary.html, result_details.tar.gz
>
>
> In a large cluster with multiple concurrent range movements in flight,
> calculating the final state of data placements after all movements are
> completed can be a CPU intensive operation. This is done solely to predict
> the future local write ranges so that DiskBoundaryManager can locate SSTables
> correctly on disk and reduce the relocation required to balance disks.
> Calculating the outcome of every in-flight movement is overkill for this, as
> only the operations which affect the local node need to be considered.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
