Articolo tecnico

Questo articolo è stato aggiornato per includere il software GC Portal per Linux e Java Desktop System (JDS), disponibile sia per Sun Java System Application Server 7 (precedentemente Sun ONE Application Server 7 (S1AS7)) che per i server Tomcat. Originariamente, era stato reso disponibile solo per Solaris e Windows. Questa versione del software GC Portal include anche VisualGC integrato nel GC Portal.

Il GC Portal permette l’analisi e la messa a punto delle prestazioni delle applicazioni Java dal punto di vista della garbage collection (GC) estraendo i verbose:gc log generati dalla JVM. GC Portal è una pagina unica per i problemi GC e include una vasta collezione di whitepaper, casi di studio e altro materiale. Il portale è destinato ad essere usato con HotSpot JVM di Sun Microsystems, distribuito come parte di Java 2, Standard Edition (J2SE). L’uso di GC Portal permette agli sviluppatori di modellare i comportamenti dell’applicazione e della JVM da una prospettiva GC. Questo articolo introduce il design e le caratteristiche del GC Portal, per permettere agli sviluppatori di usarlo come strumento per l’analisi e la messa a punto di GC.

Il GC Portal richiede l’uso dei seguenti switch da parte della JVM per la generazione di verbose:gc log che vengono elaborati dal Portal per l’analisi.

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

Altri switch della JVM non sono richiesti per essere usati per generare i log appropriati per GC Portal, ma possono essere aggiunti come considerato appropriato per il tuning e il dimensionamento della JVM e dell’applicazione. Nota: gli interruttori -XX non sono standard e sono anche soggetti a cambiamenti senza preavviso nelle future versioni della JVM.

Modellazione dell’applicazione e ottimizzazione delle prestazioni da una prospettiva GC

La modellazione delle applicazioni Java permette agli sviluppatori di rimuovere l’imprevedibilità attribuita alla frequenza e alla durata delle pause della garbage collection. Queste pause sono direttamente collegate a:

• Numero e dimensione totale degli oggetti creati e vivi
• Vita media di questi oggetti
• Dimensione dell’heap della JVM

In base all’analisi fornita da GC Portal per un set specifico di verbose:gc file di log alimentati al Portal, gli sviluppatori possono costruire un modello che li aiuta a capire meglio il comportamento dell’applicazione e della JVM.

I log verbose:gc contengono informazioni preziose su:

• Tempi di pausa GC
• Frequenza di GC
• Tempi di esecuzione dell’applicazione
• Dimensione degli oggetti creati e distrutti
• Rata di creazione degli oggetti
• Memoria riciclata ad ogni GC

Il comportamento dell’applicazione può essere tracciato e analizzato per determinare le diverse relazioni tra durata delle pause, la frequenza delle pause, il tasso di creazione degli oggetti e la memoria liberata. L’analisi di queste informazioni può permettere agli sviluppatori di mettere a punto le prestazioni di un’applicazione, ottimizzando la frequenza di GC e i tempi di raccolta specificando le migliori dimensioni di heap, altre opzioni JVM e algoritmi GC alternativi per una data situazione.

Informazioni derivate dai log verbose:gc per analizzare e modellare il comportamento di GC

Questo tipo di informazioni può essere usato per ottimizzare le prestazioni del processo di garbage collection.

Media delle pause GC nella giovane e vecchia generazione

Il tempo medio in cui l’applicazione è sospesa mentre la garbage collection viene fatta nella JVM.

Media della frequenza GC nella giovane e vecchia generazione

La periodicità con cui il garbage collector viene eseguito nella giovane e vecchia generazione. Questo può essere ottenuto dal momento che l’istanza temporale di ogni attività GC è registrata.

GC sequential overhead

La percentuale di tempo di sistema per cui l’applicazione è sospesa per la garbage collection. Calcolata come Media. GC pausa * GC media GC frequenza * 100%

GC concurrent overhead

La percentuale di tempo del sistema per cui il garbage collection avviene contemporaneamente all’applicazione. Calcolato come tempo medio di GC concorrente (fase di spazzamento) * frequenza media di GC concorrente / numero di CPU

