Leitfäden
So legen Sie die Größe von Runnern für Java-Builds fest
Sie vermuten eine Läufergröße für einen Maven- oder Gradle-Build.
4 Min. Lesezeit
Sie vermuten eine Läufergröße für einen Maven- oder Gradle-Build.
Warum es passiert
JVM-Builds sind speicherhungrig, bevor sie CPU-hungrig sind, und GC-Thrash sieht genauso aus wie ein langsamer Build.
So beheben Sie das Problem
- Beginnen Sie bei 8 vCPU mit 4 GB pro vCPU; Gradle und Maven arbeiten beide modulübergreifend parallel
- Geben Sie der JVM genügend Heap – ein zu kleiner Heap kostet mehr als eine zu kleine CPU
- Achten Sie auf die Konfigurationsphase, die Single-Threaded ist und von der Kernanzahl nicht beeinflusst wird
- Skalieren Sie nur, wenn die Parallelität auf Modulebene tatsächlich die Kerne auslastet
Ihr nächster Build könnte doppelt so schnell sein — zum halben Preis
Kostenlos starten. Der Wechsel zurück ist dieselbe eine Zeile — auch dieses Diff veröffentlichen wir.
Verwandt
So skalieren Sie selbst gehostete LäuferSelbst gehostete Läufer stehen entweder zu Spitzenzeiten in der Warteschlange oder bleiben untätig und teuer.So verwenden Sie LäufergruppenJedes Repository kann Jobs auf jedem Runner planen.So entwerfen Sie eine Läufer-Label-StrategieDie Etiketten sind organisch gewachsen und niemand weiß, welche sie verwenden sollen.Gehostet oder BYOC: So wählen Sie ausSie sind sich nicht sicher, ob Sie gehostete Läufer verwenden oder in Ihrer eigenen Cloud bereitstellen sollen.