【发布时间】:2018-10-31 04:13:44
【问题描述】:
根据研究扩展本机传输请求,我配置了以下参数,应用程序似乎可以扩展,但我不明白以下内容,
1)我配置了native_transport_max_threads: 256,据我了解它提供并发请求处理,所以应该等于核心总数吧,为什么默认为128?
2) 我将这个值设置为-Dcassandra.max_queued_native_transport_requests=5192 增加这些值有什么问题?
【问题讨论】:
根据研究扩展本机传输请求,我配置了以下参数,应用程序似乎可以扩展,但我不明白以下内容,
1)我配置了native_transport_max_threads: 256,据我了解它提供并发请求处理,所以应该等于核心总数吧,为什么默认为128?
2) 我将这个值设置为-Dcassandra.max_queued_native_transport_requests=5192 增加这些值有什么问题?
【问题讨论】:
1) 它可以协调的最大并发请求数,不一定限制它执行的请求数。这种协调包括诸如等待副本(由一致性级别决定)返回数据之类的事情。这不是积极的工作,因此没有理由限制核心数量。
2) 向您的应用程序推送的背压超过了您的协调器配置为一次处理的数量,该压力正在应用到您的协调器的内存中。这里的成本是系统可用的堆压力和内存,以及排队等候的时间增加了您的延迟。
根据您的other question,我认为您可能过于关注 NTR 阶段,而问题可能出在您的数据模型/查询中。如果增加该队列没有帮助,则可能不是原因。通常情况下,排队的 NTR 成为问题的唯一情况是您一次猛击大量微小查询(通常不止一个客户端可以进行,因为默认情况下每个主机有 1024 个默认限制)。这几乎是增加队列限制以消除尖峰的唯一情况。如果它没有帮助,那么使用 proxyhistograms/tablehistograms/tablestats 来缩小表格和查询造成压力的范围。如果它不明显,则可能是与 GC 相关的问题或两者兼而有之。
【讨论】: