Will try if we get to replicate the node upgrade on that node, or if we
replicate in a lower env.
Thanks
On Wed, Apr 17, 2019 at 1:49 PM Jon Haddad wrote:
> Let me be more specific - run the async java profiler and generate a
> flame graph to determine where CPU time is spent.
>
> On Wed, Apr
Let me be more specific - run the async java profiler and generate a
flame graph to determine where CPU time is spent.
On Wed, Apr 17, 2019 at 11:36 AM Jon Haddad wrote:
>
> Run the async java profiler on the node to determine what it's doing:
>
Run the async java profiler on the node to determine what it's doing:
https://github.com/jvm-profiling-tools/async-profiler
On Wed, Apr 17, 2019 at 11:31 AM Carl Mueller
wrote:
>
> No, we just did the package upgrade 2.1.9 --> 2.2.13
>
> It definitely feels like some indexes are being
No, we just did the package upgrade 2.1.9 --> 2.2.13
It definitely feels like some indexes are being recalculated or the entire
sstables are being scanned due to suspected corruption.
On Wed, Apr 17, 2019 at 12:32 PM Jeff Jirsa wrote:
> There was a time when changing some of the parameters
There was a time when changing some of the parameters (especially bloom
filter FP ratio) would cause the bloom filters to be rebuilt on startup if
the sstables didnt match what was in the schema, leading to a delay like
that and similar logs. Any chance you changed the schema on that table
since
Oh, the table in question is SizeTiered, had about 10 sstables total, it
was JBOD across two data directories.
On Wed, Apr 17, 2019 at 12:26 PM Carl Mueller
wrote:
> We are doing a ton of upgrades to get out of 2.1.x. We've done probably
> 20-30 clusters so far and have not encountered anything
We are doing a ton of upgrades to get out of 2.1.x. We've done probably
20-30 clusters so far and have not encountered anything like this yet.
After upgrade of a node, the restart takes a long time. like 10 minutes
long. ALmost all of our other nodes took less than 2 minutes to upgrade
(aside
