Perché Windows 2008 utilizza lo scambio prima che la memoria sia piena?

Gestisco un server Windows 2008 (bene, su Amazon EC2) con IIS e un'app Web .NET4. L'altro giorno ho ricevuto un avviso di memoria e sono andato a guardare, e sicuramente la memoria di processo è cresciuta nel tempo attraverso una sorta di perdita lenta. Non è cresciuto molto, proprio come 60M a 200M, ma stava succedendo abbastanza altro con la scatola che ha superato la nostra soglia piuttosto bassa (75%) per spegnere il monitor.

Ho riciclato il pool di app e la memoria liberata e, dopo aver esaminato le statistiche, ho notato che lo spazio di swap veniva utilizzato in modo significativo e che oltre 1 GB di esso veniva liberato con quel riciclo.

Forse questa è una domanda di base, ma io sono un ragazzo UNIX e sono abituato a scambiarmi non abituandomi fino a quando non avrai esaurito la memoria. Questa scatola non ha mai superato il 75% di utilizzo della memoria. È una cosa di Windows o una cosa di .NET o una cosa di Amazon? Ho il sospetto che in questa app ci sia una perdita di memoria molto più grande di quanto sospetti: non sta passando da 60M a 200M, sta perdendo da 60M a 1.2GB, ma gran parte di questo sta andando in qualche modo "freddo" e viene spinto fuori per scambiare?

Ho il riciclo della memoria impostato nel pool di applicazioni, ma innesca la memoria piena della scatola, quindi questa app potrebbe diventare davvero grande prima che ricicli automaticamente.

Potrei impostare un riciclaggio "a tempo" regolare, ma questa è una soluzione alternativa, chiederò allo sviluppatore di riparare l'app ma devo capire cosa sta succedendo qui con l'uso dello scambio per essere sicuro di aver capito bene.

Modifica con maggiori informazioni: memoria di istanza: 1,7 GB di scambio: 4,5 GB

Vedo il processo w3wp.exe in taskmgr che mostra quella memoria: 211.000 k. Ma quando l'ho riavviato (è nel suo pool di app ed è l'unica app sulla scatola), il suo utilizzo della memoria è sceso al suo normale punto di partenza di 60M e come 1 GB + di swap anche liberato. In taskmgr ho appena avuto la solita statistica Memory (Private Working Set), ma ho visto il cambio di swap tramite il mio altro monitoraggio (Cloudkick). Tornando indietro e guardandolo oggi, la memoria è tornata a 195M sul processo (1,2 GB in totale) e lo swap è passato da 1,0 GB a 1,1 GB, ma non è tornato indietro nel modo in cui si trovava (graficamente nel tempo, è un strisciamento lento).

Sono meno preoccupato per questa app specifica e più preoccupato solo di capire quando Windows scambia e come lo usa, e cosa preoccuparsi della data memoria di Windows e dell'utilizzo dello scambio in generale.

Windows e Linux hanno due diverse strategie di pagina / scambio.

Linux

Linux vuole evitare di usare lo spazio di swap e attende fino all'ultimo momento possibile. Se vedi una grande quantità di swap in Linux, il tuo sistema probabilmente è o era nei guai. Questa strategia è utile per ridurre al minimo l'I / O generale del disco, che è la parte più lenta del sistema, ma più debole per i sistemi con periodi alternati di carico leggero e pesante (e, onestamente, è la maggior parte di noi). I tempi in cui il tuo carico è già pesante ora saranno gravati dall'i / o del disco "extra", o, in altri termini, devi progettare le build del tuo server con un occhio per avere abbastanza RAM che non cambi anche durante massimi tempi di carico previsti.

finestre

Windows vuole trattare la memoria come una semplice cache del file di paging. La tua vera memoria è sempre su disco, ma leggerà / scriverà dalla "cache" prima se può. Questa strategia è utile per ridurre il carico nel tempo; quando il sistema è occupato e deve scambiare pagine, la pagina corrente è già su disco e metà del lavoro è già fatto. Questo approccio aveva un grande senso quando Windows era giovane, 32 MB (dimentica GB) era ancora molta RAM e la frequente necessità di utilizzare lo spazio di swap era un dato di fatto. Ancora oggi questo è utile per i carichi di lavoro che si alternano tra carichi leggeri e occupati, poiché aiuta a distribuire gli I / O del disco in modo più uniforme nel tempo.

