Cassandra Leveled Compaction Strategy需要50％的磁盘空间开销

时间：2016-07-11 17:53:04

标签： cassandra cassandra-2.2

我们有一个运行Cassandra 2.2.5的24节点AWS集群（i2.xlarge）。我们有一张大桌子和一些小桌子。大表占用大部分磁盘空间。磁盘使用量意外增加。

我们正在使用LCS，并注意到SSTables没有进入更高级别。

表中的cfstats向我们展示了SSTable似乎没有被压缩到更高级别：

    SSTables in each level: [2, 20/10, 206/100, 2146/1000, 1291, 0, 0, 0, 0]

数据集大约在一个月前完成加载，磁盘使用率为60-65％。我们正在更新数据集，磁盘使用量每天增加约0.5％。我们目前在节点上看到75-80％已满。行正在更新，但没有新行，也没有行被删除。所以我们没想到磁盘使用率会上升。我们最好的猜测是压缩不再从sstables中删除重复。

当尝试强制对数据集进行压缩（nodetool compact）时，我们会收到有关磁盘空间不足的错误。

    "error: Not enough space for compaction, estimated sstables = 1977, expected write size = 331746061359"

LCS的文档声称“只有足够的空间才能保留10倍sstable大小，以便通过压缩临时使用。”在我们的例子中，压缩需要1977x 160MB。

我们确实遇到了重置LCS压缩级别的建议： Leveled Compaction Strategy with low disk space

然而，当我们在具有相同问题的较小数据集的较小集群上尝试此操作时，它所进行的压缩似乎也需要大量空间，而不仅仅是承诺的1.6G。

在：

    SSTables in each level: [1, 20/10, 202/100, 7, 0, 0, 0, 0, 0]
    Space used (live): 38202690995

执行sstablelevelreset后：

    SSTables in each level: [231/4, 0, 0, 0, 0, 0, 0, 0, 0]
    Space used (live): 38258539433

之后的第一次压缩开始压缩21698490019字节。这似乎是大约129个sstables值的数据。

在小型集群上，我们有足够的额外磁盘空间，但在较大的集群上，似乎没有足够的空间来强制压缩或通过使用sstablelevelreset实用程序来重新开始压缩。

压缩完成后，这就是sstable级别的样子（请注意，文档会不断更新，但不会添加到数据库中）：

    SSTables in each level: [0, 22/10, 202/100, 13, 0, 0, 0, 0, 0]
    Space used (live): 39512481279

我们还有什么办法可以尝试恢复磁盘空间吗？或者至少是为了防止磁盘使用量上升？

该表定义如下：

CREATE TABLE overlordnightly.document (
    id bigint PRIMARY KEY,
    del boolean,
    doc text,
    ver bigint
) WITH bloom_filter_fp_chance = 0.1
    AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
    AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.DeflateCompressor'}
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 864000
    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 = '99.0PERCENTILE';

来自其中一个节点的完整cfstats：

Keyspace: overlordprod
    Read Count: 68000539
    Read Latency: 3.948187530190018 ms.
    Write Count: 38569748
    Write Latency: 0.02441453179834102 ms.
    Pending Flushes: 0
        Table: document
        SSTable count: 3283
        SSTables in each level: [0, 22/10, 210/100, 2106/1000, 943, 0, 0, 0, 0]
        Space used (live): 526180595946
        Space used (total): 526180595946
        Space used by snapshots (total): 0
        Off heap memory used (total): 2694759044
        SSTable Compression Ratio: 0.22186642596102463
        Number of keys (estimate): 118246721
        Memtable cell count: 45944
        Memtable data size: 512614744
        Memtable off heap memory used: 0
        Memtable switch count: 1994
        Local read count: 68000545
        Local read latency: 4.332 ms
        Local write count: 38569754
        Local write latency: 0.027 ms
        Pending flushes: 0
        Bloom filter false positives: 526
        Bloom filter false ratio: 0.00000
        Bloom filter space used: 2383928304
        Bloom filter off heap memory used: 2383902040
        Index summary off heap memory used: 24448020
        Compression metadata off heap memory used: 286408984
        Compacted partition minimum bytes: 87
        Compacted partition maximum bytes: 12108970
        Compacted partition mean bytes: 16466
        Average live cells per slice (last five minutes): 1.0
        Maximum live cells per slice (last five minutes): 1
        Average tombstones per slice (last five minutes): 1.0
        Maximum tombstones per slice (last five minutes): 1

对于正在发生的压缩，这里出现了错误。这是一个特别的：

DEBUG [CompactionExecutor:1146] 2016-07-26 08:49:02,333 CompactionTask.java:142 - Compacting (cd2baa50-530d-11e6-9c8e-b5e6d88d6e11) [
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12943-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12970-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12972-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12953-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12955-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12957-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12978-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12976-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-4580-big-Data.db:level=4,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-14528-big-Data.db:level=2,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12949-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12959-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12974-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12962-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-11516-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12941-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12968-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12951-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12983-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12947-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12966-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12945-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12964-big-Data.db:level=3,
 ]

如果你注意到有23个sstables正在被压缩：一个来自二级，一个来自级别4，其余来自级别3.在这种情况下，它还需要更多的10倍空间（3,720,676,532字节到3,531,157,508）。最终将这些压缩到3级，但我的印象是桌子只升级。为什么4级表被压缩到3级？现在我已经在日志中注意到这一点，我发现它经常发生。例如，这是另一个来自同一时间：

DEBUG [CompactionExecutor:1140] 2016-07-26 08:46:47,420 CompactionTask.java:142 - Compacting (7cbb0390-530d-11e6-9c8e-b5e6d88d6e11) [
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12910-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-14524-big-Data.db:level=2,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12908-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-12906-big-Data.db:level=3,
 /data/cassandra/overlordprod/document-57ed497007c111e6a2174fb91d61e383/la-3543-big-Data.db:level=4,
 ]

我不知道这是不是问题。

0 个答案:

没有答案
相关问题
最新问题