Java
Memory
To run Java on MOGON, you need to reserve much more memory than you think.
One example: Just calling java -version
with a specified maximum heap size (1GB in this example), you need to reserve sufficient memory or Java will not be able to run correctly.
#!/bin/bash
# for multithreaded JAVA programs it might(!) make sense to occupy a full node
#SBATCH -p short # MOGON I
#SBATCH -p smp # MOGON II
#SBATCH -A <mogon-project>
#SBATCH --mem=1800M
module load lang/Java
export MALLOC_ARENA_MAX=4
srun java -Xms1G -Xmx1G -version
Note that for larger heap sizes, you just need to keep the offset large enough. To use more CPUs, instruct your program accordingly and reserve them.
export MALLOC_ARENA_MAX=4
might be necessary to cope with the
memory allocation in glibc arenas
.CPU
As Java creates additional threads for JVM maintainance (e.g. garbage collection) it is advisable to reserve an additional core for the Java overhead. I.e., if you have a single-threaded Java application, you should reserve a second CPU slot by using the -c 2
option in your submission script to sbatch
.
Pointing JAVA applications to node local scratch directories
On our clusters all jobs are provided with a node local scratch directory: /localscratch/$SLURM_JOB_ID
. If a particular application does not allow this directory to be supplied on the command line, yet requires to write scratch files, the _JAVA_OPTIONS
allows to define the scratch directory anyway:
# put this in your job submission script to specify the local scratch directory
export _JAVA_OPTIONS="-Djava.io.tmpdir/localscratch/${SLURM_JOB_ID}/"