Memoria, Garbage Collector e Performance

Transcript

1 Memoria, Garbage Collector e Performance Università di Genova Facoltà di Ingegneria Martedi 16 Dicembre 2008 Venerdi 19 Dicembre malta@vevy.com Blog: Profilo:

2 Processo e memoria 2 32 = 4GB 1GB 2GB User 2GB Kernel

3 Non tutte le pagine di memoria sono uguali... 2GB User Ram fisica 2GB User File di swap Pagine allocate condivise Pagine allocate private in ram Pagine allocate e in swap

4 Alcuni termini Page Fault. Quando un processo richiede della memoria e questa non è subito disponibile, viene scatenato un page fault. Se la pagina in questione è nel file di paging su disco fisso, il page fault è detto "hard page fault" Maggiori sono gli "hard page fault" e minore è la performance generale del sistema I "soft page fault" sono invece generati se la pagina non è stata trovata ma è già in memoria e tipicamente non sono responsabili di grosse perdite di performance. Committed Page. Pagina di memoria allocate e presenti in RAM o su disco Uncommitted Page. Pagine di memoria virtuale non ancora allocate, non usabili e non disponibili. In pratica i "buchi" nello spazio di indirizzamento virtuale. In pratica il tentativo di accedere in lettura o scrittura in una Uncommitted Page risulta nel classico e noto errore di "Access Violation"

5 Task manger, Process Explorer e il nostro uso della memoria 2GB User Ram fisica System.*.dll... MSVCRT Pagine allocate condivise WS Shareable (ProcExp) File di swap Pagine allocate private in ram WS Private Pagine allocate e in swap Private Bytes - WS Private Spazio di indirizzamento virtuale assegnato al processo (dinamico) Discussione 1. Rebasing 2. Mem Usage alto tante pagine shared? Ottimo! 3. VM Size alto pagine su disco Hard page fault?

6 Q&A Perché "Mem Usage" non è un'informazione utile? Le pagine di memoria condivise sono contate per ciascun processo. Per cui la somma di tutti i "Mem Usage" di tutti i processi è superiore alla memoria realmente occupata. Un alto "Mem Usage" (Working Set) può dire che stiamo usando poca memoria ma sono tante le dll condivise con altri processi Quando accade che un processo condivida le sue pagine? Ad esempio la porzione read-only delle DLL che vengono caricate in un processo e non sono ribasate dal loader vengono condivise, permettendo al sistema di occupare meno memoria. Cosa indica "Memory (Private Working Set)" in Vista o "WS Private" di Procexp? pagine private di un processo in RAM e non su disco Cosa indica "WS-Shareable" in Procexp? È la memoria condivisa con altri processi. È pari a Working Set - WS Private

7 Q&A Cosa sono le pagine riservate? Le allocazioni fatte con VirtualAlloc riservano solo dello spazio nella memoria virtuale senza doverci fare un accesso fisico. Non appena ci scrivo viene messa in RAM. Per esempio una allocazione di 1MB eseguita dal GC riserva lo spazio ma non incrementa l'uso di RAM fisica fino a che non vado a scriverci dentro Disabilitare il file di swap è negativo perché impedisce di riservare lo spazio anche se non usato subito La memoria privata ma riservata nel file di swap è pari a Private Bytes - WS Private Cosa rappresenta "Vm Size" (Private Bytes di Procexp, Commit Size di Vista)? È la somma delle pagine private in memoria e sul file di swap. Sono tutte pagine allocate e private dal processo, quindi non condivise

8 La soluzione ai problemi di memoria IL GARBAGE COLLECTOR

9 Memoria Ogni applicazione usa memoria Ogni reference type finisce nel managed heap gestito dal GC Il compito del GC è di prendere in carico la disallocazione dell'oggetto La disallocazione di memoria non è predicibile Problemi risolti Memory Leak (dimenticare di disallocare) Frammentazione della memoria Bug sui memory leak porterebbero ad OutOfMemoryException

10 Soluzione per la memoria Il GC gestisce tutti i reference type (allocati nel managed heap) Il codice utente non deve/può mai liberare memoria Quando non esiste più un reference che punta in modo diretto o indiretto ad un oggetto, questo è candidato ad essere liberato dal GC Ogni processo ha il suo managed heap privato "new" alloca sempre gli oggetti in fondo al managed heap Se lo heap è pieno, viene eseguita una Garbage Collection In realtà avviene solo quando è piena la Generazione 0 A B C NextObjPtr

