【问题标题】:Cassandra Native Transport Request tuningCassandra 本机传输请求调优
【发布时间】:2018-10-31 04:13:44
【问题描述】:

根据研究扩展本机传输请求,我配置了以下参数,应用程序似乎可以扩展,但我不明白以下内容,

1)我配置了native_transport_max_threads: 256,据我了解它提供并发请求处理,所以应该等于核心总数吧,为什么默认为128?

2) 我将这个值设置为-Dcassandra.max_queued_native_transport_requests=5192 增加这些值有什么问题?

【问题讨论】:

    标签: cassandra cassandra-3.0


    【解决方案1】:

    1) 它可以协调的最大并发请求数,不一定限制它执行的请求数。这种协调包括诸如等待副本(由一致性级别决定)返回数据之类的事情。这不是积极的工作,因此没有理由限制核心数量。

    2) 向您的应用程序推送的背压超过了您的协调器配置为一次处理的数量,该压力正在应用到您的协调器的内存中。这里的成本是系统可用的堆压力和内存,以及排队等候的时间增加了您的延迟。

    根据您的other question,我认为您可能过于关注 NTR 阶段,而问题可能出在您的数据模型/查询中。如果增加该队列没有帮助,则可能不是原因。通常情况下,排队的 NTR 成为问题的唯一情况是您一次猛击大量微小查询(通常不止一个客户端可以进行,因为默认情况下每个主机有 1024 个默认限制)。这几乎是增加队列限制以消除尖峰的唯一情况。如果它没有帮助,那么使用 proxyhistograms/tablehistograms/tablestats 来缩小表格和查询造成压力的范围。如果它不明显,则可能是与 GC 相关的问题或两者兼而有之。

    【讨论】:

    • “我认为您可能过于关注 NTR 阶段,而问题可能出在您的数据模型/查询中。”我的想法完全正确。
    • @Chris Lohfink 我的 GC 不到 1.2 秒,所以它是正确的。将此参数设置为 -Dcassandra.max_queued_native_transport_requests=5192 有意义吗?根据您的评论,单个节点每个连接只能处理 1024 个限制
    • @Chris Lohfink 我也验证了数据模型和查询似乎都很好,根据 datastax 最佳数据建模
    • 从技术上讲,每个连接的飞行请求限制为 32k(或 64k?)(协议中的 seq_id),但驱动程序默认将其限制为 1k,因为此时更好地分布在其他连接上。最佳实践规则存在差距,因为它无法测试所有可能的问题,只能测试一些更常见的问题(我实际上写了其中一些:))。如果您通过增加队列大小来排除 NTR 作为问题,那么 GC 可以很好地排除。然后是时候开始看其他事情了。 5192 很好,如果再增加它也无济于事 - 它是症状而不是原因。
    • @ChrisLohfink 感谢您的解释,我试图理解最后一点,对于单节点中的一个写入请求,执行的 NTR 操作是什么?我试图理解为什么设置 256 和 5192 会缩放?
    猜你喜欢
    • 2018-10-30
    • 2017-01-09
    • 2015-12-04
    • 1970-01-01
    • 2014-02-08
    • 2019-05-04
    • 2011-06-07
    • 2015-08-21
    • 1970-01-01
    相关资源
    最近更新 更多