cassandra - Cassandra：CompactionExecutor，达到最大内存使用量

Question

我发现我对 Cassandraks.data表的摄取有点慢（节点和输入摄取大约需要21几个小时）。4340 GB

当我检查日志时，我只有：

INFO  [CompactionExecutor:2608] 2021-10-27 17:02:12,954 NoSpamLogger.java:91 - Maximum memory usage reached (536870912), cannot allocate chunk of 1048576
INFO  [CompactionExecutor:2608] 2021-10-27 17:22:21,716 NoSpamLogger.java:91 - Maximum memory usage reached (536870912), cannot allocate chunk of 1048576
INFO  [CompactionExecutor:2614] 2021-10-27 17:42:43,567 NoSpamLogger.java:91 - Maximum memory usage reached (536870912), cannot allocate chunk of 1048576
INFO  [CompactionExecutor:2617] 2021-10-27 18:02:41,808 NoSpamLogger.java:91 - Maximum memory usage reached (536870912), cannot allocate chunk of 1048576
INFO  [CompactionExecutor:2619] 2021-10-27 18:22:29,340 NoSpamLogger.java:91 - Maximum memory usage reached (536870912), cannot allocate chunk of 1048576
INFO  [CompactionExecutor:2625] 2021-10-27 18:41:40,535 NoSpamLogger.java:91 - Maximum memory usage reached (536870912), cannot allocate chunk of 1048576

当我检查是否有任何压缩正在运行时nodetool compactionstats，我有：

pending tasks: 0

所以我检查了历史nodetool compactionhistory：

Compaction History:
id                                   keyspace_name columnfamily_name                    compacted_at            bytes_in      bytes_out     rows_merged                                                                                  
1c75e3a0-3742-11ec-9857-214f2f58c37c ks            data                                 2021-10-27T18:22:42.650 390473464     390484113     {1:16075}                                                                                    
7a6e9ea0-373f-11ec-9857-214f2f58c37c ks            data                                 2021-10-27T18:03:51.818 1707027830    1707018031    {1:64370}                                                                                    
58a88830-373f-11ec-9857-214f2f58c37c ks            data                                 2021-10-27T18:02:55.155 398950265     398960890     {1:16079}                                                                                    
8ea5f8d0-373c-11ec-9857-214f2f58c37c ks            data                                 2021-10-27T17:42:57.245 424591552     424600397     {1:16090}                                                                                     
b66700b0-3739-11ec-9857-214f2f58c37c ks            data                                 2021-10-27T17:22:35.451 432286657     432297374     {1:16098}                                                                                        

看来，每次系统对 table 进行压缩时，都会写入ks.data一个抱怨的信息日志Maximum memory usage reached。

所以我检查cfhistograms了那张桌子：

Percentile  SSTables     Write Latency      Read Latency    Partition Size        Cell Count
                              (micros)          (micros)           (bytes)
50%             0.00            105.78              0.00            545791                 1
75%             0.00            105.78              0.00            545791                 1
95%             0.00            126.93              0.00            785939                 1
98%             0.00            126.93              0.00            785939                 1
99%             0.00            152.32              0.00            785939                 1
Min             0.00             73.46              0.00            219343                 0
Max             0.00            182.79              0.00            785939                 1

和cfstats：

Keyspace : ks
        Read Count: 227
        Read Latency: 84.00625550660794 ms
        Write Count: 2888271
        Write Latency: 0.07958705813962748 ms
        Pending Flushes: 0
                Table: data
                SSTable count: 20
                Space used (live): 1112974882377
                Space used (total): 1112974882377
                Space used by snapshots (total): 0
                Off heap memory used (total): 249968759
                SSTable Compression Ratio: 0.5526821933214058
                Number of partitions (estimate): 4084058
                Memtable cell count: 3982
                Memtable data size: 2818857176
                Memtable off heap memory used: 0
                Memtable switch count: 560
                Local read count: 0
                Local read latency: NaN ms
                Local write count: 2888274
                Local write latency: 0.107 ms
                Pending flushes: 0
                Percent repaired: 1.72
                Bloom filter false positives: 0
                Bloom filter false ratio: 0.00000
                Bloom filter space used: 3264744
                Bloom filter off heap memory used: 3264584
                Index summary off heap memory used: 961935
                Compression metadata off heap memory used: 245742240
                Compacted partition minimum bytes: 219343
                Compacted partition maximum bytes: 785939
                Compacted partition mean bytes: 539117
                Average live cells per slice (last five minutes): NaN
                Maximum live cells per slice (last five minutes): 0
                Average tombstones per slice (last five minutes): NaN
                Maximum tombstones per slice (last five minutes): 0
                Dropped Mutations: 22

数据模型只是一个基本的键/值：

CREATE TABLE ks.data (
    a int,
    b int,
    value blob,
    PRIMARY KEY ((a, b))
) WITH bloom_filter_fp_chance = 0.1
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}

在我看来一切都很正常……你呢？

• 您认为每次压缩的信息消息是否正常？
• 它是否指出了内存配置问题？

谢谢

标签： cassandradatastaxdatastax-enterprise