建议停止压实以减少缓慢

Question

我看到种子节点上 cassandra 的 CPU 和内存使用率很高。是否建议停止压缩（nodetool stop）并在非高峰时间启用。我应该手动压缩还是启用自动压缩。我看到很多Native-Transport-Requests。我有三个种子节点。这是第一个种子节点。

Pool Name                         Active   Pending      Completed   Blocked  All time blocked
ReadStage                              0         0          54255         0                 0
MiscStage                              0         0              0         0                 0
CompactionExecutor                     2      2566         352765         0                 0
MutationStage                          0         0     2659921760         0                 0
MemtableReclaimMemory                  0         0         180958         0                 0
PendingRangeCalculator                 0         0             21         0                 0
GossipStage                            0         0         338375         0                 0
SecondaryIndexManagement               0         0              0         0                 0
HintsDispatcher                        0         0             63         0                 0
RequestResponseStage                   0         1     1684328696         0                 0
Native-Transport-Requests              4         0     1538523706         0          47006391
ReadRepairStage                        0         0           2197         0                 0
CounterMutationStage                   0         0              0         0                 0
MigrationStage                         0         0              0         0                 0
MemtablePostFlush                      1         1         216220         0                 0
PerDiskMemtableFlushWriter_0           1         1         180958         0                 0
ValidationExecutor                     0         0          33250         0                 0
Sampler                                0         0              0         0                 0
MemtableFlushWriter                    1         1         180958         0                 0
InternalResponseStage                  0         0         141677         0                 0
ViewMutationStage                      0         0              0         0                 0
AntiEntropyStage                       0         0         166254         0                 0
CacheCleanupExecutor                   0         0              0         0                 0
Repair#9                               0         0           5719         0                 0

我确实看到了高压实度。是否建议使用 nodetool stop 禁用压缩

$ nodetool info
ID                     : ebeda774-cea8-40bb-9322-69c6fcded5a9
Gossip active          : true
Thrift active          : true
Native Transport active: true
Load                   : 535.37 GiB
Generation No          : 1636316595
Uptime (seconds)       : 73152
Heap Memory (MB)       : 19542.18 / 32168.00
Off Heap Memory (MB)   : 1337.98
Data Center            : us-west2
Rack                   : a
Exceptions             : 15
Key Cache              : entries 152283, size 23.07 MiB, capacity 100 MiB, 23835 hits, 280738 requests, 0.085 recent hit rate, 14400 save period in seconds
Row Cache              : entries 0, size 0 bytes, capacity 0 bytes, 0 hits, 0 requests, NaN recent hit rate, 0 save period in seconds
Counter Cache          : entries 0, size 0 bytes, capacity 50 MiB, 0 hits, 0 requests, NaN recent hit rate, 7200 save period in seconds
Chunk Cache            : entries 6782, size 423.88 MiB, capacity 480 MiB, 23947952 misses, 24381819 requests, 0.018 recent hit rate, 250.977 microseconds miss latency
Percent Repaired       : 0.49796724500672584%
Token                  : (invoke with -T/--tokens to see all 256 tokens)

$ free -h
              total        used        free      shared  buff/cache   available
Mem:            62G         53G        658M        1.0M        8.5G        8.5G
Swap:            0B          0B          0B

~$ nodetool compactionstats
pending tasks: 197
....
id                                   compaction type keyspace         table                          completed total    unit  progress
5e555610-40b2-11ec-9b5a-27bc920e6e55 Compaction      mykeyspace       table1 27299674  89930474 bytes 30.36%
5e55f251-40b2-11ec-9b5a-27bc920e6e55 Compaction      mykeyspace       table2 13922048  74426264 bytes 18.71%
Active compaction remaining time :   0h00m02s

Answer 1

我绝对不会手动运行压缩。许多压缩阈值是基于文件大小的，这意味着强制它会创建超出正常进程大小的文件。结果，再次在该表上运行压缩的机会非常渺茫。基本上，一旦你开始走这条路，你将永远运行手动压缩。

我还要说压缩是一件好的事情。您希望它发生，因为压缩文件是保持读取性能良好所必需的。当然，当压缩过程影响操作活动时，这并不是什么安慰。

tl;dr;

我过去做过的一项工作是降低白天的压缩吞吐量。不确定您当前运行的吞吐量是多少，但您可以通过运行nodetool getcompactionthroughput 找到它：

% bin/nodetool getcompactionthroughput
Current compaction throughput: 64 MB/s

因此，当客户/运营流量很高时，您可以显着减少：

% bin/nodetool setcompactionthroughput 1
% bin/nodetool getcompactionthroughput
Current compaction throughput: 1 MB/s

1 MB / 秒是可以设置的压缩吞吐量的最低值。如果将其设置为零，则它是“不受限制的”，这意味着它将消耗它可以获得的所有资源。将其设置为 1 会降低其资源使用（和速度）。

一旦繁忙的日常交通消退，该设置可以恢复：

% bin/nodetool setcompactionthroughput 256
Current compaction throughput: 256 MB/s

这可以通过为每个命令安排一个作业来完成。