Memoria riciclata da ogni GC nella giovane e vecchia generazione

La spazzatura totale raccolta durante ogni GC.

Tasso di allocazione

Il tasso al quale i dati vengono allocati dall’applicazione nella giovane generazione. Se la giovane generazione di heap occupancy_at_start_of_current_gc=x, occupancy_at_end_of_previous_gc = y e la frequenza di GC è 1 al secondo, allora il tasso di allocazione è approssimativamente x-y al secondo.

Tasso di promozione

Il tasso al quale i dati vengono promossi alla vecchia generazione.

Dati totali allocati dall’applicazione

Questo è il totale dei dati allocati dall’applicazione per transazione.

I dati totali possono essere divisi in dati a breve termine e dati a lungo termine

I dati a lungo termine sono quelli che sopravvivono ai cicli GC della giovane generazione e vengono promossi alla vecchia generazione.

Dati a breve termine

I dati a breve termine che muoiono molto rapidamente e vengono raccolti nella giovane generazione. Questo può essere calcolato come Dati totali – Dati a lungo termine.

Dati totali attivi

Questo è il totale dei dati vivi in qualsiasi momento. Questo è fondamentale per costruire un modello di dimensionamento dell’heap della JVM. Per esempio, per un carico di 100 transazioni al secondo, con dati a lungo termine di 50K per transazione che durano per un minimo di 40 secondi, l’impronta minima di memoria della vecchia generazione dovrebbe essere

50K*40s*100 = 200M

Memory leaks

Questi possono essere rilevati e gli errori “out of memory” possono essere meglio compresi monitorando la spazzatura raccolta ad ogni sweep come mostrato da questi log.

Flags e switch per la generazione di log di GC

C’è un sacco di informazioni utili relative al GC che la JVM può registrare in un file. Queste informazioni sono usate dal portale GC per sintonizzare e dimensionare le applicazioni e la JVM dal punto di vista del GC. I log contenenti informazioni dettagliate sul GC vengono generati quando un’applicazione Java viene eseguita con i seguenti switch:

– verbose:gc Questo flag attiva il log delle informazioni GC. Disponibile in tutte le JVM.

-XX:+PrintGCTimeStamps Stampa i tempi in cui i GC avvengono rispetto all’inizio dell’applicazione. Disponibile solo da J2SE1.4.0.

-XX:+PrintGCDetails Dà dettagli sui GC, come:

• Dimensione della generazione giovane e vecchia prima e dopo i GC
• Dimensione dell’heap totale
• Tempo necessario perché un GC avvenga nella generazione giovane e vecchia
• Dimensione degli oggetti promossi ad ogni GC

Disponibile solo da JVM1.4.0.

Usare il Portale GC per la modellazione delle applicazioni e l’ottimizzazione delle prestazioni

Il Portale GC può essere usato per capire meglio il comportamento GC di un’applicazione in modo da ottimizzare le prestazioni e dimensionare le applicazioni per farle funzionare in modo ottimale in condizioni di magra, picco e scoppio. Supporta J2SE1.2.2, J2SE1.3, J2SE1.4 e J2SE1.4.1 in poi, comprese le due nuove implementazioni di garbage collection, il Parallel Collector e il Concurrent Collector. Permette agli sviluppatori di inviare file di log GC e analizzare il comportamento dell’applicazione, basandosi su questi file di log. Considera anche alcune informazioni specifiche dell’applicazione e dell’ambiente, tra cui:

• Transaction Rate o Server Load

  Questo si applica alle tipiche applicazioni lato server che operano in una configurazione Client-Server. Per tali applicazioni, questo è il tasso al quale il client potrebbe generare un carico costante per il server da elaborare ed è utile per un’analisi dello stato stazionario del server. L’analisi dello stato stazionario può includere diversi scenari come il caso peggiore/il picco/la situazione di picco o una situazione media. Questa informazione non è obbligatoria. Se non è disponibile o non è applicabile, può essere ignorata. In tal caso, alcune delle informazioni presentate dal portale dovrebbero anche essere ignorate che includono:

  • Il throughput teorico
  • Dati a breve termine
  • Dati a lungo termine

