Thanks Erick, I see below tasks are being run mostly. I didn't quite understand what exactly these scheduled tasks are for? Is there a way to reduce the boot-up time or do I have to live with this delay?
$ zgrep "CompactionStrategyManager.java:380 - Recreating compaction > strategy" debug.log* | wc -l > 3249 > $ zgrep "DiskBoundaryManager.java:53 - Refreshing disk boundary cache for" > debug.log* | wc -l > 6293 > $ zgrep "DiskBoundaryManager.java:92 - Got local ranges" debug.log* | wc > -l > 6308 > $ zgrep "DiskBoundaryManager.java:56 - Updating boundaries from > DiskBoundaries" debug.log* | wc -l > 3249 On Mon, Jun 1, 2020 at 5:01 PM Erick Ramirez <erick.rami...@datastax.com> wrote: > There's quite a lot of steps that takes place during the startup sequence > between these 2 lines: > > >>> *INFO [main] 2020-05-31 23:51:15,555 Gossiper.java:1723 - No gossip >>> backlog; proceeding*INFO [main] 2020-05-31 23:54:06,867 >>> NativeTransportService.java:70 - Netty using native Epoll event loop >>> >> > For the most part, it's taken up by CompactionStrategyManager and > DiskBoundaryManager. If you check debug.log, you'll see that it's mostly > updating disk boundaries. The length of time it takes is proportional to > the number of tables in the cluster. > > Have a look at this section [1] of CassandraDaemon if you're interested > in the details of the startup sequence. Cheers! > > [1] > https://github.com/apache/cassandra/blob/cassandra-3.11.3/src/java/org/apache/cassandra/service/CassandraDaemon.java#L399-L435 >
