I think it would because it Cassandra will process more sstables to create response to read queries.
Now after clean if the data volume is same and compaction has been running, I can’t think of any more diagnostic step. Let’s wait for other experts to comment. Can you also check sstable count for each table just to be sure that they are not extraordinarily high? Sent from my iPhone > On Jun 11, 2018, at 10:21 AM, Fd Habash <fmhab...@gmail.com> wrote: > > Yes we did after adding the three nodes back and a full cluster repair as > well. > > But even it we didn’t run cleanup, would it have impacted read latency the > fact that some nodes still have sstables that they no longer need? > > Thanks > > ---------------- > Thank you > > From: Nitan Kainth > Sent: Monday, June 11, 2018 10:18 AM > To: user@cassandra.apache.org > Subject: Re: Read Latency Doubles After Shrinking Cluster and Never Recovers > > Did you run cleanup too? > > On Mon, Jun 11, 2018 at 10:16 AM, Fred Habash <fmhab...@gmail.com> wrote: > I have hit dead-ends every where I turned on this issue. > > We had a 15-node cluster that was doing 35 ms all along for years. At some > point, we made a decision to shrink it to 13. Read latency rose to near 70 > ms. Shortly after, we decided this was not acceptable, so we added the three > nodes back in. Read latency dropped to near 50 ms and it has been hovering > around this value for over 6 months now. > > Repairs run regularly, load on cluster nodes is even, application activity > profile has not changed. > > Why are we unable to get back the same read latency now that the cluster is > 15 nodes large same as it was before? > > -- > > ---------------------------------------- > Thank you > > > >
