Thanks Alain I tried to make index before starting tests. The problem hasn't occurred for now.
What happen if you run it on a screen and come back later to see if this > query completed successfully? The index was made after I forced the hanging cqlsh to stop. Which problem, cqlsh hanging or tons of compactions + 100% CPU? > Was the STCS test done against a table holding as much data as the LCS one? In STCS setting, cqlsh hanging didn't happen. This size of tables is almost same as in LCS setting. Regards, Yuji On Wed, Jul 20, 2016 at 7:03 PM, Alain RODRIGUEZ <arodr...@gmail.com> wrote: > Hi Yuji Ito, > > I don't know Cassandra 2.2 that much and I try to avoid using indexes, but > I imagine that what happened there is that creating the index took some > time, and all the newly created data went to L0 and compaction was > intensive as this node suddenly had a lot of pending compactions. > > From > https://docs.datastax.com/en/cql/3.1/cql/cql_reference/create_index_r.html: > "If data already exists for the column, Cassandra indexes the data during > the execution of this statement." > > Why does cqlsh sometimes make no response in LCS setting for compaction? > > > So I would say it is basically still doing work. What happen if you run it > on a screen and come back later to see if this query completed > successfully? Again, I don't really know secondary indexes, I am just > guessing. > > When this problem happened, Cassandra process used 100% CPU >> and debug.log was filled by "Choosing candidates for L0". >> > > This would make sense if newly index created is using LCS internally (I am > not sure how much this is configurable, I imagine it is like a standard > table). As creating index start by handling existing columns, I imagine > this burst is expected. Yet there have been a lot of work done around LCS > to put data in the right level during some streaming operations, maybe are > you hitting an issue or at least something we could improve: a good > question would be, "is it normal / good for every sstable to go to L0 while > creating an index using LCS". > > This problem hasn't occurred in STCS setting > > > Which problem, cqlsh hanging or tons of compactions + 100% CPU? > > I imagine STCS would have used less resources to compact the newly created > index data, but the command would probably have hanged about the same way > than while using LCS as compaction is an asynchronous work and the indexes > for existing data need to be created anyway. Was the STCS test done against > a table holding as much data as the LCS one? > > I am just guessing, I hope this makes sense. > > C*heers, > ----------------------- > Alain Rodriguez - al...@thelastpickle.com > France > > The Last Pickle - Apache Cassandra Consulting > http://www.thelastpickle.com > > 2016-07-19 7:22 GMT+02:00 Yuji Ito <y...@imagine-orb.com>: > >> Hi all, >> >> I have a question. >> I use Cassandra 2.2.6. >> >> Why does cqlsh sometimes make no response in LCS setting for compaction? >> >> I requested as below: >> cqlsh -e "create index new_index on keyspace.table (sub_column);" >> >> When this problem happened, Cassandra process used 100% CPU >> and debug.log was filled by "Choosing candidates for L0". >> This problem hasn't occurred in STCS setting. >> >> Thanks, >> Yuji Ito >> > >
