Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 18 Aug 2016 03:48:20 +0000 (UTC)
From: "Nate McCall (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12950933.1458151909000.339873.1471492100755@Atlassian.JIRA>
In-Reply-To: <JIRA.12950933.1458151909000@Atlassian.JIRA>
References: <JIRA.12950933.1458151909000@Atlassian.JIRA> <JIRA.12950933.1458151909896@arcas>
Subject: [jira] [Commented] (CASSANDRA-11363) High Blocked NTR When
 Connecting
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 18 Aug 2016 03:48:23 -0000


    [ https://issues.apache.org/jira/browse/CASSANDRA-11363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15425867#comment-15425867 ] 

Nate McCall commented on CASSANDRA-11363:
-----------------------------------------

[~tjake] 
The patch was deployed running with the following setting:
{noformat}
-Dcassandra.max_queued_native_transport_requests=4096
{noformat}

After an hour of soaking in, it looks good so far:
{noformat}
Native-Transport-Requests         5         0       17738639         0                 0
{noformat}

On this particular cluster, the NTR all-time would start ticking up immediately (but sporadically) after a restart so the above is an excellent sign. The workload contains a large number of very small rows mixed read and write. 

There is no discernable impact on client latencies, nor with GC churn. If anything, both are marginally smaller. 

> High Blocked NTR When Connecting
> --------------------------------
>
>                 Key: CASSANDRA-11363
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11363
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Coordination
>            Reporter: Russell Bradberry
>            Assignee: T Jake Luciani
>         Attachments: cassandra-102-cms.stack, cassandra-102-g1gc.stack, max_queued_ntr_property.txt, thread-queue-2.1.txt
>
>
> When upgrading from 2.1.9 to 2.1.13, we are witnessing an issue where the machine load increases to very high levels (> 120 on an 8 core machine) and native transport requests get blocked in tpstats.
> I was able to reproduce this in both CMS and G1GC as well as on JVM 7 and 8.
> The issue does not seem to affect the nodes running 2.1.9.
> The issue seems to coincide with the number of connections OR the number of total requests being processed at a given time (as the latter increases with the former in our system)
> Currently there is between 600 and 800 client connections on each machine and each machine is handling roughly 2000-3000 client requests per second.
> Disabling the binary protocol fixes the issue for this node but isn't a viable option cluster-wide.
> Here is the output from tpstats:
> {code}
> Pool Name                    Active   Pending      Completed   Blocked  All time blocked
> MutationStage                     0         8        8387821         0                 0
> ReadStage                         0         0         355860         0                 0
> RequestResponseStage              0         7        2532457         0                 0
> ReadRepairStage                   0         0            150         0                 0
> CounterMutationStage             32       104         897560         0                 0
> MiscStage                         0         0              0         0                 0
> HintedHandoff                     0         0             65         0                 0
> GossipStage                       0         0           2338         0                 0
> CacheCleanupExecutor              0         0              0         0                 0
> InternalResponseStage             0         0              0         0                 0
> CommitLogArchiver                 0         0              0         0                 0
> CompactionExecutor                2       190            474         0                 0
> ValidationExecutor                0         0              0         0                 0
> MigrationStage                    0         0             10         0                 0
> AntiEntropyStage                  0         0              0         0                 0
> PendingRangeCalculator            0         0            310         0                 0
> Sampler                           0         0              0         0                 0
> MemtableFlushWriter               1        10             94         0                 0
> MemtablePostFlush                 1        34            257         0                 0
> MemtableReclaimMemory             0         0             94         0                 0
> Native-Transport-Requests       128       156         387957        16            278451
> Message type           Dropped
> READ                         0
> RANGE_SLICE                  0
> _TRACE                       0
> MUTATION                     0
> COUNTER_MUTATION             0
> BINARY                       0
> REQUEST_RESPONSE             0
> PAGED_RANGE                  0
> READ_REPAIR                  0
> {code}
> Attached is the jstack output for both CMS and G1GC.
> Flight recordings are here:
> https://s3.amazonaws.com/simple-logs/cassandra-102-cms.jfr
> https://s3.amazonaws.com/simple-logs/cassandra-102-g1gc.jfr
> It is interesting to note that while the flight recording was taking place, the load on the machine went back to healthy, and when the flight recording finished the load went back to > 100.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)