amazon-web-services - Cassandra 无限期地紧凑运行 - CPU 使用率高

Question

上下文

我们在 AWS 上托管了 6 个 Cassandra 实例，分为 3 个不同的区域，每个区域 2 个(欧盟西部 2 个，美国西部 2 个，亚太东南部 2 个)。

2 天前，我们将 2 个 EC2 Cassandra 实例从 us-west-1 移至 us-east-1。当我说“移动”时，我的意思是我们停用了它们并在集群上添加了 2 个新实例。

我们运行了 nodetool Repair ，它没有做任何事情，而 nodetool rebuild 则同步了来自欧盟西部数据中心的数据。进行此更改后，我们注意到 Cassandra 集群上的多个实例使用了超过 70% 的 CPU，并且有传入流量。

起初，我们以为是在进行复制，但考虑到我们只有 500MB 的数据，而且它仍在运行，我们对发生的情况感到困惑。

<小时/>

实例硬件:

我们所有的实例都在 m3.medium 上运行，这意味着我们正在:

• 1 个 CPU，2.5 GHz
• 3.75 GB RAM
• 4GB 固态硬盘

我们还为 /var/lib/cassandra 安装了一个 EBS 卷，它实际上是 EBS 上 6 个 SSD 的 RAID0:

• EBS 卷 300GB SSD、RAID0

引用号:Amazon Instances Types

<小时/>

软件版本:

Cassandra 版本:2.0.12

<小时/>

想法:

分析数据后，我们认为这是由 Cassandra 数据压缩引起的。

还有另一个关于同一主题的 stackoverflow 问题:Cassandra compaction tasks stuck .

但是，这是通过使用单个 SSD(Azure 高级存储 - 仍处于预览版)并且没有为 Cassandra 配置 RAID0 来解决的，正如作者所说，没有理由解决根本问题(为什么会这样)从等式中删除 RAID0 部分可以解决此问题吗？)。

我们还不太热衷于迁移到本地存储，因为 AWS 定价比我们现在高得多。尽管如此，如果这确实是我们问题的原因，我们会尝试一下。

这听起来像是一个更深层次问题的另一个原因是，我们有数据显示这些 EBS 卷在过去 3 天内写入/读取了大量数据。

自从我们移动实例以来，我们在每个 EBS 卷上每秒获得大约 300-400KB 的写入数据，因此由于我们有 RAID0，每秒该数量的 6 倍 = 1.8-2.4MB/s。这相当于过去 3 天内每个实例写入的数据量约为 450GB。我们对于 READ 操作也有基本相同的值。

我们目前仅对它们进行测试，因此我们获得的唯一流量来自 CI 服务器，并最终来自 Gossip 在实例之间进行的通信。

<小时/>

调试注释

nodetool 状态的输出:

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

nodetoolcompactionstats的输出:

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，按字节排序:

Answer 1

我们尝试了其他答案和评论中的一些操作，但最终解决此问题的是终止 2 个新实例。

当我们尝试向集群添加新实例时，一切进展顺利，负载现已恢复正常。

我的直觉是，nodetool重建或nodetool修复可能已经开始对我们的两个节点进行意外处理。也有可能这些特定实例有错误，但我还没有找到任何证据。

以下是回收 us-east 实例后 eu-west 实例上的 CPU 使用情况: