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

【问题标题】：Cassandra High client read request latency compared to local read latencyCassandra 与本地读取延迟相比，客户端读取请求延迟较高
【发布时间】：2018-04-15 14:07:13
【问题描述】：

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

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

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

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 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，两个值不应该彼此相似，因为不需要协调吗？我错过了什么吗？还有什么我可以检查的吗？

提前致谢。

【问题讨论】：

标签： cassandra cassandra-3.0

【解决方案1】：

@卢西亚诺

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

这些可以是协调器代码与读取路径中副本的存储引擎代码之间的任何内容。

例子可以是：

读取修复（与特定请求没有直接关系，与触发它的读取异步，但可能导致问题），
主机超时（和/或推测重试），
令牌识别失败（动态告密者根本跟不上），
GC 暂停，

查找每个主机的指标异常，与 GC 重叠，甚至尝试捕获一些较慢请求的跟踪，并调查它们是否在执行您对 C* 的期望（例如令牌感知）。

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

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

【讨论】：

我的答案不适合这里，见下文。

【解决方案2】：

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

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

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

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

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

【讨论】：

感谢您的回复。是的，我已经确认 TokenAwarePolicy 正在运行。我不知道这个指标，但我刚刚检查过它们确实是相同的（我已将这些指标添加到我原来的问题中）。考虑到 TokenAwarePolicy 看起来不错并且本地读取延迟如此之小，我如何检查协调员实际花费了这么多时间的任务有什么其他想法吗？
您好，我认为繁重的网络流量可能是造成瓶颈的主要因素，因为您的副本节点似乎工作正常（“正常”意味着 GC 没有跳跃并且读取延迟低于协调器延迟。）。我会告诉你我可以找到一些很好的指标来找出网络瓶颈。可能您已经阅读了以下文档，但是 datastax 的一个很好的文档描述了 TCP 设置中的调整技巧。 docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/…

【解决方案3】：

感谢您的回复，对于延迟回复您感到抱歉。

我发现的一件事是我们的集群有： dynamic_snitch_badness_threshold=0 在配置文件中。将其更改为默认值 (0.1) 对客户端请求延迟有很大帮助。

GC 似乎很稳定，即使在高负载下也是如此。暂停是恒定的（~10ms / sec），我没有看到尖峰（甚至没有完整的 gcs）。我们正在使用具有更大 Xmn (2.5GB) 的 CMS。

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

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

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

【讨论】：