streamalism.org

1. Oversikt

I denne raske opplæringen vil vi utforske de mest kjente alternativene som kan brukes til å konfigurere Java Virtual Machine.

2. Eksplisitt høyminne - Xms- og Xmx-alternativer

En av de vanligste ytelsesrelaterte metodene er å initialisere heapminnet i henhold til applikasjonskravene.

Derfor bør vi spesifisere minimal og maksimal dyngstørrelse. Nedenfor kan du bruke parametere for å oppnå det:

-Xms [enhet] -Xmx [enhet]

Her, enhet betegner enheten der minnet (angitt med haugestørrelse) skal initialiseres. Enheter kan merkes som ‘G’ for GB, ‘M’ for MB og ‘K’ for KB.

For eksempel, hvis vi vil tildele minimum 2 GB og maksimalt 5 GB til JVM, må vi skrive:

-Xms2G -Xmx5G

Starter med Java 8, størrelsen på Metaspace er ikke definert. Når den når den globale grensen, øker JVM den automatisk, men for å overvinne unødvendig ustabilitet kan vi sette Metaspace størrelse med:

-XX: MaxMetaspaceSize = [enhet]

Her, metaspace størrelse angir hvor mye minne vi vil tildele Metaspace.

I henhold til Oracle-retningslinjene, etter totalt tilgjengelig minne, er den nest mest innflytelsesrike faktoren andelen av haugen som er reservert for den unge generasjonen. Minimumsstørrelsen på YG er som standard 1310 MB, og maksimal størrelse er ubegrenset.

Vi kan tildele dem eksplisitt:

-XX: NewSize = [enhet] -XX: MaxNewSize = [enhet]

3. Søppelinnsamling

For å få bedre stabilitet i applikasjonen, er det viktig å velge riktig Garbage Collection-algoritme.

JVM har fire typer GC implementeringer:

• Seriell søppeloppsamler
• Parallell søppeloppsamler
• CMS søppeloppsamler
• G1 Søppeloppsamler

Disse implementeringene kan erklæres med parametrene nedenfor:

-XX: + UseSerialGC -XX: + UseParallelGC -XX: + USeParNewGC -XX: + UseG1GC

Flere detaljer om Søppelsamling implementeringer finner du her.

4. GC-logging

For å overvåke applikasjonens helse strengt, bør vi alltid sjekke JVM-ene Søppelsamling opptreden. Den enkleste måten å gjøre dette på er å logge GC aktivitet i leselig format.

Ved hjelp av følgende parametere kan vi logge GC aktivitet:

-XX: + UseGCLogFileRotation -XX: NumberOfGCLogFiles = -XX: GCLogFileSize = [unit] -Xloggc: /path/to/gc.log

BrukGCLogFileRotation spesifiserer policyen for rulling av loggfiler, omtrent som log4j, s4lj, etc. NumberOfGCLogFiles angir det maksimale antall loggfiler som kan skrives for en enkelt applikasjonssyklus. GCLogFileSize angir maks størrelse på filen. Endelig, loggc angir plasseringen.

Merk at det er to flere JVM-parametere tilgjengelig (-XX: + PrintGCTimeStamps og -XX: + PrintGCDateStamps) som kan brukes til å skrive ut tidsmessig tidsstempel i GC Logg.

For eksempel hvis vi vil tildele maksimalt 100 GC loggfiler, som hver har en maksimal størrelse på 50 MB og vil lagre dem i ‘/ hjem / bruker / logg / ' plassering, kan vi bruke under syntaksen:

-XX: + UseGCLogFileRotation -XX: NumberOfGCLogFiles = 10 -XX: GCLogFileSize = 50M -Xloggc: /home/user/log/gc.log

Problemet er imidlertid at en ekstra daemon-tråd alltid brukes til å overvåke systemtid i bakgrunnen. Denne oppførselen kan skape ytelsesflaskehals; det er derfor det alltid er bedre å ikke leke med denne parameteren i produksjonen.

5. Håndtering av minne

Det er veldig vanlig at et stort program møter minnefeil, som igjen resulterer i programkrasj. Det er et veldig kritisk scenario og veldig vanskelig å replikere for å feilsøke problemet.

