卡桑德拉CPU負載（太多）

Question

top使用

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 Memtable-bid_list@2003093066(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 Memtable-bid_list@1124683519(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 Memtable-bid_list@473510037(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正在踢。停止傾銷數據等。

Answer 1

您使用哪種類型的壓實？大小分層還是平坦？ 如果您使用的是水平壓實，您是否可以關閉到「尺寸」分層，因爲您似乎有太多的壓實。增加水平壓實的尺寸也可能有所幫助。

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創建