4:12 p.m.
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