[英]Determining how full a Cassandra cluster is
I just imported a lot of data in a 9 node Cassandra cluster and before I create a new ColumnFamily with even more data, I'd like to be able to determine how full my cluster currently is (in terms of memory usage). 我刚刚在一个9节点的Cassandra集群中导入了大量数据,在我创建一个包含更多数据的新ColumnFamily之前,我希望能够确定当前集群的完整程度(就内存使用而言)。 I'm not too sure what I need to look at.
我不太清楚我需要注意什么。 I don't want to import another 20-30GB of data and realize I should have added 5-6 more nodes.
我不想导入另外20-30GB的数据,并意识到我应该增加5-6个节点。
In short, I have no idea if I have too few/many nodes right now for what's in the cluster. 简而言之,我不知道我现在是否有太少/很多节点用于集群中的内容。
Any help would be greatly appreciated :) 任何帮助将不胜感激 :)
$ nodetool -h 192.168.1.87 ring
Address DC Rack Status State Load Owns Token
151236607520417094872610936636341427313
192.168.1.87 datacenter1 rack1 Up Normal 7.19 GB 11.11% 0
192.168.1.86 datacenter1 rack1 Up Normal 7.18 GB 11.11% 18904575940052136859076367079542678414
192.168.1.88 datacenter1 rack1 Up Normal 7.23 GB 11.11% 37809151880104273718152734159085356828
192.168.1.84 datacenter1 rack1 Up Normal 4.2 GB 11.11% 56713727820156410577229101238628035242
192.168.1.85 datacenter1 rack1 Up Normal 4.25 GB 11.11% 75618303760208547436305468318170713656
192.168.1.82 datacenter1 rack1 Up Normal 4.1 GB 11.11% 94522879700260684295381835397713392071
192.168.1.89 datacenter1 rack1 Up Normal 4.83 GB 11.11% 113427455640312821154458202477256070485
192.168.1.51 datacenter1 rack1 Up Normal 2.24 GB 11.11% 132332031580364958013534569556798748899
192.168.1.25 datacenter1 rack1 Up Normal 3.06 GB 11.11% 151236607520417094872610936636341427313
- -
# nodetool -h 192.168.1.87 cfstats
Keyspace: stats
Read Count: 232
Read Latency: 39.191931034482764 ms.
Write Count: 160678758
Write Latency: 0.0492021849459404 ms.
Pending Tasks: 0
Column Family: DailyStats
SSTable count: 5267
Space used (live): 7710048931
Space used (total): 7710048931
Number of Keys (estimate): 10701952
Memtable Columns Count: 4401
Memtable Data Size: 23384563
Memtable Switch Count: 14368
Read Count: 232
Read Latency: 29.047 ms.
Write Count: 160678813
Write Latency: 0.053 ms.
Pending Tasks: 0
Bloom Filter False Postives: 0
Bloom Filter False Ratio: 0.00000
Bloom Filter Space Used: 115533264
Key cache capacity: 200000
Key cache size: 1894
Key cache hit rate: 0.627906976744186
Row cache: disabled
Compacted row minimum size: 216
Compacted row maximum size: 42510
Compacted row mean size: 3453
- -
[default@stats] describe;
Keyspace: stats:
Replication Strategy: org.apache.cassandra.locator.SimpleStrategy
Durable Writes: true
Options: [replication_factor:3]
Column Families:
ColumnFamily: DailyStats (Super)
Key Validation Class: org.apache.cassandra.db.marshal.BytesType
Default column value validator: org.apache.cassandra.db.marshal.UTF8Type
Columns sorted by: org.apache.cassandra.db.marshal.UTF8Type/org.apache.cassandra.db.marshal.UTF8Type
Row cache size / save period in seconds / keys to save : 0.0/0/all
Row Cache Provider: org.apache.cassandra.cache.ConcurrentLinkedHashCacheProvider
Key cache size / save period in seconds: 200000.0/14400
GC grace seconds: 864000
Compaction min/max thresholds: 4/32
Read repair chance: 1.0
Replicate on write: true
Built indexes: []
Column Metadata:
(removed)
Compaction Strategy: org.apache.cassandra.db.compaction.LeveledCompactionStrategy
Compression Options:
sstable_compression: org.apache.cassandra.io.compress.SnappyCompressor
Obviously, there are two types of memory -- disk and RAM. 显然,有两种类型的内存 - 磁盘和RAM。 I'm going to assume you're talking about disk space.
我假设你在谈论磁盘空间。
First, you should find out how much space you're currently using per node. 首先,您应该了解每个节点当前使用的空间大小。 Check the on-disk usage of the cassandra data dir (by default
/var/lib/cassandra/data
) with this command: du -ch /var/lib/cassandra/data
You should then compare that to the size of your disk, which can be found with df -h
. 使用以下命令检查cassandra数据目录的磁盘使用情况(默认情况下为
/var/lib/cassandra/data
): du -ch /var/lib/cassandra/data
然后应将其与磁盘大小进行比较,可以用df -h
找到。 Only consider the entry for the df
results for the disk your cassandra data is on, by checking the Mounted on column. 通过选中Mounted on列,只考虑cassandra数据所在磁盘的
df
结果条目。
Using those stats, you should be able to calculate how full in % the cassandra data partition. 使用这些统计信息,您应该能够计算cassandra数据分区的百分比。 Generally you don't want to get too close to 100% because cassandra's normal compaction processes temporarily use more disk space.
通常,您不希望太接近100%,因为cassandra的正常压缩过程暂时使用更多的磁盘空间。 If you don't have enough, then a node can get caught with a full disk, which can be painful to resolve (as I side note I occasionally keep a "ballast" file of a few Gigs that I can delete just in case I need to open some extra space).
如果你没有足够的,那么一个节点可能会被一个完整的磁盘捕获,这可能很难解决(因为我注意到我偶尔会保留一些我可以删除的Gigs的“镇流器”文件,以防万一需要打开一些额外的空间)。 I've generally found that not exceeding about 70% disk usage is on the safe side for the 0.8 series.
我一般发现0.8系列的磁盘使用率不超过70%是安全的。
If you're using a newer version of cassandra, then I'd recommend giving the Leveled Compaction strategy a shot to reduce temporary disk usage. 如果您使用的是较新版本的cassandra,那么我建议您使用Leveled Compaction策略来减少临时磁盘使用量。 Instead of potentially using twice as much disk space, the new strategy will at most use 10x of a small, fixed size (5MB by default).
新策略最多只使用固定大小的10倍(默认为5MB),而不是可能使用两倍的磁盘空间。
You can read more about how compaction temporarily increases disk usage on this excellent blog post from Datastax: http://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassandra It also explains the compaction strategies. 您可以从Datastax的这篇优秀博客文章中了解更多有关压缩如何暂时增加磁盘使用量的信息: http ://www.datastax.com/dev/blog/leveled-compaction-in-apache-cassandra它还解释了压缩策略。
So to do a little capacity planning, you can figure up how much more space you'll need. 因此,为了进行一些容量规划,您可以计算出您需要多少空间。 With a replication factor of 3 (what you're using above), adding 20-30GB of raw data would add 60-90GB after replication.
复制因子为3(您在上面使用的内容),添加20-30GB的原始数据将在复制后增加60-90GB。 Split between your 9 nodes, that's maybe 3GB more per node.
在9个节点之间拆分,每个节点可能多3GB。 Does adding that kind of disk usage per node push you too close to having full disks?
是否每个节点添加这种磁盘使用量会使您太接近拥有完整磁盘? If so, you might want to consider adding more nodes to the cluster.
如果是这样,您可能需要考虑向群集添加更多节点。
One other note is that your nodes' loads aren't very even -- from 2GB up to 7GB. 另一个注意事项是节点的负载不是很均匀 - 从2GB到7GB。 If you're using the ByteOrderPartitioner over the random one, then that can cause uneven load and "hotspots" in your ring.
如果您使用ByteOrderPartitioner而不是随机的那个,则可能导致环中负载不均匀和“热点”。 You should consider using random if possible.
如果可能,您应该考虑使用随机。 The other possibility could be that you have extra data hanging out that needs to be taken care of (Hinted Handoffs and snapshots come to mind).
另一种可能是您需要处理剩余的额外数据(Hinted Handoffs和快照会浮现在脑海中)。 Consider cleaning that up by running
nodetool repair
and nodetool cleanup
on each node one at a time (be sure to read up on what those do first!). 考虑通过在每个节点上一次运行一个
nodetool repair
和nodetool cleanup
它(请务必阅读那些先做的事情!)。
Hope that helps. 希望有所帮助。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.