Comprensione dell'utilizzo della memoria virtuale> swap + fisico su Linux

Ho un processo che riporta in "top" che ha 6 GB di memoria residente e 70 GB di memoria virtuale allocata. La cosa strana è che questo particolare server ha solo 8 GB fisici e 35 GB di spazio di swap disponibili.

Dal manuale "top":

   o: VIRT  --  Virtual Image (kb)
      The total amount of virtual memory used by the  task.   It  includes
      all  code,  data  and  shared  libraries  plus  pages that have been
      swapped out. (Note: you can define the STATSIZE=1 environment  vari-
      able  and  the VIRT will be calculated from the /proc/#/state VmSize
      field.)

      VIRT = SWAP + RES.

Data questa spiegazione, mi aspetterei che l'allocazione della memoria virutale per un processo sia limitata al mio scambio + memoria fisica disponibile.

Secondo 'pmap', il codice, la libreria condivisa e le sezioni di memoria condivisa di questo processo sono tutte minime - non più di 300 M circa.

Ovviamente, la macchina e il processo continuano a funzionare correttamente (anche se lentamente), quindi cosa mi manca qui?

Potrebbe essere richiesta una memoria pari a zero che non si trova nella RAM fisica o nel file di paging.

Alcune risorse che potresti voler consultare:

• http://www.gitam.edu/eresource/comp/gvr(os)/13.6.htm
• http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.system/2006-11/msg00176.html

La tua applicazione crea molte pagine di memoria vuote? In tal caso, l'applicazione potrebbe trarre grandi vantaggi da:

• http://code.google.com/p/compcache/ ( EXPERIMENTAL )

Ti consente di comprimere e decomprimere in pagine di memoria in tempo reale. A sua volta, sei in grado di mantenere tutto nella RAM piuttosto che scambiare su disco ( molto lento ).

Ecco una discussione di virt vs. memoria residente:

/programming/561245/virtual-memory-usage-from-java-under-linux-too-much-memory-used

La discussione si riferisce ai processi Java, ma è applicabile a tutto ciò che funziona sotto Linux. Il punto principale per quanto riguarda virt è che il totale include un sacco di cose che non possono mai essere usate. La Virt è qualcosa da considerare per i sistemi operativi a 32 bit (poiché i processi colpiranno i limiti dello spazio indirizzabile), ma per il resto non è molto utile. Come notato, la cosa a cui prestare attenzione è la memoria residente, che sarà limitata alla RAM fisica disponibile e allo swap.

Ciò è probabilmente dovuto al fatto che lo spazio degli indirizzi del processo ha le dimensioni indicate, ma non è realmente assegnato dal sistema operativo.

Da: http://lwn.net/Articles/428100/

Nel tentativo di raggiungere l'obiettivo di "sovraccarico abbastanza basso e nessuna latenza significativa", gli sviluppatori Go hanno formulato alcune ipotesi semplificanti, una delle quali è che la memoria gestita per un'applicazione in esecuzione proviene da un singolo, praticamente contiguo intervallo di indirizzi. Tali ipotesi possono incorrere nello stesso problema che il tuo editor ha riscontrato con vi - un altro codice può allocare pezzi nel mezzo dell'intervallo - quindi gli sviluppatori Go hanno adottato la stessa soluzione: semplicemente allocano tutta la memoria di cui pensano di aver bisogno (hanno pensato, ragionevolmente, che 16 GB dovrebbero essere sufficienti su un sistema a 64 bit) all'avvio.

Quindi questo è il modo in cui non viene eseguita la gestione della memoria a volte - avere uno spazio di indirizzi continuo semplifica il rilascio di mem inutilizzate.

La risposta è probabilmente MMAP: i dati si trovano sul disco, ma sono "esterni" allo scambio e non possono essere visti con il comando "libero" o "in alto".

Se il processo java non è troppo complicato, puoi provare a giocare con "lsof" per trovare dove si trova il file MMAP. Tuttavia, se questo processo Java è complicato, sarà difficile vederlo.

Sono stato anche sorpreso dal fatto che Linux ti permetta di allocare più memoria virtuale rispetto alla memoria fisica + spazio di scambio, ma apparentemente aiuta le prestazioni in situazioni tipiche.

Fortunatamente, esiste un parametro di ottimizzazione del kernel che può essere utilizzato per cambiare la modalità di contabilità della memoria. Questo parametro è vm.overcommit_memory e indica quale algoritmo viene utilizzato per tenere traccia della memoria disponibile. L'impostazione predefinita (0) utilizza il metodo euristico e esegue il commit eccessivo del sistema di memoria virtuale. Se vuoi che i tuoi programmi ricevano errori di memoria insufficiente nell'allocazione invece di sottoporre i tuoi processi a omicidi casuali, dovresti impostare questo parametro su 2.

http://www.linuxjournal.com/article/10678