0

I have submitted a sbatch job to SLURM.

#!/bin/bash
#SBATCH --job-name=freset_weighting
#SBATCH --output=freset.out
#SBATCH --error=freset.err
#SBATCH --time=120:00:00
#SBATCH --mem=32769
#SBATCH --mail-type=BEGIN
#SBATCH --mail-type=END

java -jar ~/FReSET/freset_0.1.jar -XX:-UseGCOverheadLimit -Xmx32g

The job stops with the following error:

Exception in thread "main" java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58)
Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
    at java.util.regex.Matcher.<init>(Matcher.java:207)
    at java.util.regex.Pattern.matcher(Pattern.java:885)
    at java.util.regex.Pattern.split(Pattern.java:994)
    at java.util.regex.Pattern.split(Pattern.java:1056)

The java process should have been started with the -XX:-UseGCOverheadLimit argument to avoid this error.

Cheers, Markus

markus
  • 57
  • 1
  • 8

1 Answers1

0

From the java usage

Usage:  java [-options] -jar jarfile [args...]
           (to execute a jar file)

so you should be specifying the options "-XX:-UseGCOverheadLimit -Xmx32g" before the "-jar myJar.jar"

java -XX:-UseGCOverheadLimit -Xmx32g -jar ~/FReSET/freset_0.1.jar

If you are getting this error though I would be concerned about what your program is doing to make the garbage collection work overtime like this. I would suggest doing some profiling to figure out what is causing so many temporary objects. This question has some answers about tuning, GC overhead limit exceeded.

Community
  • 1
  • 1
greedybuddha
  • 7,488
  • 3
  • 36
  • 50