cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominic Letz (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8559) OOM caused by large tombstone warning.
Date Tue, 06 Jan 2015 02:49:35 GMT

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

Dominic Letz commented on CASSANDRA-8559:
-----------------------------------------

To qualify that a bit more, you are right [~slebresne] the deletionInfo() is the big one and
the fragment seen in the screenshot shows what is generated in DeletionInfo.toString(), and
the second 700mb string is what is generated from rangesAsString() and copied into the first.

So the huge dump is rather generated here in DeletionInfo: 

{code}
    private String rangesAsString()
    {
        assert !ranges.isEmpty();
        StringBuilder sb = new StringBuilder();
        CType type = (CType)ranges.comparator();
        assert type != null;
        Iterator<RangeTombstone> iter = rangeIterator();
        while (iter.hasNext())
        {
            RangeTombstone i = iter.next();
            sb.append("[");
            sb.append(type.getString(i.min)).append("-");
            sb.append(type.getString(i.max)).append(", ");
            sb.append(i.data);
            sb.append("]");
        }
        return sb.toString();
    }
{code}

Should this be limited to a maximum (e.g. 1000 ranges?)

> OOM caused by large tombstone warning.
> --------------------------------------
>
>                 Key: CASSANDRA-8559
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8559
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: 2.0.11 / 2.1
>            Reporter: Dominic Letz
>         Attachments: Selection_048.png
>
>
> When running with high amount of tombstones the error message generation from CASSANDRA-6117
can lead to out of memory situation with the default setting.
> Attached a heapdump viewed in visualvm showing how this construct created two 777mb strings
to print the error message for a read query and then crashed OOM.
> {code}
>         if (respectTombstoneThresholds() && columnCounter.ignored() > DatabaseDescriptor.getTombstoneWarnThreshold())
>         {
>             StringBuilder sb = new StringBuilder();
>             CellNameType type = container.metadata().comparator;
>             for (ColumnSlice sl : slices)
>             {
>                 assert sl != null;
>                 sb.append('[');
>                 sb.append(type.getString(sl.start));
>                 sb.append('-');
>                 sb.append(type.getString(sl.finish));
>                 sb.append(']');
>             }
>             logger.warn("Read {} live and {} tombstoned cells in {}.{} (see tombstone_warn_threshold).
{} columns was requested, slices={}, delInfo={}",
>                         columnCounter.live(), columnCounter.ignored(), container.metadata().ksName,
container.metadata().cfName, count, sb, container.deletionInfo());
>         }
> {code}



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

Mime
View raw message