协调员从一个节点获得响应明显晚于其他节点

请帮我理解我错过了什么。我看到一个集群节点上奇怪的行为选择与LIMIT和ORDER BY DESC条款：协调员从一个节点获得响应明显晚于其他节点

SELECT cid FROM test_cf WHERE uid = 0x50236b6de695baa1140004bf ORDER BY tuuid DESC LIMIT 1000;

跟踪（仅部分）：

...
发送REQUEST_RESPONSE消息到/10.0.25.56 [MessagingService-Outgoing-/10.0.25.56] | 2016-02-29 22:17：25.117000 | 10.0.23.15 | 7862
将REQUEST_RESPONSE消息发送到/10.0.25.56 [MessagingService-Outgoing-/10.0.25.56] | 2016-02-29 22：17：25.136000 | 10.0.25.57 | 6283
将REQUEST_RESPONSE消息发送到/10.0.25.56 [MessagingService-Outgoing-/10.0.25.56] | 2016-02-29 22：17：38.568000 | 10.0.24.51 | 457931
...

10.0.25.56 - 协调器节点
10.0.23.15，10.0.24.51，10.0.25.57 - 与数据节点

协调员得到10.0.24.51 13秒响应晚于其他节点！为什么这么说？我该如何解决它？

行的分区键（UID = 0x50236b6de695baa1140004bf）的数量约为300

一切都很好，如果我们使用ORDER BY ASC（我们的集群顺序）或LIMIT值小于行数这个分区键。

Cassandra（v2.2.5）集群包含25个节点。每个节点容纳大约400Gb的数据。

集群放置在AWS中。节点均匀分布在VPC中的3个子网上。节点的实例类型为c3.4xlarge（16个CPU核心，30GB RAM）。我们使用EBS支持的存储（1TB GP SSD）。

KEYSPACE RF等于3

柱家族：

CREATE TABLE test_cf (
    uid blob, 
    tuuid timeuuid, 
    cid text, 
    cuid blob, 
    PRIMARY KEY (uid, tuuid) 
) WITH CLUSTERING ORDER BY (tuuid ASC) 
    AND bloom_filter_fp_chance = 0.01 
    AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}' 
    AND comment = '' 
    AND compaction ={'class':'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'} 
    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 = 86400 
    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';

nodetool gcstats（10.0.25.57）：

Interval (ms) Max GC Elapsed (ms)Total GC Elapsed (ms)Stdev GC Elapsed (ms) GC Reclaimed (MB)   Collections  Direct Memory Bytes 
    1208504     368    4559     73  553798792712     58    305691840

nodetool gcstats（10.0.23.15）：

Interval (ms) Max GC Elapsed (ms)Total GC Elapsed (ms)Stdev GC Elapsed (ms) GC Reclaimed (MB)   Collections  Direct Memory Bytes 
    1445602     369    3120     57  381929718000     38    277907601

nodetool gcstats（10.0.24。51）：

Interval (ms) Max GC Elapsed (ms)Total GC Elapsed (ms)Stdev GC Elapsed (ms) GC Reclaimed (MB)   Collections  Direct Memory Bytes 
    1174966     397    4137     69  1900387479552     45    304448986

来源

2016-02-29 Alexander D.

什么是RF？一致性是什么？该节点上还运行着什么（修复？压缩？）？ –

RF等于3. Consistensy等级ALL。没有其他的。 –

这可能是由于一批既有相关，而不是与卡桑德拉因素。

非卡桑德拉具体

怎样的硬件（CPU/RAM /磁盘类型（SSD v旋转）这个节点上比较其他节点？
如何配置网络？是此节点的流量比其它节点慢？你有节点之间的路由问题？
请问这个服务器上的负载比其他节点？

卡桑德拉具体

JVM是否正确配置？ GC运行比其他节点更频繁吗？请在此节点和其他节点上检查nodetool gcstats以进行比较。
最近是否在此节点上运行过压实？检查nodetool compactionhistory
磁盘上的文件是否损坏？
你是否检查过system.log，看它是否包含任何信息。

除了一般的Linux疑难解答我会建议你比较一些使用nodetool和具体的C *功能寻找差异：

https://docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsNodetool_r.html

来源

2016-03-01 13:54:33 bechbd

我添加了一些关于“非特定”和“特定”问题的信息。请解释一下，在“损坏的文件”中你是什么意思？这个关于sstables或fs的问题一般？我如何检查sstables？在cassandra/system.log中没有错误消息 –

根据上面的附加信息，我将推测此问题可能与子网之间的路由或EBS存储的延迟有关。 EBS支持的存储是NAS，因此预计会有高延迟。请在此处查看更多信息：http：//www.datastax.com/dev/blog/what-is-the-story-with-aws-storage – bechbd

协调员从一个节点获得响应明显晚于其他节点

回答

相关问题