[
https://issues.apache.org/jira/browse/CASSANDRA-16071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235006#comment-17235006
]
Scott Carey edited comment on CASSANDRA-16071 at 11/18/20, 9:15 PM:
--------------------------------------------------------------------
On the other hand, maybe I'm the only one crazy enough to use this feature on
an LCS table with 500GB of data per node.
Yet, it absolutely obliterates the ordinary secondary indexing on a low to
moderate cardinality index and opens up use cases that are impossible without
it. I'm looking forward to the new secondary indexing feature that is being
designed that likewise uses a local index alongside an SSTable.
Sorry for the delay replying, I'm not getting email notifications at the moment.
Thanks for listening! I thought about submitting a patch but I don't have a
cassandra dev environment set up.
was (Author: scott_carey):
On the other hand, maybe I'm the only one crazy enough to use this feature on
an LCS table with 500GB of data per node.
> max_compaction_flush_memory_in_mb is interpreted as bytes
> ---------------------------------------------------------
>
> Key: CASSANDRA-16071
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16071
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SASI
> Reporter: Michael Semb Wever
> Assignee: Michael Semb Wever
> Priority: Normal
> Fix For: 4.0, 3.11.8, 4.0-beta2, 4.0-beta4, 3.11.10
>
>
> In CASSANDRA-12662, [~scottcarey]
> [reported|https://issues.apache.org/jira/browse/CASSANDRA-12662?focusedCommentId=17070055&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17070055]
> that the {{max_compaction_flush_memory_in_mb}} setting gets incorrectly
> interpreted in bytes rather than megabytes as its name implies.
> {quote}
> 1. the setting 'max_compaction_flush_memory_in_mb' is a misnomer, it is
> actually memory in BYTES. If you take it at face value, and set it to say,
> '512' thinking that means 512MB, you will produce a million temp files
> rather quickly in a large compaction, which will exhaust even large values of
> max_map_count rapidly, and get the OOM: Map Error issue above and possibly
> have a very difficult situation to get a cluster back into a place where
> nodes aren't crashing while initilaizing or soon after. This issue is minor
> if you know about it in advance and set the value IN BYTES.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
