Teknisk artikel

Denne artikel er blevet opdateret for at inkludere GC Portal-softwaren til Linux og Java Desktop System (JDS), som er tilgængelig både for Sun Java System Application Server 7 (tidligere Sun ONE Application Server 7 (S1AS7)) og Tomcat-servere. Oprindeligt blev det kun stillet til rådighed for Solaris og Windows. Denne version af GC Portal-softwaren indeholder også VisualGC integreret i GC Portal.

GC Portal muliggør analyse og ydelsesjustering af Java-programmer ud fra et garbage collection (GC)-perspektiv ved at udvinde de verbose:gc logfiler, der genereres af JVM’en. GC Portal er en one-stop-side for GC-spørgsmål og indeholder en omfattende samling af whitepapers, casestudier og andet materiale. Portalen er beregnet til at blive brugt sammen med HotSpot JVM fra Sun Microsystems, der distribueres som en del af Java 2, Standard Edition (J2SE). Ved at bruge GC Portal kan udviklere modellere applikations- og JVM-adfærd ud fra et GC-perspektiv. Denne artikel introducerer GC Portalens design og funktioner, så udviklere kan bruge den som et værktøj til analyse og tuning af GC.

GC Portal kræver, at JVM’en bruger følgende switches til generering af verbose:gc logs, som behandles af Portalen til analyse.

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

Det er ikke påkrævet at anvende andre JVM-switches til at generere de relevante logfiler til GC Portal, men de kan tilføjes, hvis det anses for hensigtsmæssigt med henblik på tuning og dimensionering af JVM’en og programmet. Bemærk: -XX-switches er ikke-standardiserede og kan også ændres uden varsel i fremtidige JVM-udgaver.

Applikationsmodellering og ydelsestuning fra et GC-perspektiv

Modellering af Java-applikationer gør det muligt for udviklere at fjerne uforudsigelighed, der tilskrives hyppigheden og varigheden af pauser for garbage collection. Disse pauser er direkte relateret til:

• Antal og samlet størrelse af objekter, der er oprettet og i live
• Gennemsnitlig levetid for disse objekter
• Størrelse af JVM-heap

Baseret på den analyse, som GC Portal leverer for et specifikt sæt verbose:gc logfiler, der føres til portalen, kan udviklere opbygge en model, der hjælper dem med at forstå applikationen og JVM-adfærden bedre.

De verbose:gc logfiler indeholder værdifulde oplysninger om:

• GC pausetider

Hyppighed af GC Køretider for applikationen Størrelse af objekter, der er oprettet og destrueret Hastighed for oprettelse af objekter

• Hukommelse genbrugt ved hver GC

Anvendelsens adfærd kan kortlægges og analyseres for at bestemme de forskellige sammenhænge mellem pausens varighed, pausernes hyppighed, objektoprettelseshastighed og frigivet hukommelse. Analyse af disse oplysninger kan sætte udviklere i stand til at afstemme et programs ydeevne og optimere GC-frekvens og opsamlingstider ved at angive de bedste heap-størrelser, andre JVM-optioner og alternative GC-algoritmer for en given situation.

Informationer afledt fra verbose:gc-logfiler til analyse og modellering af GC-adfærd

Denne slags oplysninger kan bruges til at ydeevnetune processen med garbage collection.

Gennemsnitlige GC-pauser i den unge og gamle generation

Den gennemsnitlige tid, programmet er suspenderet, mens garbage collection udføres i JVM’en.

Gennemsnitlig GC-frekvens i den unge og gamle generation

Den periodicitet, hvormed garbage collector kører i den unge og den gamle generation. Dette kan fås, da tidsinstansen for hver GC-aktivitet logges.

GC sekventielt overhead

Procentdelen af systemtiden, hvor programmet er suspenderet, for at garbage collection kan finde sted. Beregnet som Gennemsnitlig. GC pause * Avg. GC-frekvens * 100 %

GC concurrent overhead

Den procentdel af systemtiden, hvor garbage collection finder sted samtidig med programmet. Beregnet som Gennemsnitlig samtidig GC-tid (fejende fase) * Gennemsnitlig samtidig GC-frekvens / antal CPU’er

Hukommelse, der genbruges af hver GC i den unge og gamle generation

Den samlede skraldemængde, der indsamles under hver GC.

Allokeringshastighed

Den hastighed, hvormed data bliver allokeret af programmet i den unge generation. Hvis heap-belægning_at_start_of_current_gc=x, belægning_at_end_of_previous_gc = y og GC-frekvensen er 1 pr. sekund, er allokeringshastigheden ca. x-y pr. sekund.

Forfremmelseshastighed

Den hastighed, hvormed data bliver forfremmet til den gamle generation.

Samlede data allokeret af programmet

Dette er de samlede data, der allokeres af programmet pr. transaktion.

De samlede data kan opdeles i kortsigtede data og langsigtede data

Langsigtede data er det, der overlever den unge generations GC-cyklusser og forfremmes til den gamle generation.

Kortsigtede data

De kortlivede data, der dør meget hurtigt og opsamles i den unge generation. Dette kan beregnes som Samlede data – Langtidsdata.

Samlede aktive data

Dette er de samlede data, der er i live på et hvilket som helst tidspunkt. Dette er afgørende for opbygningen af en model til dimensionering af JVM-heap’en. For eksempel, for en belastning på 100 transaktioner pr. sekund med langtidsdata på 50K pr. transaktion, der varer mindst 40 sekunder, skal den gamle generations mindste hukommelsesaftryk være

50K*40s*100 = 200M

Hukommelseslækager

Disse kan opdages, og “out of memory”-fejl kan forstås bedre ved at overvåge den garbage, der indsamles ved hvert sweep, som det fremgår af disse logfiler.

Flag og switches til generering af GC-logs

Der findes en masse nyttige GC-relaterede oplysninger, som JVM’en kan logge i en fil. Disse oplysninger bruges af GC Portal til at indstille og dimensionere programmer og JVM’en ud fra et GC-perspektiv. Logfiler med detaljerede GC-oplysninger genereres, når et Java-program køres med følgende switches:

– verbose:gc Dette flag slår logning af GC-oplysninger til. Tilgængelig i alle JVM’er.

-XX:+PrintGCTimeStamps Udskriver de tidspunkter, hvor GC’erne sker i forhold til starten af programmet. Kun tilgængelig fra J2SE1.4.0.

-XX:+PrintGCDetails Giver oplysninger om GC’erne, f.eks.:

Størrelse af den unge og gamle generation før og efter GC’er Størrelse af den samlede heap Tid det tager for en GC at ske i den unge og gamle generation Størrelse af objekter, der promoveres ved hver GC

Er kun tilgængelig fra JVM1.4.0.

Anvendelse af GC-portalen til applikationsmodellering og præstationsjustering

GC-portalen kan bruges til bedre at forstå en applikations GC-adfærd med henblik på præstationsjustering og dimensionering af applikationer, så de kan køre optimalt under magre, spidsbelastede og burst-betingelser. Den understøtter J2SE1.2.2.2, J2SE1.3, J2SE1.4 og J2SE1.4.1 og fremefter, herunder de to nye garbage collection-implementeringer, Parallel Collector og Concurrent Collector. Den giver udviklere mulighed for at indsende GC-logfiler og analysere applikationsadfærd på grundlag af disse logfiler. Den tager også hensyn til nogle applikations- og miljøspecifikke oplysninger, herunder:

