Nice :)
On Apr 18, 2013, at 6:43 AM, Mircea Markus <mmarkus(a)redhat.com> wrote:
Now the suite is forks a new process for each module. I've
complete the run with 128m MaxPerm.
On 20 Mar 2013, at 23:55, Sanne Grinovero wrote:
> Thanks Dan,
> with the following options it completed the build:
>
> MAVEN_OPTS=-server -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode
> -XX:+UseParNewGC -XX:+CMSClassUnloadingEnabled -XX:NewRatio=4 -Xss500k
> -Xmx16G -Xms1G -XX:MaxPermSize=700M -XX:HeapDumpPath=/tmp/java_heap
> -Djava.net.preferIPv4Stack=true -Djgroups.bind_addr=127.0.0.1
> -XX:ReservedCodeCacheSize=200M
> -Dlog4j.configuration=file:/opt/infinispan-log4j.xml
>
> Sanne
>
> On 20 March 2013 17:36, Manik Surtani <msurtani(a)redhat.com> wrote:
>>
>> On 20 Mar 2013, at 15:29, Adrian Nistor <anistor(a)redhat.com> wrote:
>>
>> I've also tried changing the fork mode of surefire from 'none' to
'once' and
>> the entire suite runs fine now on jvm 1.6 with 500mb MaxPermSize.
>> Previously I did not complete, 500mb was not enough.
>> Anyone knows why surefire was not allowed to fork?
>>
>> Haven't tried to analyze closely the heap yet but first thing I noticed is
>> 15% of it is occupied by 190000 ComponentMetadataRepo instances, which
>> probably is not the root cause of this issue, but is odd anyway :).
>>
>>
>> Yes, very odd. Do you also see 190000 instances of a
>> GlobalComponentRegistry?
>>
>>
>> On 03/20/2013 05:12 PM, Dan Berindei wrote:
>>
>> The problem is that we still leak threads in almost every module, and that
>> means we keep a copy of the core classes (and all their dependencies) for
>> every module. Of course, some modules' dependencies are already oversized,
>> so keeping only one copy is already too much...
>>
>> I admit I don't run the whole test suite too often either, but I recently
>> changed the Cloudbees settings to get rid of the OOM there. It uses about
>> 550MB of permgen by the end of the test suite, without
>> -XX:+UseCompressedOops. These are the settings I used:
>>
>> -server -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+UseParNewGC
>> -XX:+CMSClassUnloadingEnabled -XX:NewRatio=4 -Xss500k -Xms100m -Xmx900m
>> -XX:MaxPermSize=700M
>>
>>
>> Cheers
>> Dan
>>
>>
>>
>> On Wed, Mar 20, 2013 at 2:59 PM, Tristan Tarrant <ttarrant(a)redhat.com>
>> wrote:
>>>
>>> Sanne, turn on CompressedOops ? Still those requirements are indeed
>>> ridiculous.
>>>
>>> Tristan
>>>
>>> On 03/20/2013 01:27 PM, Sanne Grinovero wrote:
>>>> I'm testing master, at da5c3f0
>>>>
>>>> Just killed a run which was using
>>>>
>>>> java version "1.7.0_17"
>>>> Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
>>>> Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
>>>>
>>>> this time again an OOM (while I have 2GB !), last sign of life came
>>>> from the "Rolling Upgrade Tooling"
>>>>
>>>> I'm not going to merge/review any pull request until this works.
>>>>
>>>> Sanne
>>>>
>>>> On 20 March 2013 12:09, Mircea Markus <mmarkus(a)redhat.com> wrote:
>>>>> I've just run it on master and didn't get OOM. well I'm
using osx. Are
>>>>> you running it on master or a particular branch? Which module
crashes?
>>>>> e.g. pedro's ISPN-2808 adds quite some threads to the party -
that's
>>>>> the reason it hasn't been integrated yet.
>>>>>
>>>>> On 20 Mar 2013, at 11:40, Sanne Grinovero wrote:
>>>>>
>>>>>> Hi all,
>>>>>> after reviewing some pull requests, I'm since a couple of
days unable
>>>>>> to run the testsuite; since Anna's fixes affect many modules
I'm
>>>>>> trying to run the testsuite of the whole project, as we should
always
>>>>>> do but I admit I haven't done it in a while because of the
core module
>>>>>> failures.
>>>>>>
>>>>>> So I run:
>>>>>> $ mvn -fn clean install
>>>>>>
>>>>>> using -fn to have it continue after the core failures.
>>>>>>
>>>>>> First attempt gave me an OOM, was running with 1G heap.. I'm
pretty
>>>>>> sure this was good enough some months back.
>>>>>>
>>>>>> Second attempt slowed down like crazy, and I found a warning
about
>>>>>> having filled the code cache size, so doubled it to 200M.
>>>>>>
>>>>>> Third attempt: OutOfMemoryError: PermGen space! But I'm
running with
>>>>>> -XX:MaxPermSize=380M which should be plenty?
>>>>>>
>>>>>> This is :
>>>>>> java version "1.6.0_43"
>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_43-b01)
>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 20.14-b01, mixed mode)
>>>>>>
>>>>>> MAVEN_OPTS=-Xmx2G -XX:MaxPermSize=380M -XX:+TieredCompilation
>>>>>> -Djava.net.preferIPv4Stack=true -Djgroups.bind_addr=127.0.0.1
>>>>>> -XX:ReservedCodeCacheSize=200M
>>>>>> -Dlog4j.configuration=file:/opt/infinispan-log4j.xml
>>>>>>
>>>>>> My custom log configuration just disables trace & debug.
>>>>>>
>>>>>> Going to try now with larger PermGen and different JVMs but it
looks
>>>>>> quite bad.. any other suggestion?
>>>>>> (I do have the security limits setup properly)
>>>>>>
>>>>>> Sanne
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> infinispan-dev(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>> Cheers,
>>>>> --
>>>>> Mircea Markus
>>>>> Infinispan lead (
www.infinispan.org)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> --
>> Manik Surtani
>> manik(a)jboss.org
>>
twitter.com/maniksurtani
>>
>> Platform Architect, JBoss Data Grid
>>
http://red.ht/data-grid
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (
www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev