[jira] [Comment Edited] (CASSANDRA-15213) DecayingEstimatedHistogramReservoir Inefficiencies

["Jordan West (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17031972#comment-17031972 ] 

Jordan West edited comment on CASSANDRA-15213 at 2/6/20 9:57 PM:
-----------------------------------------------------------------

Was asked to run tlp-stress against this branch. After several runs I think at the cluster level its pretty much a wash between this branch and trunk (except the memory savings of this branch ofc). Added the output from one of the runs if folks want to look closer. Its worth noting: this was pretty small / limited hardware.

Workload:
{code}
./bin/tlp-stress run KeyValue --populate 500k --partitions 1m --threads 4 \
--replication "{'class': 'NetworkTopologyStrategy', 'DC1': 3 }" \
--duration 1h --username $CUSER --password $CPASS \
--host $HOST
{code}


was (Author: jrwest):
Was asked to run tlp-stress against this branch. After several runs I think at the cluster level its pretty much a wash between this branch and trunk (except the memory savings of this branch ofc). Added the output from one of the runs if folks want to look closer. Its worth noting: this was pretty small / limited hardware.

> DecayingEstimatedHistogramReservoir Inefficiencies
> --------------------------------------------------
>
>                 Key: CASSANDRA-15213
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-15213
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Observability/Metrics
>            Reporter: Benedict Elliott Smith
>            Assignee: Jordan West
>            Priority: Normal
>             Fix For: 4.0-beta
>
>         Attachments: 15213-perf-branch, 15213-perf-trunk
>
>
> * {{LongAdder}} introduced to trunk consumes 9MiB of heap without user schemas, and this will grow significantly under contention and user schemas with many tables.  This is because {{LongAdder}} is a very heavy class designed for single contended values.  
>  ** This can likely be improved significantly, without significant loss of performance in the contended case, by simply increasing the size of our primitive backing array and providing multiple buckets, with each thread picking a bucket to increment, or simply multiple backing arrays.  Probably a better way still to do this would be to introduce some competition detection to the update, much like {{LongAdder}} utilises, that increases the number of backing arrays under competition.
>  ** To save memory this approach could partition the space into chunks that are likely to be updated together, so that we do not need to duplicate the entire array under competition.
>  * Similarly, binary search is costly and a measurable cost as a share of the new networking work (without filtering it was > 10% of the CPU used overall).  We can compute an approximation floor(log2 n / log2 1.2) extremely cheaply, to save the random memory access costs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org