高本机传输请求一直被阻止 [英] High Native-Transport-Requests All time Blocked

问题描述

在所有节点上运行tpstats之后。我看到很多节点的ALL TIME BLOCKED NTR数量很高。我们有一个4节点群集，并且NTR ALL TIME BLOCKED的值是：

After running tpstats on all nodes. I see a lot of nodes having high number of ALL TIME BLOCKED NTR. We have a 4 node cluster and the values for NTR ALL TIME BLOCKED are :

节点1：23953
节点2：2935
节点3： 15229
NODE 4：5951

NODE 1: 23953 NODE 2: 2935 NODE 3: 15229 NODE 4: 5951

我知道所有时间段都不好，因此担心自己在做什么。

I know ALL TIME BLOCKED is bad and hence worried as to what I am doing wrong.

推荐答案

此池处理cql请求，因此它是允许的活动CQL请求数。它的作用是防止过多的活动对象因OOM而无法对系统进行OOM处理（即，每一个都返回较大的Blob）。这将向客户端应用程序有效施加反压，以减慢速度。不幸的是，如果您的要求不高，那么这不是理想的选择，并且会影响您的吞吐量，因此在 CASSANDRA-11363 >他们添加了一个设置，以在小型突发性工作负载之间进行空间权衡。

This pool handles cql requests, so it is the number of active CQL requests allowed. Its limited to prevent too many active ones from OOMing your system (ie each returning large blobs). This effectively applies backpressure to your client application to slow down. Unfortunately if you have small requests this isnt ideal and hurts your throughput so in CASSANDRA-11363 they added a setting to make the space tradeoff for small bursty workloads.

如果升级到2.2.8+，则可以使用 -Dcassandra.max_queued_native_transport_requests = 4096

If you upgrade to 2.2.8+ you can set the max queue size of that threadpool with -Dcassandra.max_queued_native_transport_requests=4096

这篇关于高本机传输请求一直被阻止的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！