Jenkins-Leistungsoptimierung: Ein umfassender Leitfaden zur Ressourcenverwaltung

Die Jenkins-Leistungsoptimierung beginnt normalerweise, nachdem die Leute bereits genervt sind: Pull-Requests warten in der Warteschlange, die UI zögert, Builds schlagen mit seltsamen Agent-Fehlern fehl oder der Controller benötigt einen weiteren Neustart. Die Lösung ist selten ein einzelnes magisches JVM-Flag. Jenkins ist ein Koordinator plus eine Flotte von Maschinen, die unordentliche Arbeit erledigen, daher ist die nützliche Optimierungsarbeit die Ressourcenverwaltung: CPU, Speicher, Festplatte, Netzwerk, Executors, Plugins, Aufbewahrung und Agent-Design.

Dieser Leitfaden konzentriert sich auf praktische Jenkins-Leistungsoptimierung für reale CI/CD-Systeme. Ziel ist es nicht, jeden letzten Benchmark-Punkt aus Jenkins herauszuholen. Ziel ist es, Builds vorhersagbar zu halten, den Controller gesund zu halten und deutlich zu machen, wo der nächste Engpass herkommt.

Verständnis des Jenkins-Ressourcenverbrauchs

Jenkins selbst, zusammen mit den Jobs, die es über Agents ausführt, verbraucht drei primäre Ressourcen: CPU-Zyklen, RAM und Festplatten-E/A. Leistungsengpässe treten oft auf, wenn diese Ressourcen unterdimensioniert, überbucht oder falsch konfiguriert sind.

1. CPU-Zuweisung und -Verwaltung

Die CPU-Verfügbarkeit wirkt sich direkt darauf aus, wie schnell Jenkins Aufgaben planen kann und wie schnell einzelne Builds ausgeführt werden. Fehlmanagement führt hier oft zu hohen Auslastungsdurchschnitten und spürbaren Verzögerungen.

Master- vs. Agent-CPU-Zuweisung

Es ist Standardpraxis, die schwere Arbeit (Kompilieren, Testen) an Jenkins-Agents zu delegieren, anstatt an den Jenkins-Controller. Ältere Dokumentationen bezeichnen diese möglicherweise als "Master" und "Slave"; die aktuellen Jenkins-Begriffe sind Controller und Agent. Der Controller sollte für Koordination, UI-Bereitstellung und API-Interaktionen reserviert sein.

Controller-Knoten: Ausreichend CPU zuweisen, um gleichzeitige Anfragen zu bewältigen, aber die Arbeitslast niedrig halten. Eine kleine oder mittlere Installation kann auf wenigen Kernen laufen, aber ausgelastete Controller benötigen Messung statt einer festen Regel.
Agent-Knoten: Diese sollten die meiste CPU-Leistung erhalten, skaliert basierend auf der erwarteten gleichzeitigen Build-Last.

Begrenzung der Executor-Slots

Eine der effektivsten Methoden zur Kontrolle der CPU-Konkurrenz ist die Begrenzung der Anzahl gleichzeitiger Builds.

Auf dem Master-Knoten:

Konfigurieren Sie die Anzahl der Executors direkt auf der Hauptkonfigurationsseite von Jenkins oder über die Knotenkonfigurationseinstellungen für Agents.

Wenn Sie einen Agent mit $N$ CPU-Kernen haben, verhindert das Setzen der Anzahl der Executors auf etwas weniger als $N$ (z.B. $N-1$ oder $N/2$, wenn Builds extrem CPU-intensiv sind), dass das System vollständig gesättigt wird, und ermöglicht dem Betriebssystem und Jenkins-Hintergrundaufgaben zu atmen.

Beispielkonfiguration für einen Agent:

Beim Konfigurieren eines neuen Agents (Knoten) suchen Sie nach dem Feld 'Anzahl der Executors'. Setzen Sie dies konservativ basierend auf den Hardware-Fähigkeiten.

