Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 71329 invoked from network); 12 Dec 2010 16:22:19 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 12 Dec 2010 16:22:19 -0000 Received: (qmail 43481 invoked by uid 500); 12 Dec 2010 16:22:16 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 43467 invoked by uid 500); 12 Dec 2010 16:22:16 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 43459 invoked by uid 99); 12 Dec 2010 16:22:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 12 Dec 2010 16:22:16 +0000 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jbellis@gmail.com designates 74.125.83.172 as permitted sender) Received: from [74.125.83.172] (HELO mail-pv0-f172.google.com) (74.125.83.172) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 12 Dec 2010 16:22:11 +0000 Received: by pvc21 with SMTP id 21so1278849pvc.31 for ; Sun, 12 Dec 2010 08:21:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=sKWttNgw1tafhNbMDHbxYgvRHK7WWIPxjrfxWClZcow=; b=mi3IUW2oqbLAb52CfMCmut1LMQYyGpVk+GZvQqBTNp2BnHOemoXshN+gZN1POYXcod DdWmdfJWrJYyk36iS4KF8QO6geOt6e3wuJpJt6mcJXNl7rtOzjQo5BrtDkoq5GHPNVVh rSGqQw1QNPqHGhtbhmT0KpHQDKftqqKSA1Tqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=q7knBf+jqSaH4dxrFn3jQ7ETdojP8xmMs8d/Hm9whtB5HWdvqVojBs4QC1Rzi1gMvG lCLhXJYpXcM6NEW3YteKFSyItwXtWdi+GV2hAXOG5juDyzXUsiOy5dNLVCrO2UlXntk6 cYUcVi/si5uoAE4q4nanv8TI2UNpGpUsgS0RE= MIME-Version: 1.0 Received: by 10.143.41.7 with SMTP id t7mr2408387wfj.102.1292170910263; Sun, 12 Dec 2010 08:21:50 -0800 (PST) Received: by 10.142.223.4 with HTTP; Sun, 12 Dec 2010 08:21:50 -0800 (PST) In-Reply-To: <43B93B23-D289-481A-8C69-8BCB866ADFF9@toptarif.de> References: <43B93B23-D289-481A-8C69-8BCB866ADFF9@toptarif.de> Date: Sun, 12 Dec 2010 10:21:50 -0600 Message-ID: Subject: Re: Memory leak with Sun Java 1.6 ? From: Jonathan Ellis To: user Content-Type: multipart/alternative; boundary=001636e0b34c186ba1049738fcba --001636e0b34c186ba1049738fcba Content-Type: text/plain; charset=ISO-8859-1 http://www.riptano.com/docs/0.6/troubleshooting/index#nodes-are-dying-with-oom-errors On Sun, Dec 12, 2010 at 9:52 AM, Timo Nentwig wrote: > > On Dec 10, 2010, at 19:37, Peter Schuller wrote: > > > To cargo cult it: Are you running a modern JVM? (Not e.g. openjdk b17 > > in lenny or some such.) If it is a JVM issue, ensuring you're using a > > reasonably recent JVM is probably much easier than to start tracking > > it down... > > I had OOM problems with OpenJDK, switched to Sun/Oracle's recent 1.6.0_23 > and...still have the same problem :-\ Stack trace always looks the same: > > java.lang.OutOfMemoryError: Java heap space > at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57) > at java.nio.ByteBuffer.allocate(ByteBuffer.java:329) > at > org.apache.cassandra.utils.FBUtilities.readByteArray(FBUtilities.java:261) > at > org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:76) > at > org.apache.cassandra.db.ColumnSerializer.deserialize(ColumnSerializer.java:35) > at > org.apache.cassandra.db.ColumnFamilySerializer.deserializeColumns(ColumnFamilySerializer.java:129) > at > org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:120) > at > org.apache.cassandra.db.RowMutationSerializer.defreezeTheMaps(RowMutation.java:383) > at > org.apache.cassandra.db.RowMutationSerializer.deserialize(RowMutation.java:393) > at > org.apache.cassandra.db.RowMutationSerializer.deserialize(RowMutation.java:351) > at > org.apache.cassandra.db.RowMutationVerbHandler.doVerb(RowMutationVerbHandler.java:52) > at > org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:63) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:636) > > I'm writing from 1 client with 50 threads to a cluster of 4 machines (with > hector). With QUORUM and ONE 2 machines quite reliably will soon die with > OOM. What may cause this? Won't cassandra block/reject when memtable is full > and being flushed to disk but grow and if flushing to disk isn't fast enough > will run out of memory? -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com --001636e0b34c186ba1049738fcba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable http://www.riptano.com/docs/0.6/troubleshooting/inde= x#nodes-are-dying-with-oom-errors

