Memoire free/used sous linux

On Wed, 06 Apr 2005 13:23:28 +0200, bill wrote:

Bonjour à tous,

J'ai commencé à m'interesser à l'etude de la mémoire utilisée (ou pas)
sous linux (noyau 2.4 , red hat et suse )

J essaye de mettre en place une supervision qui me permettrait de savoir
si la machine commence à etre limite coté memoire Vive. Sachant que de
tres nombreux process plus ou moins gourmands tournent sur le serveur
(oracle , java etc...)

D'apres les informations recoltées , je sais que la commande "free" est
une blague et qu'il est nécessaire de taper sur /proc/meminfo pour
connaitre la mémoire "immédiatement reallouable" autrement dit la
mémoire effectivement disponible à l instant T sur le serveur.


A priori il semblerait qu'il faille regarder "Inact_target" afin de
connaitre la mémoire reellement dispo.

En parallele j'ai lu ailleurs que Memoire libre = Buffers + Cached
(toujours dans /proc/meminfo)


Lorsque je tente d'analyser un serveur de production je vois ceci :
(/proc)>cat meminfo
total: used: free: shared: buffers: cached:
Mem: 2108510208 2083962880 24547328 0 5677056 1973755904
Swap: 2138562560 144998400 1993564160
MemTotal: 2059092 kB
MemFree: 23972 kB
MemShared: 0 kB
Buffers: 5544 kB
Cached: 1880324 kB
SwapCached: 47172 kB
Active: 1200628 kB
Inact_dirty: 709788 kB
Inact_clean: 22624 kB
Inact_target: 20 kB
HighTotal: 1179584 kB
HighFree: 14088 kB
LowTotal: 879508 kB
LowFree: 9884 kB
SwapTotal: 2088440 kB
SwapFree: 1946840 kB


Sur 2 Go , il ne resterait que 20 kilo de memoire libre sur ce Serveur
à en croire Inact_target ? O_o

Dois je ajouter Cached + Buffers pour me faire une idée de ma memoire
restante et prete à etre utilisée ?
J aurai tendance a dire que Cached et buffers sont des memoires qui sont
"utilisées" donc non disponibles.

Dois je faire une simple soustraction : MemTotale - Active pour me
faire une idée de ce qu'il me reste reellement à disposition ?


Bref, quelqu'un pourrait il m eclairer sur ma mémoire disponible et sur
un manque potentiel à ce niveau sur mon serveur ?

La mémoire immédiatement disponible est la mémoire "free" (comme son
nom l'indique). Les caches peuvent être libérés plus ou moins
rapidement en fonction des besoins.
La mémoire dite 'inactive' est allouée. Il me semble que le fait qu'elle
soit marqué inactive indique seulement qu'elle n'a pas été accédé
depuis un certain temps, donc qu'elle est toute désignée pour être
swappée (si c'est du code ou des données) ou libérée (si c'est du
cache) en cas de besoin.

La mémoire immédiatement disponible est la mémoire "free" (comme son
nom l'indique). Les caches peuvent être libérés plus ou moins
rapidement en fonction des besoins.
La mémoire dite 'inactive' est allouée. Il me semble que le fait qu'elle
soit marqué inactive indique seulement qu'elle n'a pas été accédé
depuis un certain temps, donc qu'elle est toute désignée pour être
swappée (si c'est du code ou des données) ou libérée (si c'est du
cache) en cas de besoin.

Merci pour ces infos.
Je note ^^

La mémoire immédiatement disponible est la mémoire "free" (comme son
nom l'indique). Les caches peuvent être libérés plus ou moins
rapidement en fonction des besoins.
La mémoire dite 'inactive' est allouée. Il me semble que le fait qu'elle
soit marqué inactive indique seulement qu'elle n'a pas été accédé
depuis un certain temps, donc qu'elle est toute désignée pour être
swappée (si c'est du code ou des données) ou libérée (si c'est du
cache) en cas de besoin.

2 petites questions suplémentaires :o)

1)
J'ai mis en place une surveillance sur les valeurs HighFree et LowFree
de /proc/meminfo sur un serveur sur lequel tournent de nombreux
process Java (tomcat) , httpd ...

Je me retrouve avec une memoire disponible de 22 Mo sur 1,5 Go de
Memoire au totale.
==> Dois je en conclure que mon serveur est à la ramasse concernant la
memoire ???

J'ai une swap de 2 Go dont 370 Mo est utilisé.



2)
Autre chose, si je fais le cumul des valeurs 'VmRSS' des fichiers
/proc/PID/status du serveur j'obtiens 663 Mo .

J'imagine que le reste de la memoire n est pas non plus totalement libre...
Comment puis je obtenir ma memoire totale a partir de cette memoire
utilisée par mes process ?

Process (663 Mo) + Cached ? ( 576 Mo ) + Buffers ( 40 Mo )

J'ai des difficulté à retrouver une certaine cohérence dans tout ca .
/proc/meminfo :

MemTotal: 1545088 kB
MemFree: 22860 kB
MemShared: 0 kB
Buffers: 39668 kB
Cached: 576704 kB
SwapCached: 258468 kB
Active: 973220 kB
ActiveAnon: 597296 kB
ActiveCache: 375924 kB
Inact_dirty: 0 kB
Inact_laundry: 215840 kB
Inact_clean: 24232 kB
Inact_target: 242656 kB
HighTotal: 655336 kB
HighFree: 2108 kB
LowTotal: 889752 kB
LowFree: 20752 kB
SwapTotal: 2044072 kB
SwapFree: 1670784 kB
HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 2048 kB




Merci de votre aide.

On Thu, 07 Apr 2005 10:15:53 +0200, bill wrote:

La mémoire immédiatement disponible est la mémoire "free" (comme son
nom l'indique). Les caches peuvent être libérés plus ou moins
rapidement en fonction des besoins.
La mémoire dite 'inactive' est allouée. Il me semble que le fait qu'elle
soit marqué inactive indique seulement qu'elle n'a pas été accédé
depuis un certain temps, donc qu'elle est toute désignée pour être
swappée (si c'est du code ou des données) ou libérée (si c'est du
cache) en cas de besoin.

2 petites questions suplémentaires :o)

1)
J'ai mis en place une surveillance sur les valeurs HighFree et LowFree
de /proc/meminfo sur un serveur sur lequel tournent de nombreux
process Java (tomcat) , httpd ...

Je me retrouve avec une memoire disponible de 22 Mo sur 1,5 Go de
Memoire au totale.
==> Dois je en conclure que mon serveur est à la ramasse concernant la
memoire ???

Non, au contraire, moins tu as de mémoire libre, plus tu peux te dire que
Linux s'en sert, ce qui est une bonne chose. La mémoire libre est perdue,
alors que si elle est utilisée pour des caches, elle devient très utile,
tout en étant récupérable rapidement en cas de besoin.

[...]

2)
Autre chose, si je fais le cumul des valeurs 'VmRSS' des fichiers
/proc/PID/status du serveur j'obtiens 663 Mo .

J'imagine que le reste de la memoire n est pas non plus totalement libre...
Comment puis je obtenir ma memoire totale a partir de cette memoire
utilisée par mes process ?

La mémoire physique utilisée par les process est exactement la somme des
champs RSS (résident size).

Process (663 Mo) + Cached ? ( 576 Mo ) + Buffers ( 40 Mo )

plus la mémoire utilisée par le noyau lui même pour ses besoins
internes. Les stats pour celà sont plutôt dans /proc/slabinfo

J'ai des difficulté à retrouver une certaine cohérence dans tout ca .
/proc/meminfo :

Sans doute parce que plusieurs statistiques de significations différentes
y sont regroupées.

MemTotal: 1545088 kB
MemFree: 22860 kB

Ca, c'est la mémoire physique. Tu perds 22 Mo sur 1.5 Go, soit moins de 2%.
Les 22 Mo, c'est la marge que Linux se laisse pour pouvoir allouer très
vite de la RAM pour quiconque en aurait besoin.

MemShared: 0 kB

