Teknisk artikel

Denna artikel har uppdaterats för att inkludera GC Portal-programvaran för Linux och Java Desktop System (JDS), tillgänglig både för Sun Java System Application Server 7 (tidigare Sun ONE Application Server 7 (S1AS7)) och Tomcat-servrar. Ursprungligen gjordes den endast tillgänglig för Solaris och Windows. Den här versionen av GC Portal-programvaran innehåller också VisualGC integrerat i GC Portal.

GC Portal gör det möjligt att analysera och trimma prestandan för Java-program ur ett GC-perspektiv (garbage collection, skräpplockning) genom att utvinna de verbose:gc loggar som genereras av JVM. GC Portal är en enda sida för GC-frågor och innehåller en omfattande samling whitepapers, fallstudier och annat material. Portalen är avsedd att användas med HotSpot JVM från Sun Microsystems, som distribueras som en del av Java 2, Standard Edition (J2SE). GC Portal gör det möjligt för utvecklare att modellera program- och JVM-beteenden ur ett GC-perspektiv. I den här artikeln presenteras GC-portalens utformning och funktioner så att utvecklare kan använda den som ett verktyg för att analysera och ställa in GC.

GC-portalen kräver att JVM:n använder följande växlar för att generera verbose:gc loggar som behandlas av portalen för analys.

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

Andra JVM-switchar behöver inte användas för att generera lämpliga loggar för GC Portal, men kan läggas till om det anses lämpligt för att ställa in och dimensionera JVM:n och programmet. Observera: -XX-switchar är icke-standardiserade och kan också ändras utan förvarning i framtida JVM-versioner.

Applikationsmodellering och prestandatuning ur ett GC-perspektiv

Modellering av Java-applikationer gör det möjligt för utvecklare att avlägsna oförutsägbarhet som tillskrivs frekvensen och varaktigheten av pauser för garbage collection. Dessa pauser är direkt relaterade till:

• Antal och total storlek på objekt som skapats och lever
• Genomsnittlig livslängd för dessa objekt

Storlek på JVM-heap

Baserat på analysen som tillhandahålls av GC-portalen för en specifik uppsättning verbose:gc loggfiler som matas in till portalen, kan utvecklare bygga upp en modell som hjälper dem att förstå programmet och JVM:s beteende bättre.

De verbose:gc loggarna innehåller värdefull information om:

• GC-paustider
• Frekvens av GC
• Körningstider för programmet

Storlek på objekt som skapats och förstörts

• Sats för skapande av objekt

Historia som återanvänds vid varje GC

Applikationens beteende kan kartläggas och analyseras för att fastställa de olika sambanden mellan pausvaraktighet, frekvensen av pauserna, objektskapandefrekvens och frigjort minne. Analys av den här informationen kan göra det möjligt för utvecklare att trimma en applikations prestanda och optimera GC-frekvensen och hämtningstiderna genom att ange de bästa heapstorlekarna, andra JVM-alternativ och alternativa GC-algoritmer för en viss situation.

Information som härleds från verbose:gc-loggar för att analysera och modellera GC-beteende

Den här typen av information kan användas för att prestandamässigt trimma processen för garbage collection.

Genomsnittliga GC-pauser i den unga och gamla generationen

Den genomsnittliga tiden som programmet avbryts medan skräpinsamlingen utförs i JVM:n.

Genomsnittlig GC-frekvens i den unga och gamla generationen

Den periodicitet med vilken skräpinsamlaren körs i den unga och gamla generationen. Detta kan erhållas eftersom tidsinstansen för varje GC-aktivitet loggas.

GC sequential overhead

Procentuell andel av systemtiden för vilken programmet avbryts för att skräpinsamlingen ska äga rum. Beräknas som Avg. GC-paus * Avg. GC-frekvens * 100 %

GC concurrent overhead

Procentuell andel av systemtiden för vilken sophämtning sker samtidigt med programmet. Beräknas som Genomsnittlig samtidig GC-tid (svepfas) * Genomsnittlig samtidig GC-frekvens / antal CPU:er

Minne som återanvänds av varje GC i den unga och gamla generationen

Den totala mängden skräp som samlas in under varje GC.

Allokeringshastighet

Hastigheten med vilken data allokeras av programmet i den unga generationen. Om den unga generationens heap occupancy_at_start_of_current_gc=x, occupancy_at_end_of_previous_gc = y och GC-frekvensen är 1 per sekund, är allokeringshastigheten ungefär x-y per sekund.

Promotion rate

Hastigheten med vilken data främjas till den gamla generationen.

Totala data som allokeras av programmet

Det här är de totala data som allokeras av programmet per transaktion.

