cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] Resolved: (CASSANDRA-896) GC issues with LinkedBlockingQueue, very large heap sizes
Date Sun, 28 Mar 2010 02:13:27 GMT


Jonathan Ellis resolved CASSANDRA-896.

    Resolution: Won't Fix
      Assignee:     (was: Chris Goffinet)

[Chris adds that the pending operations for the messagingservice was 0, indicating that the
lower throughput was from reduced concurrency in ABQ vs LBQ rather than blocking from the
capped queue size.]

Let's wait for the JDK's fix, because going back to 0.5 ConcurrentLinkedQueue + manual locking
is likely to have the same concurrency characteristics as ABQ here.

You might be able to mitigate it by adding


to have it start full GC at 50% of heap...  at the cost of doing more GCs of course.

> GC issues with LinkedBlockingQueue, very large heap sizes
> ---------------------------------------------------------
>                 Key: CASSANDRA-896
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.6
>            Reporter: Chris Goffinet
>             Fix For: 0.6
>         Attachments: HeapMemoryLBQvsABQ.png, Screen shot 2010-03-14 at 10.19.09 PM.png,
Screen shot 2010-03-14 at 10.20.31 PM.png, WriteOpsLBQvsABQ.png
> We were doing a large import over thrift today (250M rows) with 50 columns each. We noticed
when this process started, that the heap usage slowly began to rise. Eventually hitting 10GB.
After investigating heap dumps we noticed this is linked to GC problems in the JVM for LinkedBlockingQueue.
Sending a hint through jconsole to perform GC didn't help either.
> See this article:
> JDK  1.6.18 doesn't have this fix yet either. We could possibly add the change from:

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message