与本地读取延迟相比，Cassandra客户端读取请求延迟较高

我们有一个20节点的Cassandra集群，运行大量读取请求（峰值约900k/sec）。我们的数据集相当小，所以一切都是直接从内存（OS页面缓存）提供的。我们的数据模型非常简单（只是一个键/值），所有读取都是在一致性级别1（RF 3）下执行的

我们将Java Datastax驱动程序与TokenAwarePolicy一起使用，因此所有读取操作都应该直接转到具有请求数据的一个节点

这些是从其中一个节点提取的有关客户端读取请求延迟和本地读取延迟的一些度量

org_apache_cassandra_metrics_ClientRequest_50thPercentile{scope="Read",name="Latency",} 105.778
org_apache_cassandra_metrics_ClientRequest_95thPercentile{scope="Read",name="Latency",} 1131.752
org_apache_cassandra_metrics_ClientRequest_99thPercentile{scope="Read",name="Latency",} 3379.391
org_apache_cassandra_metrics_ClientRequest_999thPercentile{scope="Read",name="Latency",} 25109.16

org_apache_cassandra_metrics_Keyspace_50thPercentile{keyspace=“<keyspace>”,name="ReadLatency",} 61.214
org_apache_cassandra_metrics_Keyspace_95thPercentile{keyspace="<keyspace>",name="ReadLatency",} 126.934
org_apache_cassandra_metrics_Keyspace_99thPercentile{keyspace="<keyspace>",name="ReadLatency",} 182.785
org_apache_cassandra_metrics_Keyspace_999thPercentile{keyspace="<keyspace>",name="ReadLatency",} 454.826

org_apache_cassandra_metrics_Table_50thPercentile{keyspace="<keyspace>",scope="<table>",name="CoordinatorReadLatency",} 105.778
org_apache_cassandra_metrics_Table_95thPercentile{keyspace="<keyspace>",scope="<table>",name="CoordinatorReadLatency",} 1131.752
org_apache_cassandra_metrics_Table_99thPercentile{keyspace="<keyspace>",scope="<table>",name="CoordinatorReadLatency",} 3379.391
org_apache_cassandra_metrics_Table_999thPercentile{keyspace="<keyspace>",scope="<table>",name="CoordinatorReadLatency",} 25109.16

可以看出，每个节点中的读取速度都非常快，99.9%小于0.5毫秒。但是，客户端请求延迟要高得多，在99%的节点上超过4毫秒。如果我阅读CL ONE并使用TokenAwarePolicy，这两个值是否应该彼此相似，因为不需要协调？我错过什么了吗？还有什么我可以查一下的吗

提前谢谢。

@luciano

协调器和副本可以报告不同的第99百分位读取延迟的原因有很多，即使在客户端配置了令牌感知

这些可以是在读取路径中从协调器代码到复制副本的存储引擎代码之间显示的任何内容

例如：

• 读取修复（与特定请求没有直接关系，因为与触发它的读取是异步的，但可能会导致问题）
• 主机超时（和/或推测性重试）
• 令牌感知故障（动态告密根本无法跟上）
• GC暂停

查找每台主机的指标异常，与GC重叠，甚至尝试捕获一些较慢请求的跟踪，并调查它们是否完成了您从C*中期望的所有操作（例如令牌感知）

经过良好调整和规范的集群也可能见证动态告密者根本无法跟上并完成其预期的工作。在这种情况下，禁用dynamic snitch可以修复高端读取百分比的高延迟。看

---

但是要小心，测量并确认假设，因为错误应用的解决方案很容易产生负面影响

谢谢您的回复，很抱歉延迟回复

我发现我们的集群有： 动态\u告密\u不良\u阈值=0 在配置文件中。将其更改为默认值（0.1）在客户端请求延迟方面有很大帮助

GC似乎是稳定的，即使在高负载下也是如此。暂停是恒定的（约10毫秒/秒），我没有看到尖峰（甚至没有完整的地面军事系统）。我们使用的CMS具有更大的Xmn（2.5GB）

读取修复一直都在发生（我们将其设置为10%的几率），因此当系统处理800k rec/秒时，我们会在后台发生约80k读取修复/秒

似乎我们对20台机器集群的要求太高了。从客户机的角度来看，延迟在800k qps之前是相当稳定的，之后开始有一点尖峰，但仍然在一个可管理的阈值之下

---

感谢所有的提示，动态告密真的很有帮助

即使使用TokenAwarePolicy，当驱动程序不知道哪个分区键是时，驱动程序也无法使用该策略

如果您使用的是简单语句，则不提供路由信息。因此，您需要通过调用setRoutingKey向驱动程序提供更多信息

DataStax Java驱动程序手册是一个好朋友。

如果TokenAware工作正常，CoordinatorReadLatency值与ReadLatency值基本相同。你也应该检查一下

---

我的答案不适合这里，请参见下文。谢谢您的回复。是的，我已经确认TokenAwarePolicy正在运作。我不知道这个指标，但我刚刚检查了一下，它们确实是相同的（我已经将这些指标添加到我的原始问题中）。考虑到TokenAwarePolicy看起来很好，本地读取延迟也很小，我如何检查协调器实际花费了这么多时间的任务呢？您好，我认为繁重的网络流量可能是瓶颈的主要因素，因为您的副本节点似乎工作得很好（“很好”）表示GC未跳转，读取延迟低于协调器延迟。）。我会告诉你们，我可以找到一些很好的指标来找出网络瓶颈。您可能已经阅读了以下文档，但下面是datastax提供的一个很好的文档，介绍了TCP设置中的tuing技巧。

Bloom filter false positives: 27574
Bloom filter false ratio: 0.00000
Bloom filter space used: 
Bloom filter off heap memory used: 6760992