Le profondità della memoria di Windows (parte 2) — La vita di una pagina fisica: cinque elenchi e la verità sul file di paging

· · Windows, Gestione della memoria, File di paging, Working Set, Standby, RAMMap, Monitoraggio delle prestazioni

Nell’articolo precedente, «Le profondità della memoria di Windows (parte 1) — Il momento in cui un indirizzo virtuale diventa RAM fisica», abbiamo seguito fino al momento in cui il gestore di page fault assegna una pagina fisica al primo tocco di una pagina già in Commit. Dove va quella pagina fisica dopo essere stata tolta dal Working Set?

Si vede spesso la spiegazione ridotta a «viene espulsa nel file di paging», ma in realtà ci sono diversi stati prima e dopo. Una pagina non modificata può passare in Standby lasciando il contenuto al suo posto. Una pagina modificata aspetta prima la riscrittura su Modified. Al riutilizzo può passare da Free o Zeroed e, se servono di nuovo gli stessi contenuti, può tornare da Standby con un soft fault.

Questo articolo usa il database PFN come asse e segue come una singola pagina fisica si muove tra Active, Modified, Standby, Free e Zeroed. La lettura dei numeri stessi dà per scontato l’articolo introduttivo «What Does Windows’ “Memory Usage” Actually Mean? — Correctly Reading Working Set, Private Bytes, Commit, and the Page File».

«Le profondità della memoria di Windows» — tutte e 3 le parti

  1. Parte 1: indirizzi virtuali e page fault
    Seguiamo quando una pagina virtuale in Commit ottiene RAM fisica.
  2. Parte 2 (questo articolo): la vita di una pagina fisica
    Seguiamo le transizioni di stato di una pagina che lascia il Working Set e il ruolo del file di paging.
  3. Parte 3: oggetti sezione e copy-on-write
    Seguiamo il meccanismo con cui DLL, mapping di file e memoria condivisa condividono pagine fisiche.

La domanda a cui risponde la parte 2 è una sola.

Una pagina fisica che lascia il Working Set scompare, va su disco o resta in RAM?

I lettori previsti sono sviluppatori e operatori che vogliono capire, dal meccanismo, perché Available è alto e Standby lo è altrettanto, il comportamento dopo il trim del Working Set, la configurazione del file di paging e la compressione della memoria. I prerequisiti sono Windows 10/11 o Windows Server attuale, e lo sfondo richiesto sono le basi di Working Set, Commit e soft/hard fault. La difficoltà è intermedia; usiamo termini interni come PFN ed elenchi di pagine, ma ci concentriamo su ciò che si può osservare con RAMMap e PerfMon senza un debugger del kernel.

1. Prima il succo

Per iniziare, ecco i punti facili da leggere male.

  • Una pagina che lascia il Working Set non scompare necessariamente subito.
    Una pagina pulita resta su Standby e può tornare senza leggere il disco se servono gli stessi contenuti.
  • Una pagina modificata non può essere riutilizzata subito.
    I contenuti privati diventano riutilizzabili dopo potersi riscrivere nel file di paging; un file mappato, dopo potersi riscrivere nel file corrispondente; e così via.
  • Available include Standby.
    Standby è una cache che conserva ancora i contenuti e, allo stesso tempo, un candidato al riutilizzo che si può prendere subito se serve.1
  • La scrittura nel file di paging non è un lavoro a lotti che parte solo dopo che la RAM è completamente esaurita.
    Procede in background secondo l’elenco Modified e la pressione di memoria.23
  • Il file di paging non è solo «RAM lenta».
    Allarga il Commit Limit, diventa il backing store delle pagine private modificate e sostiene i dump di crash.4
  • Disabilitare il file di paging non sistema una perdita di memoria.
    Il Commit Limit scende e si possono perdere opzioni per usare bene la RAM e la capacità di catturare dump.

