cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Motta (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-13810) Overload because of hint pressure + MVs
Date Fri, 01 Sep 2017 09:08:00 GMT


Paulo Motta updated CASSANDRA-13810:
    Component/s: Materialized Views

> Overload because of hint pressure + MVs
> ---------------------------------------
>                 Key: CASSANDRA-13810
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Materialized Views
>            Reporter: Tom van der Woerdt
>              Labels: materializedviews
> Cluster setup: 3 DCs, 20 Cassandra nodes each, all 3.0.14, with approx. 200GB data per
machine. Many tables have MVs associated.
> During some maintenance we did a rolling restart of all nodes in the cluster. This caused
a buildup of hints/batches, as expected. Most nodes came back just fine, except for two nodes.
> These two nodes came back with a loadavg of >100, and 'nodetool tpstats' showed a
million (not exaggerating) MutationStage tasks per second(!). It was clear that these were
mostly (all?) mutations coming from hints, as indicated by thousands of log entries per second
in debug.log :
> {noformat}
> DEBUG [SharedPool-Worker-107] 2017-08-27 13:16:51,098 - Failed
to apply hint
> java.util.concurrent.CompletionException: org.apache.cassandra.exceptions.WriteTimeoutException:
Operation timed out - received only 0 responses.
>     at java.util.concurrent.CompletableFuture.encodeThrowable(
>     at java.util.concurrent.CompletableFuture.completeThrowable(
>     at java.util.concurrent.CompletableFuture.uniAccept( ~[na:1.8.0_144]
>     at java.util.concurrent.CompletableFuture$UniAccept.tryFire(
>     at java.util.concurrent.CompletableFuture.postComplete(
>     at java.util.concurrent.CompletableFuture.completeExceptionally(
>     at org.apache.cassandra.db.Keyspace.applyInternal( ~[apache-cassandra-3.0.14.jar:3.0.14]
>     at org.apache.cassandra.db.Keyspace.lambda$applyInternal$0( ~[apache-cassandra-3.0.14.jar:3.0.14]
>     at java.util.concurrent.Executors$ ~[na:1.8.0_144]
>     at org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$
>     at ~[apache-cassandra-3.0.14.jar:3.0.14]
>     at ~[na:1.8.0_144]
> Caused by: org.apache.cassandra.exceptions.WriteTimeoutException: Operation timed out
- received only 0 responses.
>     ... 6 common frames omitted
> {noformat}
> After reading the relevant code, it seems that a hint is considered droppable, and in
the mutation path when the table contains a MV and the lock fails to acquire and the mutation
is droppable, it throws a WTE without waiting until the timeout expires. This explains why
Cassandra is able to process a million mutations per second without actually considering them
'dropped' in the 'nodetool tpstats' output.
> I managed to recover the two nodes by stopping handoffs on all nodes in the cluster and
reenabling them one at a time. It's likely that the hint/batchlog settings were sub-optimal
on this cluster, but I think that the retry behavior(?) of hints should be improved as it's
hard to express hint throughput in kb/s when the mutations can involve MVs.
> More data available upon request -- I'm not sure which bits are relevant and which aren't.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message