Ca ne veut rien dire (ce champ n'est plus maintenu).

Buffers: 39668 kB
Cached: 576704 kB
SwapCached: 258468 kB

Active: 973220 kB
ActiveAnon: 597296 kB
ActiveCache: 375924 kB

La mémoire active, c'est la mémoire qui a été accédé récement.
Donc, c'est celle qu'il convient de garder en mémoire physique pour
statistiquement avoir de bonnes performances (donc, qu'il faut éviter de
swapper).

Inact_dirty: 0 kB
Inact_laundry: 215840 kB
Inact_clean: 24232 kB
Inact_target: 242656 kB

La mémoire inactive n'a pas été accédée depuis un certain temps. Elle
peut donc être swappée/discardée rapidement.

HighTotal: 655336 kB
HighFree: 2108 kB
LowTotal: 889752 kB
LowFree: 20752 kB

La mémoire low est celle en dessous de 850 Mo, qui est directement
mappée par le noyau. La mémoire high est plus longue à atteindre
(lorsqu'il faut faire des transferts de données entre le noyau et les
process user). C'est pour celà qu'elles ne sont pas gérées de la même
façon et que leurs statistiques sont distinctes.

SwapTotal: 2044072 kB
SwapFree: 1670784 kB

Les stats du swap...

HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 2048 kB

Le noyau a la possibilité d'utiliser des pages plus grande que 4 Ko pour
les programmes qui demandes des grandes quantité de mémoire virtuelles.
L'avantage est que ça réduit la taille des tables de page.
L'inconvénient, c'est que les allocations mémoires physiques se font
alors par gros blocs. Les statistiques concernant ces "grandes" pages sont
donc maintenues séparément.

/proc/meminfo rapporte toutes les informations globales sur l'utilisation
de la mémoire. Par conséquent, ces informations se recoupent: on peut
très bien imaginer avoir une "huge page" qui soit du cache marqué
inactive et modifiée. Dans ce cas, cette page sera comptabilisé trois
fois: une fois dans la taille du cache, une fois dans les "inactive dirty"
et une fois dans les "huge pages".

Ce qu'il faut bien garder en mémoire (!), c'est que la notion de mémoire
libre n'a pas grand sens sur un OS moderne. Le but d'un OS efficace est
d'avoir le moins possible de mémoire libre ! Et le fait d'avoir de la
mémoire libre ne garanti jamais qu'on peut allouer cette mémoire: comme
l'execution des process est préemptive, il suffit qu'un autre process
écrive dans une page (qu'il peut avoir mappé depuis très longtemps)
pour que la mémoire physique disponible diminue. Par conséquent, il est
impossible d'avoir la garantie de pouvoir allouer de la mémoire (quelle
que soit la taille du bloc demandé) à un instant donné. Sous Linux,
c'est même pire: il n'y a aucune garantie qu'on pourra effectivement
accéder à une page qu'on a demandé au noyau. En effet, lorsqu'on
demande une page au noyau, celui ci ne l'alloue jamais. L'allocation n'est
faite que si on accède réellement à cette zone de mémoire. Il est donc
tout à fait possible d'allouer de la mémoire et de se prendre une
SEGFAULT au premier accès parce qu'il n'y a plus de mémoire physique
disponible pour allouer physiquement la page à cet instant là (c'est
bien sur heureusement très rare).
Les statistiques sur la mémoire sont donc des indications utiles, mais à
manier avec beaucoup de précautions...

[...]

Ce qu'il faut bien garder en mémoire (!), c'est que la notion de mémoire
libre n'a pas grand sens sur un OS moderne. Le but d'un OS efficace est
d'avoir le moins possible de mémoire libre ! Et le fait d'avoir de la
mémoire libre ne garanti jamais qu'on peut allouer cette mémoire: comme
l'execution des process est préemptive, il suffit qu'un autre process
écrive dans une page (qu'il peut avoir mappé depuis très longtemps)
pour que la mémoire physique disponible diminue. Par conséquent, il est
impossible d'avoir la garantie de pouvoir allouer de la mémoire (quelle
que soit la taille du bloc demandé) à un instant donné. Sous Linux,
c'est même pire: il n'y a aucune garantie qu'on pourra effectivement
accéder à une page qu'on a demandé au noyau. En effet, lorsqu'on
demande une page au noyau, celui ci ne l'alloue jamais. L'allocation n'est
faite que si on accède réellement à cette zone de mémoire. Il est donc
tout à fait possible d'allouer de la mémoire et de se prendre une
SEGFAULT au premier accès parce qu'il n'y a plus de mémoire physique
disponible pour allouer physiquement la page à cet instant là (c'est
bien sur heureusement très rare).
Les statistiques sur la mémoire sont donc des indications utiles, mais à
manier avec beaucoup de précautions...

Merci beaucoup pour cette explication tres précise. bcp de chose sont
plus claires.

Malheureusement, la grande question de départ n est pas vraiment reglée :/


La question départ etant :
A partir de <<quand>> , sur un serveur critique linux, peut on dire :

"Houla... il va falloir penser à programmer un arret du serveur pour lui
rajouter XXX Mo/Go de RAM "
Avec une preuve à l appui du besoin.

Bref , une supervision préventive du serveur comme peut l'exiger tout DI
sur une utilisation linux en entreprise.

Dans le message <news:42552c16$0$3143$8fcfb975@news.wanadoo.fr>,
*bill* tapota sur f.c.o.l.configuration :

La question départ etant :
A partir de <<quand>> , sur un serveur critique linux, peut on dire :

"Houla... il va falloir penser à programmer un arret du serveur pour lui
rajouter XXX Mo/Go de RAM "
Avec une preuve à l appui du besoin.

Tout simplement à partir du moment où le système commence à montrer des
signes de faiblesses suite à une utilisation importante et fréquente du swap
?

Bref , une supervision préventive du serveur comme peut l'exiger tout DI
sur une utilisation linux en entreprise.

La commande free répond à ça.

--
TiChou

"Houla... il va falloir penser à programmer un arret du serveur pour
lui rajouter XXX Mo/Go de RAM "
Avec une preuve à l appui du besoin.

Tout simplement à partir du moment où le système commence à montrer des
signes de faiblesses suite à une utilisation importante et fréquente du
swap ?

Bref , une supervision préventive du serveur comme peut l'exiger tout
DI sur une utilisation linux en entreprise.

La commande free répond à ça.

oui... effectivement. Vu la situation , il semble que seul le swap
semble permettre de se faire une opinion sur un manque eventuel de RAM.

Mais encore une fois, comme j'ai lu a droite à gauche , linux utilise
toutes les ressources qu'on lui donne. Et la swap en est une.

Si linux swappe parfois sur disque des choses lorsque ces dernieres ne
sont plus tres utilisées (Inact_target etc...) , ca ne signifie pas
pour autant que c est du à un manque evident de mémoire.

Donc l'analyse du swap pour savoir si on est face à un manque de memoire
ne semble pas si evident que ca j'ai l impression.



Ou alors peut etre en combinant, du style :

Si Inact_Target proche de zero (pas de memoire inutilisée) et swap
non négligeable ==> Alors manque de memoire



Cas concret d'un serveur linux : (2 Go de RAM)
meminfo :
Inact_dirty: 601348 kB
Inact_clean: 28240 kB
Inact_target: 13404 kB

Commande Free : Swap: 2088440(total) 141640(used)
1946800(free)

J'ai l impression que ce serveur serait donc limite en memoire face à
cette facon de voir les choses ?

On Thu, 07 Apr 2005 17:27:44 +0200, bill wrote:

"Houla... il va falloir penser à programmer un arret du serveur pour
lui rajouter XXX Mo/Go de RAM "
Avec une preuve à l appui du besoin.

Tout simplement à partir du moment où le système commence à montrer des
signes de faiblesses suite à une utilisation importante et fréquente du
swap ?

Bref , une supervision préventive du serveur comme peut l'exiger tout
DI sur une utilisation linux en entreprise.

La commande free répond à ça.

oui... effectivement. Vu la situation , il semble que seul le swap
semble permettre de se faire une opinion sur un manque eventuel de RAM.

Mais encore une fois, comme j'ai lu a droite à gauche , linux utilise
toutes les ressources qu'on lui donne. Et la swap en est une.

Si linux swappe parfois sur disque des choses lorsque ces dernieres ne
sont plus tres utilisées (Inact_target etc...) , ca ne signifie pas
pour autant que c est du à un manque evident de mémoire.

Donc l'analyse du swap pour savoir si on est face à un manque de memoire
ne semble pas si evident que ca j'ai l impression.

Si. Ce qu'il faut regarder, c'est si les taux de transfert entre le swap
et la RAM se mettent à augmenter. Si Linux commence à utiliser beaucoup
le swap, il y a un problème. Attention: utiliser beaucoup le swap ne veut
pas dire utiliser beaucoup de place en swap, ça veut dire faire beaucoup
de trafic entre la RAM et le swap.
Je ne sais pas si on peut observer cette statistique directement, mais il
y a des indices qui ne trompent pas: on peut observer les statistiques de
transfert pour la partition de swap, si celles-ci sont activées dans le
noyau. Si il y a beaucoup de transfert pendant un temps relativement long
(disons plus de 10 à 30 secondes d'affilées avec du trafic en
permanence), c'est que Linux a besoin de décharger/recharger beaucoup de
pages entre le swap et la RAM. Une autre technique consiste à observer
les variations de l'occupation du swap. On peut remarquer que quand Linux
swap un programme pour en recharger un autre, la taille occuppée dans le
swap soit augmente fortement, soit se met à osciller autour d'une valeur
pendant un temps non négligeable (de l'ordre la aussi de quelques
secondes à quelques minutes dans les cas les plus graves). Comme
l'occupation du swap est disponible facilement (cat /proc/swaps),
il est assez aisé de faire un programme d'alerte qui détecte cette
dernière condition.

[...]

Cas concret d'un serveur linux : (2 Go de RAM)
meminfo :
Inact_dirty: 601348 kB
Inact_clean: 28240 kB
Inact_target: 13404 kB

Commande Free : Swap: 2088440(total) 141640(used)
1946800(free)

J'ai l impression que ce serveur serait donc limite en memoire face à
cette facon de voir les choses ?

Une statistique de RAM seule ne donne pas d'information à ce sujet. Si ce
qui est swappé l'est depuis longtemps et reste sagement dans le swap, il
n'y a aucun problème. Ce qui pose problème c'est de consomer du temps
CPU à échanger des pages entre le swap et la RAM, c'est donc une
information qui ne peut être collectée que dynamiquement.

On Thu, 07 Apr 2005 17:27:44 +0200, bill wrote:

Donc l'analyse du swap pour savoir si on est face à un manque de memoire
ne semble pas si evident que ca j'ai l impression.

Si. Ce qu'il faut regarder, c'est si les taux de transfert entre le swap
et la RAM se mettent à augmenter. Si Linux commence à utiliser beaucoup
le swap, il y a un problème. Attention: utiliser beaucoup le swap ne veut
pas dire utiliser beaucoup de place en swap, ça veut dire faire beaucoup
de trafic entre la RAM et le swap.

vmstat est notre ami... Déjà, c'est fait pour ça, et puis on retrouve
les champs swapin et swapout... Bref, si on a une activité importante en
si et so (le nom des colonnes concernées) on peut en déduire un manque
de mémoire. Maintenant reste à voir si c'est un pic ponctuel ou un
manque de mémoire à plus ou moins long terme...

Utilisation: vmstat [délai], par exemple vmstat 5 pour un affichage
toutes les 5 secondes. Attention, la première ligne donne les stats par
rapport au lancement précédent de vmstat ou par rapport au reboot, je ne
sais plus ;)