In una frase: prima di scartare una pagina, Windows controlla la possibilità che serva di nuovo e se c’è un posto da cui ripristinare i contenuti originali.

2. Il database PFN — il registro sul lato della RAM fisica

La PTE vista nella parte 1 rappresentava la traduzione da una pagina virtuale a una pagina fisica. Il registro che guarda questo dal lato della pagina fisica e segue «a cosa serve ora questa pagina di RAM» è il database PFN. PFN sta per Page Frame Number: la RAM fisica numerata in unità di pagina.

Una voce PFN tiene traccia, in concetto, delle seguenti informazioni.

  • Lo stato attuale della pagina fisica
  • Conteggio dei riferimenti e conteggio delle condivisioni
  • La PTE corrispondente
  • Se è modificata
  • A quale elenco di pagine appartiene
  • Informazioni relative al nodo NUMA e alla priorità

In WinDbg, !pfn mostra le informazioni di un PFN specifico e !memusage mostra l’uso della memoria fisica e i totali di ogni elenco di pagine.56 Per osservare lo stesso mondo senza un debugger del kernel è disponibile Sysinternals RAMMap. Use Counts mostra scopo ed elenco di pagine, Priority Summary mostra Standby per priorità e Physical Pages mostra l’uso per pagina.7

3. Collegare i cinque stati in un solo schema

Questo articolo tratta il flusso di una pagina fisica come i seguenti cinque stati, semplificati. In senso stretto, il Windows attuale ha stati ed elenchi non disegnati qui — Standby per priorità, Transition, Bad e altri — e Active indica meno un singolo «elenco Active» che lo stato di essere referenziata da un Working Set o simile tramite una PTE valida. Anche così, questo schema è più che utile per leggere il comportamento di memoria di un’app.

Schema semplificato di una pagina fisica di Windows che si muove tra Active, Modified, Standby, Free e Zeroed

Figura 1: Una pagina referenziata nel Working Set va in Standby se è pulita e in Modified se è sporca. Gli stessi contenuti possono tornare; un altro uso riutilizza la pagina direttamente o passa da Free/Zeroed in preparazione di un’allocazione che richiede zeri.

Codice sorgente Mermaid della figura 1 ```text flowchart LR zeroed["Zeroed\nAzzera"] -->|Primo Touch| active["Active / Valid\nRiferita nel Working Set"] active -->|Trim clean| standby["Standby\nCandidata al riuso con contenuto"] active -->|Trim dirty| modified["Modified\nIn attesa di riscrittura"] modified -->|Riscrittura completata| standby standby -->|Ritorno con soft fault| active standby -->|Scarta la vecchia identità| free["Free\nNon azzerata"] standby -->|Riuso diretto altrove| active free -->|Per allocazione a zeri| zeroed ```

Il punto più importante di questo schema è che lasciare il Working Set e perdere i contenuti non sono la stessa cosa. Inoltre, quando una pagina Standby viene presa per un altro scopo, non passa necessariamente da Free/Zeroed in ordine. Se verrà consegnata in modalità utente come nuova pagina privata demand-zero, i vecchi contenuti vanno cancellati; se l’intera pagina verrà sovrascritta, come destinazione di una lettura di file, l’identità Standby può essere tolta e la pagina riutilizzata direttamente.

4. Active / Valid — una pagina fisica che si può referenziare ora

Una pagina Active/Valid è referenziata dal Working Set di un processo o dallo spazio di sistema tramite una PTE valida. La CPU la raggiunge con la traduzione di indirizzi ordinaria, quindi l’accesso stesso non ha bisogno di un page fault.

Non c’è però garanzia che la pagina resti Active. Per mantenere memoria disponibile, il gestore della memoria guarda la dimensione del Working Set, quanto di recente è stata usata la pagina e fattori simili, e trimma le pagine candidate. La documentazione Microsoft sul Working Set spiega anche che il gestore della memoria rimuove pagine dal Working Set per creare memoria disponibile.8

4.1. Un trim non è una liberazione