Le moderne versioni di Windows hanno ulteriori ottimizzazioni - come SuperFetch - per precaricare e preparare le pagine di memoria su disco e nella RAM quando il carico è altrimenti leggero, per evitare la necessità di ulteriori scritture del disco quando si carica un programma per la prima volta. Tutto ciò significa che puoi progettare il tuo sistema in modo che abbia bisogno di RAM sufficiente solo per qualcosa di meno del massimo carico previsto, in modo da poter comunque avere prestazioni almeno accettabili in ogni momento, con costi ridotti.

Convergenza

Questo concetto di misurazione o previsione del carico in un ambiente di test e quindi allocazione delle risorse di produzione quando il carico è noto è uno sviluppo relativamente recente nella creazione di sistemi, reso possibile, o almeno pratico, in parte con l'avvento dei server virtuali e quindi del cloud . A seconda del carico, è anche possibile progettare il sistema in modo tale che non debba mai essere sostituito. In questi casi, Windows ti consente di disattivare il paging e comportarti più come un sistema Linux. Tuttavia, devi stare attento; se la progettazione del tuo sistema richiede più memoria del previsto, puoi metterti nei guai in questo modo.

D'altro canto, i moderni kernel Linux sono più disposti a scambiarsi opportunisticamente su disco rispetto a prima. Quindi la differenza nelle strategie di gestione della memoria tra i due sistemi è ancora presente, ma ora meno distinta rispetto al passato. Entrambi i sistemi hanno i loro meriti, e ciascuno osserva l'altro per vedere quali progressi possono copiare.

Windows (e Linux e altri SO simili a Unix) sposteranno le pagine che non sono state utilizzate per un po 'di tempo su disco per fare spazio a buffer e cache per accelerare l'attività di I / O attivo. Inoltre le applicazioni spesso allocano più memoria di quella che useranno immediatamente - questo può incoraggiare il kernel a sfogliare alcune cose che non sono state recentemente toccate in background, in modo che tali applicazioni non vedano il ritardo di paging quando si avviano improvvisamente usando tale allocazione.

Sotto Linux puoi modificare (o bloccare) questo comportamento alterando i relativi valori di "swappiness" nel /procfilesystem - senza dubbio ci sono valori di registro che puoi modificare per modificare anche il comportamento di Windows in questo senso.

Un'altra cosa da tenere presente è che quando un file è stato sottoposto a paging e successivamente riletto, il kernel non lo rimuoverà dal file di paging fino a quando il file non sarà altrimenti pieno o la pagina nella RAM verrà modificata. In questo modo, se ha bisogno di sfogliare di nuovo quella parte, può farlo senza dover effettivamente scrivere le pagine sul disco: il contenuto è già lì. Ciò può migliorare notevolmente le prestazioni in situazioni in cui il sovraccarico della memoria è diventato così grave da causare il blocco dei file di pagine (un numero significativo di pagine viene costantemente mappato in entrata e in uscita). Probabilmente scoprirai che alcuni dati sono stati espulsi da quella perdita di memoria e da allora sono stati riletti ma non cancellati dal disco nel caso in cui tali pagine debbano essere mappate o RAM per fare spazio di nuovo in seguito. Sotto Linux, il valore "SwapCached" in/proc/meminfomostra quanti dati sono presenti nelle pagine con copie identiche nella RAM e sul disco. Windows senza dubbio utilizza la stessa ottimizzazione (o qualcosa di simile) ma non sono esattamente dove guardare per vedere quanto sta succedendo (senza dubbio ci sono contatori di monitoraggio delle prestazioni pertinenti che è possibile interrogare).

tl; dr: questo è normale. Un moderno kernel del sistema operativo cercherà di essere intelligente e massimizzare la quantità di RAM che può utilizzare come cache per salvare le operazioni di I / O e talvolta avrà i dati copiati sul disco e nella RAM per salvare l'I / O se è necessario eseguire il paging di quei bit di RAM più tardi. È molto probabile che questo uso dei file di paging in questi due modi, anche se non si ha attualmente poca RAM, stia migliorando le prestazioni complessive anziché ridurle.