Re: Upgrading sstables not using all available compaction slots on version 2.2

2018-02-01 Thread Oleksandr Shulgin
On Thu, Feb 1, 2018 at 9:23 AM, Oleksandr Shulgin < oleksandr.shul...@zalando.de> wrote: > On 1 Feb 2018 06:51, "kurt greaves" wrote: > > Would you be able to create a JIRA ticket for this? Not sure if this is > still a problem in 3.0+ but worth creating a ticket to investigate. It'd be > really

Re: Upgrading sstables not using all available compaction slots on version 2.2

2018-02-01 Thread Oleksandr Shulgin
On 1 Feb 2018 06:51, "kurt greaves" wrote: Would you be able to create a JIRA ticket for this? Not sure if this is still a problem in 3.0+ but worth creating a ticket to investigate. It'd be really helpful if you could try and reproduce on 3.0.15 or 3.11.1 to see if it's an issue there as well.​

Re: Upgrading sstables not using all available compaction slots on version 2.2

2018-01-31 Thread kurt greaves
Would you be able to create a JIRA ticket for this? Not sure if this is still a problem in 3.0+ but worth creating a ticket to investigate. It'd be really helpful if you could try and reproduce on 3.0.15 or 3.11.1 to see if it's an issue there as well.​

Re: Upgrading sstables not using all available compaction slots on version 2.2

2018-01-31 Thread Oleksandr Shulgin
On Wed, Jan 24, 2018 at 10:40 AM, Oleksandr Shulgin < oleksandr.shul...@zalando.de> wrote: > Hello, > > In the process of upgrading our cluster from 2.1 to 2.2 we have triggered > the SSTable rewriting process like this: > > $ nodetool upgradesstables -j 4 # concurrent_compactors=5 > > Then if we

Upgrading sstables not using all available compaction slots on version 2.2

2018-01-24 Thread Oleksandr Shulgin
Hello, In the process of upgrading our cluster from 2.1 to 2.2 we have triggered the SSTable rewriting process like this: $ nodetool upgradesstables -j 4 # concurrent_compactors=5 Then if we would immediately check the compactionstats, we see that 4 compactions of type 'Upgrade sstables' are ru