Hello Team,
When I am bootstrapping/restarting a Cassandra Node, there is a delay
between gossip settle and port opening. Can someone please explain me where
this delay is configured and can this be changed? I don't see any
information in the logs
In my case if you see there is a ~3 minutes dela
That gap seems a long time. Have you checked GC logs around the timeframe?
From: Jai Bheemsen Rao Dhanwada
Reply-To: "user@cassandra.apache.org"
Date: Monday, June 1, 2020 at 3:52 PM
To: "user@cassandra.apache.org"
Subject: Cassandra Bootstrap Sequence
Message from External Sender
Hello Team,
Is there anything specific to for in GC logs?
b/w this delay happens always whenever I bootstrap the node or restart a C*
process.
I don't believe it's a GC issue and correction from initial question, it's
not just bootstrap, but every restart of C* process is causing this.
On Mon, Jun 1, 2020 at
The thing to look for in GC logs would be signs that you’re bouncing against
your memory limits and spending a lot of time in full GC collections.
I’m not sure at what phase it kicks in but definitely there is the potential
for memory issues when you have large column families (large in the numb
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 l
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* |
Hi
I have a production 3.11.6 cluster which I'm might want to enable
authentication in, I'm trying to understand what will be the performance
impact, if any.
I understand each use case might be different, trying to understand if
there is a common % people usually see their performance hit, or if so
I just changed these properties to increase flushed file size (decrease number
of compactions):
memtable_allocation_type from heap_buffers to offheap_objects
memtable_offheap_space_in_mb: from default (2048) to 8192
Using default value for other memtable/compaction/commitlog configurations .
Set the Auth cache to a long validity
Don’t go crazy with RF of system auth
Drop bcrypt rounds if you see massive cpu spikes on reconnect storms
> On Jun 1, 2020, at 11:26 PM, Gil Ganz wrote:
>
>
> Hi
> I have a production 3.11.6 cluster which I'm might want to enable
> authentication in,
