Hvordan kan jeg konfigurere JVM -parametere for å minimere søppelinnsamlings -pauser

Velge riktig søppeloppsamler

JVM tilbyr flere søppelinnsamlingsalgoritmer, hver med forskjellige egenskaper angående gjennomstrømning, pausetid og ressursbruk:

- Seriell GC: Bruker en enkelt tråd for GC. Det stopper alle applikasjonstråder under samlingen, noe som resulterer i lange pauser. Det er vanligvis ikke egnet for å minimere pauser i større applikasjoner.
- Parallell GC: Bruker flere tråder for å utføre søppelinnsamling, og reduserer pausetider sammenlignet med seriell GC ved å utnytte flere CPU -kjerner. Den er gjennomstrømningsorientert, men tar fortsatt en pause på applikasjonstrådene under GC.
- Samtidig Mark-Sweep (CMS) GC: Utfører mye av søppelinnsamlingsarbeidet samtidig med applikasjonen, noe som reduserer pausetiden betydelig ved bare å ta en kort pause på applikasjonen i spesifikke GC-faser. Det er egnet for applikasjoner med lav latens.
- Garbage First (G1) GC: Deler haugen i regioner og fokuserer på å samle regioner med mest søppel først. Den har som mål å gi forutsigbare pausetider og god gjennomstrømning ved å blande samtidig og parallelle faser. Det er ofte standard i moderne JVM -versjoner.
- Shenandoah og ZGC: Disse samlerne med lav latens utfører alle eller mest GC-arbeid samtidig, og sikter mot veldig korte eller nesten umerkelige pauser, egnet for store hauger og svært responsive applikasjoner.

Å velge riktig samler avhenger av applikasjonskrav som maksimal tolerert pausetid, haugestørrelse og arbeidsmengdeegenskaper.

Konfigurasjon av haugestørrelse

Heapstørrelse har en direkte innvirkning på GC -frekvens og pausevarighet:

-Sett innledende og maksimal haugestørrelse lik: å bruke `-xms` og` -xmx` med samme verdi unngår størrelse på haug, som kan introdusere pauser under kjøretid.
- Tilstrekkelig haugestørrelse: Underfordelende haug forårsaker hyppige samlinger, øker pauser. Overfordeling fører imidlertid til lengre GC-sykluser. Finn en balanse basert på applikasjonsminnebehov.
- Overvåk GC -logger og bruk av bruk av bruk for å stille inn størrelsen på haugen på riktig måte.

Kontrollerer GC Pausetid

JVM gir parametere for å sette mål for maksimale GC -pausetider:

- `-xx: MaxGCPausemillis =`: Angir et mål maksimal pausetid i millisekunder for samleren for å prøve å møtes. Selv om det ikke er garantert, prøver JVM å justere gjennomstrømning og GC -arbeid for å unngå å overskride denne pausetiden.
- Bruk denne parameteren med G1 GC eller andre samlere som støtter pausetidsmål for å veilede JVM i å balansere gjennomstrømning og latens.

Gjenging og parallellisme

Utnyttelse av flere tråder under søppelinnsamling reduserer varigheten av pause:

- `-xx: Parallelgcthreads =`: Angir antall tråder som brukes i parallelle faser av GC. Flere tråder kan redusere pausetiden, men kan også øke CPU -bruken.
- `-xx: ConcgCthreads =`: For samtidige samlere som CMS og G1, angir antall tråder som utfører samtidige faser.
- Optimal trådtall skal samkjøre med antall tilgjengelige CPU -kjerner og arbeidsmengden; Overdrivende tråder kan forringe ytelsen.

Tuning unge og gamle generasjonsstørrelser

Heap er typisk delt inn i generasjons unge og gamle. Tuning av størrelsene deres påvirker GC -oppførsel:

- Ung generasjonsstørrelse: Større ung generasjon reduserer frekvensen av mindre GC -er, men øker mindre GC -pausetider. Juster basert på objektallokeringshastighet.
- Gammel generasjonsstørrelse: påvirker hvor ofte større/full GCS kjøres og deres varighet.
- G1 GC deler haugen i mange like store regioner og administrerer størrelse dynamisk, men tillater innstilling av initieringsterskler med parametere som `-xx: Initiatingheapoccupancypercent`.

Garbage Collector spesifikke parametere

For G1 GC, ofte brukt i moderne JVM -er:
- `-xx:+USEG1GC`: Aktiverer G1 GC.
- `-xx: MaxGCPausemillis =`: Pause Time Target.
- `-xx: Initiatingheapoccupancypercent =`: Begynner samtidig merking når haugen når dette belegget.
- `-xx:+BrukeringsDeDuplication`: Reduserer hukommelsesavtrykk ved å dedupliserende strenger.
- Unngå eksplisitt å sette ung generasjonsstørrelse, da det kan forstyrre G1s pausetidsmål.

For CMS GC:
- `-xx:+useconcmarksweepgc`: Aktiverer CMS.
-Tuning Fokus på å redusere globale stop-the-World pauser ved å justere initieringsterskelen og trådtellingene.

For parallell GC (gjennomstrømningsorientert):
-`-xx:+useParallelgc` og` -xx:+useParalleloldgc`: Aktiverer parallell GC for unge og gamle generasjoner.
- Tune Antall GC-tråder med `-xx: ParallelGCThreads`.

Redusere objektfordelingsfrekvens

Å redusere hastigheten som nye objekter opprettes, reduserer GC -trykk:

- Profil og optimalisere kode for å minimere unødvendig objektoppretting.
- Bruk objektpooling og gjenbruk når det er mulig.
- Juster JVM -parametere for å regulere interne hukommelsesregioner for bedre objektallokeringsmønstre.

Unngå eksplisitte GC -samtaler

- Deaktiver eksplisitt GC-anrop fra applikasjonskode eller eksterne verktøy som kan utløse full GC-pauser ved å bruke `-xx:+DisableExplicitGC`.

overvåking og logging

For å forstå og stille inn GC -oppførsel, aktiver detaljert GC -logging:

- Bruk `-xlog: GC*` I JVM-er som støtter Unified Logging (Java 9+).
-I eldre JVM -er, bruk `-xx:+printgcDetails -xx:+printgcdatestamps -xloggc:`.

Analyser logger for å identifisere pauseårsaker og stille inn tilsvarende.

Generelle anbefalinger

- Begynn å stille inn med en ren skifer ved å fjerne utdaterte JVM -argumenter.
- Test endringer i et produksjonslignende miljø.
- Bruk verktøy som Java Flight Recorder, VisualVM eller Commercial Profilers for å samle GC og hukommelsesbruksdata.
- Iterate innstillingstrinn basert på observerte GC -pausetider, gjennomstrømning og applikasjonsrespons.

Oppsummert innebærer minimering av JVM søppelinnsamlings -pauser å velge riktig søppelkollektor (helst G1, ZGC eller Shenandoah for lave pausebehov), riktig dimensjonering av haug og generasjoner, sette pausemål, innstilling av samtidighetstråder, minimere objektallokeringsfrekvens, disable Explicit GCS og forsiktig monitor. Spesifikasjonene vil avhenge av applikasjonsarbeidsmengden, heapstørrelse, JVM -versjon og maskinvareegenskaper. Justeringer bør gjøres trinnvis og valideres med overvåkningsverktøy og detaljerte GC -logger for å oppnå ønsket balanse mellom gjennomstrømning og pausetid.