• Transaktionshastighed eller serverbelastning

  Dette gælder for typiske server-side applikationer, der opererer i en klient-server konfiguration. For sådanne applikationer er dette den hastighed, hvormed klienten kan generere en stabil belastning, som serveren skal behandle, og er nyttig til en analyse af serveren i stabil tilstand. Analysen af den stationære tilstand kan omfatte flere scenarier som f.eks. worst-case/peak/burst-situation eller en gennemsnitlig situation. Disse oplysninger er ikke obligatoriske. Hvis de ikke er tilgængelige eller ikke er relevante, kan de ignoreres. I så fald bør nogle af de oplysninger, der præsenteres af portalen, også ignoreres, herunder:

  Theoretisk gennemløb

Korttidsdata

• Langtidsdata

Antal processorer på målmaskinen

Disse oplysninger bruges til at foretage visse beregninger af portalen som f.eks. overhead for Concurrent GC.

GC Portal Design

GC Portal består af fire motorer:

• Analyzer and reporting engine

Graphical engine Intelligence engine Session and storage engine VisualGC

Analyzer and Reporting Engine

Indlæser verbose:gc logfiler, udforsker dem og rapporterer:
GC-pauser i ung og gammel generation GC-frekvens i ung og gammel generation Hastighed for tildeling af objekter
• Hastighed for forfremmelse af objekter fra ung til gammel generation

Total GC-tid Total anvendelsestid Initial og Final heap-størrelser i ung og gammel generation GC sekventielt overhead GC concurrent overhead

Beregner og præsenterer applikationsrelaterede oplysninger

Kortfristede data pr. transaktion
• Langfristede data pr. transaktion

Theoretisk maksimalt gennemløb

• CPU-effektivitet

Disse oplysninger kan ignoreres for applikationer, der ikke er transaktionsbaserede, men er relevant for klientsideapplikationer eller applikationer, der kan udvise en ekstremt faseopdelt adfærd.

• Præsenterer detaljeret GC-relateret adfærd for programmet og JVM’en over tid
  • Brugeren kan se GC-data, der er udtaget med udvalgte tidsintervaller for hele kørslen.

  Disse detaljerede GC-oplysninger, der er udtaget med udvalgte intervaller for hele kørslen, er yderst nyttige, når programmer udviser varieret adfærd over tid, f.eks. programmer med faseopdelt, cyklisk eller tilfældigt reaktivitet, og de gennemsnitlige oversigtsoplysninger kan derfor være skæve. Disse detaljerede og samplede oplysninger kan bruges til at se applikationens og JVM’ens adfærd, som den ændrer sig over tid.

• Detaljerede oplysninger om genbrug af hukommelse over tid i unge og gamle generationer
  Hukommelse før GC

Hukommelse efter GC

• Hukommelse frigivet ved hver GC

Oplysninger om aldring af objekter i ung generation

• Fås, hvis -XX:+PrintTenuringDistribution-switch bruges til at generere logfiler.

Figur 1 er et øjebliksbillede af en eksempelrapport, der præsenteres af GC-portalens Analyzer-motor.

Figur 1. Snapshot af analysemotoren fra GC Portal

Grafisk motor

De fleste af de oplysninger, der præsenteres af analysemotoren i tabelform, kan plottes grafisk. Flere diagrammer kan plottes på den samme graf for at lette sammenligninger.

• Grafisk præsentation af detaljeret tidslinje GC-analyse

Grafisk præsentation af oplysninger om genbrug af hukommelse ved hver GC Grafisk sammenligning af GC-oplysninger fra forskellige logfiler

• Grafisk præsentation af oplysninger om objektalderen Tenuring-oplysninger for hver “alder”

Figur 2. Snapshot af den grafiske motor i GC-portalen

Intelligence Engine

Intelligence Engine består af:

• Generelle anbefalinger

  Dette afsnit indeholder dokumenter, der dækker generelle oplysninger og anbefalinger om tuning af GC-ydelse. Portalen giver ikke dynamiske anbefalinger eller automatisk tuning. Anbefalingerne omfatter generelle oplysninger om, hvordan man:

  • Reducerer GC-pause og -frekvens
  • Reducerer GC-sekventielt overhead
  • Dimensionerer den unge og gamle generations heaps til at håndtere en given belastning
  • Detekterer hukommelseslækager
  • Vælger collectors
  • Vælger forskellige JVM-optioner og switches.

