Jvm performance Tuning

70
1 Contatti Marco Sabatini Senior Software Engineer [email protected] https://it.linkedin.com/in/sabatinimarco

Transcript of Jvm performance Tuning

1

Contatti

Marco Sabatini

Senior Software Engineer [email protected]

https://it.linkedin.com/in/sabatinimarco

Java Performance Tuning

• 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 • 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

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à: definire 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

SiCompleta?

Definizione piano di testD

EsecuzioneD

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 IssueD

Requirement AnlysisD

Processo sviluppo Processo assessment

10

Analisi delle performance (Processo di assessment)

Analisi sistemisticaD

Identificazione IssueD

Intervento tuningD

TestingD

Assessment documentaleD

Configurazione / 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 file 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

Analisi delle performance (Analisi Sistemistica - CPU Time 2/3)

Eseguire il tuning applicativo, significa 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

Analisi delle performance (Analisi Sistemistica - CPU Time 3/3)

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

Analisi delle performance (Analisi Sistemistica - Disk Usage 2/3)

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 fisica 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

Analisi delle performance (Analisi Sistemistica - Disk Usage 3/3)

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 efficiente 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 profiling 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

• Profiling a JVM

20

Analisi delle performance (Analisi Sistemistica - Java Monitoring Tools 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

Analisi delle performance (Analisi Sistemistica - Java Monitoring Tools 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

Analisi delle performance (Analisi Sistemistica - Java Monitoring Tools 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

Analisi delle performance (Analisi Sistemistica - Java Monitoring Tools Class Information)

Ogni tool riporta qualche informazione relativa all’attività di Garbage Collector (GC).

• jconsole: visualizza il grafico 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

Analisi delle performance (Analisi Sistemistica - Java Monitoring Tools 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

Analisi delle performance (Analisi Sistemistica - Java Monitoring Tools 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

Analisi delle performance (Analisi Sistemistica - Java Monitoring Tools Profiling JVM)

• 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

27

Agenda

In informatica per garbage collection (letteralmente raccolta dei rifiuti, 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 (Definizione)

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

Garbage Collector (Generational GC 2/6)

33

Garbage Collector (Generational GC 3/6)

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

Garbage Collector (Generational GC 4/6)

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

Garbage Collector (Generational GC 5/6)

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

Garbage Collector (Generational GC 6/6)

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 flag hotspot: '-XX:+ UseSerialGC’.

NB: per disabilitare questo algoritmo bisogna necessariamente specificarne 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 specificando i flags ‘-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 flag -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 • 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

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,file=/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 first 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

Gestione della memoria (Best Practices Heap Analysis 4/5)

• -XX:+HeapDumpOnOutOfMemoryErrorTurning 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

Gestione della memoria (Best Practices Heap Analysis 5/5)

• 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

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 predefinite

• 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 flags: • -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 • 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

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 • 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

69

Agenda

Java Performance Tuning and optimization Ed 1 (IT) PRV

70

Just in Time Compiler (J2EE Performance - Overview)