# Agent-Konfigurationsausschnitt (Konzeptionell)
NUM_EXECUTORS = 4  # Für einen 8-Kern-Rechner, der schwere Builds ausführt

2. Speicherverwaltung (RAM)

Unzureichender RAM führt zu übermäßigem Swapping (Auslagern von Daten auf die Festplatte), was die Leistung stark beeinträchtigt. Jenkins ist stark von der Java Virtual Machine (JVM) abhängig, was die Heap-Größe kritisch macht.

Optimierung der JVM-Heap-Größe des Jenkins-Controllers

Die JVM-Heap-Größe des Controllers ist eine der wichtigsten Speichereinstellungen.

Dies wird typischerweise durch Ändern der Umgebungsvariablen JENKINS_JAVA_OPTIONS vor dem Start von Jenkins konfiguriert (z.B. in /etc/default/jenkins oder systemd-Service-Dateien).

Bewährte Methode: Lassen Sie sinnvollen Speicher für das Betriebssystem, den Dateisystem-Cache, Überwachungsagenten und alle Nebenprozesse übrig. Viele Teams halten den Heap unter dem Großteil des System-RAMs, anstatt Java alles zu geben.

Beispiel für JVM-Optionen:

Wenn der Server 16 GB RAM hat, könnte ein vernünftiger Ausgangspunkt ein 8-GB-Heap sein, dann basierend auf Garbage-Collection-Logs und tatsächlicher Nutzung anpassen:

export JENKINS_JAVA_OPTIONS="-Xms8192m -Xmx10240m -Djava.awt.headless=true -XX:MaxMetaspaceSize=512m"

-Xms: Anfängliche Heap-Größe.
-Xmx: Maximale Heap-Größe. Viele Produktionsumgebungen setzen dies gleich -Xms, um eine Heap-Größenänderung während der Laufzeit zu vermeiden.

Überwachung und Garbage Collection (GC)

Hohe Speichernutzung führt oft zu häufigen, langen Garbage-Collection-Pausen. Überwachen Sie GC-Logs (aktiviert durch zusätzliche JVM-Flags), um festzustellen, ob der Heap angemessen dimensioniert ist oder ob es Speicherlecks in Plugins oder Build-Prozessen gibt.

3. Optimierung der Festplatten-E/A

Die Festplattenleistung ist oft der stille Killer der CI/CD-Geschwindigkeit, insbesondere beim Umgang mit großen Artefakten, Abhängigkeits-Caches oder häufigen Checkouts/Löschungen.

Separate Volumes für Arbeitsbereich und Logs

Wenn möglich, trennen Sie die Bereiche mit hoher Schreibaktivität von der Kerninstallation von Jenkins.

Jenkins Home ($JENKINS_HOME): Dies beherbergt Konfiguration, Build-Aufzeichnungen und System-Logs. Es erfordert zuverlässigen, mittelschnellen Speicher (SSD empfohlen).
Build-Arbeitsbereiche: Diese Verzeichnisse sehen massive, häufige Lese-/Schreib-/Löschoperationen. Idealerweise platzieren Sie das primäre Verzeichnis, in dem sich Arbeitsbereiche befinden, auf dem schnellsten verfügbaren Speicher (NVMe/SSD).

Tipp: Stellen Sie sicher, dass das für Arbeitsbereiche verwendete Dateisystem (z.B. ext4, XFS) gut gewartet ist und über ausreichend Inodes verfügt.

Nutzung von Build-Caching-Strategien

Die Minimierung der Festplattenaktivität durch intelligentes Caching ist ein großer Leistungsgewinn:

Abhängigkeits-Caching: Konfigurieren Sie Maven, Gradle, npm oder pip so, dass sie gemeinsame, persistente Caches auf den Agent-Knoten verwenden, anstatt Abhängigkeiten für jeden Build erneut herunterzuladen.
Arbeitsbereichsbereinigung: Bereinigen Sie veraltete Arbeitsbereiche aggressiv. Während das Behalten von Arbeitsbereichen beim Debuggen helfen kann, verbrauchen sie Festplattenspeicher und verlangsamen Festplattenoperationen, wenn sie zu zahlreich sind.
- Verwenden Sie Pipeline-Schritte wie cleanWs() oder konfigurieren Sie Agent-Einstellungen, um Arbeitsbereiche automatisch nach einem bestimmten Zeitraum zu löschen.

Netzwerkdateisysteme (NFS/SMB)

Warnung: Vermeiden Sie die Verwendung von Netzwerkdateisystemen (NFS oder SMB) für Volumes mit hohem Schreibaufkommen wie Build-Arbeitsbereiche, es sei denn, die Netzwerkverbindung und das Speicher-Array sind extrem durchsatzstark und latenzarm. Netzwerklatenz führt zu erheblichem Overhead bei E/A-intensiven Aufgaben.

Fortgeschrittene Leistungstechniken

Über die grundlegende Ressourcenzuweisung hinaus können mehrere architektonische und betriebliche Optimierungspunkte erhebliche Vorteile bringen.

Executor-Optimierung und -Skalierung

Für Umgebungen mit unvorhersehbarer Last ist dynamische Skalierung der Schlüssel.

Cloud-native Agents (Ephemere Agents)

Verwenden Sie Jenkins-Agents, die bei Bedarf bereitgestellt werden (z.B. über Kubernetes, Docker oder EC2-Plugins). Diese Agents werden genau dann gestartet, wenn sie benötigt werden, und danach beendet. Dies stellt sicher, dass Ressourcen nur während aktiver Builds verbraucht werden, und vermeidet verschwendeten Overhead durch untätige, dauerhaft laufende Agents.

Plugin-Verwaltung

Plugins können erheblich zum Speicherverbrauch und zur Verarbeitungslast des Controllers beitragen.

Plugins prüfen: Überprüfen Sie regelmäßig die installierten Plugins. Entfernen Sie alle, die nicht verwendet oder veraltet sind, da sie Speicher verbrauchen und Leistungseinbußen verursachen können.
Arbeit auslagern: Konfigurieren Sie Plugins nach Möglichkeit so, dass sie ihre schwere Arbeit auf Agents statt auf dem Controller erledigen. Zum Beispiel sollten Tools, die Berichte erstellen oder Indizierungen durchführen, auf einem Agent ausgeführt werden.

Nutzung von Leistungsüberwachungstools

Reaktive Optimierung ist nicht ausreichend; proaktive Überwachung ist unerlässlich. Integrieren Sie Überwachungstools, um wichtige Metriken zu verfolgen:

Systemebene: CPU-Auslastung, RAM-Nutzung, Festplatten-E/A-Wartezeiten.
Jenkins-Ebene: Build-Latenz-Perzentile (P95, P99), Wartezeit, Executor-Auslastung.

Tools wie Prometheus/Grafana oder integrierte Jenkins-Überwachungsfunktionen (wie das Metrics-Plugin) bieten die notwendige Transparenz, um Ressourcenanpassungen zu rechtfertigen.

Zusammenfassung der bewährten Methoden

Ressource	Bewährte Methode	Umsetzbarer Tipp
CPU	Delegieren Sie schwere Last an Agents.	Setzen Sie Agent-Executors etwas unter der Kernanzahl für Sicherheit.
Speicher (Master)	Optimieren Sie die JVM-Heap-Größe (`-Xmx`).	Weisen Sie 50-75 % des physischen RAMs zu, setzen Sie Xms=Xmx.
Festplatten-E/A	Verwenden Sie schnellen lokalen Speicher (SSD/NVMe) für Arbeitsbereiche.	Vermeiden Sie NFS/SMB für Build-Verzeichnisse mit hohem Schreibaufkommen.
Arbeitslast	Implementieren Sie aggressives Caching.	Konfigurieren Sie Abhängigkeitsmanager (Maven/npm) für die Verwendung persistenter, gemeinsamer Caches auf Agents.
Architektur	Verwenden Sie ephemere, dynamische Agents.	Nutzen Sie Kubernetes- oder Docker-Plugins, um Ressourcen basierend auf der Warteschlangentiefe zu skalieren.

