You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Viktor Kuzmin (JIRA)" <ji...@apache.org> on 2017/02/13 13:22:41 UTC

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

Viktor Kuzmin created CASSANDRA-13215:
-----------------------------------------

             Summary: 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)