Wir sehen relativ lange Build-Zeiten auf unserem CI-Server (Hudson) und sie fangen an, uns in die Quere zu kommen. Ich bin mir bewusst, dass Hudson mehr als nur Maven aufruft und ich würde ihm gerne 10-20% mehr Zeit für den Job geben, aber eine Verlangsamung der Größenordnung scheint zu viel.
Wer weiß schon, warum das so ist und wie das Problem gelöst werden kann? Ich werde damit beginnen, zu sagen, was nicht die Ursache ist:
Die maven-Ziele sind buchstäblich sauber und installieren, nichts Schickes und ressourcenintensives wie javadoc, checkstyle usw. Wenn man sich die Ausgabe der hudson build task console anschaut, scheint es Verzögerungen zu geben, wenn "Vorherige Build-Nummer aus [unserem Nexus-Artefakt-Repository ] ", aber ich kenne keine einfache Möglichkeit, die Leistung dieses Schritts zu messen, und die Veröffentlichung eines Artefakts scheint zu einfach zu sein, um den gesamten Geschwindigkeitsunterschied zu rechtfertigen.
(Problem auch in diesem Thread)
Aktualisierung:
Wir haben Hudson / Jenkins auf die neueste Version aktualisiert und konnten das Timing-Plugin verwenden. Kurze Version:
Weitere Details
Bei einem unserer aktuellen Maven-Projekte (Maven-Build-Zeit: 3 min, Hudson-Build-Zeit: 9 min) konnten wir sehen, dass Hudson auch den Build in 3 min durchführt, aber dann 6 Minuten benötigt, um das Artefakt auf nexus hochzuladen.
Beim manuellen Upload eines anderen Artefakts über die Web-Benutzeroberfläche von nexus konnte ich Folgendes bestätigen:
<nexusworkdir>/nexus/storage/test/test2/test2/1.0.0/test2-1.0.0.rpm
Der wahre Puzzler ist der Grund, warum Nexus eine Minute braucht, um diese Datei zu erstellen:
<nexusworkdir>/nexus/proxy/attributes/test/test2/test2/1.0.0/test2-1.0.0.rpm
Soweit ich das beurteilen kann, berechnet es einfach eine MD5- und SHA1-Signatur und zeichnet allgemeine Artefakt-Informationen auf, aber md5sum und sha1sum einer 75MB-Datei brauchen & lt; 1s zum Ausführen ...
Schließlich scheint es kein Netzwerk-Timeout zu sein, da die Verzögerung in etwa proportional zur Artefaktgröße ist.
Jede Idee, was ein Nexus macht, nachdem er ein Artefakt erhalten hat, wird geschätzt.
Update 2 :
Wenn die nexus log level auf debug gesetzt wird, protokolliert nexus folgendes, wenn ein Artefakt hochgeladen wird:
%Vor%o.s.n.p.s.l.f.Defau ~ - Stream mit Puffergröße von: 4096
%Vor%- RESPONSE /nexus/content/groups/public/org/python/jython/2.5.2/jython-2.5.2.jar 200
%Vor%- REQUEST /nexus/content/groups/public/org/python/jython/2.5.2/jython-2.5.2.jar.sha1 auf
%Vor%- RESPONSE /nexus/content/groups/public/org/python/jython/2.5.2/jython-2.5.2.jar.sha1 200
%Vor%- REQUEST /nexus/content/groups/public/.index/nexus-maven-repository-index.properties auf org.mortbay.jetty.HttpConnection@141a720
%Vor%o.s.n.p.m.m.M2Group ~ - öffentlich retrieveItem () :: GEFUNDEN public: /. index / nexus-maven-repository-index.properties
%Vor%- RESPONSE /nexus/content/groups/public/.index/nexus-maven-repository-index.properties 200
%Vor%o.s.n.p.a.DefaultAt ~ - Attribute speichern auf UID = test: /test/test/1.0.1/test-1.0.1.rpm
%Vor%- Servlethalter = Nexus
%Vor%- ANTWORT /nexus/ext-2.3/resources/images/default/window/icon-info.gif 200
%Vor%- REQUEST / nexus / service / local / log / config auf org.mortbay.jetty.HttpConnection@1dbd88f ....
Es scheint nur eine Minute oder so zu sitzen und dann mit seiner Arbeit fortzufahren. Jede Idee, warum Nexus dies zu schätzen weiß.
Wie in dem Thread besprochen, vermute ich, dass Ihr gegabeltes Maven die JVM-Parameter nicht übergibt. Kannst du jconsole verwenden, um zu überprüfen, ob der maximal erlaubte Heapspeicher das ist, was du in deinem MAVEN_OPTS zugewiesen hast?
Macht es einen Unterschied, ob Sie Hudson als Dienst starten oder Hudson von der Befehlszeile aus starten?
Aktualisieren :
Die Bereitstellung auf Nexus erfordert viel RAM, viel mehr als das Kompilieren (meiner Erfahrung nach). Das Austauschen von wenig Speicher könnte das verlangsamen.
Tags und Links jenkins performance nexus maven-2 hudson