Ciò che il trim del Working Set cambia soprattutto è lo stato residente di essere immediatamente referenziabile tramite una PTE valida. Distinguete i quattro seguenti come eventi separati.

  • Togliere dal Working Set
  • Liberare il Commit
  • Liberare un intervallo di indirizzi virtuali
  • Perdere i dati originali

Eseguire EmptyWorkingSet o il «Trim Working Set» di uno strumento non sostituisce VirtualFree né una free dell’heap. Se ritoccate la stessa pagina, torna via soft fault da Standby o hard fault da un backing store. Quindi «ho reso più piccolo il Working Set» non significa «ho sistemato la perdita».

5. Una pagina pulita va in Standby

Anche dopo che una pagina è tolta dal Working Set, se i contenuti coincidono ancora con il file originale o ha già un backing store sicuro, può essere messa in Standby. Esempi rappresentativi:

  • Codice EXE/DLL non modificato
  • Un file mappato in memoria non modificato
  • Una pagina privata già riscritta
  • Dati rimasti nella cache dei file

Una pagina Standby conserva la corrispondenza con i contenuti precedenti. Quando lo stesso processo o un altro ha bisogno di quei contenuti, se la pagina non è ancora stata riutilizzata, basta un soft fault che ricollega la PTE per ripristinarla.

Dall’altro lato, se un’altra allocazione ha bisogno di una pagina fisica, la vecchia identità Standby può essere scartata e la pagina riutilizzata. Se la destinazione di riutilizzo è una pagina privata in modalità utente che richiede inizializzazione a zero, si prepara una pagina Zeroed; se l’intera pagina verrà sovrascritta con contenuti di file o simili, può essere riassegnata direttamente senza azzeramento.

Questa doppia faccia è proprio il motivo per cui Standby è insieme una cache e Available.

5.1. Perché Available include Standby

MEMORYSTATUSEX.ullAvailPhys rappresenta la memoria fisica riutilizzabile subito senza scrivere su disco ed è la somma di Standby, Free e Zeroed.1

I tre elenchi di pagine che compongono AvailableLa memoria fisica disponibile è la somma di Standby, Free e Zeroed; le pagine Active referenziate in un Working Set non sono incluseNon inclusaStandby(candidato al riutilizzo che conserva i contenuti)Available(memoria fisica disponibile)Free(inutilizzata, non azzerata)Zeroed(inutilizzata e azzerata)Active(referenziata nel Working Set)

Figura 2: Available è la somma di Standby, Free e Zeroed. Anche Standby, che conserva ancora i contenuti, conta come «disponibile».

Quindi non è una contraddizione quando Gestione attività mostra «Free è basso, eppure Cached/Standby è alto e Available è sufficiente». Windows non lascia la RAM libera inattiva; lascia file e codice usati di recente in Standby così da riutilizzarli in fretta come cache se serve, e li prende se un altro scopo ne ha bisogno.

Non concludete «Free è basso, quindi siamo subito a corto di memoria»; guardate insieme Available, Commit, hard fault e ritardo di elaborazione.

6. Una pagina sporca aspetta su Modified

Quando un’app scrive in una pagina, quei contenuti non coincidono più con il backing store originale. Sovrascrivere quella pagina sporca per un altro scopo perderebbe i dati. Quindi una pagina modificata tolta dal Working Set aspetta la riscrittura su Modified.

La destinazione di riscrittura dipende dal tipo di pagina.

Tipo di pagina Destinazione tipica di riscrittura
Pagina privata in Commit File di paging
File mappato scrivibile Il file di dati corrispondente
Dati sporchi nella cache dei file Il file di dati corrispondente
Pagina EXE/DLL pulita Nessuna riscrittura. Si può rileggere dall’immagine originale

La documentazione Microsoft sul file di paging spiega anche che .dll, .exe e file ordinari già presenti su disco non vanno riscritti nel file di paging, e che i dati modificati senza una copia su disco originale diventano candidati al file di paging.2

