Return-Path: Delivered-To: apmail-tomcat-dev-archive@www.apache.org Received: (qmail 68469 invoked from network); 4 May 2006 07:04:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 4 May 2006 07:04:19 -0000 Received: (qmail 87649 invoked by uid 500); 4 May 2006 07:04:12 -0000 Delivered-To: apmail-tomcat-dev-archive@tomcat.apache.org Received: (qmail 87607 invoked by uid 500); 4 May 2006 07:04:12 -0000 Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Developers List" Delivered-To: mailing list dev@tomcat.apache.org Received: (qmail 87591 invoked by uid 99); 4 May 2006 07:04:12 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 May 2006 00:04:12 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [64.39.31.158] (HELO zeus.atlassian.com) (64.39.31.158) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 May 2006 00:04:11 -0700 Received: (from jturner@localhost) by zeus.atlassian.com (8.12.11.20060308/8.11.6) id k4473oUL014550; Thu, 4 May 2006 02:03:50 -0500 X-Authentication-Warning: zeus.atlassian.com: jturner set sender to jefft@apache.org using -f Date: Thu, 4 May 2006 02:03:49 -0500 From: Jeff Turner To: dev@tomcat.apache.org Subject: Memory leak? (issues.apache.org) Message-ID: <20060504020349.I396@zeus.atlassian.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Hi, For the last few months, issues.apache.org/jira has been running out of memory about once a week. We've finally got it running in a profiler, and are seeing most of the memory (eg. 486 of 572Mb) used up by char[] buffers in BodyContentImpl. Here is a sample GC Root -> Object trace: char[16777218] cb of org.apache.jasper.runtime.BodyContentImpl [0] of org.apache.jasper.runtime.BodyContentImpl[7] outs of org.apache.jasper.runtime.PageContextImpl [86] of java.lang.Object[101] pool of org.apache.jasper.util.SimplePool pool of org.apache.jasper.runtime.JspFactoryImpl deflt of javax.servlet.jsp.JspFactory [57] of java.lang.Object[641] elementData of java.util.Vector classes of org.apache.catalina.loader.StandardClassLoader [Other] There seems to be a constantly increasing number of BodyContentImpl objects in the system: 1 May: 93 Objects (126Mb) 2 May: 107 Objects (263Mb) 3 May: 492 Objects (486MB) (the first two were taken directly after a full gc) It appears to be a case of this bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=37793 Perhaps this bug affects the ASF JIRA in particular (and not most people) because people occasionally request huge (20-30Mb) pages. There are 23 BodyContentImpls between 33Mb and 10Mb in the last dump, and due to the pooling, these all stick around taking up memory. Could anyone comment on this issue? Remy seemed to think it was 'as intended', and the bug is marked WONTFIX. I'm happy to provide yourkit memory dumps or access to the server if necessary. We're currently running 5.5.16. Thanks! Jeff --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org For additional commands, e-mail: dev-help@tomcat.apache.org