Re: Long GC pauses during repair
High inter-dc latency could make writes more likely not to land, which would make repair do more work. Also true for read and writes - waiting for the cross-dc request will keep threads around longer, so more concurrent work, so more GC. May be that the GC is coming from the read/write path, and you're only noticing it when repair tips you over the edge. On Wed, Aug 4, 2021 at 6:54 AM manish khandelwal < manishkhandelwa...@gmail.com> wrote: > Can inter dc latency cause high gc pauses? Other clusters working fine > with same configuration? Only this particular cluster is giving long GC > pauses during repair. > > Regards > Manish > > On Tue, Aug 3, 2021 at 6:42 PM Jim Shaw wrote: > >> CMS heap too large will have long GC. you may try reduce heap on 1 node >> to see. or go GC1 if it is easy way. >> >> Thanks, >> Jim >> >> On Tue, Aug 3, 2021 at 3:33 AM manish khandelwal < >> manishkhandelwa...@gmail.com> wrote: >> >>> Long GC (1 seconds /2 seconds) pauses seen during repair on the >>> coordinator. Running full repair with partition range option. GC collector >>> is CMS and heap is 14G. Cluster is 7+7. Cassandra version is 3.11.2. Not >>> much traffic when repair is running. What could be the probable cause of >>> long gc pauses? What things should I look into? >>> >>> Regards >>> Manish >>> >>
Re: Long GC pauses during repair
Can inter dc latency cause high gc pauses? Other clusters working fine with same configuration? Only this particular cluster is giving long GC pauses during repair. Regards Manish On Tue, Aug 3, 2021 at 6:42 PM Jim Shaw wrote: > CMS heap too large will have long GC. you may try reduce heap on 1 node > to see. or go GC1 if it is easy way. > > Thanks, > Jim > > On Tue, Aug 3, 2021 at 3:33 AM manish khandelwal < > manishkhandelwa...@gmail.com> wrote: > >> Long GC (1 seconds /2 seconds) pauses seen during repair on the >> coordinator. Running full repair with partition range option. GC collector >> is CMS and heap is 14G. Cluster is 7+7. Cassandra version is 3.11.2. Not >> much traffic when repair is running. What could be the probable cause of >> long gc pauses? What things should I look into? >> >> Regards >> Manish >> >
Re: Increased read latency with Cassandra >= 3.11.7
Dear community, is someone working on this ticket? This is clearly performance regression and we stuck with 3.11.6 and could not upgrade to latest version. Regards, Maxim. On Mon, Feb 22, 2021 at 10:37 AM Ahmed Eljami wrote: > Hey, > I have created the issue, here => > https://issues.apache.org/jira/browse/CASSANDRA-16465 > > Le ven. 19 févr. 2021 à 10:10, Ahmed Eljami a > écrit : > >> Hi folks, >> >> If this can help, we encountered the same behaviour with 3.11.9. We are >> using LCS. >> After upgrading from 3.11.3 to 3.11.9 in Bench Environnement, Cassandra >> read latency 99% is multiplied by ~3 >> >> We are planning a second test with 3.11.6, I'll send you the results when >> it's done. >> Cheers, >> >> >> >> Le lun. 15 févr. 2021 à 19:55, Jai Bheemsen Rao Dhanwada < >> jaibheem...@gmail.com> a écrit : >> >>> Any update on this? Any idea if this is already tracked under JIRA >>> issue, so we can follow for updates >>> >>> On Wednesday, February 10, 2021, Johannes Weißl wrote: >>> Hi Nico, On Mon, Sep 14, 2020 at 03:51PM +0200, Nicolai Lune Vest wrote: > after upgrading my Cassandra nodes from version 3.11.6 to either > 3.11.7 or 3.11.8 I experience a significant increase in read latency Any update here? Does version 3.11.10 provide any improvement? Thanks, Johannes - To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org For additional commands, e-mail: user-h...@cassandra.apache.org >> >> -- >> Cordialement; >> >> Ahmed ELJAMI >> > > > -- > Cordialement; > > Ahmed ELJAMI >
Re: Reduce num_tokens on single node cluster
On Fri, Jul 30, 2021 at 7:21 PM Bowen Song wrote: > Since you have only one node, sstableloader is unnecessary. Copy/move the > the data directory back to the right place and restart Cassandra or run > 'nodetool > refresh' is sufficient. Do not restore the 'system' keyspace, but do > restore the other system keyspaces, such as 'system_auth' and ' > system_schema'. > > In fact, it comes to my mind that the following is much quicker, simpler > and should do the trick anyway: > > 1. shutdown Cassandra > > 2. backup /var/lib/cassandra (just in case...) > > 3. run 'rm -rf > /var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377' > > 4. change num_tokens > > 5. start Cassandra > > > Thanks Bowen, I used simple procedure, everything worked well, data is there. Regards, Maxim.