• Numero di processori sulla macchina di destinazione

  Queste informazioni sono usate per fare certi calcoli dal portale come il Concurrent GC overhead.

• Versione JVM usata dall’applicazione (1.2.2_xx, 1.3.x, 1.4.0, 1.4.1)

  Poiché il formato del log verbose:gc non è standard, e ci sono stati dei cambiamenti dalla JVM, queste informazioni sono necessarie al portale GC.

Design del portale GC

Il portale GC è composto da quattro motori:

• Motore di analisi e reporting
• Motore grafico
• Motore di intelligenza
• Motore di sessione e archiviazione
• VisualGC

Motore di analisi e reporting

• Carica verbose:gc file di log, li analizza e fa rapporto:
  • Pause GC nella giovane e vecchia generazione
  • Frequenza GC nella giovane e vecchia generazione
  • Rata di assegnazione degli oggetti
  • Rata di promozione degli oggetti dalla giovane alla vecchia generazione
  • Totale tempo di GC
  • Totale tempo di applicazione
  • Dimensioni iniziali e finali degli heap delle giovani e vecchie generazioni
  • GC sequenziale
  • GC concurrent overhead
• Calcola e presenta informazioni relative all’applicazione
  • Dati a breve termine per transazione
  • Dati a lungo termine per transazione
  • Passaggio massimo teorico
  • EfficienzaCPU

  Questa informazione può essere ignorata per applicazioni che non sono basate su transazioni, ma è rilevante per le applicazioni lato client o quelle che potrebbero mostrare un comportamento estremamente sfasato.

• Presenta il comportamento dettagliato relativo al GC dell’applicazione e della JVM nel tempo
  • L’utente può visualizzare i dati GC, campionati a intervalli di tempo scelti per l’intera esecuzione.

  Queste informazioni GC dettagliate campionate a intervalli scelti per l’intera esecuzione sono estremamente utili quando le applicazioni mostrano un comportamento vario nel tempo, come le applicazioni a fasi, cicliche o casualmente reattive, e le informazioni medie di riepilogo potrebbero essere distorte come risultato. Queste informazioni dettagliate e campionate possono essere utilizzate per vedere il comportamento dell’applicazione e della JVM mentre cambia nel tempo.

• Informazioni dettagliate sul riciclo della memoria nel tempo nelle generazioni giovani e vecchie
  • Memoria prima del GC
  • Memoria dopo il GC
  • Memoria liberata ad ogni GC
• Informazioni sull’invecchiamento degli oggetti nella generazione giovane
  • Disponibile se lo switch -XX:+PrintTenuringDistribution è usato per generare i log.

La figura 1 è un’istantanea di un report di esempio presentato dal motore di analisi del portale GC.

Figura 1. Istantanea del motore di analisi di GC Portal

Motore grafico

La maggior parte delle informazioni che sono presentate dal motore Analyzer in forma tabellare possono essere tracciate graficamente. Più grafici possono essere tracciati sullo stesso grafico per aiutare i confronti.

• Presentazione grafica dell’analisi dettagliata del GC della timeline
• Presentazione grafica delle informazioni sul riciclo della memoria ad ogni GC
• Confronto grafico delle informazioni GC da vari file di log
• Presentazione grafica delle informazioni sull’invecchiamento degli oggetti per ogni “età”

Figura 2. Snapshot del motore grafico del GC Portal

Intelligence Engine

L’Intelligence Engine è composto da:

• Raccomandazioni generali

  Questa sezione fornisce documenti che coprono informazioni generali e raccomandazioni sulla messa a punto delle prestazioni del GC. Il portale non fornisce raccomandazioni dinamiche o tuning automatico. Le raccomandazioni includono informazioni generali su come:

  • Ridurre la pausa e la frequenza del GC
  • Ridurre l’overhead sequenziale del GC
  • Dimensionare gli heap di giovane e vecchia generazione per gestire un dato carico
  • Rilevare le perdite di memoria
  • Scegliere i collettori
  • Scegliere diverse opzioni e switch della JVM.
