Jvm performance Tuning

1
Contatti
Marco Sabatini
Senior Software Engineer
sabatini.m@gmail.com
https://it.linkedin.com/in/sabatinimarco

• Introduzione
• Analisi delle performance
• Il Garbage Collector
• Gestione della memoria (Best Practices)
• Just in Time Compiler (JIT) HotSpot Tuning
• J2EE Performance
• Overview Performance Test J2EE Web Application
3
Agenda

1. Comprensione dell’architettura e i moduli interni della JVM (GC, JIT …)
2. Comprensione del contesto architetturale
3. Configurazione corretta dei parametri della JVM (Heap, Garbage Collector,
JIT compiler)
4. Classificazione e isolamento dei problemi riscontrati in ambiente di
produzione
5. Identificazione dello strumento più adattato alla tipologia di problema
6. Documentazione del problema utilizzando le informazioni di un eventuale
monitoraggio / profiling
4
Introduzione (Obiettivi)

• Introduzione
5
Agenda

Analisi delle performance può intervenire in
differenti fasi del ciclo di vita di un software:
• Design
• Testing
• Evolution / Maintenance
6
Analisi delle performance (Software Lifecycle)

• Input: Documento Requisiti
• Ruolo: Progettista Software
• Attività: deﬁnire l’architettura che soddisfa i
requisiti che richiedono standard di performance.
(es. Http Response time, SQL execution time… )
• Deliverables: Architettura Software
7
Analisi delle performance (Design)
Requirement
Analysis
Documento
Requisiti
Analisi Performance
No
Si
Completa?

8
Analisi delle performance (Testing)
• Input: Software/Architettura
• Ruolo: Tester
• Attività: definire un piano di test mirato
a verificare i requisiti di performance
• Deliverables: Piano di test
Software/Architettura
No
Si
Completa?
Definizione piano di test
D
Esecuzione
D
Completa?
No
Si

9
Analisi delle performance (Evolution / Maintenance)
• Input: Enhancement / Issue
• Ruolo: System Architect
• Attività:
• Deliverables: Documento di
assessment o intervento sistemistico
Argomento che sarà approfondito in questo corso.
Enhancement / Issue
Analisi Issue
D
Requirement Anlysis
D
Processo sviluppo Processo assessment

10
Analisi delle performance (Processo di assessment)
Analisi sistemistica
D
Identiﬁcazione Issue
D
Intervento tuning
D
Testing
D
Assessment documentale
D
Conﬁgurazione / tuning Applicativa
Esito positivo? SI
NO

La prima attività da svolgere è monitorare la CPU dei software Java che
stiamo analizzando. L’uso della CPU è diviso in due categorie:
• user Time: percentuale di tempo in cui la CPU esegue codice applicativo
• system Time: percentuale di tempo in cui la CPU esegue il codice del
kernel.
Se ad esempio l'applicazione esegue operazioni di I/O, è il kernel ad
eseguire il codice per leggere il ﬁle dal disco, o scrivere i dati nel buffer di
rete, e così via.
Il software che utilizza una risorsa di sistema fa in modo che l' applicazione
utilizzerà più “system Time”.
L’obbiettivo di prestazione è quello di utilizzare il maggior carico di CPU
in minor tempo possibile.
11
Analisi delle performance (Analisi Sistemistica - CPU Time 1/3)

Il valore di utilizzo della CPU è una media su un intervallo (5 secondi,
30 secondi , forse anche il meno 1 secondo).
Esempio
L'utilizzo medio della CPU di un programma è del 50% per i 10 minuti
necessari per l’esecuzione.
Se l'utilizzo della CPU va al 100 %, le performance del programma
raddoppieranno: verrà eseguito in 5 minuti.
SE vogliamo raddoppiare ancora, la CPU sarà ancora al 100%
durante 2,5 minuti necessari per completare il programma.
e cosi via…
12

Eseguire il tuning applicativo, signiﬁca comprendere prima di tutto la tipologia di
applicazione che deve essere eseguita.
Tuning
Applicazioni di tipo “Batch”: la CPU non deve essere mai nello stato “IDLE”.
L’obiettivo per applicazioni di questo tipo è quello di mantenere la CPU sempre attiva.
Applicazioni di tipo “server”: la CPU deve essere nello stato IDLE mentre aspetta di
processare una richiesta che sta arrivando.
Comandi da utilizzare
vmstat (unix), top (unix), process console (unix , windows , macos)
13