6.1. Il Modified Page Writer

Il Modified Page Writer è un worker di sistema che scansiona le pagine sporche con backing nel file di paging che il gestore della memoria tiene traccia e le scrive nel file di paging.3 Sul lato dei file mappati ci sono percorsi come il Mapped Page Writer, che collaborano con il file system e il gestore della cache per riscrivere nel file corrispondente.

Il punto importante è che la scrittura non è uno schema «non fare nulla finché la RAM è 0 byte». Windows prepara in background pagine riutilizzabili in futuro, secondo l’elenco Modified, Available, lo stato del file di paging e fattori simili. Quando la riscrittura finisce e non ci sono altri riferimenti validi, la pagina procede in Standby con i contenuti intatti.

Percorsi di riscrittura di una pagina modificataUna pagina modificata che lascia il Working Set aspetta sull'elenco Modified; per una pagina privata, se è configurato un file di paging, il Modified Page Writer la scrive nel file di paging, e una pagina di file mappato viene riscritta nel file di dati corrispondente dal Mapped Page Writer o simile, poi procede in Standby con i contenuti intattiPagina privata(file di paging configurato)Pagina di file mappatoPagina modificata uscita dal Working SetAttesa di riscrittura sull'elenco ModifiedIl Modified Page Writer scrive nel file di pagingIl Mapped Page Writer o simile riscrive nel file corrispondenteDopo la riscrittura, in Standby con i contenuti intatti

Figura 3: La destinazione di riscrittura è determinata dal tipo di pagina e entrambi i percorsi procedono in background. Su un sistema con file di paging disabilitato, il lato pagina privata non ha destinazione di riscrittura, quindi le pagine private modificate restano in RAM.

6.2. Separare l’output di pagine e l’I/O specifico del file di paging

I seguenti contatori si confondono facilmente; confermate cosa significano.

  • Memory\\Page Writes/sec: il numero di I/O di scrittura di paging emessi per liberare memoria fisica
  • Memory\\Pages Output/sec: il numero di pagine scritte su disco da quelle scritture
  • Memory\\Page Reads/sec: il numero di I/O di lettura da disco emessi per risolvere hard fault
  • Memory\\Pages Input/sec: il numero di pagine entrate in RAM da quelle letture

Notate che Page Writes/sec e Pages Output/sec non sono contatori che identificano solo il file di paging. Possono salire anche sul percorso che riscrive pagine sporche con backing su file, come i file mappati. Al contrario, il lato input non distingue file di paging, DLL, EXE e file mappati in memoria.2 Per identificare l’I/O specifico di pagefile.sys, non stimate solo da questi quattro contatori; registrate File I/O e Disk I/O con ETW/WPA e confermate il file di destinazione abbinando FileObject e FileName.9

Un altro punto: scrivere prima nel file di paging non significa rileggere subito da disco. Se la pagina non viene acceduta, la pagina riscritta può essere tolta dalla RAM e la memoria fisica data a pagine usate più spesso.

7. La differenza tra Standby, Free e Zeroed

7.1. Standby

Uno stato che conserva ancora la corrispondenza con i contenuti precedenti.

  • Se servono gli stessi contenuti, può tornare via soft fault
  • Se un altro scopo ne ha bisogno, la vecchia identità può essere scartata e può essere riutilizzata
  • Ci sono elenchi Standby per priorità

7.2. Free

La corrispondenza valida con i contenuti precedenti è persa e la pagina è allocabile. Tuttavia il vecchio pattern di bit può ancora restare nella pagina. Consegnarla così com’è in modalità utente rischia di far trapelare informazioni del processo precedente.

7.3. Zeroed

I contenuti sono zero e la pagina può essere consegnata in sicurezza come nuova pagina in modalità utente. Il demand-zero fault della parte 1 era un caso rappresentativo di ottenimento di una pagina Zeroed disponibile e di binding a una PTE. La preparazione da Free a Zeroed avviene secondo domanda e stato del sistema.