• Modellazione empirica

  Classifica l’applicazione in base ai dati analizzati da più verbose:gc log. L’utente può scegliere i file (tra tutti quelli caricati) per la modellazione in base alle seguenti scelte:

  • Tasso di transazione
  • Numero di processori
  • Dimensione della giovane generazione
  • Dimensione della vecchia generazione
  • Versione JDK
  • Dimensioni dell’heap

  L’utente può classificare l’ambiente JVM ottimale in base ai seguenti criteri:

  • GC pause
  • GC overhead sequenziale
  • GC frequenza
  • efficienzaCPU

  L’utente può anche visualizzare il confronto grafico delle varie esecuzioni.



Figura 3. Snapshot del motore di intelligenza del GC Portal

• Proiezioni per il dimensionamento e il tuning attraverso scenari “what-if”

  Come potrebbe cambiare il comportamento del GC con il cambiamento della dimensione della generazione giovane. Questa funzionalità è attualmente limitata e funziona solo su J2SE1.4.1 in poi usando il Concurrent Collector. L’output della proiezione mostra potenziali cambiamenti in:

  • GC pausa
  • GC frequenza
  • GC carico sequenziale
  • utilizzoCPU (%)
  • Speedup
  • Tasso di allocazione
  • Tasso di promozione
  • Dimensione dei dati a vita brevevissuto
  • Dimensione dei dati a vita lunga

• Studi di casi

  Alcuni studi di casi reali su come sintonizzare da una prospettiva GC.

• Libri bianchi

  Puntatori ad alcuni libri bianchi con dettagli approfonditi sulla messa a punto di GC.

Session e Storage Engine

• Gestire le sessioni utente
• Gestire e memorizzare i profili utente
• Gestire e memorizzare i dati/log degli utenti in modo sicuro
• Rendere i log degli utenti/dati disponibili per la visualizzazione di riferimento e la modellazione empirica

Figura 4. Snapshot del motore di archiviazione del GC Portal

VisualGC

Lo strumento visualgc si attacca a una JVM HotSpot strumentata e raccoglie e visualizza graficamente i dati di garbage collection, class loader e prestazioni del compilatore HotSpot. È incorporato in GC Portal per raccogliere informazioni relative alla GC durante il runtime della JVM. GC Portal usa lo strumento webstart per eseguire e visualizzare le informazioni visualGC in un browser. Maggiori dettagli su questo strumento sono disponibili alla pagina CoolStuff – jvmstat. Il file ReadMe per eseguire VisualGC dall’interno di GC Portal è incorporato nel software di GC Portal.

Riconoscimenti:

L’autore vorrebbe ringraziare Mayank Srivastava, Nagendra Nagarajayya, Nandula Narasimham e S.R.Venkatramanan per il loro contributo a GC Portal. L’autore vorrebbe anche ringraziare gli architetti e gli esperti di garbage collection della Sun JVM John Coomes, David Detlefs, Steve Heller, Peter Kessler, Ross Knippel, Jon Masamitsu, James Mcilree e Y.S. Ramakrishna per il loro aiuto e la loro guida in questo lavoro. L’autore vorrebbe anche ringraziare i membri del team Sun’s JVM performance, Timothy Cramer e Brian Doherty (autore degli strumenti VisualGC e jvmstat) per il loro aiuto nell’integrazione di VisualGC in GC Portal.

A proposito dell’autore:

Alka Gupta è un membro dello staff tecnico presso Sun Microsystems. È responsabile della collaborazione con gli ISV e i partner di Sun per aiutarli ad adottare le tecnologie e le piattaforme Sun emergenti in modo rapido ed efficiente. Lavora nell’area del tuning delle prestazioni su piattaforme Sun da quasi 7 anni, ed è in questo settore da quasi 10 anni. Alka si è laureata all’Indian Institute of Technology (IIT), India.