Monitorare l’utilizzo del disco ha due obbiettivi molto importanti:
1. se l’applicazione sta eseguendo molte operazioni di I/O è facile che
queste possano diventare un collo di bottiglia per l’intero sistema.
Esempio 1/2
% iostat -xm 5 
avg-cpu: %user %nice %system %iowait %steal %idle
23.45 0.00 37.89 0.10 0.00 38.56
Device: rrqm/s wrqm/s r/s w/s rMB/s
sda 0.00 11.60 0.60 24.20 0.02
wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
0.14 13.35 0.15 6.06 5.33 6.08 0.42 1.04
14
Analisi delle performance (Analisi Sistemistica - Disk Usage 1/3)

Esempio 2/2
% iostat -xm 5 
avg-cpu: %user %nice %system %iowait %steal %idle
35.05 0.00 7.85 47.89 0.00 9.20
Device: rrqm/s wrqm/s r/s w/s rMB/s
sda 0.00 0.20 1.00 163.40 0.00
wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
81.09 1010.19 142.74 866.47 97.60 871.17 6.08 100.00
15

2. Monitorare l’uso del disco anche se l’applicazione non esegue
molte operazioni di I/O può essere utile per capire il livello di
swapping della stessa. I computer possono eseguire una serie
di applicazioni che utilizzano una quantità molto maggiore di
memoria virtuale . Le applicazioni tendono a riservare più
memoria di quanto effettivamente ne hanno bisogno. Il sistema
operativo può mantenere le parti inutilizzate della memoria su
disco, e reinserirle nella memoria ﬁsica solo se è necessario.
Un sistema che sta scappando può muovere pagine di
memoria dal disco alla ram e viceversa. Questo generalmente
fa si che ci sia un peggioramento delle performance
16

Se l’applicazione che si sta eseguendo è un applicazione che
utilizza la rete, ad esempio un J2EE Application Server, è
necessario monitorare il traffico di rete.
Il traffico di rete è simile al disk usage: l’applicazione potrebbe
essere inefficiente poiché non si dispone della banda necessaria
oppure la quantità di dati scritti è superiore a quello che
l’interfaccia di rete può gestire.
I tool di sistema non sono sufficienti per l’analisi delle performance
di rete. In genere si limitano a indicare il numero di pacchetti inviati
o ricevuti.
17
Analisi delle performance (Analisi Sistemistica - Network Usage 1/2)

Esempio (nicstat)
% nicstat 5 
Time Int rKB/s wKB/s rPk/s wPk/s rAvs wAvs %Util Sat
17:05:17 e1000g1 225.7 176.2 905.0 922.5 255.4 195.6 0.33 0.00
In questo output ci sono circa 225 Kbps letti e circa 176 Kbps scritti.
L’utilizzo dell’interfaccia di rete è del 0,33%, che è un utilizzo efﬁciente della
rete.
18
Analisi delle performance (Analisi Sistemistica - Network Usage 1/2)

Per eseguire un analisi approfondita riguardante la Java Virtual
Machine (JVM) possiamo utilizzare i tools che essa ci mette a
disposizione:
• jcmd: stampa le classi, i thread e le informazioni relative alla VM
dei processi Java.
• jconsole: è una GUI per la visualizzazione di parametri di
processi Java.
• jhat: legge e analizza un memory dump. (Postprocessing utility).
• jmap: esegue il dump della dell’heap di memoria.
• jinfo: fornisce le system property con cui la JVM è partita.
• jstack: esegue il dump dello stack di un processo java.
19
Analisi delle performance (Analisi Sistemistica - Java Monitoring Tools
1/2)

• jstat: fornisce informazioni sul Garbage Collector e le attività di class-loading.
• jvisualvm: è un tool per monitorare la JVM, eseguire il proﬁling dei processi
Java e analizzare i dump dell’heap di memoria.
Questi tool coprono le seguenti tematiche:
• Basic VM information
• Thread information
• Class information
• Live GC analysis
• Heap dump postprocessing
• Proﬁling a JVM  
20
2/2)

Alcuni JVM Tools forniscono le informazioni base di un processo java. Ad
esempio da quanto tempo è in esecuzione, le JVM system properties
oppure la versione della JVM che lo sta eseguendo:
Esempi
% jcmd process_id VM.uptime
% jcmd process_id VM.system_properties
% jcmd process_id VM.version
% jcmd process_id VM.command_line
% jcmd process_id VM.system_flags [-all]
% jinfo -flags process_id (jvm tuning flags!!!)
 
