Cassandra 运行 无限压缩 - 高 CPU 使用率
Cassandra running compact indefinitely - High CPU usage
上下文
我们在 AWS 上托管了 6 个 Cassandra 实例，分为 3 个不同的区域，每个区域 2 个（欧洲西部 2 个，美国西部 2 个，亚太东南部 2 个）。
2 天前，我们将 2 个 EC2 Cassandra 实例从 us-west-1 移到了 us-east-1。当我说 "move" 时，我的意思是我们停用了它们并在我们的集群上添加了 2 个新实例。
我们 运行 nodetool repair 没有做任何事情，nodetool rebuild 从欧盟西部数据中心同步了我们的数据。在这一变化之后，我们注意到我们的 Cassandra 集群上的多个实例使用了超过 70% CPU 并且有传入流量。
起初，我们以为是复制发生了，但考虑到我们只有 500MB 的数据，而且它仍然是 运行，我们对发生了什么感到困惑。
实例硬件：
我们所有的实例都在 运行 m3.medium 这意味着我们在：
- 1 CPU, 2.5 GHz
- 3.75 GB 内存
- 4GB 固态硬盘
我们还为 /var/lib/cassandra 安装了一个 EBS 卷，它实际上是 EBS 上 6 个 SSD 的 RAID0：
- EBS 卷 300GB SSD，RAID0
软件版本：
卡桑德拉版本：2.0.12
想法：
分析我们的数据后，我们认为这是由 Cassandra 数据压缩引起的。
关于同一主题还有另一个 Whosebug 问题：。
然而，这是通过选择单个 SSD（Azure 高级存储 - 仍处于预览阶段）并且没有为 Cassandra 配置 RAID0 来解决的，正如作者所说，没有理由解决根本问题（为什么从等式中删除 RAID0 部分可以解决这个问题？）。
我们还不热衷于迁移到本地存储，因为 AWS 定价比我们现在的定价高很多。即使，如果它真的是我们问题的原因，我们也会尝试。
这听起来像是一个更深层次问题的另一个原因是，我们有数据显示这些 EBS 卷在过去 3 天里 writing/reading 很多数据。
自从我们移动了实例后，我们在每个 EBS 卷上每秒写入了大约 300-400KB 的数据，因此由于我们有 RAID0，每秒这个数量的 6 倍 = 1.8-2.4MB/s。这相当于在过去 3 天内每个实例写入了约 450GB 的数据。我们也有基本相同的 READ 操作值。
我们目前只对它们进行 运行 测试，所以我们获得的唯一流量来自我们的 CI 服务器，最终来自 Gossip 在实例之间进行的通信。
调试笔记
nodetool status 的输出：
Datacenter: cassandra-eu-west-1-A
=================================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN xxx.xxx.xxx.xxx 539.5 MB 256 17.3% 12341234-1234-1234-1234-12341234123412340cd7 eu-west-1c
UN xxx.xxx.xxx.xxx 539.8 MB 256 14.4% 30ff8d00-1ab6-4538-9c67-a49e9ad34672 eu-west-1b
Datacenter: cassandra-ap-southeast-1-A
======================================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN xxx.xxx.xxx.xxx 585.13 MB 256 16.9% a0c45f3f-8479-4046-b3c0-b2dd19f07b87 ap-southeast-1a
UN xxx.xxx.xxx.xxx 588.66 MB 256 17.8% b91c5863-e1e1-4cb6-b9c1-0f24a33b4baf ap-southeast-1b
Datacenter: cassandra-us-east-1-A
=================================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN xxx.xxx.xxx.xxx 545.56 MB 256 15.2% ab049390-f5a1-49a9-bb58-b8402b0d99af us-east-1d
UN xxx.xxx.xxx.xxx 545.53 MB 256 18.3% 39c698ea-2793-4aa0-a28d-c286969febc4 us-east-1e
nodetool compactionstats 的输出：
pending tasks: 64
compaction type keyspace table completed total unit progress
Compaction staging stats_hourly 418858165 1295820033 bytes 32.32%
Active compaction remaining time : 0h00m52s
运行 dstat 在不健康的实例上：
图表形式的压缩历史记录（从 16 日开始平均每小时 300 次）：
EBS 卷使用情况：
运行 df -h:
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 33G 11G 21G 34% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 1.9G 12K 1.9G 1% /dev
tmpfs 377M 424K 377M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 1.9G 4.0K 1.9G 1% /run/shm
none 100M 0 100M 0% /run/user
/dev/xvdb 3.9G 8.1M 3.7G 1% /mnt
/dev/md0 300G 2.5G 298G 1% /var/lib/cassandra
运行 nodetool tpstats:
Pool Name Active Pending Completed Blocked All time blocked
MutationStage 0 0 3191689 0 0
ReadStage 0 0 574633 0 0
RequestResponseStage 0 0 2698972 0 0
ReadRepairStage 0 0 2721 0 0
ReplicateOnWriteStage 0 0 0 0 0
MiscStage 0 0 62601 0 0
HintedHandoff 0 1 443 0 0
FlushWriter 0 0 88811 0 0
MemoryMeter 0 0 1472 0 0
GossipStage 0 0 979483 0 0
CacheCleanupExecutor 0 0 0 0 0
InternalResponseStage 0 0 25 0 0
CompactionExecutor 1 39 99881 0 0
ValidationExecutor 0 0 62599 0 0
MigrationStage 0 0 40 0 0
commitlog_archiver 0 0 0 0 0
AntiEntropyStage 0 0 149095 0 0
PendingRangeCalculator 0 0 23 0 0
MemtablePostFlusher 0 0 173847 0 0
Message type Dropped
READ 0
RANGE_SLICE 0
_TRACE 0
MUTATION 0
COUNTER_MUTATION 0
BINARY 0
REQUEST_RESPONSE 0
PAGED_RANGE 0
READ_REPAIR 0
运行 iptraf，按字节排序：
m3.medium 处于 运行 C* 的低端，具有任何实际负载（450GB 是实际负载），EBS 远非最佳。您可以尝试使用临时数据驱动器来消除 read/write 请求的一些延迟，但您可能只需要更多 cpu 来处理这种事情。
我们从其他答案和评论中尝试了一些方法，但最终解决这个问题的是终止 2 个新实例。
当我们尝试向集群添加新实例时，一切顺利，负载现在恢复正常。
我的预感是 nodetool rebuild 或 nodetool repair 可能已经开始对我们的两个节点进行意外处理。也有可能这些特定实例有问题，但我还没有找到任何证据。
这是回收 us-east 实例后 CPU 在我们的 eu-west 实例上的用法：
上下文
我们在 AWS 上托管了 6 个 Cassandra 实例，分为 3 个不同的区域，每个区域 2 个（欧洲西部 2 个，美国西部 2 个，亚太东南部 2 个）。
2 天前，我们将 2 个 EC2 Cassandra 实例从 us-west-1 移到了 us-east-1。当我说 "move" 时，我的意思是我们停用了它们并在我们的集群上添加了 2 个新实例。
我们 运行 nodetool repair 没有做任何事情，nodetool rebuild 从欧盟西部数据中心同步了我们的数据。在这一变化之后，我们注意到我们的 Cassandra 集群上的多个实例使用了超过 70% CPU 并且有传入流量。
起初，我们以为是复制发生了，但考虑到我们只有 500MB 的数据，而且它仍然是 运行，我们对发生了什么感到困惑。
实例硬件：
我们所有的实例都在 运行 m3.medium 这意味着我们在：
- 1 CPU, 2.5 GHz
- 3.75 GB 内存
- 4GB 固态硬盘
我们还为 /var/lib/cassandra 安装了一个 EBS 卷，它实际上是 EBS 上 6 个 SSD 的 RAID0：
- EBS 卷 300GB SSD，RAID0
软件版本：
卡桑德拉版本：2.0.12
想法：
分析我们的数据后，我们认为这是由 Cassandra 数据压缩引起的。
关于同一主题还有另一个 Whosebug 问题：
然而，这是通过选择单个 SSD（Azure 高级存储 - 仍处于预览阶段）并且没有为 Cassandra 配置 RAID0 来解决的，正如作者所说，没有理由解决根本问题（为什么从等式中删除 RAID0 部分可以解决这个问题？）。
我们还不热衷于迁移到本地存储，因为 AWS 定价比我们现在的定价高很多。即使，如果它真的是我们问题的原因，我们也会尝试。
这听起来像是一个更深层次问题的另一个原因是，我们有数据显示这些 EBS 卷在过去 3 天里 writing/reading 很多数据。
自从我们移动了实例后，我们在每个 EBS 卷上每秒写入了大约 300-400KB 的数据，因此由于我们有 RAID0，每秒这个数量的 6 倍 = 1.8-2.4MB/s。这相当于在过去 3 天内每个实例写入了约 450GB 的数据。我们也有基本相同的 READ 操作值。
我们目前只对它们进行 运行 测试，所以我们获得的唯一流量来自我们的 CI 服务器，最终来自 Gossip 在实例之间进行的通信。
调试笔记
nodetool status 的输出：
Datacenter: cassandra-eu-west-1-A
=================================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN xxx.xxx.xxx.xxx 539.5 MB 256 17.3% 12341234-1234-1234-1234-12341234123412340cd7 eu-west-1c
UN xxx.xxx.xxx.xxx 539.8 MB 256 14.4% 30ff8d00-1ab6-4538-9c67-a49e9ad34672 eu-west-1b
Datacenter: cassandra-ap-southeast-1-A
======================================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN xxx.xxx.xxx.xxx 585.13 MB 256 16.9% a0c45f3f-8479-4046-b3c0-b2dd19f07b87 ap-southeast-1a
UN xxx.xxx.xxx.xxx 588.66 MB 256 17.8% b91c5863-e1e1-4cb6-b9c1-0f24a33b4baf ap-southeast-1b
Datacenter: cassandra-us-east-1-A
=================================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN xxx.xxx.xxx.xxx 545.56 MB 256 15.2% ab049390-f5a1-49a9-bb58-b8402b0d99af us-east-1d
UN xxx.xxx.xxx.xxx 545.53 MB 256 18.3% 39c698ea-2793-4aa0-a28d-c286969febc4 us-east-1e
nodetool compactionstats 的输出：
pending tasks: 64
compaction type keyspace table completed total unit progress
Compaction staging stats_hourly 418858165 1295820033 bytes 32.32%
Active compaction remaining time : 0h00m52s
运行 dstat 在不健康的实例上：
图表形式的压缩历史记录（从 16 日开始平均每小时 300 次）：
EBS 卷使用情况：
运行 df -h:
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 33G 11G 21G 34% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 1.9G 12K 1.9G 1% /dev
tmpfs 377M 424K 377M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 1.9G 4.0K 1.9G 1% /run/shm
none 100M 0 100M 0% /run/user
/dev/xvdb 3.9G 8.1M 3.7G 1% /mnt
/dev/md0 300G 2.5G 298G 1% /var/lib/cassandra
运行 nodetool tpstats:
Pool Name Active Pending Completed Blocked All time blocked
MutationStage 0 0 3191689 0 0
ReadStage 0 0 574633 0 0
RequestResponseStage 0 0 2698972 0 0
ReadRepairStage 0 0 2721 0 0
ReplicateOnWriteStage 0 0 0 0 0
MiscStage 0 0 62601 0 0
HintedHandoff 0 1 443 0 0
FlushWriter 0 0 88811 0 0
MemoryMeter 0 0 1472 0 0
GossipStage 0 0 979483 0 0
CacheCleanupExecutor 0 0 0 0 0
InternalResponseStage 0 0 25 0 0
CompactionExecutor 1 39 99881 0 0
ValidationExecutor 0 0 62599 0 0
MigrationStage 0 0 40 0 0
commitlog_archiver 0 0 0 0 0
AntiEntropyStage 0 0 149095 0 0
PendingRangeCalculator 0 0 23 0 0
MemtablePostFlusher 0 0 173847 0 0
Message type Dropped
READ 0
RANGE_SLICE 0
_TRACE 0
MUTATION 0
COUNTER_MUTATION 0
BINARY 0
REQUEST_RESPONSE 0
PAGED_RANGE 0
READ_REPAIR 0
运行 iptraf，按字节排序：
m3.medium 处于 运行 C* 的低端，具有任何实际负载（450GB 是实际负载），EBS 远非最佳。您可以尝试使用临时数据驱动器来消除 read/write 请求的一些延迟，但您可能只需要更多 cpu 来处理这种事情。
我们从其他答案和评论中尝试了一些方法，但最终解决这个问题的是终止 2 个新实例。
当我们尝试向集群添加新实例时，一切顺利，负载现在恢复正常。
我的预感是 nodetool rebuild 或 nodetool repair 可能已经开始对我们的两个节点进行意外处理。也有可能这些特定实例有问题，但我还没有找到任何证据。
这是回收 us-east 实例后 CPU 在我们的 eu-west 实例上的用法：