sbt Assembly Aufgabe läuft langsam nach dem Hinzufügen einiger Abhängigkeiten

Question

Ich bin irgendwie neu in der Bereitstellung in scala und ich konfigurierte das sbt-assembly Plugin, alles hat gut funktioniert.

Vor einigen Tagen habe ich Hadoop, Funken und einige andere Abhängigkeiten hinzugefügt, dann wurde die assembly Aufgabe extrem langsam (8 bis 10 Minuten) und davor war es < 30s. Die meiste Zeit wird zum Generieren des Assembly-Jars verwendet (es dauert einige Sekunden, bis das JAR 1 MB groß wird).

Ich beobachtete, dass es viele Zusammenführungskonflikte gibt, die durch first Strategie gelöst werden. Beeinflusst dies die Geschwindigkeit der Montage?

Ich habe mit der Option -Xmx für sbt (add -Xmx4096m) gespielt, aber es hilft nicht.

Ich verwende 12.4 und sbt-assembly. Irgendwelche Vorschläge oder Hinweise zur Optimierung dieser Aufgabe?

Answer 1

So 0__ ‚s Kommentar liegt direkt an:

Haben Sie die Readme lesen. Es schlägt insbesondere vor, dass Sie die Einstellungen cacheUnzip und cacheOutput ändern können. Ich würde es versuchen.

cacheUnzip ist eine Optimierungsfunktion, aber cacheOutput ist nicht. Der Zweck von cacheOutput ist, dass Sie das identische Glas bekommen, wenn Ihre Quelle sich nicht geändert hat. Für manche Leute ist es wichtig, dass sich die Ausgabe-Gläser nicht unnötig ändern. Der Vorbehalt ist, dass es den SHA-1-Hash aller * .class-Dateien überprüft. So ist die readme sagt:

Wenn es eine große Anzahl von Klassendateien ist, diese eine lange Zeit

Von dem, was nehmen könnte ich sagen kann, Entpacken und Anwendung von Merge-Strategie nimmt zusammen etwa eine Minute oder zwei, aber die Überprüfung der SHA-1 scheint ewig zu dauern. Hier ist assembly.sbt, dass die Ausgabe-Cache schaltet sich aus:

import AssemblyKeys._ // put this at the top of the file 

assemblySettings 

mergeStrategy in assembly <<= (mergeStrategy in assembly) { (old) => { 
    case PathList("javax", "servlet", xs @ _*)   => MergeStrategy.first 
    case PathList("org", "apache", "commons", xs @ _*) => MergeStrategy.first // commons-beanutils-core-1.8.0.jar vs commons-beanutils-1.7.0.jar 
    case PathList("com", "esotericsoftware", "minlog", xs @ _*) => MergeStrategy.first // kryo-2.21.jar vs minlog-1.2.jar 
    case "about.html"         => MergeStrategy.rename 
    case x => old(x) 
    } 
} 

assemblyCacheOutput in assembly := false 

Die Montage in 58 Sekunden beendet nach der Reinigung und der zweite Lauf ohne Reinigung dauerte 15 Sekunden. Obwohl einige der Läufe auch 200+ Sekunden benötigten.

Mit Blick auf die Quelle, könnte ich wahrscheinlich optimieren cacheOutput, aber für den Moment, sollte das Ausschalten der Montage viel schneller.

bearbeiten:

Ich habe #96 Performance degradation when adding library dependencies auf diese Frage, zugegeben, und fügte hinzu, einige Korrekturen in sbt-assembly 0.10.1 für sbt 0,13.

sbt-assembly 0.10.1 verhindert Content-Hashing der entpackten Elemente der abhängigen Bibliotheksgläser. Es überspringt auch das JAR-Caching, das von sbt ausgeführt wird, da sbt-assembly die Ausgabe bereits zwischenspeichert.

Die Änderungen führen dazu, dass die Assembly-Task konsistenter ausgeführt wird. Unter Verwendung von Deps-Heavy Spark als Beispielprojekt wurde die Assembly-Task 15 Mal nach einem kleinen Quellenwechsel ausgeführt. sbt-assembly 0.10.0 dauerte 19 +/- 157 Sekunden (meistens innerhalb von 20 Sekunden, aber mehr als 150 Sekunden in 26% der Läufe). Auf der anderen Seite benötigte sbt-assembly 0.10.1 16 +/- 1 Sekunden.