21
Basic VM Information)

jconsole e jvisulavm forniscono informazioni in tempo reale circa il
numero di thread che stanno girando nell’applicazione.
Può anche essere molto utile analizzare lo stack dei thread per
determinare se sono bloccati o in esecuzione.
Esempio
% jstack process_id 
22
Thread Information)

L’informazione circa le classi in uso da un’applicazione, possono
essere fornite dai tools console oppure jstat. Quest’ultimo ci indica
anche il compilation time di una classe.
Lo vedremo più avanti (JIT Compiler)
23
Class Information)

Ogni tool riporta qualche informazione relativa all’attività di
Garbage Collector (GC).
• jconsole: visualizza il graﬁco relativo all’utilizzo dell’heap
• jcmd: può far eseguire operazioni al GC (release memoria)
• jstat: produce differenti viste di cosa sta facendo il GC.
24
Live GC Analysis)

Il dump dell’heap di memoria può essere
catturato tramite l’utilizzo del tool:
• jvisualvm.
• jmap.
L’analisi dell’heap può essere eseguita con:
• jhat.
• jvisualvm.
• Eclipse Mat.
25
Hep Dump post processing)

• I Profilers sono lo strumento più importante per JVM tuning analyst.
Ci sono molti profilers disponibili per Java, ognuno con i suoi
vantaggi e svantaggi.
• Quasi tutti gli strumenti di profiling Java sono scritti in Java. Di solito
funzionano aprendo un socket ( o un altro canale di
comunicazione ) per l'applicazione di destinazione . L' applicazione
di destinazione e lo strumento di profiling poi scambiano
informazioni sul comportamento della applicazione stessa.
• Anche lo strumento di profiling deve essere opportunamente tarato
(tuning) poiché potrebbe gestisce un enorme quantità di
informazioni.
• Sampling profilers / Instrumented profilers
26
Profiling JVM)

• Introduzione
27
Agenda

In informatica per garbage collection (letteralmente raccolta dei
riﬁuti, a volte abbreviato con GC) si intende una modalità
automatica di gestione della memoria, mediante la quale un
sistema operativo, o un compilatore e un modulo di run-time,
liberano le porzioni di memoria che non dovranno più essere
successivamente utilizzate dalle applicazioni. In altre parole, il
garbage collector annoterà le aree di memoria non più
referenziate, cioè allocate da un processo attivo, e le libererà
automaticamente. La garbage collection è stata inventata da John
McCarthy intorno al 1959 per il linguaggio di programmazione
Lisp. (fonte. Wikipedia)
28
Garbage Collector (Deﬁnizione)

29
Garbage Collector (Overview 1/2)
Esempio (Situazione):
• new di un array di 1000 bytes
• new di un array di 24 bytes
• ripetizione in un ciclo
• free degli array da 24 bytes
• gli array di 1000 bytes ancora in uso
Conclusione:
Heap è svuotato ma può allocare solamente 24 bytes.
Il GC ha la necessità di muovere i 1000 bytes array in
maniera contigua in modo tale da liberare lo spazio
rilasciato e poterlo riutilizzare.

30
Garbage Collector (Overview 2/2)
Funzionalità base del GC:
• trovare oggetti non più utilizzati
• rilasciare la memoria di questi oggetti
• compattare l’heap memory
Queste operazioni sono abbastanza semplici in contesti applicativi con un singolo
Thread. Le applicazioni Java EE sono fortemente multithread.
GC Threads Vs. Application Threads and stop-the-world pauses!!!

Tutti i garbage collectors lavorano splittando l’heap
in differenti generazioni:
• young generation
• eden: dove sono creati gli oggetti (minor GC).
• survivor: dove il GC mette gli oggetti che
sono ancora in uso (storicizzazione).
• old generation: dove vengono messi gli oggetti
che saranno analizzati da GC per essere
rilasciati (full GC).
31
Garbage Collector (Generational GC 1/6)
Survivor
Young Generation
Old Generation Eden

Analisi codice
La logica con cui il GC separa le generazioni è che molti oggetti
sono utilizzati per un periodo di tempo molto breve.
Ad esempio nel codice riportato gli oggetti intermedi utilizzati per
l’aritmetica sono rilasciati ad ogni iterazione.
32

