【发布时间】：2015-03-21 20:24:43
【问题描述】：
上下文
我们在 AWS 上托管了 6 个 Cassandra 实例，分为 3 个不同的区域，每个区域 2 个（2 个在 eu-west，2 个在 us-west，2 个在 ap-southeast）。
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 内存
- 4GB 固态硬盘
我们还为/var/lib/cassandra 挂载了一个 EBS 卷，这实际上是 EBS 上 6 个 SSD 的 RAID0：
- EBS 卷 300GB SSD，RAID0
软件版本：
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，按字节排序：
【问题讨论】：
-
可以添加nodetool tpstats和netstats输出吗？
-
完成。我添加了 iptraf 而不是 netstats。该图像看起来有点小，但您可以在选项卡中打开其 URL 以查看其完整大小。希望对您有所帮助。
-
啊，我还添加了 Amazon EBS 统计信息...
-
你在使用分级压缩策略吗？
-
我们使用默认的压缩策略（Size-tiered compaction）。我读了一些关于水平压实的文章，这是一个很好的猜测，但我们没有使用它:(。
标签： amazon-web-services amazon-ec2 cassandra