11 L'algoritmo usato dal GC Allocare gli oggetti è un'operazione veloce Quasi tanto quanto allocare sullo stack Più rapida di HeapAlloc/malloc Gli oggetti grossi (>= 85,000 bytes) sono allocati in LOH LOH = Large Object Heap Gli oggetti LOH non vengono mai spostati Gli oggetti non referenziati (direttamente o indirettamente) sono soggetti a garbage collection Nell'immediato sono considerati memoria libera e riusabile Durante la garbage collection gli oggetti in uso vengono spostati per compattare la memoria Se l'heap è pieno di oggetti in uso viene lanciata una OutOfMemoryException

12 L'algoritmo usato dal GC Ogni applicazione ha un set di Roots Le Roots sono qualsiasi locazione dove vengono memorizzati i reference che puntano ad oggetti nel managed heap Reference di variabili nelle classi, locali, statiche (globali),... Reference agli oggetti nelle variabili/parametri locali Registri CPU che contengono reference ad oggetti Il compilatore JIT costruisce una tabella che indica dove sono le roots Il GC usa questa tabella All'avvio il GC fa l'assunzione che non esistano oggetti nell'heap Poi il GC esamina le roots e costruisce il grafo di tutti gli oggetti raggiungibili Quando un oggetto viene identificato, il GC guarda se questo oggetto contiene nuovi reference per percorrere l'intero grafo Il procedimento è ricorsivo fino a quando l'intero grafo viene ispezionato

13 Prima e dopo una Collection Managed Heap A B C D E F G H I J A C D F H Managed Heap NextObjPtr NextObjPtr ROOTS (strong references) Globals Statics Locals CPU Registers

14 La soluzione ai problemi di Risorse LA FINALIZZAZIONE E IL RUOLO DEL GARBAGE COLLECTOR

15 Risorse Cosa sono le "Risorse"? File, buffer di memoria, output su video, connessioni di rete, risorse di DB, etc. Il loro rilascio, per loro natura, deve essere deterministico Per convenzione il rilascio delle risorse si esegue dentro Dispose Cosa c'entra quindi il GC con le risorse? È utile solo quando lo sviluppatore dimentica di chiamare Dispose È possibile solo se il pattern Dispose è implementato correttamente Il GC in modo non deterministico chiama Finalize la quale chiama Dispose Problemi risolti Resource Leak (Handle leak, etc.) Questi bug sono statisticamente delle "piaghe" Non predicibili sia nel tempo che nell'entità del disastro

16 Se si usa la Finalize... Ricordarsi che viene eseguita in un thread diverso C'e il rischio di race conditions Deve contenere il minimo codice necessario Evitare qualsiasi tipo di blocco (lock, etc.) Non sollevare eccezioni Chiamare la Finalize della classe base // Sintassi C# class MyObject { ~MyObject() {... // Codice prodtto dal compilatore class MyObject { protected override void Finalize() { try {... finally { base.finalize();

17 Coda di finalizzazione Managed Heap A B C D E F G H I J ROOTS (strong references) Globals Statics Locals CPU Registers Finalization Queue C E F I J Freachable Queue

18 La coda Freachable Managed Heap A C D E F I J ROOTS (strong references) Globals Statics Locals CPU Registers Finalization Queue C F Nello step precedente erano in coda di finalizzazione E I J Freachable Queue

19 Stato dopo la GC successiva A C D F Managed Heap ROOTS (strong references) Globals Statics Locals CPU Registers Finalization Queue C F Sono state necessarie due GC per liberare la memoria! Freachable Queue

20 DISPOSE E FINALIZE NELLA PRATICA

21 Usare classi che implementano IDisposable È sufficiente chiamare Dispose (o Close) FileStream fs = new FileStream( Readme.txt, FileMode.Open); fs.write(...); fs.close(); // fs.dispose() funzionerebbe uguale // File viene chiuso, l'oggetto non è più soggetto a finalizzazione Esiste uno statement in C# per semplificare using (FileStream fs = new FileStream( ReadMe.txt, FileMode.Open)){ fs.write(...); Using produce questo codice: FileStream fs = new FileStream( ReadMe.txt, FileMode.Open); try { fs.write(...); finally { if (fs!= null) fs.dispose();

22 Scrivere classi che devono rilasciare risorse Le classi che hanno bisogno di rilasciare risorse in modo deterministico sono candidate al pattern Dispose Implementare sempre IDisposable Consente l'uso dello statament "using" Wrappare se possibile le risorse in SafeHandle o in altre classi in Microsoft.Win32.SafeHandles Implementare il pattern Dispose

