GC overhead limit exceeded

[jqassistant]

GC overhead limit exceeded

[DirkMahler]

We have some reports that this happens sometimes but right now the pattern is unclear... Which version of jQA and the JRE/JDK are you using?

[ambition-consulting]

We got JDK jdk1.8.0_66 with jQA 1.5.0-RC-1 on our Jenkins Slaves

<!-- architectural constraints-->
<plugin>
	<groupId>com.buschmais.jqassistant</groupId>
	<artifactId>jqassistant-maven-plugin</artifactId>
               <version>1.5.0-RC-1</version>
	<executions>
		<execution>
			<phase>test</phase>
			<goals>
				<goal>scan</goal>
				<goal>analyze</goal>
			</goals>
			<configuration>
				<warnOnSeverity>MINOR</warnOnSeverity>
				<failOnSeverity>MAJOR</failOnSeverity>
				<storeLifecycle>MODULE</storeLifecycle>
			</configuration>
		</execution>
	</executions>
</plugin>

[DirkMahler]

I know the question is trivial: how much memory do you give your process to run (recommending 1GB+ due to having a fully fledged Neo4j "onboard")?
What's the OS where the problem is coming up? We've seen this problem in the last time only on a heavily loaded Linux (CentOS) machine.

[ambition-consulting]

yep, we give 1 GB XMX already - will give it a little more. Our slaves are CentOs or Debian based. Will check whether the error occured on CentOS here as well and come back to you next week.

[ambition-consulting]

We have tried various maven options to influence the gc, but ultimately gave up. Instead now we are just skipping on the problematic project.

[DirkMahler]

That's bad news... Just a question: is there anything specific about that module/project, e.g. large test data files?

[ambition-consulting]

it's a module about database migration.

[ambition-consulting]

I also get the same GC overhead problem on resetting (big) stores.

[DirkMahler]

Closing issue: reset and known expensive rules have been changed to use Neo4j's call in transactions functionality with jQA 2.0