Beginnen Sie mit dem Controller: Halten Sie ihn langweilig

Der Controller sollte langweilig sein. Das ist ein Kompliment. Ein langweiliger Controller plant Builds, speichert Job-Konfigurationen, bedient Seiten, kommuniziert mit Agents und schreibt Metadaten. Er führt keine Test-Suiten aus, baut keine Container, scannt keine riesigen Abhängigkeitsbäume und veröffentlicht keine Multi-Gigabyte-Berichte. Wenn der Controller zu einer weiteren Build-Maschine wird, teilt sich jedes Team die Schadenszone.

Setzen Sie die Executor-Anzahl des Controllers auf Null, es sei denn, Sie haben eine kleine Ein-Maschinen-Installation oder eine sehr bewusste Ausnahme. Diese eine Änderung verhindert, dass versehentliche Arbeitslasten auf dem wichtigsten Knoten des Systems landen. Wenn ein Job wirklich dort laufen muss, fragen Sie nach dem Grund. Oft ist die Antwort "weil ein Tool dort installiert ist", und die bessere Lösung ist, ein Agent-Image mit diesem Tool zu erstellen.

Überwachen Sie die Controller-CPU getrennt von der Agent-CPU. Ein Controller mit hoher CPU, während keine Builds laufen, könnte mit Plugin-Aktivitäten, Branch-Indexierung, Log-Rendering, Sicherheitsbereichsabfragen oder zu viel Job-Verlauf zu tun haben. Ein Controller mit hoher CPU während der Haupt-Build-Zeit könnte zu viele Pipelines planen, große Logs serialisieren oder Berichte verarbeiten, die woanders behandelt werden sollten.

Die Speicheroptimierung folgt dem gleichen Muster. Ein größerer Heap kann den Garbage-Collection-Druck verringern, aber er kann auch ein Plugin-Leck eine Weile verbergen und eventuelle Pausen verschlimmern. Aktivieren Sie GC-Logs, behalten Sie die Nutzung der alten Generation nach vollständigen Sammlungen im Auge und vergleichen Sie das Speicherverhalten vor und nach Plugin-Upgrades. Wenn die Heap-Nutzung den ganzen Tag ansteigt und nie zurückgeht, bezeichnen Sie dies nicht als normales Wachstum, bis Sie Lecks oder außer Kontrolle geratene Jobs ausgeschlossen haben.

Optimieren Sie Executors nach Arbeitslast, nicht nur nach Kernanzahl

Der übliche "ein Executor pro Kern"-Kurzschluss ist nur eine erste Schätzung. Ein Build, der die meiste Zeit mit dem Warten auf Netzwerk-Downloads verbringt, kann mehr Parallelität vertragen als ein Build, der C++ kompiliert oder Browser-Tests ausführt. Ein Job, der Tausende kleiner Dateien erstellt, kann die Festplatte sättigen, lange bevor die CPU ausgelastet aussieht. Ein Job, der Docker-in-Docker ausführt, kann auf überraschende Weise an Speichertreiber- oder Netzwerkgrenzen stoßen.

Für CPU-intensive Builds beginnen Sie konservativ. Auf einem 8-Kern-Agent können vier Executors bessere durchschnittliche Build-Zeiten liefern als acht. Für E/A-intensive Builds messen Sie die Festplattenwartezeit und die Dateisystemlatenz, während Sie die Parallelität langsam erhöhen. Für speicherintensive Builds verfolgen Sie den residenten Speicher pro Build und lassen Platz für den OS-Cache. Swap-Aktivität auf einem Jenkins-Agent ist normalerweise ein Zeichen dafür, dass die Executor-Anzahl zu hoch ist oder der Job eine größere Maschine benötigt.

