[
https://issues.apache.org/jira/browse/CASSANDRA-10792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-10792:
----------------------------------------
Fix Version/s: (was: 3.2)
3.x
> Make warning level for count of partitions in unlogged BatchStatement
> configurable.
> -----------------------------------------------------------------------------------
>
> Key: CASSANDRA-10792
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10792
> Project: Cassandra
> Issue Type: Improvement
> Components: Coordination
> Environment: CentOS, JDK 1.7, cluster of servers with 32 CPU each.
> Reporter: Pawel Matras
> Priority: Minor
> Fix For: 3.x
>
>
> Currently mutations for only one partition are allowed in BatchStatement.
> This amount is hard coded and not configurable as e.g. batch size.
> General suggestion looks to be to consider multi partition unlogged batch
> statements as distributed anti pattern. As cure async inserts are proposed.
> Proposal might be OK if one consider only cassandra side of the system.
> If a complete system have to share the same hardware things does not look so
> obvious any more. When cassandra shares the same hardware with other also
> clustered components lots of small async inserts become another well known
> distributed anti pattern.
> In our case changing from unlogged batches to async inserts destabilize the
> system as async inserts require amounts of interrupts per second and context
> switches per second beyond what hardware can handle. With replica aware
> unlogged batches these parameters are at 40% of hardware limits and the
> system as a whole runs stable without visible hotspots (cassandra metrics
> looks almost the same on all nodes).
> Unfortunately latest versions (we switched from 2.0.6 to 2.2.1) of cassandra
> log lots of warnings of type "Unlogged batch covering NN partitions detected
> against table XXX...". I found two workarounds to avoid this warning. The one
> is to use logged batches. But they generate 20% more interrupts and context
> switches and 400% more network load. The other way is more a hack and uses
> filtering features of logging framework and suppresses the warning just
> before it get logged.
> So my suggestion is to allow users of cassandra to decide by configuration if
> they consider unlogged batches antipattern or not. This is partially done
> with the size of the batch, where size is configurable and not hardcoded to 5
> kB.
> It would be fine to stay consistent on this and let the user configure
> mutations for how many partitions to allow.
> Of course there are several other solutions possible here, probably more
> costly. E.g warning could be produced only if batch is not token/replica
> aware.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
