卡桑德拉CPU负载（太多）

top使用卡桑德拉CPU负载（太多）

8260 root  20 0 5163m 4.7g **133m** S 144.6 30.5 2496:46 java

大多数时候％的CPU的是> 170。

我试图找出问题。我认为GC或冲洗太过责怪。

S0  S1  E  O  P  YGC  YGCT FGC FGCT  GCT LGCC     GCC 
0.00 16.73 74.74 29.33 59.91 27819 407.186 206 10.729 417.914 Allocation Failure No GC  
0.00 16.73 99.57 29.33 59.91 27820 407.186 206 10.729 417.914 Allocation Failure Allocation Failure

同样来自Cassandra日志，它说，具有相同段ID和memtable的Replaying位置过于频繁。

INFO [SlabPoolCleaner] 2015-01-20 13:55:48,515 ColumnFamilyStore.java:840 - Enqueuing flush of bid_list: 112838010 (11%) on-heap, 0 (0%) off-heap 
INFO [MemtableFlushWriter:1587] 2015-01-20 13:55:48,516 Memtable.java:325 - Writing [email protected](23761503 serialized bytes, 211002 ops, 11%/0% of on/off-heap limit) 
INFO [MemtableFlushWriter:1587] 2015-01-20 13:55:49,251 Memtable.java:364 - Completed flushing /root/Cassandra/apache-cassandra-2.1.2/bin/./../data/data/bigdspace/bid_list-27b59f109fa211e498559b0947587867/bigdspace-bid_list-ka-3965-Data.db (4144688 bytes) for commitlog position ReplayPosition(segmentId=1421647511710, position=25289038) 
INFO [SlabPoolCleaner] 2015-01-20 13:56:23,429 ColumnFamilyStore.java:840 - Enqueuing flush of bid_list: 104056985 (10%) on-heap, 0 (0%) off-heap 
INFO [MemtableFlushWriter:1589] 2015-01-20 13:56:23,429 Memtable.java:325 - Writing [email protected](21909522 serialized bytes, 194778 ops, 10%/0% of on/off-heap limit) 
INFO [MemtableFlushWriter:1589] 2015-01-20 13:56:24,130 Memtable.java:364 - Completed flushing /root/Cassandra/apache-cassandra-2.1.2/bin/./../data/data/bigdspace/bid_list-27b59f109fa211e498559b0947587867/bigdspace-bid_list-ka-3967-Data.db (3830733 bytes) for commitlog position ReplayPosition(segmentId=1421647511710, position=25350445) 
INFO [SlabPoolCleaner] 2015-01-20 13:56:55,493 ColumnFamilyStore.java:840 - Enqueuing flush of bid_list: 95807739 (9%) on-heap, 0 (0%) off-heap 
INFO [MemtableFlushWriter:1590] 2015-01-20 13:56:55,494 Memtable.java:325 - Writing [email protected](20170635 serialized bytes, 179514 ops, 9%/0% of on/off-heap limit) 
INFO [MemtableFlushWriter:1590] 2015-01-20 13:56:56,151 Memtable.java:364 - Completed flushing /root/Cassandra/apache-cassandra-2.1.2/bin/./../data/data/bigdspace/bid_list-27b59f109fa211e498559b0947587867/bigdspace-bid_list-ka-3968-Data.db (3531752 bytes) for commitlog position ReplayPosition(segmentId=1421647511710, position=25373052)

任何帮助或建议将是伟大的。我也为KeySpace禁用了持久写入false。谢谢

刚刚发现重新启动所有节点后，即使没有发生任何事情发生，服务器之一上的YGC正在踢。停止倾销数据等。

来源

2015-01-20 cykopath

你的路径中包含Apache的卡桑德拉-2.1.2，这是为什么标签卡桑德拉 - 2.0吗？ – RussS 2015-01-20 21:38:45

我认为sstables和内部结构的考虑方式。 Cassandra 2.0和2.1+非常相似。不是大修。也没有2.1.2的标签。这是一个普遍的问题，即使使用Cassandra 2.0也可能发生。 – cykopath 2015-01-20 21:40:30

您使用哪种类型的压实？大小分层还是平坦？如果您使用的是水平压实，您是否可以关闭到“尺寸”分层，因为您似乎有太多的压实。增加水平压实的尺寸也可能有所帮助。

sstable_size_in_mb（默认值：160MB）目标大小使用在水平的压实战略SSTables。尽管SSTable大小应该小于或等于sstable_size_in_mb，但在压缩过程中可能会使有更大的SSTable。当给定的分区键的数据异常大时，会发生这种情况。数据不会分成两个 SSTables。

（http://www.datastax.com/documentation/cassandra/1.2/cassandra/reference/referenceTableAttributes.html#reference_ds_zyq_zmz_1k__sstable_size_in_mb）

如果您使用的大小分层压实，增加SS表的数量，你看到一个小的压缩前。这是在创建表时设置的，因此您可以使用ALTER命令更改它。下面的实施例：

WITH compaction_strategy_class = 'SizeTieredCompactionStrategy' AND min_compaction_threshold = 6 ALTER TABLE用户;紧凑型后

6个SSTables创建

来源

2015-01-22 12:37:05

我使用水平压实（因为我需要快速读取）。我使用的是ActiveMQ，因此数据首先进入队列，然后写入Cassandra。所以写作不是问题。是否有指导什么应该是sstable的大小？此外，如果问题没有解决这个问题，我改变了大小分层压实在我看到压缩之前增加SS表的数量。非常感谢 – cykopath 2015-01-22 16:04:34

如果您的Level 0 SS Table快速填充，则压平压实会导致压缩和高磁盘使用率。我会建议你们使用大小分层压实或使用更高大小的水平压实来达到0级。 – 2015-01-23 07:00:46

增加了有关如何增加分级大小或增加分层大小的SSTables数量的信息。让我知道它是否有帮助 – 2015-01-23 07:07:11

卡桑德拉CPU负载（太多）

回答

相关问题