33
Tutti gli oggetti sono allocati nell’eden
space. Entrambi i survivor spaces sono
inizializzati vuoti
Quando l’eden space si riempie viene
eseguito un “minor GC”

34
Gli oggetti che hanno delle references sono
posti nel primo survivor space. Gli oggetti
senza references vengono cancellati
dall’eden space
Al prossimo minor GC gli oggetti senza references
vengono sempre cancellati dall’eden space. Gli
oggetti con references e presenti già nel survivor
vengono posti nel survivor space S1, mentre quelli
provenienti dell’eden e con references vengono
posti nel survivor S0. Adesso abbiamo una
differenza negli oggetti storicizzati.

35
Al successivo minor GC il processo si ripete. I
survivor spaces si scambiano. Gli oggetti con
references vengono spostati in S0. I surviving
objects vengono storicizzati. L’eden e S1 vengono
ripuliti.
Dopo un minor GC quando gli oggetti
storicizzati raggiungono un determinato
“age threshold” (8 in questo esempio),
vengono promossi per la “old generation”

36
Mentre il processo si ripete gli oggetti
vengono promossi nell’old generation space
Quando verrà eseguito un major GC sulla old
generation, verranno rimossi tutti gli oggetti,
presenti in quest’area di memoria e senza più un
riferimento.

Young Generation Processing
• Stop dei thread per tempo minore.
• Quando si esegue un GC gli oggetti vengono tutti spostati nella
old generation oppure nei survivor. Così facendo l’eden è
automaticamente compattato.
Performance migliorata!
37
Garbage Collector (Generational Conclusioni)

• E’ il collector di default se l'applicazione è in esecuzione su un
computer di classe client (JVM a 32-bit su Windows o macchine con
singolo processore).
• Il Serial collector utilizza un singolo thread per analizzare l'heap.
• Tutti i thread dell’applicazione verranno bloccati mentre l'heap viene
analizzato (sia per un minor che per un full GC).
• Durante un full GC la old generation viene completamente compattata.
• Il Serial collector viene abilitato utilizzando il seguente ﬂag hotspot:
'-XX:+ UseSerialGC’.
NB: per disabilitare questo algoritmo bisogna necessariamente
speciﬁcarne un altro.
38
Garbage Collector (GC Algotithms - Serial)

• Questo è il collector di default per le macchine di classe server (macchine Unix multi-CPU e
qualsiasi JVM a 64-bit).
• Il Throughput collector utilizza più thread per analizzare le young generation, il che rende il
minor GC molto più veloce rispetto a quando si utilizza l’algoritmo Serial.
• Il Throughput collector può utilizzare più thread per analizzare anche la old generation.
Questo è il comportamento predefinito nella JDK 7 e nelle versioni successive.
• E’ abilitato in JDK v.7 specificando il flag ‘-XX:+ UseParallelOldGC.
• Spesso viene indicato come ParallelGC essendo multithreading.
• Il Throughput collector blocca tutti i thread applicativi sia durante un minor GC sia durante
un full GC,e compatta completamente la old generation nel corso di un full GC.
• Se non è attivato è necessario, utilizzare i flags: ‘-XX:+UseParallelGC -XX:
+UseParallelOldGC’.
39
Garbage Collector (GC Algotithms - Throughput)

• Il CMS collector è progettato per eliminare le lunghe pause associate ai full GC eseguiti tramite l’algoritmo
Throughput e Serial.
• Il CMS collector blocca tutti i thread applicativi durante un minor GC minore, che viene eseguito con più thread.
• Il CMS collector utilizza un algoritmo diverso per analizzare le young generation (-XX:+UseParNewGC) rispetto
Throughput collector (-XX:+UseParallelGC).Invece di fermare i thread delle applicazioni nel corso di un full GC,
CMS utilizza uno o più thread in background per eseguire periodicamente la scansione della old generation e
rilasciare la memoria degli oggetti senza riferimenti.
• Questo rende CMS un collector di tipo low-pause: i thread applicativi sono bloccati soltanto durante un minor
GC e per alcuni brevi periodi di tempo come ad esempio la scansione in background della old generation. Il
tempo complessivo di pausa dei thread applicativi è molto inferiore rispetto ai collettori Serial e Throughput.
• In compenso vi è un aumento dell'utilizzo della CPU: deve esserci un'adeguata CPU disponibile per il thread in
background utilizzato dal collector per eseguire lo scan dell’heap allo stesso tempo in cui i thread applicativi
stanno girando. Se il collettore non ha abbastanza risorse di CPU per completare i suoi task, verrà ripristinato il
collettore Serial.
• Il CMS collector è abilitato speciﬁcando i ﬂags ‘-XX:+UseConcMarkSweepGC -XX:+UseParNewGC’ (che
sono entrambi false di default).
40
Garbage Collector (GC Algotithms - CMS)