23 Pattern Dispose public class ComplexCleanupBase : IDisposable { // some fields that require cleanup private bool disposed = false; // to detect redundant calls public ComplexCleanupBase() { // allocate resources protected virtual void Dispose(bool disposing) { if (!disposed) { if (disposing) { // dispose-only, i.e. non-finalizable logic // shared cleanup logic disposed = true; ~ComplexCleanupBase() { Dispose(false); public void Dispose() { Dispose(true); GC.SuppressFinalize(this);

24 Design Guidelines per il Pattern Dispose nandresourcemanagement.aspx public class SimpleCleanup : IDisposable { SafeHandle Internamente implementa la Finalize // some fields that require cleanup private SafeHandle handle; private bool disposed = false; // to detect redundant calls public SimpleCleanup() { this.handle = /* */; protected virtual void Dispose(bool disposing) { if (!disposed) { if (disposing) { if (handle!= null) handle.dispose(); disposed = true; public void Dispose() { Dispose(true);

25 GC E GENERAZIONI

26 Generazioni È un meccanismo per migliorare le performance Il Garbage Collector (detto "ephemeral" o generazionale) fa le seguenti assunzioni Più un oggetto è di recente creazione, più corta sarà la sua vita Più un oggetto è vecchio, più lunga sarà la sua vita Gli oggetti più recenti tipicamente si referenziano tra loro e vengono frequentemente accessi contemporaneamente Compattare una porzione dell'heap è più veloce che compattare l'intero heap Statisticamente sono assunzioni valide per tante applicazioni

27 Come funziona il GC Ci sono Gen0, Gen1, Gen2 e LOH (Large Object Heap) Se allocazione > bytes va direttamente in LOH Gli oggetti in LOH non sono mai spostati In futuro potrebbe cambiare quindi facciamo finta di non saperlo e continuiamo a farne il pinning Ogni allocazione managed costa solo 8 byte in più rispetto ad una nativa: sync + method table ptr

28 Garbage Collection Generations A B C D EL MF NG OH PI QJ RK Roots (strong references) Generazioni 2 1 0

29 Garbage Collection Generations A C D G L M N O PS QT UR Roots (strong references) Generazioni 2 1 0

30 Garbage Collection Generations A C D G M O Q R S VT WU X Y Z Roots (strong references) Generazioni 2 1 0

31 Garbage Collection vs Performance Quando accade la GC? Quando la Gen0 è finita In questo caso accade una GC sulla Gen0 Se l'ephemeral Segment è esaurito Gen2 collection Quando chiamiamo GC.Collect() Negativa perché ci fa perdere tempo Negativa perché sballa l'auto-tuning del GC Non necessaria quasi mai Sotto Memory Pressure La Memory Pressure è un'informazione passata dall'os QueryMemoryResourceNotification API

32 Quanto è veloce accedere in Gen0,1? L'Ephemeral segment può stare nella cache L2 della CPU così che non vi siano "cache miss" In questo modo la RAM non deve essere accessa Trasferimento Tipo di copia Tempo Banda Registri CPU CPU CPU 1 clock L1 Cache CPU L1 Cache 1-5 ns - L2 Cache L1 L2 Cache 4-10 ns MB/s Memoria RAM L2 Cache memoria ns MB/s Diskco locale CPU disco 5-15 ms 1-80 MB/s Rete CPU CPU remota 5-50 μs MB/s

33 DIAGNOSTICA E BEST PRACTICES

34 Best practices Per le allocazioni non-loh (<85000) Vanno allocate senza abbondanza Si rischia di esaurire più velocemente l'ephemeral Segment Prima vengono disallocate, meglio è La loro deframmentazione/riuso sarà veloce Verranno eseguite meno collection Liberare quanto prima la memoria pinned (GCHandle) Impedisce al GC di deframmentarla Per le allocazioni LOH (>85000) Riusare se possibile lo spazio (eventualmente allocando più memoria) Tipico esempio: immagini bitmap, buffer per criptare/decrittare,... Finiscono in LOH anche gli static (>2K), double[] (>100 elementi)

35 Monitorare il Managed Heap Performance Monitor: perfmon.exe

36 Come leggere i Contatori del GC % Time in GC 10% 50% % alta % alta Allocated Bytes/Sec 50-60MB/sec % bassa verifica rapporto Gen Alto numero di allocazioni # of Gen0 1 2 collections Gen1:Gen2=10:1 Large object heap size Promoted Memory from Gen0 1 Alto numero di promotion Gen2 Heap Size Promoted finalization-memory from Gen0

37 Domande?