streamalism.org

1. Oversigt

I denne hurtige vejledning undersøger vi de mest kendte muligheder, der kan bruges til at konfigurere Java Virtual Machine.

2. Eksplicit Heap-hukommelse - Xms og Xmx Options

En af de mest almindelige præstationsrelaterede fremgangsmåder er at initialisere bunkehukommelsen i henhold til applikationskravene.

Derfor skal vi specificere minimal og maksimal dyngestørrelse. Nedenstående parametre kan bruges til at opnå det:

-Xms [enhed] -Xmx [enhed]

Her, enhed angiver den enhed, hvor hukommelsen (angivet med bunke størrelse) skal initialiseres. Enheder kan markeres som 'G' til GB, 'M' til MB og 'K' til KB.

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

-Xms2G -Xmx5G

Startende med Java 8, størrelsen på Metaspace er ikke defineret. Når den når den globale grænse, øger JVM den automatisk, men for at overvinde enhver unødvendig ustabilitet kan vi indstille Metaspace størrelse med:

-XX: MaxMetaspaceSize = [enhed]

Her, metaspace størrelse angiver den mængde hukommelse, vi vil tildele Metaspace.

I henhold til Oracle-retningslinjer er den anden mest indflydelsesrige faktor efter den samlede tilgængelige hukommelse andelen af ​​bunken, der er reserveret til den unge generation. Minimumsstørrelsen på YG er som standard 1310 MB, og maksimal størrelse er ubegrænset.

Vi kan tildele dem eksplicit:

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

3. Affaldssamling

For bedre applikationsstabilitet er det afgørende at vælge den rigtige Garbage Collection-algoritme.

JVM har fire typer GC implementeringer:

• Seriel affaldssamler
• Parallel affaldssamler
• CMS skraldespand
• G1 Affaldssamler

Disse implementeringer kan erklæres med nedenstående parametre:

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

Flere detaljer om Dagrenovation implementeringer kan findes her.

4. GC-logning

For nøje at overvåge applikationssundheden skal vi altid kontrollere JVM'erne Dagrenovation ydeevne. Den nemmeste måde at gøre dette på er at logge GC aktivitet i læsbart format.

Ved hjælp af følgende parametre kan vi logge GC aktivitet:

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

BrugGCLogFileRotation angiver logfilens rullende politik, ligesom log4j, s4lj osv. NumberOfGCLogFiles angiver det maksimale antal logfiler, der kan skrives i en enkelt applikations livscyklus. GCLogFileSize angiver filens maksimale størrelse. Langt om længe, loggc angiver dets placering.

Punkt at bemærke her er, at der er to flere JVM-parametre tilgængelige (-XX: + PrintGCTimeStamps og -XX: + PrintGCDateStamps), som kan bruges til at udskrive tidsmæssigt tidsstempel i GC log.

For eksempel, hvis vi vil tildele maksimalt 100 GC logfiler, der hver har en maksimal størrelse på 50 MB og vil gemme dem i '/ hjem / bruger / log / ' placering, kan vi bruge nedenstående syntaks:

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

Problemet er dog, at der altid bruges en ekstra dæmontråd til overvågning af systemtid i baggrunden. Denne adfærd kan skabe en vis ydeevne flaskehals; Derfor er det altid bedre ikke at lege med denne parameter i produktionen.

5. Håndtering af hukommelse

Det er meget almindeligt, at et stort program møder hukommelsesfejl, hvilket igen resulterer i applikationsnedbrud. Det er et meget kritisk scenario og meget svært at replikere for at foretage fejlfinding af problemet.

Derfor kommer JVM med nogle parametre, der dumper heap-hukommelse i en fysisk fil, som senere kan bruges til at finde utætheder:

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

Et par punkter at bemærke her:

• HeapDumpOnOutOfMemoryError pålægger JVM at dumpe bunke i fysisk fil i tilfælde af OutOfMemoryError
• HeapDumpPath angiver stien, hvor filen skal skrives; ethvert filnavn kan gives; dog hvis JVM finder en tag i navnet, proces-id for den aktuelle proces, der forårsager hukommelsesfejl, føjes til filnavnet med .hprof format
• OnOutOfMemoryError bruges til at udstede nødkommandoer, der skal udføres i tilfælde af hukommelsesfejl; korrekt kommando skal bruges i løbet af cmd args. For eksempel, hvis vi vil genstarte serveren, så snart der ikke er mere hukommelse, kan vi indstille parameteren:

-XX: OnOutOfMemoryError = "nedlukning -r"

• BrugGCOverheadLimit er en politik, der begrænser den andel af den virtuelle computers tid, der bruges i GC før en Ikke mere hukommelse fejl kastes

6. 32/64 bit

I OS-miljøet, hvor både 32 og 64-bit pakker er installeret, vælger JVM automatisk 32-bit miljøpakker.

Hvis vi vil indstille miljøet til 64 bit manuelt, kan vi gøre det ved hjælp af nedenstående parameter:

-d

OS-bit kan være enten 32 eller 64. Flere oplysninger om dette kan findes her.

7. Diverse

• -server: aktiverer “Server Hotspot VM”; denne parameter bruges som standard i 64 bit JVM
• -XX: + UseStringDeduplication: Java 8u20 har introduceret denne JVM-parameter til at reducere den unødvendige brug af hukommelse ved at oprette for mange forekomster af det samme Snor; dette optimerer bunkehukommelsen ved at reducere duplikat Snor værdier til et enkelt globalt tegn [] array
• -XX: + BrugLWPSynchronization: sæt LWP (Letvægtsproces) - baseret synkroniseringspolitik i stedet for trådbaseret synkronisering
• -XX: LargePageSizeInBytes: indstiller den store sidestørrelse, der bruges til Java-bunken; det tager argumentet i GB / MB / KB; med større sidestørrelser kan vi bedre udnytte hardware-ressourcer til virtuel hukommelse dette kan dog medføre større pladsstørrelser for PermGen, hvilket igen kan tvinge til at reducere størrelsen på Java-bunkeplads
• -XX: MaxHeapFreeRatio: angiver den maksimale procentdel af dyngen fri efter GC for at undgå at krympe.
• -XX: MinHeapFreeRatio: angiver den mindste procentdel af dyngen fri efter GC for at undgå ekspansion for at overvåge bunkeforbruget kan du bruge VisualVM leveret med JDK.
• -XX: SurvivorRatio: Forhold af eden/overlevende plads størrelse - for eksempel, -XX: SurvivorRatio = 6 indstiller forholdet mellem hver overlevende plads og Eden plads at være 1: 6,
• -XX: + UseLargePages: Brug hukommelse til stor side, hvis den understøttes af systemet; Bemærk, at OpenJDK 7 har tendens til at gå ned, hvis du bruger denne JVM-parameter

• -XX: + UseStringCache: muliggør caching af almindeligt tildelte strenge, der er tilgængelige i Snor pool

• -XX: + UseCompressedStrings: brug en byte [] skriv til Snor objekter, der kan repræsenteres i rent ASCII-format
• -XX: + OptimizeStringConcat: det optimeres Snor sammenkædningsoperationer, hvor det er muligt

8. Konklusion

I denne hurtige artikel lærte vi om nogle vigtige JVM-parametre - som kan bruges til at tune og forbedre den generelle applikationsydelse.

Nogle af disse kan også bruges til fejlfindingsformål.

Hvis du vil udforske referenceparametrene mere detaljeret, kan du komme i gang her.