Cosa ha usato la memoria Linux? Cache bassa, buffer basso, non una macchina virtuale

11

Prima di tutto, sì, ho letto LinuxAteMyRAM , il che non spiega la mia situazione.

# free -tm
             total       used       free     shared    buffers     cached
Mem:         48149      43948       4200          0          4         75
-/+ buffers/cache:      43868       4280
Swap:        38287          0      38287
Total:       86436      43948      42488
#

Come mostrato sopra, la -/+ buffers/cache:riga mostra che la velocità di memoria utilizzata è molto alta. Tuttavia, dall'output di top, non vedo alcun processo utilizzato più di 100 MB di memoria.

Quindi, cosa ha usato la memoria?

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
28078 root      18   0  327m  92m  10m S    0  0.2   0:25.06 java
31416 root      16   0  250m  28m  20m S    0  0.1  25:54.59 ResourceMonitor
21598 root     -98   0 26552  25m 8316 S    0  0.1  80:49.54 had
24580 root      16   0 24152  10m  760 S    0  0.0   1:25.87 rsyncd
 4956 root      16   0 62588  10m 3132 S    0  0.0  12:36.54 vxconfigd
26703 root      16   0  139m 7120 2900 S    1  0.0   4359:39 hrmonitor
21873 root      15   0 18764 4684 2152 S    0  0.0  30:07.56 MountAgent
21883 root      15   0 13736 4280 2172 S    0  0.0  25:25.09 SybaseAgent
21878 root      15   0 18548 4172 2000 S    0  0.0  52:33.46 NICAgent
21887 root      15   0 12660 4056 2168 S    0  0.0  25:07.80 SybaseBkAgent
17798 root      25   0 10652 4048 1160 S    0  0.0   0:00.04 vxconfigbackupd

Questa è una macchina x86_64 (non un server di marca comune) che esegue x84_64 Linux, non un contenitore in una macchina virtuale. Kernel ( uname -a):

Linux 2.6.16.60-0.99.1-smp #1 SMP Fri Oct 12 14:24:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Contenuto di /proc/meminfo:

MemTotal:     49304856 kB
MemFree:       4066708 kB
Buffers:         35688 kB
Cached:         132588 kB
SwapCached:          0 kB
Active:       26536644 kB
Inactive:     17296272 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:     49304856 kB
LowFree:       4066708 kB
SwapTotal:    39206624 kB
SwapFree:     39206528 kB
Dirty:             200 kB
Writeback:           0 kB
AnonPages:      249592 kB
Mapped:          52712 kB
Slab:          1049464 kB
CommitLimit:  63859052 kB
Committed_AS:   659384 kB
PageTables:       3412 kB
VmallocTotal: 34359738367 kB
VmallocUsed:    478420 kB
VmallocChunk: 34359259695 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB

dfnon riporta un grande consumo di memoria dai tmpfsfilesystem.

linux memory

— Jason
fonte

2

Qual è l'output di ps -eo pid,user,args,pmem --sort pmem?

— Braiam,

Link incollato qui , provato qualche volta, ottenuto lo stesso output.

— Jason,

3

Non usare head! Voglio l'output completo del comando completo. Se volessi che tu headlo usassi lo metterei nel mio comando. Fornisci sempre l'output completo al comando richiesto dalla gente.

— Braiam,

3

Su un telefono, non ricordo la sintassi dalla parte superiore della mia testa, ma controlla la memoria condivisa sysv. Il comando è ipcs, credo.

— derobert,

5

Hai mai trovato una soluzione per questo? - Sto

— riscontrando

4

La memoria su Linux può essere una strana bestia da diagnosticare e capire.

Durante il normale funzionamento la maggior parte, se non tutte, la memoria verrà allocata a un'attività o a un'altra. Alcuni saranno assegnati ai processi di primo piano attualmente in esecuzione. Alcuni memorizzeranno i dati memorizzati nella cache dal disco. Alcuni manterranno i dati associati a processi che non si stanno attivamente eseguendo in quel preciso momento.

Un processo in Linux ha il suo spazio di indirizzi virtuale (VIRT nell'output di top). Questo contiene tutti i dati associati al processo e può essere considerato quanto "grande" sia il processo. Tuttavia è raro che tutta quella memoria faccia parte attivamente della mappa di memoria "reale" (RES nell'output di top). La RES, o memoria residente, sono i dati che sono direttamente accessibili nella RAM al momento. Quindi c'è anche una memoria condivisa (SHR). Che può essere condiviso tra più istanze dello stesso processo. Quindi la memoria utilizzata da un processo è in qualsiasi momento RES + SHR, ma se esiste più di un'istanza del processo che utilizza la memoria condivisa, l'utilizzo è RES più RES più RES ... RES più plus.

Allora perché la differenza tra RES e VIRT? Sicuramente se un processo ha un blocco di memoria allocata è allocata memoria, non è vero? No. La memoria è allocata in pagine e le pagine possono essere attive o inattive. Quelli attivi sono quelli che sono in RES. Inattivi sono "il resto". Possono essere spinti da una parte in quanto non sono accessibili al momento. Ciò significa che possono essere scambiati su disco se la memoria si restringe. Ma non vanno semplicemente sul disco. Prima si siedono in una cache. Non si desidera scambiare continuamente, quindi esiste un buffer tra l'applicazione e lo spazio di scambio. Questi buffer cambiano costantemente mentre lo swapper seleziona un processo diverso da eseguire e pagine diverse diventano attive e inattive. E tutto ciò che sta accadendo è il modo di digiunare per un semplice essere umano al passo con

E soprattutto ci sono i buffer del disco. Non solo la memoria inattiva va in una cache, ma quando quella cache viene scambiata su disco, passa prima a un buffer del disco per essere messa in coda per la scrittura. Quindi questo è un secondo strato di cache nel mix. E quei buffer del disco sono anche usati da altre parti del sistema per il buffering IO generale. Quindi cambiano continuamente.

Quindi, ciò che vedi in cose come tope freecosì via sono istantanee istantanee dello stato attuale della macchina o statistiche aggregate per un periodo di tempo. Quando hai letto i dati non sono aggiornati.

Qualsiasi processo può accedere a grandi quantità di memoria, ma raramente è sensato farlo. Non può comunque accedere a tutta la memoria in una volta, quindi la memoria che al momento non sta guardando viene spostata nella cache a meno che non sia specificatamente contrassegnata come "bloccata nel core".

Quindi la quantità di memoria "utilizzata" da un'applicazione e la quantità di memoria che "ha" sono due cose completamente diverse. Gran parte di uno spazio di dati delle applicazioni è in realtà nella cache, non nella memoria "core", ma poiché la cache è nella RAM il più delle volte è immediatamente disponibile e deve solo "attivare" per diventare memoria "core". Questo a meno che non sia stato scambiato su disco, quando quindi ha bisogno di essere sostituito (che potrebbe essere veloce se si trova nel buffer).

A causa della natura ad alta velocità della bestia e del fatto che le cifre cambiano sempre, i numeri possono anche cambiare parzialmente attraverso il calcolo di ciò che sono, quindi non è mai possibile dire esattamente "questo è quanta memoria è in uso" da la prospettiva di un utente. Meminfo è un'istantanea nel tempo fornita dal kernel, ma poiché è il kernel che sta eseguendo, non mostra necessariamente lo stato reale di uno dei processi di utilizzo della memoria, dato che nessun processo sta eseguendo attivamente in quel momento - è tra processi.

Come ho detto, è tutto molto confuso.

Ma alla fine non importa davvero. Ciò che conta non è la quantità di memoria disponibile "libera", ma la quantità di spazio di swap utilizzata e la frequenza con cui si accede allo spazio di swap. È lo scambio che rallenta un sistema, non la mancanza di memoria (sebbene la mancanza di memoria causi lo scambio eccessivo). Se hai molta memoria usata, ma non stai utilizzando (o pochissimo) spazio di swap, allora le cose sono normali. La memoria libera in generale non è desiderabile, ed è spesso puramente transitoria, in quanto era in uso per uno scopo, ma non è stata ancora allocata per un altro, ad esempio era memoria cache ed è stata scambiata su disco, ma non è stato ancora usato per nient'altro, o era buffer del disco, i buffer sono stati scaricati su disco, ma nessuna applicazione lo ha ancora richiesto per la cache.

— Majenko
fonte

6

Questo è davvero interessante ma non risponde alla domanda sul perché l'OP sta osservando questa discrepanza specifica.