Empirisk modellering

Ranger programmet kører baseret på data analyseret fra flere verbose:gc logfiler. Brugeren kan vælge de filer (blandt alle dem, der blev indlæst) til modellering baseret på følgende valgmuligheder:

Transaktionshastighed Antal processorer Unge generationsstørrelse Gamle generationsstørrelse
• JDK-version

Heap-størrelser

Brugeren kan rangordne det optimale JVM-miljø baseret på følgende kriterier:

GC pauser GC sekventielt overhead GC frekvens CPU effektivitet

Brugeren kan også se den grafiske sammenligning af de forskellige kørsler.



Figur 3. Snapshot af GC-portalens intelligensmotor

• Projektioner til dimensionering og tuning gennem “hvad nu hvis”-scenarier

  Hvordan GC-adfærd kan ændre sig med ændring i størrelsen af den unge generation. Denne funktionalitet er i øjeblikket begrænset og fungerer kun på J2SE1.4.1 og fremefter ved hjælp af Concurrent Collector. Fremskrivningsoutput viser potentielle ændringer i:

  • GC pause
  • GC frekvens
  • GC sekventiel belastning

  CPU udnyttelse (%)

• Speedup

Allokeringshastighed

• Promotionshastighed
• Størrelse af Short-lived data

Størrelse af langlivede data

Case Studies

Nogle casestudier fra den virkelige verden om, hvordan man kan indstille ud fra et GC-perspektiv. White Papers

Pointer til nogle white papers med dybdegående detaljer om GC-tuning.

Session and Storage Engine

Håndter brugersessioner Håndter og gemmer brugerprofiler
• Håndter og gemmer brugerdata/logfiler sikkert

Gør bruger-/datalogfilerne tilgængelige til referencevisning og empirisk modellering

Figur 4. Snapshot af GC-portalens lagringsmotor

VisualGC

Visualgc-værktøjet knytter sig til en instrumenteret HotSpot JVM og indsamler og viser grafisk data om garbage collection, class loader og HotSpot compiler-præstationsdata grafisk. Det er indarbejdet i GC Portal til indsamling af GC-relaterede oplysninger ved JVM-køringstid. GC Portal bruger webstart-værktøjet til at køre og vise de visuelle GC-oplysninger i en browser. Der findes flere oplysninger om dette værktøj på CoolStuff – jvmstat-siden. ReadMe-filen til at køre VisualGC fra GC Portal er indbygget i GC Portal-softwaren.

Anerkendelser:

Forfatteren vil gerne takke Mayank Srivastava, Nagendra Nagarajayya, Nandula Narasimham og S.R.Venkatramanan for deres bidrag til GC Portal. Forfatteren vil også gerne takke Sun JVM garbage collection-arkitekterne og eksperterne John Coomes, David Detlefs, Steve Heller, Peter Kessler, Ross Knippel, Jon Masamitsu, James Mcilree og Y.S. Ramakrishna for deres hjælp og vejledning i forbindelse med dette arbejde. Forfatteren vil også gerne takke medlemmerne af Suns JVM performance team, Timothy Cramer og Brian Doherty (forfatter af VisualGC- og jvmstat-værktøjerne) for deres hjælp til at integrere VisualGC i GC Portal.

Om forfatteren:

Alka Gupta er medlem af den tekniske stab hos Sun Microsystems. Hun er ansvarlig for samarbejdet med Suns ISV’er og partnere for at hjælpe dem med at indføre de nye Sun-teknologier og -platforme hurtigt og effektivt. Hun har arbejdet med ydelsestuning på Sun-platforme i næsten 7 år og har været i denne branche i næsten 10 år. Alka er uddannet fra Indian Institute of Technology (IIT), Indien.