Total data kan delas upp i kortsiktiga data och långsiktiga data

Långsiktiga data är det som överlever den unga generationens GC-cykler och befordras till den gamla generationen.

Kortsiktiga data

De kortlivade data som dör mycket snabbt och samlas in i den unga generationen. Detta kan beräknas som total data – långtidsdata.

Total aktiv data

Detta är den totala data som lever vid varje tidpunkt. Detta är avgörande för att bygga upp en modell för dimensionering av JVM-heap. Till exempel, för en belastning på 100 transaktioner per sekund, med långtidsdata på 50 000 per transaktion som varar i minst 40 sekunder, skulle den gamla generationens minsta minnesavtryck behöva vara

50K*40s*100 = 200M

Minnesläckor

Dessa kan upptäckas och fel som leder till att minnet tar slut kan förstås bättre genom att man övervakar den skräp som samlas in vid varje svepning, vilket framgår av dessa loggar.

Flaggor och växlar för att generera GC-loggar

Det finns mycket användbar GC-relaterad information som JVM kan logga i en fil. Denna information används av GC Portal för att ställa in och dimensionera program och JVM ur ett GC-perspektiv. Loggar med detaljerad GC-information genereras när ett Java-program körs med följande inställningar:

– verbose:gc Den här flaggan aktiverar loggningen av GC-information. Tillgänglig i alla JVM:er.

-XX:+PrintGCTimeStamps Skriver ut de tider då GC:erna sker i förhållande till starten av programmet. Endast tillgänglig från och med J2SE1.4.0.

-XX:+PrintGCDetails Ger detaljer om GC:

• Storlek på den unga och gamla generationen före och efter GC:

Storlek på den totala heap:

• Tid som det tar för en GC att hända i den unga och gamla generationen:

Storlek på de objekt som främjas vid varje GC:

Finns endast från JVM1.4.0.

Användning av GC-portalen för programmodellering och prestandatrimning

GC-portalen kan användas för att bättre förstå ett programs GC-beteende så att man kan prestandatrimma och dimensionera programmen så att de kan köras optimalt under magra förhållanden, toppar och störningar. Den stöder J2SE1.2.2.2, J2SE1.3, J2SE1.4 och J2SE1.4.1 och framåt, inklusive de två nya implementeringarna för sophämtning, Parallel Collector och Concurrent Collector. Det gör det möjligt för utvecklare att skicka in GC-loggfiler och analysera applikationens beteende baserat på dessa loggfiler. Den tar också hänsyn till viss applikations- och miljöspecifik information, bland annat:

• Transaktionshastighet eller serverbelastning

  Detta gäller för typiska serverbaserade applikationer som drivs i en klient-server-konfiguration. För sådana tillämpningar är detta den hastighet med vilken klienten kan generera en jämn belastning som servern ska bearbeta och är användbar för en analys av serverns jämna tillstånd. Analysen av det stationära läget kan omfatta flera scenarier, t.ex. en situation med värsta fall/spets/storstopp eller en genomsnittlig situation. Denna information är inte obligatorisk. Om den inte är tillgänglig eller tillämplig kan den ignoreras. I ett sådant fall bör även viss information som presenteras av portalen ignoreras, bland annat:

  Teoretisk genomströmning

Kortsiktiga data

• Långsiktiga data

Antal processorer på målmaskinen

Denna information används för att portalen ska kunna göra vissa beräkningar, till exempel för att beräkna överskottet för Concurrent GC.

GC Portal Design

GC Portal består av fyra motorer:

• Analyzer and reporting engine
• Graphical engine
• Intelligence engine

Session and storage engine

• VisualGC

Analyzer and Reporting Engine

• Läser in verbose:gc loggfiler, bearbetar dem och rapporterar:
  • GC-pauser i unga och gamla generationer
  • GC-frekvens i unga och gamla generationer

  Fördelning av objekt

• Förflyttning av objekt. från ung till gammal generation

Total GC-tid

• Total ansökningstid

Initial- och slutstorlek för unga och gamla generationer

• GC sekventiell overhead

GC concurrent overhead

Beräknar och presenterar tillämpningsrelaterad information

Kortsiktiga data per transaktion
• Långsiktiga data per transaktion
• Teoretiskt maximalt genomflöde
• CPU-effektivitet

Denna information kan ignoreras för tillämpningar som inte är transaktionsbaserade, men är relevant för klientsidan eller för tillämpningar som kan uppvisa extremt fasadbeteende.

Denna detaljerade GC-information, samplad med valda tidsintervaller för hela körningen, är ytterst användbar när applikationer uppvisar ett varierat beteende över tiden, som t.ex. fasade, cykliska eller slumpmässigt reaktiva applikationer och den genomsnittliga sammanfattningsinformationen kan vara snedvriden som ett resultat. Denna detaljerade och samplade information kan användas för att se applikationens och JVM:s beteende när det förändras över tiden.

Information om åldrande av objekt i unga generationer

• Tillgänglig om växeln -XX:+PrintTenuringDistribution används för att skapa loggar.

Figur 1 är en ögonblicksbild av en exempelrapport som presenteras av Analyzer-motorn i GC Portal.

Figur 1. Snapshot av analysmotorn från GC Portal

Grafisk motor

De flesta av de uppgifter som presenteras av analysmotorn i tabellform kan plottas grafiskt. Flera diagram kan plottas på samma graf för att underlätta jämförelser.

• Grafisk presentation av detaljerad tidslinje GC-analys

Grafisk presentation av information om återanvändning av minne vid varje GC

• Grafisk jämförelse av GC-information från olika loggfiler
• Grafisk presentation av information om objektålderns hållbarhet för varje ”ålder”

Figur 2. Snapshot av GC-portalens grafiska motor

Intelligence Engine

Intelligence Engine består av:

• Allmänna rekommendationer

  I det här avsnittet finns dokument med allmän information och rekommendationer om hur man ställer in GC:s prestanda. Portalen ger inga dynamiska rekommendationer eller automatisk inställning. Rekommendationerna innehåller allmän information om hur man:

  • Reducerar GC-paus och frekvens
  • Reducerar GC:s sekventiella overhead
  • Storleksanpassar den unga och den gamla generationens heaps för att hantera en given belastning
  • Detekterar minnesläckage
  • Väljer insamlare
  • Väljer olika JVM-alternativ och växlar.
• Empirisk modellering

  Rangordna programkörningar baserat på data som analyseras från flera verbose:gc loggar. Användaren kan välja filer (bland alla som laddades) för modellering baserat på följande val:

  Transaktionshastighet

Antal processorer Unga generationens storlek Gamla generationens storlek JDK-version

• Heapstorlekar

Användaren kan rangordna den optimala JVM-miljön baserat på följande kriterier:

GC pauses GC sequential overhead GC frequency CPU efficiency

Användaren kan också visa den grafiska jämförelsen av de olika körningarna.

Figur 3. Snapshot av intelligensmotorn i GC Portal

Allokeringshastighet

Storlek på data med lång livslängd

Fallstudier

Några fallstudier från den verkliga världen om hur man kan ställa in från ett GC-perspektiv. White Papers

Pekare till några white papers med djupgående detaljer om GC-justering.

Session and Storage Engine

Hantera användarsessioner
• Hantera och lagra användarprofiler
• Hantera och lagra användardata/loggar på ett säkert sätt
• Göra användardata/dataloggar tillgängliga för referensvisningar och empirisk modellering

Figur 4. Snapshot av GC-portalens lagringsmotor

VisualGC

Verktyget visualgc kopplar sig till en instrumenterad HotSpot JVM och samlar in och visar grafiskt data om prestanda för skräpplockning, klassinläsare och HotSpot-kompilator. Det ingår i GC-portalen för att samla in GC-relaterad information vid JVM-körning. GC Portal använder webstart-verktyget för att köra och visa den visuella GC-informationen i en webbläsare. Mer information om detta verktyg finns på sidan CoolStuff – jvmstat. ReadMe-filen för att köra VisualGC från GC Portal är inbyggd i GC Portal Software.

Acknowledgments:

Författaren vill tacka Mayank Srivastava, Nagendra Nagarajayya, Nandula Narasimham och S.R.Venkatramanan för deras bidrag till GC Portal. Författaren vill också tacka Sun JVM garbage collection arkitekter och experter John Coomes, David Detlefs, Steve Heller, Peter Kessler, Ross Knippel, Jon Masamitsu, James Mcilree och Y.S. Ramakrishna för deras hjälp och vägledning i detta arbete. Författaren vill också tacka medlemmarna i Suns JVM-prestandateam, Timothy Cramer och Brian Doherty (författare till verktygen VisualGC och jvmstat) för deras hjälp med att integrera VisualGC i GC Portal.

Om författaren:

Alka Gupta är medlem av den tekniska personalen på Sun Microsystems. Hon är ansvarig för att arbeta med Suns ISV:s och partners för att hjälpa dem att snabbt och effektivt ta till sig nya tekniker och plattformar från Sun. Hon har arbetat med prestandatuning på Sun-plattformar i nästan 7 år och har varit verksam i branschen i nästan 10 år. Alka tog examen från Indian Institute of Technology (IIT) i Indien.