Quindi anche se «Free» e «Zeroed» sembrano entrambe inutilizzate, differiscono nella prontezza legata alla sicurezza.

8. Il compression store della memoria — creare un’altra destinazione dentro la RAM

Da Windows 10 in poi, in presenza di pressione di memoria il gestore della memoria può, in alcuni casi, comprimere in RAM pagine poco usate invece di scriverle subito su disco. Quella raccolta di pagine compresse è il compression store.

Nell’implementazione iniziale di Windows 10 il compression store era contabilizzato nel Working Set del processo System, ma sul Windows attuale compare negli elenchi di processi del debugger come processo dedicato Memory Compression. Quindi, quando indagate la quantità di compressione attuale, non seguite solo il Working Set del processo System. Lo scopo stesso — tenere più app in memoria fisica e ridurre l’I/O su disco — non è cambiato.1011

Tenete però a mente i punti seguenti.

  • Le pagine compresse usano ancora RAM
  • Compressione e decompressione hanno un costo di CPU
  • La compressione non cancella la promessa di Commit
  • Non c’è un ordine fisso «sempre comprimere, poi il file di paging»
  • La politica cambia con il tipo di pagina, la pressione e la cronologia di accesso

«In uso (compresso)» di Gestione attività non significa che la compressione abbia svuotato del tutto la memoria fisica. Il compression store non è una funzione che rende superfluo il file di paging; aggiunge un’opzione che usa la CPU per ridurre l’I/O tra RAM e archiviazione.

9. Il vero ruolo del file di paging

Il file di paging ha almeno tre ruoli.

Tre ruoli del file di pagingIl file di paging allarga il Commit Limit, diventa il backing store delle pagine private modificate poco usate e diventa il ricettacolo di un dump di crash di sistemaFile di pagingAllargare il Commit Limit(margine sul soffitto)Backing store per pagine private modificateRicettacolo di un dump di crash di sistema

Figura 4: Il ruolo del file di paging non è solo «RAM lenta». Anche quando l’uso è 0 sostiene ancora il soffitto e i dump.

9.1. Allargare il Commit Limit

Il Commit Limit del sistema è determinato all’incirca da RAM più il totale di tutti i file di paging. Senza file di paging, il Commit Limit scende a un livello un po’ più piccolo della RAM installata. Quando Commit Total raggiunge il soffitto, un nuovo Commit fallisce e può portare a terminazione anomala dell’app o a problemi di sistema.4

Questa è un’altra questione rispetto a «quanti GB sono ora scritti in pagefile.sys». Il file di paging è anche margine sul soffitto che sostiene la promessa di Commit.

9.2. Sostenere le pagine private modificate

Se le pagine private modificate poco usate hanno backing nel file di paging, quelle pagine fisiche possono essere tolte dalla RAM e date a codice e dati usati di frequente.4 Disabilitare il file di paging riduce l’opzione di togliere tali pagine dalla RAM. Non si può dire semplicemente «è veloce perché non avviene il paging out».

9.3. Sostenere i dump di crash di sistema

Per produrre Memory.dmp in un crash di sistema serve un file di paging o un file di dump dedicato che possa sostenere il metodo di dump scelto.2 Dump della memoria completo, dump della memoria del kernel e dump automatico della memoria differiscono per la quantità richiesta.

In un ambiente in cui si indagano i crash, cancellare il file di paging solo per risparmiare spazio può significare che le prove mancano quando servono di più. Per i metodi di raccolta vedi anche «Introduzione alla raccolta di crash dump Windows - WER/ProcDump/WinDbg».

10. La dimensione giusta non è uniforme

Non si deve decidere la dimensione del file di paging da una formula fissa come «1,5 volte la RAM» da sola. Microsoft spiega che la dimensione appropriata differisce per sistema sui due punti seguenti e non è generalizzabile.2

  1. System Commit Charge di picco
  2. Il dump di crash di sistema di cui avete bisogno

