Technisch artikel

Dit artikel is bijgewerkt met de GC Portal software voor Linux en Java Desktop System (JDS), beschikbaar voor zowel Sun Java System Application Server 7 (voorheen Sun ONE Application Server 7 (S1AS7)) als Tomcat servers. Oorspronkelijk was het alleen beschikbaar voor Solaris en Windows. Deze versie van de GC Portal software bevat ook VisualGC geïntegreerd in de GC Portal.

De GC Portal maakt analyse en performance tuning van Java applicaties mogelijk vanuit een garbage collection (GC) perspectief door het ontginnen van de verbose:gc logs gegenereerd door de JVM. GC Portal is een one-stop pagina voor GC kwesties en bevat een uitgebreide verzameling van whitepapers, case studies en ander materiaal. De Portal is bedoeld voor gebruik met HotSpot JVM van Sun Microsystems, gedistribueerd als onderdeel van Java 2, Standard Edition (J2SE). Het gebruik van de GC Portal stelt ontwikkelaars in staat om applicatie- en JVM-gedrag te modelleren vanuit een GC-perspectief. Dit artikel introduceert het ontwerp en de eigenschappen van de GC Portal, om ontwikkelaars in staat te stellen het te gebruiken als een hulpmiddel voor het analyseren en tunen van GC.

De GC Portal vereist het gebruik van de volgende schakelaars door de JVM voor het genereren van verbose:gc logs die door de Portal worden verwerkt voor analyse.

 -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails 

Andere JVM-switches hoeven niet gebruikt te worden voor het genereren van de juiste logs voor GC Portal, maar kunnen worden toegevoegd als dat nodig wordt geacht voor het afstemmen en dimensioneren van de JVM en de applicatie. Opmerking: -XX switches zijn niet-standaard en zijn ook onderhevig aan verandering zonder aankondiging in toekomstige JVM releases.

Applicatie Modellering en Performance Tuning vanuit een GC Perspectief

Modellering van Java applicaties maakt het mogelijk voor ontwikkelaars om onvoorspelbaarheid te verwijderen die wordt toegeschreven aan de frequentie en duur van pauzes voor garbage collection. Deze pauzes zijn direct gerelateerd aan:

• Aantal en totale grootte van gecreëerde en levende objecten
• Gemiddelde levensduur van deze objecten
• Grootte van de JVM heap

Gebaseerd op de analyse die door de GC Portal wordt geleverd voor een specifieke set van verbose:gc logbestanden die aan de Portal worden toegevoerd, kunnen ontwikkelaars een model bouwen dat hen helpt om de applicatie en het JVM gedrag beter te begrijpen.

De verbose:gc logs bevatten waardevolle informatie over:

• GC pauzetijden
• Frequentie van GC
• Looptijden van de applicatie
• Grootte van gecreëerde en vernietigde objecten
• Snelheid van objectcreatie
• Gebruikt geheugen bij elke GC

Het gedrag van de applicatie kan in kaart worden gebracht en geanalyseerd om de verschillende relaties tussen pauzeduur, frequentie van pauzes, object creatie snelheid, en vrijgemaakt geheugen. Analyse van deze informatie kan ontwikkelaars in staat stellen om de prestaties van een applicatie te tunen, GC-frequentie en verzameltijden te optimaliseren door het specificeren van de beste heap sizes, andere JVM-opties, en alternatieve GC-algoritmen voor een gegeven situatie.

Informatie afgeleid van verbose:gc Logs voor het analyseren en modelleren van GC-gedrag

Dit soort informatie kan worden gebruikt om de prestaties van het proces van garbage collection te tunen.

Gemiddelde GC-pauzes in de jonge en oude generatie

De gemiddelde tijd dat de applicatie wordt opgeschort terwijl garbage collection in de JVM wordt gedaan.

Gemiddelde GC-frequentie in de jonge en oude generatie

De periodiciteit waarmee de garbage collector in de jonge en de oude generatie draait. Dit kan worden verkregen omdat de tijdsinstantie van elke GC-activiteit wordt gelogd.

GC sequentiële overhead

Het percentage systeemtijd gedurende welke de toepassing wordt opgeschort om vuilnis op te halen. Berekend als Avg. GC pauze * Avg. GC frequentie * 100%

