Utilizzo effettivo della memoria di un processo

Di seguito sono riportati l'utilizzo della memoria mysqle apacherispettivamente sul mio server. Come da output di pmapdire, mysqlsta usando circa 379M e apachesta usando 277M.

[root@server ~]# pmap 10436 | grep total
 total           379564K

[root@server ~]# pmap 10515 | grep total
 total           277588K

Confrontando questo con l'output di top, vedo che i valori sono quasi corrispondenti.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
10515 apache    20   0  271m  32m 3132 S  0.0  6.6   0:00.73 /usr/sbin/httpd
10436 mysql     20   0  370m  21m 6188 S  0.0  4.3   0:06.07 /usr/libexec/mysqld --basedir=....

Ora questi valori sicuramente non sono l'attuale utilizzo della memoria di quei due processi, poiché se così fosse avrebbe superato i 512M ramsul mio sistema e capisco il fatto che queste sono le dimensioni delle pagine assegnate a questi due processi e non proprio la dimensione della memoria utilizzata attivamente da loro. Ora, quando usiamo pmap -x, vedo una colonna in più Dirtyche mostra molto meno utilizzo della memoria per il processo. Come mostrato nell'esempio seguente, la Dirtycolonna mostra 15M rispetto a 379M nella prima colonna. La mia domanda è: il valore sotto colonna Dirtyè la quantità "reale" di memoria utilizzata attivamente da quel processo? In caso contrario, come possiamo scoprire l'utilizzo della memoria reale di un processo? Non pse topper le stesse ragioni sopra. Abbiamo qualcosa sotto/proc che darà queste informazioni?

[root@server ~]# pmap -x 10436 | grep total
total kB          379564   21528   15340
[root@server ~]#


[root@server ~]# free -m
             total       used       free     shared    buffers     cached
Mem:           489        447         41          0         52        214
-/+ buffers/cache:        180        308
Swap:         1023          0       1023
[root@server ~]#

Non esiste alcun comando che dia "l'utilizzo effettivo della memoria di un processo" perché non esiste l'utilizzo effettivo della memoria di un processo .

Ogni pagina di memoria di un processo potrebbe essere (tra le altre distinzioni):

• Archiviazione temporanea utilizzata solo da quel processo.
• Condiviso con altri processi utilizzando una varietà di meccanismi.
• Backup da un file su disco.
• Nella memoria fisica o nello scambio.

Penso che la figura "sporca" sommi tutto ciò che è nella RAM (non lo scambio) e non supportato da un file. Ciò include sia la memoria condivisa che non condivisa (sebbene nella maggior parte dei casi diversi dai server di fork, la memoria condivisa sia composta solo da file mappati in memoria).

Le informazioni visualizzate da pmapprovengono da e . Questo è il reale utilizzo della memoria del processo: non può essere riassunto da un singolo numero./proc/PID/maps/proc/PID/smaps

Citerò qualcosa che ho scritto nella pagina man per un'applicazione che fa analisi simili a quelle in alto e che disegna informazioni dalle stesse fonti di pmap(ad esempio /proc/[N]/maps):

SPAZIO INDIRIZZO VIRTUALE VS. MEMORIA FISICA

È importante comprendere la differenza tra lo spazio di indirizzi virtuale e la memoria fisica nell'interpretazione di alcune delle statistiche di cui sopra. Come suggerisce il nome, lo spazio degli indirizzi virtuali non è reale; è fondamentalmente una mappa di tutta la memoria attualmente allocata a un processo. Il limite sulla dimensione di questa mappa è lo stesso per ogni processo (generalmente 2-4 GB) e non viene accumulato (vale a dire, potresti avere dozzine o centinaia di processi, ognuno con il suo indirizzo virtuale 2-4 GB) spazio, su un sistema che in realtà ha solo 512 MB di memoria fisica ).

I dati non possono effettivamente essere archiviati o recuperati dallo spazio degli indirizzi virtuali; i dati reali richiedono memoria fisica reale. È compito del kernel gestirne uno in relazione a un altro. Le statistiche dello spazio virtuale (VirtualSz, Data + Stack e Priv & Write) sono utili per considerare la struttura di un processo e la relazione con l'uso della memoria fisica, ma per quanto riguarda la quantità di RAM effettivamente utilizzata, le statistiche della memoria fisica (ResidentSz, Share e Proporzione) sono ciò che conta.

pmapti segnala principalmente informazioni sullo spazio di indirizzi virtuali . La tua osservazione che "i valori sono quasi corrispondenti" topnell'output si riferisce presumibilmente alla figura VIRT, che è molto diversa dalla figura RES. Questi corrispondono esattamente a quanto sopra ho etichettato "VirtualSz" e "ResidentSz" (il VIRT è per il virtuale, il RES è per il residente).

Ora, quando usiamo pmap -x, vedo una colonna aggiuntiva Dirty che mostra molto meno utilizzo della memoria per il processo. Come si vede nell'esempio seguente, la colonna sporca mostra 15 M contro 379 M nella prima colonna. La mia domanda è: il valore sotto la colonna Dirty è la quantità "reale" di memoria utilizzata attivamente da quel processo?

No, ma in qualche modo. La memoria "sporca" si riferisce ai dati che sono stati caricati dal disco e successivamente modificati; poiché è stato modificato, deve far parte della memoria residente perché queste modifiche sono attualmente archiviate nella RAM. Tuttavia, non è sinonimo di esso.

La memoria virtuale è come i numeri di selezione rapida, tranne per il fatto che ce ne sono circa 3 miliardi (per il sistema a 32 bit, 4 miliardi per l'app a 32 bit sul kernel a 64 bit, molto di più per l'applicazione a 64 bit) e non è possibile comporre numeri direttamente, hanno da mappare per la composizione rapida.

Diversi processi possono avere mappature diverse (numeri di chiamata rapida) per lo stesso indirizzo (numeri di telefono). Ad esempio possono condividere più librerie, quindi hanno indirizzi virtuali per l'intera libreria (puoi vederlo in pmap). Possono persino condividere lo stesso eseguibile, ad esempio 2 istanze di bash.

Finora questo spiega come il sub di tutto l'indirizzo virtuale può adattarsi, ma c'è di più. Un processo può avere così tanta memoria virtuale da non adattarsi, come? Alcune parti di una libreria o eseguibile non possono essere utilizzate, non verranno copiate dal disco in ram, oppure ram si riempie e i bit che sono stati caricati dal disco vengono rilasciati, perché possono essere recuperati dal disco se necessario, o la memoria che non è stata salvata sul mio disco è mappata per lo scambio, copiata per lo scambio e quindi rilasciata. Può quindi essere letto da swap se e quando necessario. Se una di queste ultime strategie viene utilizzata troppo, il sistema diventa lento.