Question

我正在使用运行Cassandra 2.0.3的6个节点的测试集群观察到一些相当奇怪的事情。我在每个节点上都有大约2,5Tb的数据（文件系统）。

--  Address      Load       Tokens  Owns   Host ID                               Rack
UN  10.5.45.160  1.43 TB    256     16.4%  24496067-455a-46fc-b846-d0be2a24bd36  RAC1
UN  10.5.45.156  1.4 TB     256     14.6%  4ff697a2-d501-4be7-ad05-82e37b2445c0  RAC1
UN  10.5.45.159  1.56 TB    256     17.5%  65a3e232-2d7a-44cf-8cc4-046a9a26d3f5  RAC1
UN  10.5.45.161  1.67 TB    256     16.4%  196f645e-d4e1-47ff-a7f5-da4d51cbd5c1  RAC1
UN  10.5.45.157  1.63 TB    256     17.3%  750b8c45-480e-42a7-8cbc-1d8671df5e56  RAC1
UN  10.5.45.158  1.53 TB    256     17.8%  985c8a08-3d92-4fad-a1d1-7135b2b9774a  RAC1

我在这个集群上运行了一些流量测试但是我已经在3天前停止了它。我显然正在超载群集，我想让它冷静下来并检查我的测试参数。我看到上周或更长时间我总是关于4K待定压缩。现在奇怪的部分。除了我做的几个手动请求之外，它已经有3天没有任何流量了。然而我所有的节点仍然无休止地进行压缩。待处理的压缩数量几乎没有变化，有时会下降2-3，有时会增加相似的数量，但它会保持在4300左右。我有绝对疯狂的sstables数量 - 根据统计数据，整个群集大约56K。所有具有任何实际数据量的表（实际上，只有4个表具有大量数据）都使用水平压缩策略，160-360 Mb配置为sstable大小。压缩吞吐量没有限制。每个节点5个磁盘，而不是最慢的磁盘。磁盘负载是真实的，我看他们都努力工作。然而，这些压缩3天没有进展。事实上，我发现磁盘使用率几乎没有变化。

我几乎可以肯定Cassandra或其设置出了问题，所以它无休止地一遍又一遍地压缩相同和相同的数据。读取工作正常，我发现在大多数情况下，数据只从一个sstable加载。

有一点需要提及：我遇到了CASSANDRA-6008问题，并且必须对正在进行的压缩进行一些手动清理才能启动节点。

我刚刚看了一下这些CF及其sstables。注意到一些奇怪的事情：一个节点（其他节点似乎有或多或少类似的情况）我有大约5330个sstable文件（...- Data.db）。其中约3900个约为258 Mb左右。剩余的~1500 sstables介于几百Kb和200Mb之间，其中大部分实际上只有几个Mb。

cqlsh：mykeyspace＆GT;描述表mytable;

CREATE TABLE ... (
 ....
) WITH
  bloom_filter_fp_chance=0.100000 AND
  caching='KEYS_ONLY' AND
  dclocal_read_repair_chance=0.000000 AND
  gc_grace_seconds=864000 AND
  index_interval=128 AND
  read_repair_chance=0.100000 AND
  replicate_on_write='true' AND
  populate_io_cache_on_flush='false' AND
  default_time_to_live=0 AND
  speculative_retry='99.0PERCENTILE' AND
  memtable_flush_period_in_ms=0 AND
  compaction={'sstable_size_in_mb': '256', 'class': 'LeveledCompactionStrategy'} AND
  compression={'sstable_compression': 'SnappyCompressor'};

（经过一些调查后编辑）。看起来这是压缩发生的事情。每个压缩都从L0中选取32个文件。我认为这是来自LeveledManifest.getCompactionCandidates（）的条件：

if (generations[0].size() > MAX_COMPACTING_L0)
                {
...

在这个级别我有成千上万的sstables所以它会陷入这种状态，我相信。

然后，它压缩了这些大约256Mb的32个sstables，并且每个创建了大约32个新的sstables，每个大约256Mb。等等，等等。

Answer 1

为了让任何人在循环中看到SO，这被记录为错误： https://issues.apache.org/jira/browse/CASSANDRA-6496

修复问题的补丁附在那里，最终应该在Cassandra 2.0.4中。

Cassandra 2.0.3 - 没有流量的无休止的压缩

1 个答案: