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 SSD

此外，我们已为/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 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，按字节排序：

Answer 1

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

当我们尝试向群集添加新实例时，它运行顺利，负载现已恢复正常。

我的预感是nodetool rebuild或nodetool repair可能已经开始对我们的两个节点进行意外处理。这些特定情况也可能是错误的，但我没有找到任何证据。

以下是回收us-east实例后我们的欧洲西部实例的CPU使用情况：

Answer 2

m3.medium处于低端以运行C *，任何实际负载（450GB是实际负载）并且EBS远非最佳。您可以尝试使用短暂的驱动器来获取数据，以消除读/写请求的一些延迟，但您可能只需要更多的CPU用于此类事情。

退房：  http://www.datastax.com/documentation/cassandra/2.1/cassandra/planning/architecturePlanningEC2_c.html