• Il G1 (o Garbage First) collector è progettato per analizzare heap di grandi dimensioni (superiore a circa
4 GB) con pause minime.
• Divide l’heap in un certo numero di regioni, ma è ancora un collector di tipo generazionale.
Esso blocca tutti i thread applicativi quando analizza le young generations ed utilizza più thread per
spostare gli oggetti nelle aree di survivor oppure old generation.
G1 è un collector concorrente: la old generation viene analizzata dal background thread in che non ha
bisogno di fermare i thread delle applicazioni per eseguire la maggior parte del lavoro.
Poiché la old generation è divisa in regioni, G1 può pulire oggetti dalla questa generazione copiando da
una regione all'altra, questo significa che (almeno parzialmente) compatta l’heap durante la normale
lavorazione.
Con il G1 collector è molto meno probabile che l’heap sia soggetto a frammentazione.
Come CMS, GC ha necessità di CPU i thread in background hanno bisogno di cpu per la loro esecuzione.
G1 è abilitato specificando il flag -XX: + UseG1GC (che di default è false).
41
Garbage Collector (GC Algotithms - G1)

1. I quattro algoritmi GC disponibili adottano approcci diversi per
minimizzare l'effetto del GC su un'applicazione.
2. Il serial collector ha senso quando è disponibile una sola CPU oppure i
thread del GC possono inferire con l’applicazione.
3. Il Throughput collector è di default sulle altre macchine; massimizza il
throughput dell applicazione ma può essere soggetto a pause molto
lunghe.
4. Il CMS collector può collezionare la old generation mentre i thread
dell’applicazione sono attivi. Se vi è abbastanza CPU per l’esecuzione
dei thread di background, questo potrebbe evitare dei full GC.
6. Anche il G1 collector può concorrentemente collezionare la old
generation mentre i thread applicativi girano. Il suo design rende meno
probabile il full GC rispetto al CMS collector.  
42
Garbage Collector (GC Algotithms - Summary)

Come scegliere il collettore adatto?
• Contesto dell’applicazione
• Requisiti di performance dell’applicazione
• Batch Jobs (ad es. un full GC prende 0,5 sec su 5 min di esecuzione il 3,4%)
• Single CPU full GC == concurrent GC (background thread bloccano comunque
l’applicazione )
• CMS è il miglior collettore concorrente quando la dimensione dell’heap è piccola.
• G1 è stato progettato per dividere la old generation in sotto regioni, in questo modo scala
meglio per heap di grandi dimensioni.
43
Garbage Collector (GC Algotithms - Choosing)
Batch Application Http Server

Esempio:
• Java application con heap configurato a12Gb
• Il SO indirizza 8Gb in RAM e 4Gb nella
partizione di swap
• la JVM non conosce la gestione della
memoria del SO, questo meccanismo è
trasparente
• Seri problemi di performance se un full CG
viene eseguito mentre parte della memoria
l’applicazione è messa nella partizione di
swap.
• Non bisognerebbe mai configurare l’heap con
una dimensione maggiore della memoria
fisica della macchina
• Ozioni ‘-XmsN’ (initial) ‘-XmxN’ (max)
44
Garbage Collector (GC Tuning - Sizing heap)
12 Gb
4Gb
8Gb

• young generation abbastanza grande: meno full GC, stop più frequenti per alcuni tipi di collettore
(Serial, Throughtput) meno per altri (CMS, G1)
• old generation abbastanza grande: maggiori full GC, performance degradate in quel frangente di
tempo
Configuration flag
• -XX:NewRatio=N: Ad esempio configurare -XX:NewRatio=3 significa che la “ratio” tra la old e
la young generationè di 1:3, la dimensione combinata dell’eden e del survivor spaces sarà un
quarto dell’ heap.
• -XX:NewSize=N:Initial size of young generation
• -XX:MaxNewSize=N:Maximum size of young generation
• -XmnN:Shorthand for setting both NewSize and MaxNewSize to the same value
Initial Young Gen Size = Initial Heap Size / (1 + NewRatio)
45
Garbage Collector (GC Tuning - sizing Generations)

