You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Edward Capriolo (JIRA)" <ji...@apache.org> on 2010/08/24 23:26:18 UTC
[jira] Created: (CASSANDRA-1426) Bring back RowWarningThresholdInMB
and set it low
Bring back RowWarningThresholdInMB and set it low
-------------------------------------------------
Key: CASSANDRA-1426
URL: https://issues.apache.org/jira/browse/CASSANDRA-1426
Project: Cassandra
Issue Type: New Feature
Affects Versions: 0.7 beta 1
Reporter: Edward Capriolo
The problem with big rows in 6.0 and 7.0 is they tend to cause OOM with row cache and other memory problems. CFStats shows us the MaximumSizedRow but it does not show which row this is. Applications that have to scan all the data on a node to turn up a big row are intensive and while they are running they lower cache hit rate significantly.
Even though Cassandra 7.0 can accommodate larger rows then 6.X, most use cases would never have rows that go over 2 MB.
Please consider bringing this feature back and setting it low. <RowWarningThresholdInMB>10</RowWarningThresholdInMB>. With this admins can monitor logs and point out large rows before they get out of hand and cause mysterious crashes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1426) Bring back
RowWarningThresholdInMB and set it low
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902103#action_12902103 ]
Jonathan Ellis commented on CASSANDRA-1426:
-------------------------------------------
$ grep memory.compaction conf/cassandra.yaml
in_memory_compaction_limit_in_mb: 64
> Bring back RowWarningThresholdInMB and set it low
> -------------------------------------------------
>
> Key: CASSANDRA-1426
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1426
> Project: Cassandra
> Issue Type: New Feature
> Affects Versions: 0.7 beta 1
> Reporter: Edward Capriolo
>
> The problem with big rows in 6.0 and 7.0 is they tend to cause OOM with row cache and other memory problems. CFStats shows us the MaximumSizedRow but it does not show which row this is. Applications that have to scan all the data on a node to turn up a big row are intensive and while they are running they lower cache hit rate significantly.
> Even though Cassandra 7.0 can accommodate larger rows then 6.X, most use cases would never have rows that go over 2 MB.
> Please consider bringing this feature back and setting it low. <RowWarningThresholdInMB>10</RowWarningThresholdInMB>. With this admins can monitor logs and point out large rows before they get out of hand and cause mysterious crashes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1426) Bring back
RowWarningThresholdInMB and set it low
Posted by "Edward Capriolo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902100#action_12902100 ]
Edward Capriolo commented on CASSANDRA-1426:
--------------------------------------------
I am for smarter row cache as well, as long as there is no other issues that large rows can cause. Just putting a scenario out there, getSlicing on a large row. OOM's are not the only problem. Any activity that does not OOM but causes a random GC/JVM pause. Those are thing things I worry about, one bad row spoiling the show :)
Sorry for a RTFM question but what size is the in-memory compaction threshold, and can it be changed on the user end?
> Bring back RowWarningThresholdInMB and set it low
> -------------------------------------------------
>
> Key: CASSANDRA-1426
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1426
> Project: Cassandra
> Issue Type: New Feature
> Affects Versions: 0.7 beta 1
> Reporter: Edward Capriolo
>
> The problem with big rows in 6.0 and 7.0 is they tend to cause OOM with row cache and other memory problems. CFStats shows us the MaximumSizedRow but it does not show which row this is. Applications that have to scan all the data on a node to turn up a big row are intensive and while they are running they lower cache hit rate significantly.
> Even though Cassandra 7.0 can accommodate larger rows then 6.X, most use cases would never have rows that go over 2 MB.
> Please consider bringing this feature back and setting it low. <RowWarningThresholdInMB>10</RowWarningThresholdInMB>. With this admins can monitor logs and point out large rows before they get out of hand and cause mysterious crashes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CASSANDRA-1426) Bring back
RowWarningThresholdInMB and set it low
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis resolved CASSANDRA-1426.
---------------------------------------
Resolution: Not A Problem
as mentioned on the ML, there is a similar warning logged in 0.7 for rows that exceed the in-memory compaction threshold:
logger.info(String.format("Compacting large row %s (%d bytes) incrementally",
FBUtilities.bytesToHex(rows.get(0).getKey().key), rowSize));
(Definitely in favor of a smarter cache, too, in principle.)
> Bring back RowWarningThresholdInMB and set it low
> -------------------------------------------------
>
> Key: CASSANDRA-1426
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1426
> Project: Cassandra
> Issue Type: New Feature
> Affects Versions: 0.7 beta 1
> Reporter: Edward Capriolo
>
> The problem with big rows in 6.0 and 7.0 is they tend to cause OOM with row cache and other memory problems. CFStats shows us the MaximumSizedRow but it does not show which row this is. Applications that have to scan all the data on a node to turn up a big row are intensive and while they are running they lower cache hit rate significantly.
> Even though Cassandra 7.0 can accommodate larger rows then 6.X, most use cases would never have rows that go over 2 MB.
> Please consider bringing this feature back and setting it low. <RowWarningThresholdInMB>10</RowWarningThresholdInMB>. With this admins can monitor logs and point out large rows before they get out of hand and cause mysterious crashes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-1426) Bring back
RowWarningThresholdInMB and set it low
Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902084#action_12902084 ]
Stu Hood commented on CASSANDRA-1426:
-------------------------------------
OOMs due to the rows in the row cache growing too large is probably the core problem: we should probably treat the disease rather than the symptom. If we could find a way to store partial rows in the row cache, we could enable it by default, and forget about OOMs.
> Bring back RowWarningThresholdInMB and set it low
> -------------------------------------------------
>
> Key: CASSANDRA-1426
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1426
> Project: Cassandra
> Issue Type: New Feature
> Affects Versions: 0.7 beta 1
> Reporter: Edward Capriolo
>
> The problem with big rows in 6.0 and 7.0 is they tend to cause OOM with row cache and other memory problems. CFStats shows us the MaximumSizedRow but it does not show which row this is. Applications that have to scan all the data on a node to turn up a big row are intensive and while they are running they lower cache hit rate significantly.
> Even though Cassandra 7.0 can accommodate larger rows then 6.X, most use cases would never have rows that go over 2 MB.
> Please consider bringing this feature back and setting it low. <RowWarningThresholdInMB>10</RowWarningThresholdInMB>. With this admins can monitor logs and point out large rows before they get out of hand and cause mysterious crashes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.