La carica di commit è piena al 100% ma la memoria fisica è solo del 60% quando non si utilizza alcun file di paging

Ho disabilitato il file di paging nel mio sistema (il disco rigido è troppo lento, non è possibile acquistarne uno nuovo immediatamente, non è possibile spostare il file di paging in un'altra partizione). Quando vedo in Resource Monitor, usando applicazioni che richiedono memoria, il sistema mostra che la carica di commit è piena quasi al 100%. In effetti, se continuo a richiedere più memoria, i programmi iniziano a bloccarsi quando la commissione di commit raggiunge effettivamente il 100%.

Nel frattempo, il sistema dice che sto usando solo il 50-60% di memoria fisica e ho a disposizione circa 1 GB di memoria (gratuita + standby).

Se il commit charge è la memoria totale effettivamente richiesta, perché il sistema dice che tanta memoria è libera? La memoria fisica non è utilizzata da Windows? Il grafico della memoria è sbagliato? Mi sto perdendo qualcosa?

Esaurire il limite di commit mentre hai ancora molta RAM disponibile non è affatto insolito. Né il limite di commit né il costo di commit sono direttamente correlati alla RAM libera o disponibile.

Il limite di commit = dimensione del file di paging corrente + dimensione della RAM.

Poiché non si dispone di un file di paging, il limite di commit è inferiore rispetto a quello che si avrebbe se si disponesse di un file di paging. Non importa quanta RAM è libera . Per il limite di commit, conta solo la quantità di RAM installata . Puoi esaurire il limite di commit anche con il 90% della RAM libera o disponibile.

Commit charge è un conteggio della memoria virtuale, non fisico. Supponiamo che il mio programma richieda 2 GB impegnati, ma poi accede solo a 5 GB. I restanti 1,5 GB non ricevono mai errori, non vengono mai assegnati alla RAM, quindi l'utilizzo della RAM non riflette i 2 GB, solo 0,5 GB.

Tuttavia, "il commit del sistema" è aumentato di 2 GB perché il sistema ha "impegnato" che ci sarà un posto per contenere i miei 2 GB, se dovessi effettivamente averne bisogno. Il fatto che su una determinata esecuzione del programma non proverò necessariamente a usarlo tutto non aiuta. Ho chiesto 2 GB e il successo del ritorno da quella chiamata mi dice che il sistema operativo "ha commesso" - cioè promesso - che posso usare così tanto spazio di indirizzi virtuale. Il sistema operativo non può fare questa promessa a meno che non ci sia un posto per mantenere tutto.

Quindi: rimetti il ​​tuo file di paging, aggiungi più RAM o esegui meno roba contemporaneamente. O una combinazione dei tre. Queste sono le uniche opzioni per evitare gli errori "memoria insufficiente" e "memoria insufficiente".

Vedi anche le mie risposte qui (più a lungo) e qui (molto più a lungo).

Come dimostra il test di allocazione della memoria nell'articolo su http://brandonlive.com/2010/02/21/measuring-memory-usage-in-windows-7/ , Windows è un tipo di sistema che fallirebbe una grande allocazione di memoria se tale allocazione, insieme a tutte le allocazioni precedenti (il concetto che Microsoft chiama come "commit"), porterebbe il "commit" totale al di sopra della somma sia della memoria fisica che della somma di tutti i file di paging (swap).

Si consideri che un'allocazione di per sé non utilizza alcuna memoria effettiva (né fisica né di scambio), prima che una lettura o scrittura avvenga all'interno dello spazio di indirizzi virtuale del processo per l'allocazione di cui sopra. Ad esempio, un'allocazione di 2 GB da sola influirebbe solo sui numeri "Commit" (in Windows 7 talk), lasciando da sola la "memoria fisica" (fino a quando non si verifica la lettura / scrittura all'interno di tale allocazione).

Per quanto riguarda la progettazione del sistema operativo, l'approccio alternativo sarebbe quello di consentire sempre l'allocazione di qualsiasi dimensione (a meno che la memoria disponibile non sia già completamente esaurita) e quindi lasciare che le applicazioni falliscano in lettura / scrittura. Vedi /cs/42877/when-theres-no-memory-should-malloc-or-read-write-fail per maggiori dettagli.

La memoria disponibile non è quella che pensi che sarebbe. In realtà non è stata utilizzata una cache di file di processi terminati di recente o di processi che sono stati forzati a rinunciare alla memoria di altri processi. Potrebbero essere richiamati allo scopo originale. vedi per maggiori dettagli.

http://support.microsoft.com/kb/312628

Per non avere un file di paging questo è molto male. Windows si degrada male senza uno. Ricorda che anche i file eseguibili vengono utilizzati come file di scambio quando non è presente alcun file di paging. Anche se l'unità è lenta, è meglio avere un file di paging fino a quando non si ottengono da 8 a 16 GB di memoria. Alcune persone pensano che anche Windows 7 possa funzionare senza uno.

Dò regolarmente una spinta alla vecchia macchina facendo alcune cose. Pulisci il disco rigido il più possibile. Copia tutto ciò che puoi rimuovere temporaneamente dall'unità su un backup. Rimuovi le applicazioni che non ti servono. Rimuovere le app può reinstallare.

Al termine, deframmenta il tuo disco rigido. A quel punto ricrea il tuo file di paging. Sarà il più vicino possibile alla parte anteriore dell'unità. Crea una dimensione fissa circa 1,5 volte la memoria. Questa è la mia regola, di solito ho visto dimensioni tra 1 e 3 volte la memoria. Questo gli darà un leggero aumento di velocità rispetto ai soliti posti in cui verrebbe posizionato.

Uso il defrager auslogico gratuito (annunci per più strumenti). Ce ne sono altri che fanno anche questo. Dai un'occhiata agli sbrinatori su portableapps.com. Ottimizza il disco posizionando i file di recente accesso vicino alla parte anteriore dell'unità per un accesso più rapido. Mostra dove si trova il file di paging in modo da poter vedere se lo hai spostato nel 25% superiore dell'unità.

Successivamente, reinstalla le app e copia i tuoi dati.

Direi che ottieni un aumento del 10 o del 20%. Ma il valore principale è che gran parte dell'esitazione scompare per un'esperienza più fluida.