GC concurrent overhead

Het percentage systeemtijd gedurende welke garbage collection gelijktijdig met de applicatie plaatsvindt. Berekend als Avg. concurrent GC-tijd (veegfase) * Avg. concurrent GC-frequentie / aantal CPU’s

Geheugen dat door elke GC in de jonge en oude generatie wordt gerecycleerd

De totale hoeveelheid vuilnis die tijdens elke GC wordt verzameld

Allocatiesnelheid

De snelheid waarmee gegevens door de applicatie in de jonge generatie worden gealloceerd. Als de jonge-generatie-heap occupancy_at_start_of_current_gc=x, occupancy_at_end_of_previous_gc = y en de GC-frequentie 1 per seconde is, dan is de toewijzingssnelheid ongeveer x-y per seconde.

Promotion rate

De snelheid waarmee gegevens naar de oude generatie worden gepromoveerd.

Totaal door de applicatie gealloceerde gegevens

Dit is het totaal aan gegevens dat door de applicatie per transactie wordt gealloceerd.

De totale gegevens kunnen worden opgesplitst in kortetermijngegevens en langetermijngegevens

Langetermijngegevens zijn de gegevens die de GC-cycli van de jonge generatie overleven en naar de oude generatie worden overgebracht.

Kortetermijngegevens

De kortlevende gegevens die zeer snel sterven en in de jonge generatie worden verzameld. Dit kan worden berekend als Totale gegevens – Lange-termijngegevens.

Totale actieve gegevens

Dit is het totaal aan gegevens dat op een bepaald moment in leven is. Dit is van cruciaal belang voor het bouwen van een model voor het dimensioneren van de JVM-heap. Bijvoorbeeld, voor een belasting van 100 transacties per seconde, met lange-termijn gegevens van 50K per transactie die minimaal 40 seconden duren, zou de minimale geheugen footprint van de oude generatie moeten zijn

50K*40s*100 = 200M

Geheugenlekken

Deze kunnen worden gedetecteerd en “out of memory” fouten kunnen beter worden begrepen door het monitoren van de garbage verzameld bij elke sweep, zoals blijkt uit deze logs.

Flags and Switches for Generating GC Logs

Er is veel nuttige GC-gerelateerde informatie die de JVM kan loggen in een bestand. Deze informatie wordt door de GC Portal gebruikt om applicaties en de JVM vanuit een GC perspectief af te stemmen en te dimensioneren. Logs met gedetailleerde GC informatie worden gegenereerd wanneer een Java applicatie wordt uitgevoerd met de volgende switches:

– verbose:gc Deze flag zet het loggen van GC informatie aan. Beschikbaar in alle JVMs.

-XX:+PrintGCTimeStamps Geeft de tijdstippen weer waarop de GC’s plaatsvinden ten opzichte van de start van de applicatie. Alleen beschikbaar vanaf J2SE1.4.0.

-XX:+PrintGCDetails Geeft details over de GC’s, zoals:

• Grootte van de jonge en oude generatie voor en na GC’s
• Grootte van de totale heap
• Tijd die nodig is voor een GC in jonge en oude generatie
• Grootte van objecten gepromoveerd bij elke GC

Alleen beschikbaar vanaf JVM1.4.0.

Gebruik van het GC-portaal voor applicatiemodellering en performancetuning

Het GC-portaal kan worden gebruikt om het GC-gedrag van een applicatie beter te begrijpen, zodat de applicaties optimaal kunnen presteren onder “lean”, “peak” en “burst” omstandigheden. Het ondersteunt J2SE1.2.2, J2SE1.3, J2SE1.4 en J2SE1.4.1 en hoger, inclusief de twee nieuwe garbage collection implementaties, de Parallel Collector en de Concurrent Collector. Ontwikkelaars kunnen GC-logbestanden indienen en het gedrag van toepassingen analyseren op basis van deze logbestanden. Het beschouwt ook enkele applicatie- en omgevingsspecifieke informatie, waaronder:

