读取速度越来越慢，但写入速度仍然很快
Posted: Sun Feb 09, 2025 8:13 am
轻微/严重压实
每次从 memtable（内存）刷新到 sstables（磁盘）时都会自动触发 Minor Compaction。你可以根据自己的性能需求调整 Minor Compaction 的设置。
默认情况下，当 4 个或更多表被刷新到磁盘且具有相似大小时，并且磁盘上总共有 4 到 32 个 SSTable 时，就会启动小压缩。
当您使用 nodetool 命令手动执行压缩时，它会强制进行主要压缩。主要压缩的行为可能有所不同，具体取决于受影响表使用的压缩策略：
按大小分层压缩 (STCS) 将已修复和未修复的数据拆分到单独的池中，以进行单独的压缩。主要压缩会生成两个 SSTable，每个数据池一个。
分级压缩 (LCS) 对未修复的数据执行大小分级压缩。修复完成后，Casandra 将数据从未修复的 SSTable 集中移至 L0。
日期分层 (DTCS) 将已修复和未修复的数据拆分到单独的池中，以进行单独的压缩。主要压缩会生成两个 SSTable，每个数据池一个。
性能影响
下面列出了由于压缩参数调整错误而可能发生的一些问题。
节点不可访问
当有大量待处理的压缩任务时，就会发生这种情况。
原因：在同时执行读取和写入操作时，压缩操作通常会运行。如果您继续尽可能快地向压缩操作发送写入操作，压缩操作可能会落后，这也是正常的。在这种情况下，压缩活动会占用机器资源，平均负载可能会上升，这可能会导致多个节点无法访问。
可能的解决方案：如果需要压缩的工作负载始终保持最新状态，那么您将需要更大的集群来将负载分散到更多机器上。您可以在 Cassandra 节点上使用此命令检查待处理的压缩任务。
“nodetool compactionstats”
慢读
原因：同样，当行随着时间的推移而碎片化时，可能会出现此问题，从而需要更多的 IO 和 CPU 时间进行读取。过多的 SSTable 可能会导致读取速度变慢。这可能是由于待处理的压缩而发生的。即使刷新不是过于频繁，压缩也可能无法跟上。如果存在大量待处理的压缩，则压缩无法跟上。
可能的解决方案：要解决此问题，您需要确保compaction_throughput_mb_per_sec设置正确。对于旋转磁盘， compaction_throughput_mb_per_sec 的默认值为 16 MB/秒。 SSD 可以使用更高的设置，例如 128 MB/秒或更高。
如果您设置了较高的压缩吞吐量，但 I/O 利用率较低且压缩仍未跟上，则压 巴西电报数据 缩可能受到 CPU 限制。
您需要检查 CompactionExecutor 线程的每核 CPU 利用率。如果线程利用了单个核心的 100%，则压缩可能受 CPU 限制。增加 concurrent_compactors 将允许对不同 SSTables 集进行多次并发压缩，但每组 SSTables 的压缩本质上都是单线程的。如果我们使用 LeveledCompactionStrategy (LCS)，则需要切换到 SizeTieredCompactionStrategy (STCS) 或添加更多节点以分散压缩负载。注意：将并发压缩器的数量增加到超过物理 CPU 核心的数量可能会适得其反。使用所有可用的 CPU 进行压缩意味着没有剩余的 CPU 来处理读取和写入。如果您需要在赶上压缩的同时继续处理请求，请确保至少留出 1 或 2 个物理 CPU 供读取和/或写入使用。
切换到 SizeTieredCompactionStrategy。如果您使用的是 LeveledCompactionStrategy (LCS)，并且上述步骤不起作用，请考虑切换到 SizeTieredCompactionStrategy (STCS)。LCS 比 STCS 需要更多的资源来压缩。通常，使用 LCS 压缩时落后的节点可以使用 STCS 轻松跟上。
如果由于 SSTable 过多而导致读取速度缓慢，则一种选择是使用 nodetool 运行压缩（Major Compaction）。此过程将所有现有 SSTable 合并为一个，由于新旧 SSTable 共存，导致磁盘空间使用量和磁盘 I/O 暂时激增。但是，请务必注意，Major Compaction 可能会导致大量磁盘 I/O。
注意：您不应明确运行 nodetool compact。这不会造成致命后果，但确实会创建非常大的 SSTable。如果您使用SizeTieredCompactionStrategy，Cassandra 将等待 n 个（可以配置 n 个）相同大小的 SSTable，然后才会触发下一次次要压缩，但有时它可能有助于清除已删除/覆盖的数据。
想要与我们的专家团队进一步讨论 Cassandra 吗？立即联系我们。
每次从 memtable（内存）刷新到 sstables（磁盘）时都会自动触发 Minor Compaction。你可以根据自己的性能需求调整 Minor Compaction 的设置。
默认情况下，当 4 个或更多表被刷新到磁盘且具有相似大小时，并且磁盘上总共有 4 到 32 个 SSTable 时，就会启动小压缩。
当您使用 nodetool 命令手动执行压缩时，它会强制进行主要压缩。主要压缩的行为可能有所不同，具体取决于受影响表使用的压缩策略：
按大小分层压缩 (STCS) 将已修复和未修复的数据拆分到单独的池中，以进行单独的压缩。主要压缩会生成两个 SSTable，每个数据池一个。
分级压缩 (LCS) 对未修复的数据执行大小分级压缩。修复完成后，Casandra 将数据从未修复的 SSTable 集中移至 L0。
日期分层 (DTCS) 将已修复和未修复的数据拆分到单独的池中，以进行单独的压缩。主要压缩会生成两个 SSTable，每个数据池一个。
性能影响
下面列出了由于压缩参数调整错误而可能发生的一些问题。
节点不可访问
当有大量待处理的压缩任务时，就会发生这种情况。
原因：在同时执行读取和写入操作时，压缩操作通常会运行。如果您继续尽可能快地向压缩操作发送写入操作，压缩操作可能会落后，这也是正常的。在这种情况下，压缩活动会占用机器资源，平均负载可能会上升，这可能会导致多个节点无法访问。
可能的解决方案：如果需要压缩的工作负载始终保持最新状态，那么您将需要更大的集群来将负载分散到更多机器上。您可以在 Cassandra 节点上使用此命令检查待处理的压缩任务。
“nodetool compactionstats”
慢读
原因：同样，当行随着时间的推移而碎片化时，可能会出现此问题，从而需要更多的 IO 和 CPU 时间进行读取。过多的 SSTable 可能会导致读取速度变慢。这可能是由于待处理的压缩而发生的。即使刷新不是过于频繁，压缩也可能无法跟上。如果存在大量待处理的压缩，则压缩无法跟上。
可能的解决方案：要解决此问题，您需要确保compaction_throughput_mb_per_sec设置正确。对于旋转磁盘， compaction_throughput_mb_per_sec 的默认值为 16 MB/秒。 SSD 可以使用更高的设置，例如 128 MB/秒或更高。
如果您设置了较高的压缩吞吐量，但 I/O 利用率较低且压缩仍未跟上，则压 巴西电报数据 缩可能受到 CPU 限制。
您需要检查 CompactionExecutor 线程的每核 CPU 利用率。如果线程利用了单个核心的 100%，则压缩可能受 CPU 限制。增加 concurrent_compactors 将允许对不同 SSTables 集进行多次并发压缩，但每组 SSTables 的压缩本质上都是单线程的。如果我们使用 LeveledCompactionStrategy (LCS)，则需要切换到 SizeTieredCompactionStrategy (STCS) 或添加更多节点以分散压缩负载。注意：将并发压缩器的数量增加到超过物理 CPU 核心的数量可能会适得其反。使用所有可用的 CPU 进行压缩意味着没有剩余的 CPU 来处理读取和写入。如果您需要在赶上压缩的同时继续处理请求，请确保至少留出 1 或 2 个物理 CPU 供读取和/或写入使用。
切换到 SizeTieredCompactionStrategy。如果您使用的是 LeveledCompactionStrategy (LCS)，并且上述步骤不起作用，请考虑切换到 SizeTieredCompactionStrategy (STCS)。LCS 比 STCS 需要更多的资源来压缩。通常，使用 LCS 压缩时落后的节点可以使用 STCS 轻松跟上。
如果由于 SSTable 过多而导致读取速度缓慢，则一种选择是使用 nodetool 运行压缩（Major Compaction）。此过程将所有现有 SSTable 合并为一个，由于新旧 SSTable 共存，导致磁盘空间使用量和磁盘 I/O 暂时激增。但是，请务必注意，Major Compaction 可能会导致大量磁盘 I/O。
注意：您不应明确运行 nodetool compact。这不会造成致命后果，但确实会创建非常大的 SSTable。如果您使用SizeTieredCompactionStrategy，Cassandra 将等待 n 个（可以配置 n 个）相同大小的 SSTable，然后才会触发下一次次要压缩，但有时它可能有助于清除已删除/覆盖的数据。
想要与我们的专家团队进一步讨论 Cassandra 吗？立即联系我们。