• Quando la JVM carica le classi mantiene traccia di alcune informazioni riguardanti
queste ultime.
• Java 7 mette queste informazioni in un’area dell’heap chiamata permgen. In Java 8
quest’area si chiama metaspace.
• Permgen e Metaspace non sono esattamente la stessa cosa.
• In Java 7 queste informazioni riguardano dati relativi alle classi; in Java 8 questi dati
sono inseriti in regioni speciali dell’heap.
• No instances, no reflection info. Runtime or compiler info.
• La size dovrebbe essere proporzionale al numero di classi che si sta utilizzando.
• -XX:PermSize=N, -XX:MaxPermSize=N: Permgen flags.
• -XX:MetaspaceSize=N, -XX:MaxMetaspaceSize=N: Metaspace flags.
• Configurare una size aumenta le performance di startup.
46
Garbage Collector (GC Tuning - sizing Permgen and Metaspace)

• Tutti i collector ad eccezione del Serial sono multithread
• I thread sono controllati dal ﬂag -XX:ParallelGCThreads=N
• Dato che lo operazioni del GC bloccano l’esecuzione dei thread
applicativi, la JVM deve usare risorse di CPU per minimizzare questi
tempi di blocco
• La JVM eseguirà un thread per ogni CPU presente
• La formula per calcolare il numero di thread è: ParallelGCThreads = 8 +
((N - 8) * 5 / 8)
• Se sulla macchina sta girando più di una JVM è buona norma limitare il
numero di questi thread altrimenti la CPU sarà maggiormente utilizzata.
47
Garbage Collector (Controlling Parallelism)

• Introduzione
48
Agenda

