Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4F3C203C.20406@oracle.com>
Date: Wed, 15 Feb 2012 22:14:36 +0100
From: Kristian Waagan <kristian.waagan@oracle.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Quetion on out memory usage
References: <97EB699F861AD841B5908C7CA9C956560206542B173C@VSERVER1.canoga.com>
 <4F3BE6E3.7050207@sbcglobal.net> <4F3BF92C.6030607@oracle.com>
 <97EB699F861AD841B5908C7CA9C956560206542B1781@VSERVER1.canoga.com>
In-Reply-To: 
 <97EB699F861AD841B5908C7CA9C956560206542B1781@VSERVER1.canoga.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 15.02.2012 19:59, Bergquist, Brett wrote:
> Thanks for the reply Kristian.
>
> The ++HeapDumpOnOutOfMemoryError is of no use because up to now, I have not found any tool that can read the heap dump when the heap is configured to 8Gb.  I have tried with this before.

What about getting just the heap histogram?
I'm assuming it takes a while to fill the heap when it's 8 GB, so a 
script fetching the histogram every now and then may give us a clue to 
what's going on.


-- 
Kristian
>
> The stack traces when the " java.lang.OutOfMemoryError: GC overhead limit exceeded" is reported are in the Derby.log, so it is Derby that is trying to put "more stuff on the heap than what can fit there".   Note that Derby is running in its own JVM with an 8Gb heap.   The system actually has 32Gb of physical memory and the app server is constrained to 12Gb.
>
> I am in the process of getting the database back locally onto a test system.  I will probably turn down the heap size to 2Gb and try the query.  Maybe then a tool can analyze the heap.
>
> Again, I appreciate the response and will post what I find.
>
> Brett
>
> -----Original Message-----
> From: Kristian Waagan [mailto:kristian.waagan@oracle.com]
> Sent: Wednesday, February 15, 2012 1:28 PM
> To: derby-dev@db.apache.org
> Subject: Re: Quetion on out memory usage
>
> On 15.02.2012 18:09, Katherine Marsden wrote:
>> On 2/15/2012 8:45 AM, Bergquist, Brett wrote:
> <  snip>
>>> java.lang.OutOfMemoryError: GC overhead limit exceeded
>>>
>> I have not personally encountered the GC overhead limit, but google
>> search indicates it is related to the amount of time spent on garbage
>> collection ("too much") and can be overridden.
>> http://www.petefreitag.com/item/746.cfm
> I've seen this several times and for practical purposes I have always considered this the same as "Java heap space": for whatever reason you're trying to put more stuff on the heap than what can fit there.
>
>
> <  snip>
>>> The server is a Oracle M3000 and the Derby engine heap is setup to be
>>> 8Gb.
>>>
>> For a heap out of memory, I have seen occasional cases where  Derby's
>> estimate of whether it can sort in memory is wrong.   You'd need to
>> look at the plan and do some debugging with the actual query  if you
>> are able to reproduce to find out if that is the case here.
>>
> Not sure, but the code in impl/store/access/sort/MergeInserter may be relevant and a good starting point.
>
> If you're debugging this, it may be useful to specify -XX:+HeapDumpOnOutOfMemoryError (and possibly
> |-XX:HeapDumpPath=/your/dump/path).
>
> |