根据缩放本地传输请求的研究,我已经配置了以下参数,应用程序似乎规模很好,但我不理解以下内容,
1)我已配置native_transport_max_threads: 256
根据我的理解,它提供并发请求处理,因此它应该等于核心总数,为什么它默认为128?
2)我将此值设置为-Dcassandra.max_queued_native_transport_requests=5192
增加这些值有什么问题?
谢谢,
哈利
答案 0 :(得分:3)
1)它可以协调的最大并发请求数,不一定是它所执行的请求数限制。此协调包括等待副本(由一致性级别确定)以返回数据。这不是主动工作,因此没有理由限制核心数量。
2)对您的应用程序施加的压力超过协调器配置为立即处理的压力将应用于协调器的内存中。这里的成本是系统可用的堆压力和内存,以及队列中的时间增加了延迟。
根据您的other question,我认为当您的数据模型/查询中出现问题时,您可能会过于专注于NTR阶段。如果增加那个队列没有帮助它可能不是原因。通常情况下,排队的NTR出现问题的唯一情况是,您同时抨击大量微小查询(通常多于一个客户端可以生成默认情况下每个主机的默认限制为1024)。这几乎是增加队列限制以平滑峰值的唯一方案。如果它没有帮助,那么使用proxyhistograms / tablehistograms / tablestats缩小表格并查询导致压力。如果不明显,可能与GC有关,或两者兼而有之。