On = Sun, Dec 12, 2010 at 9:52 AM, Timo Nentwig <timo.nentwig@toptarif.de> w= rote:

On Dec 10, 2010, at 19:37, Peter Schuller wrote:

> To cargo cult it: Are you running a modern JVM? (Not e.g. openjdk b17<= br> > in lenny or some such.) If it is a JVM issue, ensuring you're usin= g a
> reasonably recent JVM is probably much easier than to start tracking > it down...

I had OOM problems with OpenJDK, switched to Sun/Oracle's recent = 1.6.0_23 and...still have the same problem :-\ Stack trace always looks the= same:

java.lang.OutOfMemoryError: Java heap space
=A0 =A0 =A0 =A0at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java= :57)
=A0 =A0 =A0 =A0at java.nio.ByteBuffer.allocate(ByteBuffer.java:329)
=A0 =A0 =A0 =A0at org.apache.cassandra.utils.FBUtilities.readByteArray(FBU= tilities.java:261)
=A0 =A0 =A0 =A0at org.apache.cassandra.db.ColumnSerializer.deserialize(Col= umnSerializer.java:76)
=A0 =A0 =A0 =A0at org.apache.cassandra.db.ColumnSerializer.deserialize(Col= umnSerializer.java:35)
=A0 =A0 =A0 =A0at org.apache.cassandra.db.ColumnFamilySerializer.deseriali= zeColumns(ColumnFamilySerializer.java:129)
=A0 =A0 =A0 =A0at org.apache.cassandra.db.ColumnFamilySerializer.deseriali= ze(ColumnFamilySerializer.java:120)
=A0 =A0 =A0 =A0at org.apache.cassandra.db.RowMutationSerializer.defreezeTh= eMaps(RowMutation.java:383)
=A0 =A0 =A0 =A0at org.apache.cassandra.db.RowMutationSerializer.deserializ= e(RowMutation.java:393)
=A0 =A0 =A0 =A0at org.apache.cassandra.db.RowMutationSerializer.deserializ= e(RowMutation.java:351)
=A0 =A0 =A0 =A0at org.apache.cassandra.db.RowMutationVerbHandler.doVerb(Ro= wMutationVerbHandler.java:52)
=A0 =A0 =A0 =A0at org.apache.cassandra.net.MessageDeliveryTask.run(Message= DeliveryTask.java:63)
=A0 =A0 =A0 =A0at java.util.concurrent.ThreadPoolExecutor.runWorker(Thread= PoolExecutor.java:1110)
=A0 =A0 =A0 =A0at java.util.concurrent.ThreadPoolExecutor$Worker.run(Threa= dPoolExecutor.java:603)
=A0 =A0 =A0 =A0at java.lang.Thread.run(Thread.java:636)

I'm writing from 1 client with 50 threads to a cluster of 4 machines (w= ith hector). With QUORUM and ONE 2 machines quite reliably will soon die wi= th OOM. What may cause this? Won't cassandra block/reject when memtable= is full and being flushed to disk but grow and if flushing to disk isn'= ;t fast enough will run out of memory?



--
Jonathan Ellis
Project Chair, Apa= che Cassandra
co-founder of Riptano, the source for professional Cassand= ra support
http://riptano.com
--001636e0b34c186ba1049738fcba--