In pratica, pensate in quest’ordine.

10.1. Partire dal gestito dal sistema come base

Il valore predefinito di Windows è gestito dal sistema. Cresce e si riduce secondo RAM installata, domanda di Commit, requisiti di dump di crash e simili. Senza un vincolo speciale o un risultato di misura, partire da qui è la scelta sicura.

10.2. Misurare il Commit di picco sotto un carico rappresentativo

Raccogliete a lungo i seguenti contatori in PerfMon.

  • Memory\\Committed Bytes
  • Memory\\Commit Limit
  • Memory\\% Committed Bytes In Use
  • Memory\\Modified Page List Bytes
  • Paging File(*)\\% Usage
  • Memory\\Available MBytes
  • Memory\\Page Reads/sec
  • Memory\\Page Writes/sec

Includete i picchi reali nel periodo di raccolta — elaborazioni di fine mese, backup, build, più utenti insieme e così via.

Una percentuale di uso del file di paging alta da sola non prova un problema di prestazioni di archiviazione. Restare attaccati al soffitto, però, è un avviso di capacità insufficiente. Guardate insieme se il Commit si avvicina al soffitto, se una grande quantità di Modified aspetta e se il disco è saturo.2

10.3. Decidere prima il requisito di dump

Decidete se vi serve un dump della memoria completo, se basta un dump della memoria del kernel o se userete un file di dump dedicato. Se passate a una dimensione fissa, deve soddisfare non solo il Commit di picco ma anche il requisito di dump.

11. Vedetelo voi stessi

11.1. Guardare gli elenchi di pagine in RAMMap

Avviate RAMMap come amministratore e aprite prima Use Counts.7 Gli elementi da guardare sono i seguenti.

  • Active
  • Standby
  • Modified
  • Modified no write
  • Free
  • Zeroed

Priority Summary permette di confermare che Standby è suddiviso per priorità. Processes mostra il Working Set di ogni processo; File Summary e File Details permettono di seguire i dati di file presenti in RAM.

Come prova, leggete una volta un file locale abbastanza grande, terminate la lettura e poi Refresh. Le pagine di quel file possono restare in File Summary o sul lato Standby. Rileggere lo stesso file può ripristinare pagine non ancora riutilizzate senza I/O su disco, o con poco I/O. I risultati variano con pressione di memoria, antivirus e dimensione del file, quindi guardate la direzione della transizione di stato piuttosto che un solo insieme di numeri.

Notate che il menu Empty di RAMMap cambia artificialmente lo stato del sistema. Non svuotate Standby come miglioramento delle prestazioni in produzione; usatelo solo su un ambiente di test isolato.

11.2. Separare Commit e Touch con Testlimit

Testlimit è uno strumento Sysinternals che simula carenze di risorse di memoria, handle, processi, thread e simili. Eseguite prima quanto segue contro il binario che avete a portata di mano e confermate versione e uso visualizzati.

.\\testlimit64.exe -?

Quanto segue riguarda Testlimit v5.24. Nella sintassi ufficiale v5.24, -m [MB] alloca la quantità di memoria indicata, -d [MB] alloca e Touch, -e [seconds] è l’intervallo di allocazione e -c [count] è il numero di allocazioni. Specificate -c per ultimo. Se ciò che vedete in locale differisce, preferite quell’uso.12

Poi provate in piccolo su una VM usa e getta.

# -m 64: alloca 64 MiB, -e 1: intervallo di 1 secondo, -c 8: si ferma dopo 8 volte
.\\testlimit64.exe -m 64 -e 1 -c 8

# Lo stesso numero e lo stesso intervallo, con -d così ogni regione viene Touch
.\\testlimit64.exe -d 64 -e 1 -c 8

