Gids voor de belangrijkste JVM-parameters

1. Overzicht

In deze korte tutorial verkennen we de meest bekende opties die kunnen worden gebruikt om de Java Virtual Machine te configureren.

2. Expliciet heapgeheugen - Xms- en Xmx-opties

Een van de meest voorkomende prestatiegerelateerde praktijken is om het heap-geheugen te initialiseren volgens de toepassingsvereisten.

Daarom moeten we een minimale en maximale heapgrootte specificeren. Onderstaande parameters kunnen worden gebruikt om dit te bereiken:

-Xms [eenheid] -Xmx [eenheid]

Hier, eenheid geeft de eenheid aan waarin het geheugen (aangegeven door hoop grootte) moet worden geïnitialiseerd. Eenheden kunnen worden gemarkeerd als ‘G ' voor GB, 'M' voor MB en ‘K ' voor KB.

Als we bijvoorbeeld minimaal 2 GB en maximaal 5 GB aan JVM willen toewijzen, moeten we schrijven:

-Xms2G -Xmx5G

Beginnend met Java 8, de grootte van Metaspace is niet gedefinieerd. Zodra het de globale limiet bereikt, verhoogt JVM het automatisch. Om onnodige instabiliteit te overwinnen, kunnen we het instellen Metaspace maat met:

-XX: MaxMetaspaceSize = [eenheid]

Hier, metaspace-grootte geeft de hoeveelheid geheugen aan waaraan we willen toewijzen Metaspace.

Volgens de Oracle-richtlijnen is na het totale beschikbare geheugen de tweede meest invloedrijke factor het deel van de hoop gereserveerd voor de Young Generation. Standaard is de minimale grootte van de YG 1310 MB, en de maximale grootte is onbeperkt.

We kunnen ze expliciet toewijzen:

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

3. Garbagecollection

Voor een betere stabiliteit van de applicatie is het kiezen van het juiste Garbage Collection-algoritme van cruciaal belang.

JVM heeft vier soorten GC implementaties:

  • Seriële Garbage Collector
  • Parallelle vuilnisman
  • CMS Garbage Collector
  • G1 Garbage Collector

Deze implementaties kunnen worden gedeclareerd met de onderstaande parameters:

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

Meer details over Garbage Collection implementaties zijn hier te vinden.

4. GC-registratie

Om de status van de applicatie strikt te bewaken, moeten we altijd de JVM's controleren Garbage Collection prestatie. De eenvoudigste manier om dit te doen, is door het GC activiteit in voor mensen leesbaar formaat.

Met behulp van de volgende parameters kunnen we het GC activiteit:

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

UseGCLogFileRotation specificeert het rollend beleid voor logbestanden, net zoals log4j, s4lj, enz. NumberOfGCLogFiles geeft het maximale aantal logboekbestanden aan dat kan worden geschreven voor een enkele levenscyclus van een toepassing. GCLogFileSize specificeert de maximale grootte van het bestand. Tenslotte, loggc geeft de locatie aan.

Een punt om op te merken is dat er nog twee JVM-parameters beschikbaar zijn (-XX: + PrintGCTimeStamps en -XX: + PrintGCDateStamps) die kan worden gebruikt om datumgewijs tijdstempel in het GC logboek.

Als we bijvoorbeeld maximaal 100 willen toewijzen GC log-bestanden, elk met een maximale grootte van 50 MB en die u wilt opslaan in ‘/ home / user / log / ' locatie, kunnen we onderstaande syntaxis gebruiken:

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

Het probleem is echter dat er altijd één extra daemon-thread wordt gebruikt om de systeemtijd op de achtergrond te bewaken. Dit gedrag kan een knelpunt in de prestaties veroorzaken; daarom is het altijd beter om tijdens de productie niet met deze parameter te spelen.

5. Omgaan met geheugen

Het komt vaak voor dat een grote applicatie een geheugenfout krijgt, wat op zijn beurt resulteert in de applicatiecrash. Het is een zeer kritiek scenario en erg moeilijk te repliceren om het probleem op te lossen.

Daarom wordt JVM geleverd met enkele parameters die heap-geheugen in een fysiek bestand dumpen dat later kan worden gebruikt om lekken op te sporen:

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