Yves

--
http://wiki.rougy.net -- Wiki Unix/Linux

On Fri, 08 Apr 2005 11:30:18 +0200, yves wrote:

On Thu, 07 Apr 2005 17:27:44 +0200, bill wrote:

Donc l'analyse du swap pour savoir si on est face à un manque de memoire
ne semble pas si evident que ca j'ai l impression.

Si. Ce qu'il faut regarder, c'est si les taux de transfert entre le swap
et la RAM se mettent à augmenter. Si Linux commence à utiliser beaucoup
le swap, il y a un problème. Attention: utiliser beaucoup le swap ne veut
pas dire utiliser beaucoup de place en swap, ça veut dire faire beaucoup
de trafic entre la RAM et le swap.

vmstat est notre ami... Déjà, c'est fait pour ça, et puis on retrouve
les champs swapin et swapout... Bref, si on a une activité importante en
si et so (le nom des colonnes concernées) on peut en déduire un manque
de mémoire. Maintenant reste à voir si c'est un pic ponctuel ou un
manque de mémoire à plus ou moins long terme...

Effectivement, c'est exactement l'outil qu'il faut. Il me semblait bien
que l'info swapin/swapout était dispo quelque part (mais impossible de me
rappeller). Il faut que je le note ;-)

Ce qui est caractéristique d'un manque de RAM, c'est du
trafic swapin & swapout simultané pendant longtemps (ie au moins
plusieurs secondes) ou très fréquement: ça veut dire que le noyau est
obligé de swapper un process pour en relancer un autre.
Il faut quand même faire attention: au lancement d'un process, il y a un
swapin important: chaque page de code du process qui n'a jamais été
accédée déclenche un swapin qui la charge depuis le fichier executable.
Mais, dans ce cas de figure, il ne devrait pas y avoir de swapout (ou
très peu) en même temps.

Apparement, les champs si/so sont donnés en Ko/s, c'est donc exactement
l'info voulue.

[...]