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

Question

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

我们将JavaDatastax驱动程序与TokenAware策略一起使用，因此所有的读取都应该直接到达一个拥有请求数据的节点。

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

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

另一个重要的细节是，我们的大多数查询（~70%）都不会返回任何内容，也就是说，它们用于找不到的记录。因此，bloom过滤器在这里发挥着重要作用，它们似乎很好：

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

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

提前感谢。

Answer 1

谢谢你的回复，很抱歉耽误了回复。

我发现我们的集群在配置文件中有一个问题：dynamic_snitch_badness_threshold=0。将其更改为默认值（0.1）在客户端请求延迟方面有很大帮助。

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

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

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

感谢所有的提示，动态飞贼的东西真的很有帮助！

Answer 2

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

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

DataStax Java驱动程序手册是一个好朋友。http://docs.datastax.com/en/developer/java-driver/3.1/manual/load_balancing/#requirements

如果TokenAware是完美的工作，协调器ReadLatency值基本上是与ReadLatency值相同的值。您也应该检查它。

http://cassandra.apache.org/doc/latest/operating/metrics.html?highlight=coordinatorreadlatency

Answer 3

@卢西亚诺

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

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

例子可以是：

• 读取修复（与特定请求没有直接关系，因为与触发它的读取请求是异步的，但可能会导致问题），

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

经过良好调整和规范的集群也可能见证动态告密者根本无法跟上并完成其预期的工作。在这种情况下，禁用动态告密者可以修复高端读取百分比的高延迟。请参见https://issues.apache.org/jira/browse/CASSANDRA-6908

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