• Transaction Rate of Server Load

  Dit is van toepassing op typische server-side applicaties die in een client-server configuratie werken. Voor dergelijke toepassingen is dit de snelheid waarmee de client een constante belasting genereert voor de server om te verwerken en is nuttig voor een steady-state analyse van de server. De steady-state-analyse kan verschillende scenario’s omvatten, zoals worst-case/piek/burst-situatie of een gemiddelde situatie. Deze informatie is niet verplicht. Indien zij niet beschikbaar of niet van toepassing is, kan zij worden genegeerd. In zo’n geval moet sommige informatie die door de Portal wordt gepresenteerd ook worden genegeerd, zoals:

  • Theoretische doorvoer
  • Korte termijn gegevens
  • Lange termijn gegevens

• Aantal processoren op de doelmachine

  Deze informatie wordt gebruikt om bepaalde berekeningen door de Portal uit te voeren, zoals de Concurrent GC overhead.

• JVM-versie gebruikt door de applicatie (1.2.2_xx, 1.3.x, 1.4.0, 1.4.1)

  Aangezien het verbose:gc log formaat niet standaard is, en er veranderingen zijn geweest van de JVM, is deze informatie nodig voor het GC Portal.

GC Portal Design

Het GC Portal bestaat uit vier engines:

• Analyzer en rapportage engine
• Grafische engine
• Intelligentie engine
• Sessie en opslag engine
• VisualGC

Analyzer en rapportage engine

• Laadt verbose:gc log files, mijnt ze en rapporteert:
  • GC pauzes in jonge en oude generatie
  • GC frequentie in jonge en oude generatie
  • Snelheid van toewijzing van objecten
  • Snelheid van promotie van objecten van jonge naar oude generatie
  • Totale GC-tijd
  • Totale Applicatietijd
  • Initiële en Uiteindelijke heapgrootte van jonge en oude generaties
  • GC sequentiële overhead
  • GC concurrent overhead
• Berekent en presenteert applicatie-gerelateerde informatie
  • Korte termijn data per transactie
  • Lange termijn data per transactie
  • Theoretische maximale throughput
  • CPU efficiency

  Deze informatie kan worden genegeerd voor applicaties die niet transactie-gebaseerd zijn, maar is relevant voor client side toepassingen of toepassingen die extreem gefaseerd gedrag kunnen vertonen.

• Geeft gedetailleerd GC-gerelateerd gedrag van de applicatie en JVM in de tijd
  • Gebruiker kan de GC data zien, gesampled op gekozen tijdsintervallen voor de gehele run.

  Deze gedetailleerde GC informatie gesampled op gekozen tijdsintervallen voor de gehele run is uiterst nuttig waar applicaties gevarieerd gedrag vertonen in de tijd, zoals gefaseerde, cyclische of willekeurig reagerende applicaties, en de gemiddelde samenvattende informatie zou kunnen worden scheefgetrokken als een resultaat. Deze gedetailleerde en bemonsterde informatie kan worden gebruikt om het applicatie en JVM gedrag te zien zoals het verandert in de tijd.

• Gedetailleerde geheugen recycling informatie in de tijd in jonge en oude generaties
  • Geheugen voor GC
  • Geheugen na GC
  • Geheugen vrijgemaakt bij elke GC
• Verouderingsinformatie van objecten in jonge generatie
  • Beschikbaar als -XX:+PrintTenuringDistribution switch is gebruikt om logs te genereren.

Figuur 1 is een momentopname van een voorbeeldrapport dat wordt gepresenteerd door de Analyzer engine van het GC Portal.

Figuur 1. Afbeelding 1. Momentopname van de analysemotor van het GC-portaal

Grafische motor

De meeste informatie die door de analysemotor in tabelvorm wordt gepresenteerd, kan grafisch worden geplot. Meerdere grafieken kunnen op dezelfde grafiek worden uitgezet om vergelijkingen te vergemakkelijken.

• Grafische presentatie van gedetailleerde tijdlijn GC-analyse
• Grafische presentatie van geheugenhergebruikinformatie bij elke GC
• Grafische vergelijking van GC-informatie uit verschillende logbestanden
• Grafische presentatie van Object Age Tenuring-informatie voor elke “Age”

Figuur 2. Snapshot van de Graphical Engine van de GC Portal

Intelligence Engine

De Intelligence Engine bestaat uit:

• Algemene aanbevelingen

  Dit gedeelte bevat algemene informatie en aanbevelingen voor het tunen van de GC-prestaties. Het portaal biedt geen dynamische aanbevelingen of automatische afstemming. De Aanbevelingen bevatten algemene informatie over hoe:

  • De GC pauze en frequentie te verminderen
  • De GC sequentiële overhead te verminderen
  • De heaps van de jonge en oude generatie te vergroten om een gegeven belasting aan te kunnen
  • Geheugenlekken op te sporen
  • Verzamelaars te kiezen
  • Verschillende JVM opties en switches te kiezen.
• Empirische modellering

  Rangschik de applicatie draait op basis van gegevens geanalyseerd uit meerdere verbose:gc logs. De gebruiker kan de bestanden kiezen (uit alle bestanden die werden geladen) voor modellering op basis van de volgende keuzes:

  • Transactiesnelheid
  • Aantal processoren
  • Jong generatie grootte
  • Old generatie grootte
  • JDK versie
  • Heap grootte

  De gebruiker kan de optimale JVM omgeving rangschikken op basis van de volgende criteria:

  • GC pauzes
  • GC sequentiële overhead
  • GC frequentie
  • CPU efficiency

  De gebruiker kan ook de grafische vergelijking van de verschillende runs bekijken.



Figuur 3. Momentopname van de intelligentiemotor van het GC-portaal

• Projecties voor dimensionering en tuning door middel van “what-if”-scenario’s

  Hoe het GC-gedrag zou kunnen veranderen bij verandering van de grootte van de jonge generatie. Deze functionaliteit is momenteel beperkt en werkt alleen op J2SE1.4.1 en hoger met de Concurrent Collector. Projectie-uitvoer toont potentiële veranderingen in:

  • GC pause
  • GC frequency
  • GC sequential load
  • CPU utilization (%)
  • Speedup
  • Allocation rate
  • Promotion rate
  • Size of Short-lived data
  • Size of long-lived data

• Case Studies

  Enkele echte wereld case studies over hoe af te stemmen vanuit een GC perspectief.

• White Papers

  Verwijzingen naar een aantal white papers met diepgaande details over GC tuning.

Session and Storage Engine

• Beheer gebruikerssessies
• Beheer en sla gebruikersprofielen op
• Beheer en sla gebruikersgegevens/logs veilig op
• Maak de gebruikers/datalogs beschikbaar voor referentie-weergave, en empirische modellering

Figuur 4. Momentopname van de Storage Engine van het GC Portal

VisualGC

Het hulpprogramma visualgc koppelt zichzelf aan een geïnstrumenteerde HotSpot JVM en verzamelt en toont grafisch de prestatiegegevens van garbage collection, class loader en HotSpot compiler. Het is opgenomen in het GC Portal voor het verzamelen van GC-gerelateerde informatie tijdens JVM runtime. GC Portal gebruikt het webstart hulpmiddel om de visuele GC-informatie in een browser uit te voeren en weer te geven. Meer details over dit gereedschap zijn beschikbaar op de CoolStuff – jvmstat pagina. Het ReadMe bestand voor het uitvoeren van VisualGC vanuit het GC Portal is ingebouwd in de GC Portal Software.

Recondities:

De auteur zou graag Mayank Srivastava, Nagendra Nagarajayya, Nandula Narasimham en S.R.Venkatraman bedanken voor hun bijdrage aan het GC Portal. De auteur zou ook graag de Sun JVM garbage collection architecten en experts John Coomes, David Detlefs, Steve Heller, Peter Kessler, Ross Knippel, Jon Masamitsu, James Mcilree en Y.S. Ramakrishna willen bedanken voor hun hulp en begeleiding bij dit werk. De auteur wil ook graag de leden van Sun’s JVM performance team, Timothy Cramer en Brian Doherty (auteur van VisualGC en jvmstat tools) bedanken voor hun hulp bij het integreren van VisualGC in GC Portal.

Over de auteur:

Alka Gupta is lid van de technische staf bij Sun Microsystems. Zij is verantwoordelijk voor de samenwerking met Sun’s ISV’s en partners om hen te helpen de opkomende Sun technologieën en platforms snel en efficiënt te adopteren. Ze werkt al bijna 7 jaar op het gebied van performance tuning op Sun platformen, en is al bijna 10 jaar werkzaam in deze industrie. Alka is afgestudeerd aan het Indian Institute of Technology (IIT), India.