nope, but you can correlate I guess, tools/bin/sstablemetadata gives you
sstable level information
and, it is also likely that since you get so many L0 sstables, you will be
doing size tiered compaction in L0 for a while.
On Tue, Apr 21, 2015 at 1:40 PM, Anishek Agarwal <anis...@gmail.com> wrote:
> @Marcus I did look and that is where i got the above but it doesnt show
> any detail about moving from L0 -L1 any specific arguments i should try
> with ?
>
> On Tue, Apr 21, 2015 at 4:52 PM, Marcus Eriksson <krum...@gmail.com>
> wrote:
>
>> you need to look at nodetool compactionstats - there is probably a big L0
>> -> L1 compaction going on that blocks other compactions from starting
>>
>> On Tue, Apr 21, 2015 at 1:06 PM, Anishek Agarwal <anis...@gmail.com>
>> wrote:
>>
>>> the "some_bits" column has about 14-15 bytes of data per key.
>>>
>>> On Tue, Apr 21, 2015 at 4:34 PM, Anishek Agarwal <anis...@gmail.com>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> I am inserting about 100 million entries via datastax-java driver to a
>>>> cassandra cluster of 3 nodes.
>>>>
>>>> Table structure is as
>>>>
>>>> create keyspace test with replication = {'class':
>>>> 'NetworkTopologyStrategy', 'DC' : 3};
>>>>
>>>> CREATE TABLE test_bits(id bigint primary key , some_bits text) with
>>>> gc_grace_seconds=0 and compaction = {'class': 'LeveledCompactionStrategy'}
>>>> and compression={'sstable_compression' : ''};
>>>>
>>>> have 75 threads that are inserting data into the above table with each
>>>> thread having non over lapping keys.
>>>>
>>>> I see that the number of pending tasks via "nodetool compactionstats"
>>>> keeps increasing and looks like from "nodetool cfstats test.test_bits" has
>>>> SSTTable levels as [154/4, 8, 0, 0, 0, 0, 0, 0, 0],
>>>>
>>>> Why is compaction not kicking in ?
>>>>
>>>> thanks
>>>> anishek
>>>>
>>>
>>>
>>
>
