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)