Een paar punten om op te merken:

  • HeapDumpOnOutOfMemoryError instrueert de JVM om de heap in het fysieke bestand te dumpen in het geval van Onvoldoende geheugen fout
  • HeapDumpPath geeft het pad aan waarnaar het bestand moet worden geschreven; elke bestandsnaam kan worden opgegeven; als JVM echter een tag in de naam, wordt het proces-ID van het huidige proces dat de geheugenfout veroorzaakt, aan de bestandsnaam toegevoegd met .hprof formaat
  • OnOutOfMemoryError wordt gebruikt om noodopdrachten uit te voeren die moeten worden uitgevoerd in het geval van een geheugenstoring; juiste commando moet worden gebruikt in de ruimte van cmd args. Als we bijvoorbeeld de server willen herstarten zodra er onvoldoende geheugen is, kunnen we de parameter instellen:
-XX: OnOutOfMemoryError = "afsluiten -r"
  • UseGCOverheadLimit is een beleid dat het aandeel van de tijd van de virtuele machine dat in GC wordt doorgebracht vóór een OutOfMemory fout wordt gegenereerd

6. 32/64 bit

In de OS-omgeving waar zowel 32- als 64-bits pakketten zijn geïnstalleerd, kiest de JVM automatisch 32-bits omgevingspakketten.

Als we de omgeving handmatig op 64 bit willen instellen, kunnen we dat doen met onderstaande parameter:

-d

OS bit kan beide zijn 32 of 64. Meer informatie hierover vind je hier.

7. Misc

  • -server: schakelt "Server Hotspot VM" in; deze parameter wordt standaard gebruikt in 64 bit JVM
  • -XX: + UseStringDeduplication: Java 8u20 heeft deze JVM-parameter geïntroduceerd om onnodig geheugengebruik te verminderen door te veel exemplaren van hetzelfde te maken Draad; dit optimaliseert het heap-geheugen door het aantal duplicaten te verminderen Draad waarden naar een enkele globale char [] array
  • -XX: + GebruikLWPSynchronisatie: sets LWP (Lichtgewicht proces) - gebaseerd synchronisatiebeleid in plaats van op threads gebaseerde synchronisatie
  • -XX: LargePageSizeInBytes: stelt het grote paginaformaat in dat wordt gebruikt voor de Java-heap; het neemt het argument in GB / MB / KB; met grotere paginaformaten kunnen we beter gebruik maken van hardwarebronnen voor virtueel geheugen; Dit kan echter leiden tot grotere ruimte-afmetingen voor de PermGen, wat op zijn beurt kan dwingen om de grootte van de Java-heapruimte te verkleinen
  • -XX: MaxHeapFreeRatio: stelt het maximale percentage heap vrij na GC om krimp te voorkomen.
  • -XX: MinHeapFreeRatio: stelt het minimum percentage heap vrij na GC om uitbreiding te voorkomen; Om het heapgebruik te volgen, kunt u VisualVM gebruiken die met JDK wordt geleverd.
  • -XX: SurvivorRatio: Verhouding van Eden/grootte van de overlevende ruimte - bijvoorbeeld, -XX: SurvivorRatio = 6 stelt de verhouding tussen elk in overlevende ruimte en eden ruimte 1: 6 zijn,
  • -XX: + UseLargePages: gebruik een groot paginageheugen als dit wordt ondersteund door het systeem; houd er rekening mee dat OpenJDK 7 heeft de neiging te crashen bij gebruik van deze JVM-parameter

  • -XX: + UseStringCache: maakt caching mogelijk van algemeen toegewezen strings die beschikbaar zijn in het Draad zwembad

  • -XX: + UseCompressedStrings: gebruik een byte[] typ voor Draad objecten die kunnen worden weergegeven in puur ASCII-formaat
  • -XX: + OptimizeStringConcat: het optimaliseert Draad aaneenschakelingsbewerkingen waar mogelijk

8. Conclusie

In dit korte artikel hebben we enkele belangrijke JVM-parameters leren kennen - die kunnen worden gebruikt om de algemene applicatieprestaties af te stemmen en te verbeteren.

Sommige hiervan kunnen ook worden gebruikt voor foutopsporing.

Als je de referentieparameters in meer detail wilt verkennen, kun je hier aan de slag.


$config[zx-auto] not found$config[zx-overlay] not found