Continuous mode eating too much memory

I notice that running gradle task in continuous mode, after some time (~2h) eat too much memory.
I have couple project connected by deploying different library, and one project depending on them, and when I change something on some of them, than everything necessary is automatically builded, which is really nice feature.

But after some time, consumption of memory is to huge (check screenshot).

Interesting is that red one is triggered most often, I did changes mostly on that continuous build.

1 Like

Could you share heap dumps of the processes that use a lot of memory?
I’d suggest creating dumps of all live objects with this command:

jmap -dump:live,format=b,file=heapdump_file.hprof [pid]
# gzip dump file
gzip heapdump_file.hprof

Make sure that you don’t accidentially share sensitive information like passwords or other credentials in the heap dump files.

gists are handy for sharing the dump files. After creating a new gist on github (add a readme file in the UI), clone it with git cli, add the dump files to the cloned gist repo and push the changes. There are also scripts that automate this.

It might be expected behaviour that the memory usage is what you are experiencing. The default maximum heap size for the Gradle daemon client and daemon is 1024 MB. There are also separate Java processes for the Compiler daemons and test runners.

You could adjust the JVM options to optimize for low memory usage by lowering the daemon client JVM’s max heap size to something like 200MB.

export GRADLE_OPTS="-Xmx200m -Dorg.gradle.jvmargs='-Xmx1024m -XX:MaxPermSize=256m'"
You can omit the MaxPermSize setting on Java 8+.

The memory of compiler daemons can be configured with something like this:

    allprojects {
        tasks.withType(JavaCompile) {
            options.forkOptions.memoryMaximumSize = '512m'
        }
    
        tasks.withType(GroovyCompile) {
            groovyOptions.forkOptions.memoryMaximumSize = '512m'
        }
    }

IIRC, the Java compiler doesn’t fork by default.

Changing JVM options helped. Now the size is simnifically reduced.

If you still need I can add heapdump?

Ok, great that it helped. I think we don’t need the heapdumps this time. Thanks for reporting the problem.