— terdon,

Penso che l'unica vera discrepanza risieda tra le aspettative dei PO e ciò che Linux sta fornendo. Vale a dire, i valori forniti da Linux non si sommano, ed è perché sono già cambiati.

— Majenko,

Dato che l'OP non sembra davvero capire la domanda che sta ponendo, non vedo come si possa scegliere una risposta "giusta". Possiamo spiegare come funziona il sistema fino a quando non siamo blu in faccia, ma se non riesce a cogliere queste basi e rendersi conto che la sua domanda è in realtà insignificante, non avremo mai una risposta "giusta".

— Majenko,

Apprezzo per aver scritto questo, ma onestamente non mi piace il tono di agnosticismo dietro di esso. Sono d'accordo con la teoria dello "snapshot" ma se lo snapshot continua a fornire lo stesso numero che dice che l'utilizzo della RAM è elevato mentre non riesci a scoprire come è successo, non sarai curioso?

— Jason,

5

Dovresti pubblicarlo sul tuo blog. È buono, ma non è rilevante qui. Sta succedendo qualcosa di strano (e intendo strano che proviene da qualcuno che capisce quello che hai scritto), dal momento che il VIRT dei processi non tiene conto di tutto l'utilizzo della RAM e il sistema non si scambia nonostante la pressione per farlo.

— Gilles 'SO- smetti di essere malvagio' il

0

Questa è una parte della risposta:

C'è una differenza tra ciò che è designato come memoria "Usato" (nel comando "libero") e "Memoria allocata a processi attivi (utente)" (in / proc / meminfo). Ok, quindi il tuo sistema ha un totale di 48149 MB (circa 47Gb)

Se guardi il tuo / proc / meminfo vedi: Inattivo: 17296272 kB = (circa 16,5 Gb) - La memoria inattiva potrebbe provenire da processi che sono terminati. Può anche essere una memoria che non è stata utilizzata per molto tempo da un processo che è attivo. La memoria non viene "liberata" solo perché il processo è terminato. Perché? perché è più lavoro. La stessa pagina di memoria potrebbe essere utilizzata di nuovo, quindi il kernel di Linux lascia i dati lì nell'elenco "inattivo" fino a quando un processo non ne ha bisogno.

Questa pagina spiega alcuni di questi. http://careers.directi.com/display/tu/Understanding+and+optimizing+Memory+utilization ; Leggi la sezione sul PFRA (algoritmo di recupero del frame della pagina) usato dal kernel Linux: "Le pagine incluse nelle cache del disco e della memoria non referenziate da alcun processo devono essere recuperate prima che le pagine appartenenti agli spazi degli indirizzi in modalità utente dei processi" "Reclaiming" significa spostarli da "usato" (inattivo + attivo) a "libero".

Questo spiega più dettagliatamente la gestione della memoria: come funzionano gli elenchi attivi e inattivi e come le pagine si spostano tra loro https://www.cs.columbia.edu/~smb/classes/s06-4118/l19.pdf

Credo che ci sia anche memoria utilizzata dal kernel per le strutture di dati e che ciò si manifesti come "slab 1049464 kb" (~ 1 GB), ma non sono sicuro che questo sia conteggiato separatamente.

— ssl
fonte

Volevo solo aggiungere che in passato ho avuto esperienza con un sistema a corto di memoria a causa di un'applicazione scritta male che allocava segmenti di memoria condivisa, ma non li rilasciava. I segmenti di memoria condivisa sono persistiti anche quando tutti i processi che li utilizzano sono morti. Questo non era Linux, ma potrebbe essere vero anche in Linux. come menzionato sopra, vedere ipcs per informazioni al riguardo. vedi makelinux.net/alp/035 Dice che è necessario deallocare esplicitamente la memoria condivisa.

— ssl

1

Non capisco tutto ciò di cui parla la tua risposta, ma "La memoria inattiva potrebbe provenire da processi che sono terminati" è decisamente sbagliata. La memoria di Userland è disponibile in due versioni: mappata o anonima. La memoria mappata può sempre essere recuperata perché i dati possono essere ricaricati da un file. La memoria anonima può essere recuperata se viene sostituita. La memoria inattiva è la memoria che è un buon candidato per il recupero; tuttavia, il contenuto deve essere in un file o scambiare da qualche parte, perché quella memoria è ancora in uso. Quando un processo muore, la sua memoria diventa libera e non viene più considerata in attivo + inattivo.

