Could it that the app is inserting _duplicate_ keys ?
-- Brice
On Tue, Apr 21, 2015 at 1:52 PM, Marcus Eriksson <krum...@gmail.com> wrote:
> 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
>>>>>
>>>>
>>>>
>>>
>>
>