Labels sind Teil der Ressourcenverwaltung. Senden Sie nicht alles an ein generisches linux-Label, wenn einige Jobs Docker benötigen, einige viel Speicher benötigen und einige einen lizenzierten Compiler benötigen. Erstellen Sie Labels, die Ressourcenprofile beschreiben. Überprüfen Sie dann die Wartezeit nach Label. Das sagt Ihnen, ob Sie mehr linux-docker-Agents, mehr speicherintensive Agents oder weniger Jobs benötigen, die an eine knappe Umgebung gebunden sind.

Festplatte ist oft der versteckte Engpass

Jenkins erstellt, liest und löscht viele Dateien. Quellcode-Checkouts, Abhängigkeits-Caches, Testberichte, Coverage-Dateien, Build-Artefakte, archivierte Logs und temporäre Dateien greifen alle auf die Festplatte zu. Wenn die Festplatte langsam ist, sehen Builds zufällig langsam aus. Wenn die Festplatte voll ist, schlagen Builds auf eine Weise fehl, die viel menschliche Zeit verschwendet.

Platzieren Sie belebte Arbeitsbereiche nach Möglichkeit auf schnellem lokalen Speicher. Verwenden Sie separate Volumes für $JENKINS_HOME, Arbeitsbereiche und große Caches, wenn Ihre Infrastruktur dies zulässt. Diese Trennung erleichtert das Wachsen der lauten Teile, ohne die Controller-Konfiguration und Build-Metadaten zu gefährden. Es macht auch die Fehlerbehebung klarer: Wenn die Arbeitsbereichs-E/A gesättigt ist, wissen Sie, wo Sie suchen müssen.

Seien Sie vorsichtig mit Netzwerkdateisystemen. NFS und SMB können für einige gemeinsame Assets in Ordnung sein, aber sie sind oft schmerzhaft für aktive Arbeitsbereiche mit vielen kleinen Dateien. Eine JavaScript-Installation, ein Maven-Build oder eine Test-Suite, die Tausende temporärer Dateien erstellt, kann die Netzwerklatenz in Minuten verschwendeter Zeit verwandeln. Wenn Sie Netzwerkspeicher verwenden müssen, benchmarken Sie Ihre tatsächliche Arbeitslast, anstatt rohen Durchsatzzahlen zu vertrauen.

Aufbewahrungseinstellungen sind wichtig. Jedes Artefakt für immer zu behalten, ist teuer. Keine Historie zu behalten, ist während der Incident-Überprüfung schmerzhaft. Ein praktisches Setup behält genügend Builds für Debugging und Compliance, veröffentlicht langfristige Artefakte in einem Artefakt-Repository und läuft alte Logs und Arbeitsbereiche automatisch ab. Das genaue Aufbewahrungsfenster hängt vom Team ab, aber die Entscheidung sollte explizit sein.

Caching, ohne neue Probleme zu schaffen

Caching ist eine der schnellsten Methoden, um die Jenkins-Leistung zu verbessern. Es ist auch eine der einfachsten Methoden, um seltsame Builds zu erzeugen, wenn der Cache nicht sorgfältig entworfen ist.

Für Abhängigkeitsmanager bevorzugen Sie ein echtes Repository oder einen Paket-Proxy für gemeinsame Downloads: Nexus, Artifactory, ein privates npm-Registry, einen Maven-Proxy oder einen sprachspezifischen Cache-Dienst. Verwenden Sie dann lokale Pro-Agent-Caches, um wiederholte Downloads zu vermeiden. Dies gibt Ihnen Geschwindigkeit, ohne dass jeder Job in ein einziges fragiles gemeinsames Verzeichnis schreibt.

