更新

我看过很多墓碑读物，也许它与高CPU使用率有关？我认为它是关于数据模型设计的

CREATE TABLE ecoboost_visit.visit (
enterprise_id int,
id text,
app_name text,
app_version text,
appkey text,
browser_family text,
browser_version text,
browser_version_string text,
city text,
country text,
created_on timestamp,
device_brand text,
device_family text,
device_model text,
device_token text,
first_visit_page_domain_by_session text,
first_visit_page_source_by_session text,
first_visit_page_source_domain_by_session text,
first_visit_page_source_keyword_by_session text,
first_visit_page_source_url_by_session text,
first_visit_page_title_by_session text,
first_visit_page_url_by_session text,
ip text,
isp text,
net_type text,
os_category text,
os_family text,
os_language text,
os_timezone text,
os_version text,
os_version_string text,
platform text,
province text,
resolution text,
sdk_image_url text,
sdk_name text,
sdk_source text,
sdk_version text,
track_id text,
ua_string text,
PRIMARY KEY (enterprise_id, id)
) WITH CLUSTERING ORDER BY (id ASC)
AND bloom_filter_fp_chance = 0.1
AND caching = '{"keys":"ALL", "rows_per_partition":"0"}'
AND comment = ''
AND compaction = {'sstable_size_in_mb': '64', 'tombstone_threshold': '.2',     'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
AND compression = {'sstable_compression':   'org.apache.cassandra.io.compress.LZ4Compressor'}
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99.0PERCENTILE';

我使用此表来跟踪访问日志，每个ent表示一个网站

这是GC INFO

INFO  [Service Thread] 2016-04-02 07:38:16,554 GCInspector.java:278 -    ConcurrentMarkSweep GC in 225ms.  CMS Old Gen: 5640515840 -> 2868732344; Par Eden Space: 16464 -> 418333648; Par Survivor Space: 5774976 -> 3817304
INFO  [Service Thread] 2016-04-03 07:08:27,224 GCInspector.java:278 - ConcurrentMarkSweep GC in 209ms.  CMS Old Gen: 5637562768 -> 2887903056; Par Eden Space: 6704 -> 2306495144;
INFO  [Service Thread] 2016-04-06 06:34:18,908 GCInspector.java:278 - ConcurrentMarkSweep GC in 225ms.  CMS Old Gen: 5642735152 -> 3061550896; Par Eden Space: 8547280 -> 644954400; Par Survivor Space: 6253328 -> 2236696
INFO  [Service Thread] 2016-04-07 06:03:13,598 GCInspector.java:278 - ConcurrentMarkSweep GC in 221ms.  CMS Old Gen: 5638070792 -> 3173030976; Par Eden Space: 670736 -> 683574904; Par Survivor Space: 2089552 -> 2448848
INFO  [Service Thread] 2016-04-12 10:38:15,825 GCInspector.java:278 - ParNew GC in 7860ms.  CMS Old Gen: 5331043280 -> 5331554336; Par Eden Space: 2577006592 -> 0; Par Survivor Space: 2984416 -> 25906264

Answer 1

目前还不完全清楚发生了什么 - 看到nodetool tpstats的输出会让我们知道你当前正在运行的工作量（读重？写重？计数器？）。没有它，我们可以猜测：

如果您有一个节点错误的6，那么您的所有客户端都可能会以某种方式粘在该节点上。如果你有典型的RF = 3，你会发现3个节点行为不端（表示数据热点）。您的密钥空间的replication_factor是多少？

你有很多专栏。仅指出手指并说“这是错误的”是不够的，但这是相当有意义的。如果一次更新一列，则该架构可能有意义。如果您总是一次写一个完整的行，如果您将数据自己序列化为JSON或类似的blob，并将其写为不透明列，则可能会获得更好的性能。

当tombstone_threshold为0.2时，如果你被覆盖，你可能会经常重新压缩sstables。鉴于你的墓碑消息，我怀疑你正在创建一些墓碑 - 你的节点是否忙于压缩？什么是nodetool compactionstats说的？如果您正在忙于压缩，可以通过限制压缩吞吐量或减少concurrent_compactors的数量来调整它。

使用5.9GB压缩分区和2.6GB / s的堆分配，您可能会看到when Cassandra reads from a CQL partition, it has to deserialize the index segments to find the relevant parts of the partition for the slice you've requested。这样做会产生大量的垃圾 - 如果你正在使用ParNew / CMS，你会经常爆出新一代并且看到一个非常频繁的ParNew时间，因为你填充+升级到老一代，然后根据你有多少空间当你收集旧的垃圾时，你可以填写旧的并且看到非常长的收藏品，以便为随后的阅读中的下一组促销垃圾腾出空间。

在3.6中，在CASSANDRA-9754完成之前，你可能会看到stop-gap是暂时的。

Answer 2

我会查看你的内核版本。你可能会遇到here描述的java futex_wait错误。

Cassandra cpu用量很高

更新

2 个答案: