git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Infinite loop of single SSTable compactions


Hi Rahul,

the table TTL is 24 months. Oldest data is 22 months, so no
expirations yet.  Compacted partition maximum bytes: 17 GB - yeah, I
know that's not good, but we'll have to wait for the TTL to make it go
away.  More recent partitions are kept under 100 MB by bucketing.

The data model:
CREATE TABLE keyspace.table (
   group int,
   status int,
   bucket timestamp,
   ts timeuuid,
   source int,
...
   PRIMARY KEY ((group, status, bucket), ts, source)
) WITH CLUSTERING ORDER BY (ts DESC, monitor ASC)

There are no INSERT statements with the same 'ts' and 'source'
clustering columns.

Regards,

Martin
On Thu, Jul 26, 2018 at 12:16 PM Rahul Singh
<rahul.xavier.singh@xxxxxxxxx> wrote:
>
> Few questions
>
>
> What is your maximumcompactedbytes across the cluster for this table ?
> What’s your TTL ?
> What does your data model look like as in what’s your PK?
>
> Rahul
> On Jul 25, 2018, 1:07 PM -0400, James Shaw <jxyshaw@xxxxxxxxx>, wrote:
>
> nodetool compactionstats  --- see compacting which table
> nodetool cfstats keyspace_name.table_name  --- check partition side, tombstones
>
> go the data file directories:  look the data file size, timestamp,  --- compaction will write to new temp file with _tmplink...,
>
> use sstablemetadata ...   ---- look the largest or oldest one first
>
> of course, other factors may be,  like disk space, etc
> also what are compaction_throughput_mb_per_sec in cassandra.yaml
>
> Hope it is helpful.
>
> Thanks,
>
> James
>
>
>
>
> On Wed, Jul 25, 2018 at 4:18 AM, Martin Mačura <m.macura@xxxxxxxxx> wrote:
>>
>> Hi,
>> we have a table which is being compacted all the time, with no change in size:
>>
>> Compaction History:
>> compacted_at            bytes_in    bytes_out   rows_merged
>> 2018-07-25T05:26:48.101 57248063878 57248063878 {1:11655}
>>
>>                   2018-07-25T01:09:47.346 57248063878 57248063878
>> {1:11655}
>>                                          2018-07-24T20:52:48.652
>> 57248063878 57248063878 {1:11655}
>>
>> 2018-07-24T16:36:01.828 57248063878 57248063878 {1:11655}
>>
>>                   2018-07-24T12:11:00.026 57248063878 57248063878
>> {1:11655}
>>                                          2018-07-24T07:28:04.686
>> 57248063878 57248063878 {1:11655}
>>
>> 2018-07-24T02:47:15.290 57248063878 57248063878 {1:11655}
>>
>>                   2018-07-23T22:06:17.410 57248137921 57248063878
>> {1:11655}
>>
>> We tried setting unchecked_tombstone_compaction to false, had no effect.
>>
>> The data is a time series, there will be only a handful of cell
>> tombstones present. The table has a TTL, but it'll be least a month
>> before it takes effect.
>>
>> Table properties:
>>    AND compaction = {'class':
>> 'org.apache.cassandra.db.compaction.TimeWindowCompactionStrategy',
>> 'compaction_window_size': '1', 'compaction_window_unit': 'DAYS',
>> 'max_threshold': '32', 'min_threshold': '4',
>> 'unchecked_tombstone_compaction': 'false'}
>>    AND compression = {'chunk_length_in_kb': '64', 'class':
>> 'org.apache.cassandra.io.compress.LZ4Compressor'}
>>    AND crc_check_chance = 1.0
>>    AND dclocal_read_repair_chance = 0.0
>>    AND default_time_to_live = 63072000
>>    AND gc_grace_seconds = 10800
>>    AND max_index_interval = 2048
>>    AND memtable_flush_period_in_ms = 0
>>    AND min_index_interval = 128
>>    AND read_repair_chance = 0.0
>>    AND speculative_retry = 'NONE';
>>
>> Thanks for any help
>>
>>
>> Martin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@xxxxxxxxxxxxxxxxxxxx
>> For additional commands, e-mail: user-help@xxxxxxxxxxxxxxxxxxxx
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@xxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: user-help@xxxxxxxxxxxxxxxxxxxx