Für Docker-Builds ordnen Sie Dockerfile-Anweisungen so an, dass Abhängigkeitsebenen stabil bleiben. Kopieren Sie zuerst Manifest-Dateien, installieren Sie Abhängigkeiten und kopieren Sie dann den Rest des Quellcodes. Verwenden Sie BuildKit-Cache-Mounts, wo sie passen. Wenn Agents ephemer sind, ziehen Sie vorgefertigte Basis-Images in Betracht, die bereits gemeinsame Toolchains enthalten. Das Ziehen eines riesigen Images bei jedem Build kann den Vorteil dynamischer Agents zunichte machen.

Für Test-Caches seien Sie ehrlich bezüglich der Korrektheit. Compiler-Caches und Abhängigkeits-Caches sind normalerweise sicher, wenn sie gut geschlüsselt sind. Die Wiederverwendung von Testergebnissen ist gefährlicher, es sei denn, das Build-System versteht die Eingaben genau. Ein schneller falscher Build ist schlimmer als ein langsamer korrekter.

Überwachung, die tatsächlich hilft

Ein Jenkins-Dashboard sollte ein paar einfache Fragen beantworten. Warten Jobs, weil es nicht genügend kompatible Executors gibt? Können Agents keine Verbindung herstellen oder starten? Verbringt der Controller zu viel Zeit mit Garbage Collection? Füllt sich die Festplatte schneller, als die Bereinigung Daten entfernt? Verbrauchen ein paar Jobs die meisten Executor-Minuten?

Verfolgen Sie die Wartezeit nach Label, die Executor-Auslastung nach Agent, die Build-Dauer nach Job, den Controller-Heap, die GC-Pausenzeit, die Festplattennutzung, die Festplatten-E/A-Wartezeit, Agent-Startfehler und Remoting-Trennungen. Perzentile sind nützlicher als Durchschnitte. Wenn der mediane Build in Ordnung ist, aber die langsamsten zehn Prozent schrecklich sind, werden Benutzer Jenkins dennoch als unzuverlässig empfinden.

Führen Sie ein kurzes Änderungsprotokoll für die Optimierung. Notieren Sie, wann Sie die Heap-Größe, Executor-Anzahlen, Plugin-Versionen, Aufbewahrungsrichtlinien, Agent-Images oder Cache-Pfade geändert haben. Ohne diese Geschichte werden Sie irgendwann auf ein Diagramm starren und sich fragen, was letzten Dienstag passiert ist.

Ein sinnvoller Optimierungszyklus

Wählen Sie einen Engpass. Ändern Sie eine sinnvolle Sache. Messen Sie lange genug, um den normalen Spitzenverkehr einzuschließen. Behalten Sie die Änderung bei, wenn sie geholfen hat und keinen neuen Fehlermodus erzeugt hat. Machen Sie sie rückgängig, wenn die Verbesserung nur in der Theorie auftritt.

Wenn zum Beispiel ein Maven-Job sechs Minuten damit verbringt, Abhängigkeiten aufzulösen, fügen Sie einen Repository-Proxy und einen agent-lokalen Cache hinzu. Wenn die Wartezeit danach immer noch hoch ist, fügen Sie Agents für das betroffene Label hinzu. Wenn die Controller-UI immer noch langsam ist, wenn Builds ruhig sind, überprüfen Sie Plugins, Job-Anzahl, Branch-Indexierung und Heap-Verhalten. Jeder Schritt grenzt das Problem ein, anstatt Jenkins in einen Haufen von Vermutungen zu verwandeln.

Indem Sie systematisch CPU, Speicher, Festplatte, Caching und Agent-Kapazität angehen, machen Sie Jenkins weniger dramatisch. Das ist die beste Art von CI-Verbesserung: Entwickler hören auf, über das Tool nachzudenken, und kommen zurück zum Ausliefern von Code.