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 <[email protected]> wrote: >> >> On 20 Mar 2013, at 15:29, Adrian Nistor <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 >>>>>> [email protected] >>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>>> Cheers, >>>>> -- >>>>> Mircea Markus >>>>> Infinispan lead (www.infinispan.org) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> infinispan-dev mailing list >>>>> [email protected] >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> [email protected] >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> -- >> Manik Surtani >> [email protected] >> twitter.com/maniksurtani >> >> Platform Architect, JBoss Data Grid >> http://red.ht/data-grid >> >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
