Nel primo post ho parlato di "Mem Usage" e successivamente di "VM Size".
Ma fino a qui abbiamo solo allocato senza scrivere in memoria. Al momento in cui la memoria viene allocata con VirtualAlloc (API usata dal Garbage Collector del Framework.NET per blocchi di memoria relativamente grossi) questa è semplicemente assegnata al processo ma non è realmente in RAM fisica. Non appena questa viene accessa per essere scritta il sistema operativo la deve mettere in RAM.
Vediamo quindi i Page Faults (già definiti nel primo post) grazie alla piccola applicazione che ho usato al workshop e al performance monitor (perfmon) del sistema operativo.
- Per prima cosa alloco 300-500MB, provocando un'aumento del solo valore di "Private Bytes"
Questo significa che la memoria è Committed ma non è in RAM fisica
- Poi scrivo randomicamente in tutti questi blocchi grazie al pulsante "Random Write". Per farlo il sistema deve mappare le pagine in RAM.
Se la RAM non è sufficiente il sistema deve swappare su disco le porzioni di RAM occupate per fare spazio, ma in fase iniziale supponiamo di averne a sufficienza.
- La scrittura su quei blocchi provoca immediatamente l'aumento di WS Private e Working Set pari allo stesso ordine di grandezza dei Private Bytes, indice che la RAM usata da quel processo è improvvisamente cresciuta perché ne sta facendo un effettivo uso.
Le allocazioni nell'esperimento sono molto alte, perciò la differenza tra WS Private (cioè solo la RAM privata) e Working Set (cioè RAM privata + RAM condivisa) è ovviamente minima.
- A questo punto premo il pulsante "Shrink Working Set" che fa liberare la RAM fisica buttando subito il contenuto sullo Swap File.
Questa operazione fa aumentare improvvisamente il performance counter "Memory\Pages Output/sec" e il disco diventa udibile per la sua attività frenetica. Abbiamo appena assistito ad una serie di Hard Page Fault in scrittura.
- A questo punto ho due possibili strade: vedere i Soft Page Fault oppure gli Hard Page fault in lettura.
- Se ora premo di nuovo il pulsante Random Write, ottengo solo dei Soft Page Fault in quanto Windows sa che le pagine in memoria (segnate come libere in quanto abbiamo svuotato il working set) sono le stesse che sono state messe poco prima su disco fisso. I Soft Page Fault vengono lanciati perché le pagine di RAM erano state liberate però sono ancora disponibili in memoria.
Nessun Hard Page Fault in lettura è stato provocato perché non è stato necessario leggere la pagine dallo Swap File.
- In alternativa (al posto di premere la seconda volta Random Write) apro tante istanze della applicazione di test allocando tanta memoria da occupare tutta la RAM fisica disponiile, cancellando di fatto dalla RAM le pagine della prima istanza.
In questo modo Windows non ha più le pagine di memoria della prima istanza e per scriverci dentro deve necessariamente caricarle da disco.
Perciò premendo Random Write diventano visibili sul performance monitor i Memory\Pages Input/Sec che sono gli Hard Page Fault in lettura.
Ecco la demo in video:
E arriviamo quindi a delle considerazioni pratiche di quanto sperimentato.
Per collassare il Working Set ho chiamato l'API SetProcessWorkingSetSize(HandleProcesso, -1, -1). Appare chiaro che il suo uso non solo è inutile ma è peggiorativo perché non appena il processo necessita di scrivere qualcosa nella propria memoria privata (per esempio riportare in primo piano una applicazione UI minimizzata), le sue pagine su disco dovranno essere riportate in RAM, provocando potenzialmente gli hard page fault.
Se la memoria serve, è Windows a decidere quando, quale e quanta. Se invece la forziamo noi, rischiamo solo di attendere lunghissime letture/scritture sul file di swap.
Questa è l'API usata dai cosiddetti ottimizzatori di memoria che asseriscono di migliorare le performance. A mio avviso è un falso e collassare il working set è evidentemente peggiorativo.
La RAM fisica libera è solo uno spreco. Se il sistema operativo non ne fa uso è solo una cattiva ottimizzazione del sistema.