• Heap Histograms (Strumento per visualizzare problemi relativi ad allocazione eccessiva della memoria)
% jcmd {process_id} GC.class_histogram
% jmap -histo {process_id}
% jmap -histo:live {process_id} (force full GC)
num #instances #bytes class name
----------------------------------------------
1: 14000005 560000200 java.math.BigDecimal
2: 567 83100520 [Ljava.lang.Object;
3: 2250 165216 [C
4: 473 126096 [B
5: 528 56336 java.lang.Class
6: 2227 53448 java.lang.String
7: 428 13696 java.util.HashMap$Node
8: 200 9592 [I
9: 356 8544 java.util.LinkedList$Node
10: 87 6264 java.lang.reflect.Field
11: 194 6208 java.util.LinkedList
12: 103 6008 [Ljava.lang.String;
13: 46 5536 [Ljava.util.HashMap$Node;
14: 76 4864 java.net.URL
15: 107 4280 java.math.BigInteger
16: 256 4096 java.lang.Integer
49
Gestione della memoria (Best Practices - Heap Analysis 1/5)

• Heap Dumps (Analisi più dettagliata della memoria)
% jcmd {process_id} GC.heap_dump /path/to/heap_dump.hprof
% jmap -dump:live,ﬁle=/path/to/heap_dump.hprof {process_id} (force
full GC)
Per leggere il dump si può usare:
jhat
jvisualvm
eclipse mat
50
Gestione della memoria (Best Practices - Heap Analysis 2/5)

• Knowing which objects are consuming memory is the ﬁrst step
in knowing which objects to optimise in your code.  
• Histograms are a quick and easy way to identify memory issues
caused by creating too many objects of a certain type.  
• Heap dump analysis is the most powerful technique to track
down memory usage, though it requires some patience and ef‐
fort to be utilised well.  
51
Gestione della memoria (Best Practices Heap Analysis 3/5)

• Mancanza di memoria
“nativa” per la JVM.
• Permgen o Metaspace sono
pieni (es. J2EE env.)
• Il Java Heap è pieno poiché
ha troppi oggetti referenziati
• La JVM sta perdendo troppo
tempo per eseguire un GC. 
52

• -XX:+HeapDumpOnOutOfMemoryError 
Turning on this flag (which is false by default) will cause the JVM
to create a heap dump whenever an out of memory error is
thrown.
• -XX:HeapDumpPath=<path> This specifies the location where
the heap dump will be written; the default is java_pid<pid>.hprof
in the application’s current working directory. The path can
specify either a directory (in which case the default file name is
used), or the name of the actual file to produce.
• -XX:+HeapDumpAfterFullGC This generates a heap dump after
running a full GC.
• -XX:+HeapDumpBeforeFullGC This generates a heap dump
before running a full GC.
53

• Introduzione
54
Agenda

JIT Compiler (Definizione)
Un compilatore just-in-time o JIT permette un tipo di compilazione, conosciuta anche come
traduzione dinamica, con la quale è possibile aumentare le performance dei sistemi di
programmazione che utilizzano il bytecode, traducendo il bytecode nel codice macchina nativo in
fase di run-time.
L'obiettivo finale dei sistemi JIT è di combinare i vantaggi della compilazione del bytecode a quelli
della compilazione nativa, aumentando le prestazioni quasi al pari di una compilazione direttamente
in linguaggio macchina. (Wikipedia)
Ricompilazione dinamica
In informatica la ricompilazione dinamica è una tecnica di ottimizzazione implementata da molti
emulatori e macchine virtuali. Questa tecnica prevede che il codice sorgente di un programma venga
analizzato durante la sua esecuzione e ricompilato al fine di renderlo eseguibile e/o di migliorarne le
prestazioni d'esecuzione. La compilazione durante l'esecuzione permette di adattare il codice alla
macchina che lo sta eseguendo tenendo conto anche delle informazioni presenti durante
l'esecuzione, informazioni che un compilatore non possiede durante la classica compilazione statica.
(Wikipedia)
55
Just in Time Compiler (JIT - Overview)

• Esistono due tipologie di compilatori: client - server.
• il client comincia a compilare il codice dalle prime fasi
dell’esecuzione del programma. Questo lo rende più veloce
all’avvio.
• il Server esegue molte più ottimizzazioni del codice. Questo fa
si che il codice compilato sarà nel tempo, più performante di
quello compilato con il client compiler.
E’ possibile correlare le due tecniche?
(Tiered Compilation -XX:+TieredCompilation, default in Java 8)
56
Just in Time Compiler (JIT - Startup Optimization 1/2)

• Hello World
• NetBeans IDE
• BigApp (web application in J2EE container)
57
Just in Time Compiler (JIT - Startup Optimization 2/2)

58
Just in Time Compiler (JIT - Batch Operation Optimization)
• Batch applications: eseguono delle porzioni di codice predeﬁnite
• Spesso sono schedulati per essere eseguiti ad intervalli regolari
• Esempio Stock App (analisi di un anno di storia tra 1 e 10000 stocks con
calcolo della deviazione standard e della media)

59
Just in Time Compiler (JIT - Long Running Application Optimization)
• Long running applications: applicazioni spesso di tipo server con paradigma
request/response
• Le performance di questo tipo di applicazioni si misura tramite il throughput
dell’applicazione.
• Nell’esempio si evince che la compilazione server ha delle performances
nettamente superiori.

60
Just in Time Compiler (JIT - Intermediate Tuning)
• La maggior parte delle volte il tuning sul JIT compiler si limita a scegliere la
tipologia di compilatore da utilizzare (-client -server -XX:+TieredCompilation).
• In altri casi il tuning deve essere approfondito
• Tuning Code Cache: quando la JVM compila codice mantiene in una cache un
set di istruzioni assembly, che sono sostituite al bytecode quando viene eseguita
la compilazione.
• Se questa cache si riempie il codice viene interpretato e l’esecuzione degrada
molto la sua performance.
• -XX:InitialCodeCacheSize=N: flag per definire la dimensione iniziale della cache.
• -XX:ReservedCodeCacheSize=N: flag per definire la dimensione massima della
code cache.

61
Just in Time Compiler (JIT Inspecting Compilation Process)
• E’ possibile analizzare il comportamento del JIT compiler
utilizzando alcuni JVM ﬂags:
• -XX:PrintCompilation
• Output:
• %: The compilation is OSR.
• s: The method is synchronized.
• !: The method has an exception handler.
• b: Compilation occurred in blocking mode.
• n: Compilation occurred for a wrapper to a native method.
• jstat -compiler pid_process
• jstat -printcompilation pid_process

• Introduzione
62
Agenda

In informatica la Java Platform, Enterprise Edition o Java EE (conosciuta, prima della versione 5, col nome di Java 2
Enterprise Edition o J2EE) è una piattaforma software di programmazione principalmente sviluppata in linguaggio di
programmazione Java e ampiamente utilizzata nella programmazione Web.
La piattaforma fornisce infatti API e un ambiente di runtime (JDK e JRE) per lo sviluppo e l'esecuzione di software in
ambito enterprise, compresi servizi di rete e web, nella forma di grandi applicazioni di rete a più livelli, scalabili, affidabili
e sicure. La Java EE estende la Java Platform, Standard Edition (Java SE), incorporando un design basato in gran parte
su componenti modulari in esecuzione su un server di applicazioni. (Wikipedia)
Componenti principali
• Gli Enterprise JavaBeans (EJB): definiscono un sistema a componenti distribuito che rappresenta il cuore della
specifica Java EE. Tale sistema, infatti, fornisce le tipiche caratteristiche richieste dalle applicazioni enterprise, come
scalabilità, sicurezza, persistenza dei dati e altro.
• JNDI: definisce un sistema per identificare e elencare risorse generiche, come componenti software o sorgenti di dati.
• JDBC è un'interfaccia per l'accesso a qualsiasi tipo di basi di dati (compresa anche in Java Platform, Standard Edition).
• JTA: è un sistema per il supporto delle transazioni distribuite.
• JPA: è l'API per la gestione della persistenza dei dati.
• JAXP: è un API per la gestione di file in formato XML/JSON.
• Java Message Service (JMS): descrive un sistema per l'invio e la gestione di messaggi.
63
J2EE Performance (Overview)

Principi di performance per il web
container (core J2EE application server):
A. Produce Less output
B. Produce less withespace
C. Combine CSS and Javacript
resources
D. Compress Output
E. Jsp Dynamic compilation (BAD!!!)
F.
64
J2EE Performance (Web Container)

• Bisogna prestare attenzione ai dati salvati nella session. Se è possibile bisognerebbe evitare questa
tecnica.
• E’ buona norma invalidare la session quando il client non ne ha più bisogno.
• I J2EE container hanno un timeout sulla durata della Session.
• Se il client non esegue più request la session rimane appesa e non viene eseguito un GC.
• In Ambienti Clustered HA bisogna prestare attenzione a come gli oggetti Session sono replicati.
65
J2EE Performance (Http Session State)
• client esegue una request verso il server,
• il server crea una Session e la associa a quel
client tramite un ID.
• per ogni successiva request di quel client sarà
presente il riferimento alla session creata in
precedenza.
• è possibile salvare dati nella Session.

Costo per la creazione di EJB:
• Create the EJB object
• Process annotations and inject any
resource dependencies into the new EJB
• Call any method annotated with
@PostConstruct
• For stateful beans, call any method
annotated with @Init or call the ejbCreate()
method
• Execute the business method
• Call any method annotated with
@PreRemove
• For stateful beans, call the remove()
method  
66
J2EE Performance (Thread pool - EJB)

67
J2EE Performance (Xml / JSON)
{"Timestamp":"2013-03-29T02:17:14.898Z",
"Ack":"Success",
"Build":"E815_CORE_APILW2_15855352_R1",
"Version":"815",
"ItemArray":{
"Item":[{"ItemID":"140356481394",}],
... 19 other items in identical structure ...
}, }
<xml version="1.0" encoding="UTF-8"?>
<FindPopularItemsResponse xmlns="urn:ebay:apis:eBLBaseComponents"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ebay:apis:eBLBaseComponents docs/xsd/ebay.xsd">
<Timestamp>2013-03-29T01:57:46.530Z</Timestamp>
<Ack>Success</Ack>
<Build>E815_CORE_APILW2_15855352_R1</Build>
<Version>815</Version>
<ItemArray>
<Item>
<ItemID>140356481394</ItemID>
...roughly 17 individual attributes for an item
</Item>
... 19 other items in identical structure ...
</ItemArray>
</FindPopularItemsResponse>
XML JSON
Parsing time

68
J2EE Performance (JDBC)
• Una connessione DB ha un
costo elevato
• Creare pool di connessioni
• dimensionare
opportunamente il pool

• Introduzione
69
Agenda

Java Performance Tuning and optimization Ed 1 (IT) PRV
70
Just in Time Compiler (J2EE Performance - Overview)

Jvm performance Tuning

More Related Content

Viewers also liked

Similar to Jvm performance Tuning

Jvm performance Tuning