Derfor kommer JVM med noen parametere som dumper heapminne i en fysisk fil som kan brukes senere for å finne ut lekkasjer:

-XX: + HeapDumpOnOutOfMemoryError -XX: HeapDumpPath =. / Java_pid.hprof -XX: OnOutOfMemoryError = ";" -XX: + Bruk GCOverheadLimit

Et par punkter å merke seg her:

• HeapDumpOnOutOfMemoryError instruerer JVM om å dumpe dyngen i fysisk fil i tilfelle OutOfMemoryError
• HeapDumpPath angir banen der filen skal skrives; ethvert filnavn kan gis; imidlertid hvis JVM finner en merket i navnet, blir prosess-ID-en for den nåværende prosessen som forårsaker feil i minnet, lagt til filnavnet med .hprof format
• OnOutOfMemoryError brukes til å utstede nødkommandoer som skal utføres i tilfelle feil på minnet; riktig kommando skal brukes i løpet av cmd args. For eksempel, hvis vi vil starte serveren på nytt så snart det er lite minne, kan vi angi parameteren:

-XX: OnOutOfMemoryError = "shutdown -r"

• Bruk GCOverheadLimit er en policy som begrenser andelen av VM-tiden som brukes i GC før en Tomt for minne feil kastes

6. 32/64 Bit

I operativsystemmiljøet der både 32 og 64-biters pakker er installert, velger JVM automatisk 32-biters miljøpakker.

Hvis vi vil sette miljøet til 64 bit manuelt, kan vi gjøre det ved hjelp av parameteren nedenfor:

-d

OS-bit kan være enten 32 eller 64. Mer informasjon om dette finner du her.

7. Diverse

• -server: aktiverer “Server Hotspot VM”; denne parameteren brukes som standard i 64 biters JVM
• -XX: + UseStringDeduplication: Java 8u20 har introdusert denne JVM-parameteren for å redusere unødvendig bruk av minne ved å opprette for mange forekomster av det samme Streng; dette optimaliserer haugeminnet ved å redusere duplikat String verdier til en enkelt global char [] matrise
• -XX: + BrukLWPSynchronization: settene LWP (Lett vektprosess) - basert synkroniseringspolicy i stedet for trådbasert synkronisering
• -XX: LargePageSizeInBytes: angir den store sidestørrelsen som brukes til Java-bunken; det tar argumentet i GB / MB / KB; med større sidestørrelser kan vi utnytte maskinvareressurser for virtuelt minne bedre; Dette kan imidlertid føre til større plassstørrelser for PermGen, som igjen kan tvinge til å redusere størrelsen på Java-dyngeplassen
• -XX: MaxHeapFreeRatio: setter maksimal prosentandel av dyngen etter GC for å unngå krymping.
• -XX: MinHeapFreeRatio: setter minimumsprosenten av dyngen gratis etter GC for å unngå utvidelse; for å overvåke haugbruken kan du bruke VisualVM levert med JDK.
• -XX: SurvivorRatio: Forhold mellom eden/overlevelsesstørrelse - for eksempel, -XX: SurvivorRatio = 6 angir forholdet mellom hver overlevende plass og Eden plass å være 1: 6,
• -XX: + UseLargePages: bruk stort sideminne hvis det støttes av systemet; Vær oppmerksom på at OpenJDK 7 har en tendens til å krasje hvis du bruker denne JVM-parameteren

• -XX: + UseStringCache: muliggjør hurtigbufring av ofte tildelte strenger tilgjengelig i String basseng

• -XX: + UseCompressedStrings: bruk en byte [] skriv for String objekter som kan vises i rent ASCII-format
• -XX: + OptimizeStringConcat: det optimaliserer String sammenkoblingsoperasjoner der det er mulig

8. Konklusjon

I denne raske artikkelen lærte vi om noen viktige JVM-parametere - som kan brukes til å stille og forbedre generell applikasjonsytelse.

Noen av disse kan også brukes til feilsøkingsformål.

Hvis du vil utforske referanseparametrene mer detaljert, kan du komme i gang her.