[jira] [Commented] (CASSANDRA-13215) Cassandra nodes startup time 20x more after upgarding to 3.x

["Romain Hardouin (JIRA)" <ji...@apache.org>]

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

Romain Hardouin commented on CASSANDRA-13215:
---------------------------------------------

It's related to CASSANDRA-6696 i.e. since 3.2.

Regarding {{AbstractReplicationStrategy.getAddressRanges}} it seems to be a known limitation. Maybe we can now consider that it's used on a critical path:
{code}
    /*
     * NOTE: this is pretty inefficient. also the inverse (getRangeAddresses) below.
     * this is fine as long as we don't use this on any critical path.
     * (fixing this would probably require merging tokenmetadata into replicationstrategy,
     * so we could cache/invalidate cleanly.)
     */
    public Multimap<InetAddress, Range<Token>> getAddressRanges(TokenMetadata metadata)
{code}

> Cassandra nodes startup time 20x more after upgarding to 3.x
> ------------------------------------------------------------
>
>                 Key: CASSANDRA-13215
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13215
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>         Environment: Cluster setup: two datacenters (dc-main, dc-backup).
> dc-main - 9 servers, no vnodes
> dc-backup - 6 servers, vnodes
>            Reporter: Viktor Kuzmin
>         Attachments: simple-cache.patch
>
>
> CompactionStrategyManage.getCompactionStrategyIndex is called on each sstable at startup. And this function calls StorageService.getDiskBoundaries. And getDiskBoundaries calls AbstractReplicationStrategy.getAddressRanges.
> It appears that last function can be really slow. In our environment we have 1545 tokens and with NetworkTopologyStrategy it can make 1545*1545 computations in worst case (maybe I'm wrong, but it really takes lot's of cpu).
> Also this function can affect runtime later, cause it is called not only during startup.
> I've tried to implement simple cache for getDiskBoundaries results and now startup time is about one minute instead of 25m, but I'm not sure if it's a good solution.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)