Hohe Speicherauslastung durch gradle daemon

Ich bin mit Gradle 2.5 kompilieren eines Java-Projekt besteht aus 5 Modulen. Um die Dinge zu beschleunigen benutze ich auch die gradle-daemon. Jedoch, Während der Kompilierung gibt es bis zu 18 Instanzen der gradle-daemon läuft. Nachdem die Kompilierung beendet ist, gibt es noch 15 Instanzen des daemon Links. Die Dämonen-Prozess verbraucht über 600 MB RAM. Ist es normal, dass viele daemons im hintergrund laufen oder ist das gradle-daemon falsch konfiguriert?

UPDATE:
Mein Betriebssystem ist Debian Jessie. Java-version von Oracle Java 8.

  • Nein, es ist nicht normal. Wie Sie starten Ihr bauen? Von CLI-oder Android Studio?
  • Ich bin mit dem CLI. Der Befehl, den ich Frage ist,". /gradlew build"
  • Dann bin ich nicht sicher, wenn Sie mit daemon - dieser sollte festgelegt werden, gradle global config zu verwenden Dämon und ommit daemon parameter. Versuchen ./gradle build --daemon
  • Ich habe den folgenden Inhalt in meinem $HOME/.gradle/gradle.Eigenschaften Datei: "org.gradle.daemon=true". Wenn ich einen build nach dem Booten bekomme ich die Meldung von gradle, die nachfolgenden builds werden schneller, weil der daemon läuft nun. Ich kann auch sehen, das daemon-threads mit "htop". Gab ich Ihr den Befehl trotzdem nach der Tötung der Dämon. Dasselbe Verhalten. Mehrere daemon-threads sind wieder gestartet und der Speicher Verbrauch von Dämonen ist noch ca. 600 mB.
  • Das ist merkwürdig, sieht aus wie alles in Ordnung ist. Im Allgemeinen new-daemon wird gestartet, wenn bereits ausgeführt, sind "nicht kompatibel" whitch vor allem bedeutet, dass der build lief mit verschiedenen JVM-Konfiguration (wie max-Speicher, etc.) Sie sollten versuchen, stellen Sie eine Frage in gradles support-website discuss.gradle.org
InformationsquelleAutor nautical | 2015-12-16
  1. 18

    Folgenden Antoniossss' Rat ich bekam in Kontakt mit einem Entwickler. Wie es sich herausstellt, Gradle ist in der Tat Recht Ressourcen-hungrig. Auch für ein einfaches "Hello World" - Anwendung der daemon verwenden könnte sehr gut bis zu 150 MB und vielleicht sogar noch mehr.
    Es ist auch in Ordnung, dass mehrere daemon-threads gestartet, so lange, wie Sie laufen, die innerhalb der gleichen JVM.
    Es gibt nur begrenzte Kontrolle über die Benutzer-Seite zu Steuern/begrenzen der Speicherauslastung.
    Könnte man GRADLE_OPTS variable, um pass Xmx Optionen der JVM, z.B. konnte ich bauen meine Android-Projekt mit folgenden Einstellungen:

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

    Ersten-Xmx option wird festgelegt, für die Gradle, dass Sie beginnen in der CLI, die zweite (nach -Dorg.gradle.jvmargs) ist die -Xmx-Wert für den Gradle Daemon.

    Weniger Speicher, den Sie damit für Ihre JVM-desto höher das Risiko für Ihren build fail - offensichtlich. So haben Sie vielleicht optimieren die Einstellungen, bis Sie für Ihre Zwecke anpassen.

    Diese Einstellungen können Sie auch in der gradle.Eigenschaften-Datei.

    • Vielen Dank für diese, aber ich Stimme nicht mit "weniger Speicher, den Sie damit für Ihre JVM-desto höher das Risiko für Ihren build zu scheitern - das ist ganz klar." mein build ist zu scheitern, weil das bauen nimmt zu viel Speicher und das Docker-image ist so konfiguriert, um zuzulassen, dass mehr.
    InformationsquelleAutor nautical
Schreibe einen Kommentar