32

I am using Gradle 2.5 to compile a Java project which consists of 5 modules. In order to speed things up I also use the gradle-daemon. However, During compilation there are up to 18 instances of the gradle-daemon running. After compilation finishes there are still 15 instances of the daemon left. The daemons process consumes about 600 MB of RAM. Is it normal to have that many daemons running in the background or is the gradle-daemon misconfigured?

UPDATE: My operating system is Debian Jessie. Java version is Oracle Java 8.

Will
  • 24,082
  • 14
  • 97
  • 108
  • 2
    No it is not normal. How are you launching your build? From CLI or Android Studio? – Antoniossss Dec 16 '15 at 14:52
  • I am using the CLI. The command I issue is "./gradlew build" –  Dec 16 '15 at 15:02
  • Then I am not sure if you are using daemon - this should be set gradle's global config to use deamon and ommit `daemon` parameter. Try `./gradle build --daemon` – Antoniossss Dec 16 '15 at 15:09
  • 1
    I have the following content in my $HOME/.gradle/gradle.properties file: "org.gradle.daemon=true". Whenever I start a build after booting I get the message from gradle that subsequent builds will be faster because the daemon is now running. I can also see the daemon threads with "htop". I issued your command anyway after killing the daemon. Same behavior. Multiple daemon threads are started again and memory consumption by daemons is still ca. 600 mB. –  Dec 16 '15 at 15:17
  • That is odd, looks like everything is fine. In general new daemon is started when already running are "not compatible" whitch mainly means that build is ran with different JVM configuration (like max memory etc.) You should try to post a question on gradles support website https://discuss.gradle.org/ – Antoniossss Dec 16 '15 at 16:06

1 Answers1

34

Following Antoniossss' advice I got in touch with a developer. As it turns out, Gradle is in fact quite resource hungry. Even for a simple "Hello World" application the daemon might use very well up to 150 MB and maybe even more. It is also alright, that multiple daemon threads are started, as long as they run within the same JVM. There is only limited control on the user's side to control/limit memory usage. One could set GRADLE_OPTS variable in order to pass Xmx options to the JVM, e.g., I managed to build my Android project with following settings:

$ export GRADLE_OPTS="-Xmx64m -Dorg.gradle.jvmargs='-Xmx256m -XX:MaxPermSize=64m'"

The first -Xmx option is set for the Gradle that you start in CLI, the second one (after -Dorg.gradle.jvmargs) is the -Xmx value for the Gradle-Daemon.

The less memory you allow for your JVM the higher the risk for your build to fail - obviously. So you might have to tune those settings until they suit your purposes.

Those settings can also be set in the gradle.properties file.

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
  • 8
    Thanks for this, but I disagree with "The less memory you allow for your JVM the higher the risk for your build to fail - obviously." - my build is failing because the build is taking too much memory and the Docker image is configured not to allow more. – mjaggard Feb 06 '18 at 08:57