Durante l’esecuzione registrate contemporaneamente quanto segue.

  • «Confermato X/Y» di Gestione attività
  • Active, Modified e Standby di RAMMap
  • Memory\\Committed Bytes
  • Memory\\Commit Limit
  • Memory\\Available MBytes
  • Memory\\Modified Page List Bytes

Se riproducete davvero l’esaurimento del Commit, non fatelo sul PC host; aumentate il numero passo passo su una VM con snapshot. Un’esecuzione che alloca automaticamente fino al soffitto può bloccare lo schermo, terminare processi in modo anomalo e perdere i log. Lo scopo non è destabilizzare il sistema operativo; è osservare che avvicinandosi al Commit Limit, un nuovo Commit fallisce.

12. Quattro letture errate da evitare in pratica

12.1. «Standby è alto, quindi è una perdita di memoria»

Standby è una cache riutilizzabile ed è inclusa in Available. Giudicate una perdita da se la baseline di Commit privata del processo e la scomposizione delle allocazioni continuano a crescere anche dopo la fine del carico.

12.2. «Tagliare il Working Set sistemerà la perdita»

Un trim cambia solo la residenza; non libera Commit né un’allocazione virtuale. Al riaccesso la pagina torna con un fault.

12.3. «L’uso del file di paging è 0, quindi è superfluo»

Il file di paging sostiene non solo la quantità di scrittura attuale ma anche il Commit Limit e i dump di crash. Decidere di cancellarlo dal solo uso quotidiano perde il margine di picco e le prove al momento del guasto.

12.4. «Prima la compressione della memoria, poi sempre il file di paging»

La compressione non è una pipeline seriale fissa. Windows sceglie in modo dinamico secondo il tipo di pagina, l’efficienza di compressione, il carico di CPU, la pressione di memoria e se esiste un backing store.

13. Sintesi

  • Il database PFN è il registro che tiene traccia di proprietà, riferimenti, modifica e stato di elenco di una pagina fisica.
  • Una pagina pulita che lascia il Working Set resta su Standby e può tornare via soft fault se servono gli stessi contenuti.8
  • Una pagina sporca aspetta su Modified e viene riscritta nel file di paging se è privata, o nel file corrispondente se è mappata, e così via.3
  • Available è la somma di Standby, Free e Zeroed; uno Standby grande da solo non è carenza di memoria.1
  • La compressione della memoria comprime pagine in RAM per ridurre l’I/O, ma non cancella i ruoli di Commit e del file di paging.10
  • Il file di paging sostiene il Commit Limit, le pagine private modificate e i dump di crash di sistema.42
  • La dimensione appropriata è determinata dal Commit di picco e dai requisiti di dump; non si può decidere con un moltiplicatore uniforme.2
  • Il trim del Working Set e lo svuotamento di Standby non sono correzioni di perdite di memoria.

Continua nella parte 3, «Oggetti sezione e copy-on-write: cosa sono davvero le DLL e i mapping di file».

Seguiamo perché le pagine di file e le DLL che restano su Standby sono visibili da più processi come la stessa pagina fisica.

Articoli correlati

Aree di consulenza correlate

KomuraSoft LLC si occupa di indagini su pressione di memoria delle applicazioni Windows, esaurimento del Commit, paging, crescita del Working Set e progettazione della raccolta di dump di crash.

