[
https://issues.apache.org/jira/browse/CASSANDRA-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13771739#comment-13771739
]
arnaud-lb commented on CASSANDRA-6056:
--------------------------------------
I can reproduce this with only UPDATES on two columns with small values
(timestamp, int). Those columns were previously null. The entire rows are
moderately small too, less than 200 bytes in average. This happens with only 4
concurrent queries after some times.
Attached a screenshot of jvisualvm's classes view:
[^jvisualvm-class-instances.png]
The table being updated looks like this:
{code}
id timeuuid primary key
str1 text
str2 text
str3 text
str4 text
time1 timestamp (the column being updated)
time2 timestamp (mostly null)
time3 timestamp (mostly null)
n int (the second column being updated)
time4 timestamp
time5 timestamp (mostly null)
{code}
Looking at CASSANDRA-5982, it could very well be related. I'm willing to try
with the fix applied, is this merged in any 2.0 branch?
> Heavy write load exhausts heap space
> ------------------------------------
>
> Key: CASSANDRA-6056
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6056
> Project: Cassandra
> Issue Type: Bug
> Environment: Debian, Cassandra 2.0
> Reporter: arnaud-lb
> Attachments: jvisualvm-class-instances.png
>
>
> Issuing many INSERT or UPDATE queries cause cassandra to exhaust the heap
> space in a few minutes. It then gets stuck in full GCs, failing to recover.
> Observed with the default config from Datastax Debian packages, with a 8GB
> heap. Query rate is around 35K queries per second, with 16 concurrent queries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