— Gilles 'SO- smetti di essere malvagio' il

1

Alcuni riferimenti: cosa può causare un aumento della memoria inattiva e come recuperarla? in caso di errore del server; suggerimenti vecchi ma ancora per lo più applicabili da Red Hat . E anche l'articolo di Bhavin Turakhia che citi; non è esplicito sulla questione, ma spiega le pagine anonime e mappate nella sezione "Comprensione della PFRA".

— Gilles 'SO- smetti di essere malvagio' il

Ho pensato a pagine inattive a cui non fa riferimento un processo di questo articolo: kernel.org/doc/gorman/html/understand/understand013.html Anche se suppongo che potrebbe essere pagine liberate da un processo che è ancora in esecuzione. sezione "Recuperare le pagine dagli elenchi LRU"

— ssl

Ma forse questo si riferisce solo alle pagine nella cache di swap?

— SSL

-2

Usi NFS?
Potrebbe valere la pena correre in slabtop -oentrambi i modi, nfs_inode_cachepuò sfuggire di mano.

— cjve
fonte

-4

La figura che dovresti guardare è usata swap , nel tuo output che è "0", il che significa che NON hai esaurito la RAM. Finché il sistema non scambia memoria, non dovresti preoccuparti delle altre figure, che sono comunque molto difficili da interpretare.

Modifica: Ok, sembra che la mia risposta sia considerata criptica piuttosto che concisa. Quindi lasciami elaborare.

Immagino che il problema principale qui sia nell'interpretazione dell'output di top / ps, che non è molto preciso. Ad esempio, poiché gli usi multipli delle stesse librerie condivise non vengono calcolati come ci si aspetterebbe, vedere ad esempio http://virtualthreads.blogspot.ch/2006/02/understanding-memory-usage-on-linux.html

Ciò che è, tuttavia, assolutamente accurato è che se la dimensione dello scambio è esattamente zero, il sistema non ha esaurito la memoria (ancora). Ovviamente, questa è un'affermazione molto chiara, ma per la profilazione dell'utilizzo effettivo della memoria del tuo sistema, top non sarà la cosa giusta. (E se guardi in alto, almeno ordina l'output per virt o% mem.)

Vedi anche http://elinux.org/Runtime_Memory_Measurement

— Echsecutor
fonte

1

Non dovresti preoccuparti se il tuo sistema sta scambiando, è normale. Dovresti preoccuparti se il tuo sistema si scambia troppo spesso (il che non è la stessa cosa che avere un ampio spazio di scambio usato). Il fatto che lo swap usato sia 0 è di per sé strano, con così poca memoria fisica libera.

— Gilles 'SO- smetti di essere malvagio' il

bene, il suo output indica che il suo sistema non ha affatto scambiato. Questo è sicuramente il tasso di scambio ottimale. Non ho detto che una piccola dimensione di swap sia una buona cosa, ma sicuramente una dimensione zero lo è. E fintanto che il sistema non esaurisce effettivamente la memoria libera, perché dovrebbe iniziare a scambiare?

— Echsecutor,

No, l'assenza di scambio è tutt'altro che ottimale. La memoria dei programmi che al momento non vengono utilizzati dovrebbe essere scambiata per fare spazio alla cache del disco per i file utilizzati di frequente. Per quanto riguarda la punta che avete appena aggiunto circa l'uscita di free, credo che si intende top-, ma anche in questo caso la somma solo essere più rispetto al totale (perché la memoria condivisa è conteggiato più volte), non di meno.

— Gilles 'SO- smetti di essere malvagio' il

cosa intendi con la somma non può che essere più non meno? top mostra solo tutti i processi che si adattano allo schermo, sono abbastanza sicuro che quanto sopra non è tutti processi in esecuzione, quindi non vengono ordinati in base all'utilizzo della memoria, quel pezzo di output è piuttosto inutile per la domanda "che cosa ha usato la memoria" .

— Echsecutor,

oh, e non voglio entrare in un dibattito per quando è il momento ottimale per iniziare a scambiare, ma il default del server linux è non scambiare la memoria solo perché "non viene utilizzato al momento".

— Echsecutor,