Riferimenti

  1. Microsoft Learn, MEMORYSTATUSEX structure. Sul fatto che ullAvailPhys è memoria fisica riutilizzabile subito senza scrivere su disco, ed è la somma degli elenchi Standby, Free e Zeroed.  2 3

  2. Microsoft Learn, How to determine the appropriate page file size for 64-bit versions of Windows. Sul fatto che la dimensione appropriata dipende dal Commit di picco e dai requisiti di dump e non è generalizzabile; l’elenco Modified, l’uso del file di paging, i contatori correlati e il file di paging gestito dal sistema.  2 3 4 5 6 7 8

  3. Microsoft Learn, Data corruption on IO write. Sul fatto che il Modified Page Writer è un worker di sistema del gestore della memoria che scansiona le pagine sporche con backing nel file di paging e le scrive.  2 3

  4. Microsoft Learn, Introduction to page files. Sul fatto che il file di paging toglie dalla RAM le pagine modificate poco usate, allarga il Commit Limit e sostiene i dump di crash di sistema.  2 3 4

  5. Microsoft Learn, !pfn (WinDbg). Sul fatto di poter visualizzare stato, riferimenti, indirizzo PTE e altro di una voce PFN specificata. 

  6. Microsoft Learn, !memusage (WinDbg). Sul fatto di poter totalizzare l’uso della memoria fisica e stati di pagina come Zeroed, Free, Standby, Modified e Active. 

  7. Microsoft Learn, RAMMap - Sysinternals. Sul fatto che Use Counts, Processes, Priority Summary, Physical Pages, File Summary e File Details di RAMMap mostrano scopo della memoria fisica ed elenchi di pagine.  2

  8. Microsoft Learn, Working Set. Sul fatto che il gestore della memoria trimma il Working Set per creare memoria disponibile, e che si possono risolvere con un soft fault le pagine che restano in Transition o nel Working Set di un altro processo.  2

  9. Microsoft Learn, FileIo_Name class. Sul fatto che gli eventi File I/O ETW hanno FileObject e FileName, così FileObject può essere abbinato agli eventi Disk I/O per identificare l’I/O verso il file di destinazione. 

  10. Windows Insider Blog, Announcing Windows 10 Insider Preview Build 10525. Sull’implementazione iniziale del compression store di Windows 10 che poneva la raccolta di pagine compresse in RAM nel Working Set del processo System e riduceva le scritture su disco.  2

  11. Microsoft Learn, Find Process ID (PID) in Windows. Su esempi di elenchi di processi degli attuali Debugging Tools for Windows che mostrano un processo Memory Compression con un PID distinto sotto System. 

  12. Microsoft Learn, Testlimit - Sysinternals. Sulla sintassi ufficiale di Testlimit v5.24 in cui -m alloca memoria, -d alloca e Touch, -e è l’intervallo di allocazione e -c è il numero di allocazioni, con -c specificato per ultimo. 

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Una pagina viene scritta nel file di paging appena lascia il Working Set?
No. Una pagina non modificata passa in Standby con il contenuto intatto e diventa una cache riutilizzabile subito. Una pagina modificata passa in Modified e, dopo essere scritta di nuovo nel file di paging o nel file corrispondente se serve, procede verso uno stato riutilizzabile come Standby.
La memoria Disponibile di Gestione attività include Standby?
Sì. La memoria fisica disponibile che Windows riporta è la somma di Standby, Free e Zeroed. Standby conserva ancora contenuti vecchi, ma poiché può essere riutilizzata subito per un altro scopo se serve, viene contata come memoria disponibile.
La scrittura nel file di paging inizia solo dopo che la RAM è completamente esaurita?
No. Windows riscrive in background le pagine modificate poco usate, in base all'elenco Modified e allo stato della memoria disponibile. Non è un meccanismo semplice che aspetta l'esaurimento assoluto e poi evacua tutto in una volta.
Disabilitare il file di paging rende Windows più veloce?
Non si può affermarlo in generale. Disabilitarlo abbassa il Commit Limit, rende più difficile togliere dalla RAM le pagine modificate poco usate e influisce anche sui dump di crash di sistema. Di solito lo si lascia gestito dal sistema e si decide misurando il Commit di picco e i requisiti di dump.
Con la compressione della memoria il file di paging diventa superfluo?
Non diventa superfluo. Un compression store comprime pagine in RAM per ridurre l'I/O, ma le pagine compresse usano ancora memoria fisica e non sostituiscono la garanzia di Commit. La scelta tra compressione e paging out è una politica dinamica del gestore della memoria.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.

Torna al blog