Aller au contenu

Mais où est passé la mémoire ?


fabien29200

Messages recommandés

Posté(e)

Coucou à tous !

Sur mon serveur home made (Ubuntu 9.10, lamp, squid, nvidia, gnome), j'ai un écart que je ne m'explique pas entre top d'un côté, ps et free de l'autre.

Lorsque je lance un free, à la ligne "-/+ buffers/cache:", il m'indique que 1156 Mo sont utilisés.

Etonné par ce chiffre élevé, j'ai commencé à chercher quel processus prendrait autant de RAM.

Mais le souci, c'est qu'en totalisant la colonne RES de top sur les 55 processus qui prennent le plus de mémoire, j'arrive à 419 336.

De même en faisant un ps aux et en calculant la somme de la colonne RSS sur 180 lignes, j'obtiens 467 732.

Bref, on est bien loin du Go.

Mais alors, qu'est-ce que prend en compte free et qui n'apparaît ni dans ps ni dans top ?

Posté(e)

et avec la commande slabtop tu vera en partie ce qui occupe le cache. Suffit que tu lise pas mal de fichiers pour que les buffers et autres caches prennent de la place en ram. Essaye munin si tu veux monitoré ça facilement (le graph pour la mémoire est assez bien detaillé)

Posté(e)

Je colle le résultat tel quel car j'avoue avoir un peu de mal à décoder toutes ces infos :

MemTotal:		3478724 kB
MemFree:		  414736 kB
Buffers:		  451104 kB
Cached:		  1427856 kB
SwapCached:		 3000 kB
Active:		  1111624 kB
Inactive:		 951352 kB
Active(anon):	  97584 kB
Inactive(anon):	89520 kB
Active(file):	1014040 kB
Inactive(file):   861832 kB
Unevictable:		   0 kB
Mlocked:			   0 kB
SwapTotal:		497972 kB
SwapFree:		 462436 kB
Dirty:				 0 kB
Writeback:			 0 kB
AnonPages:		181216 kB
Mapped:			56980 kB
Slab:			 370752 kB
SReclaimable:	 339892 kB
SUnreclaim:		30860 kB
PageTables:		16992 kB
NFS_Unstable:		  0 kB
Bounce:				0 kB
WritebackTmp:		  0 kB
CommitLimit:	 2237332 kB
Committed_AS:	 716512 kB
VmallocTotal:   34359738367 kB
VmallocUsed:	   84280 kB
VmallocChunk:   34359638011 kB
HugePages_Total:	   0
HugePages_Free:		0
HugePages_Rsvd:		0
HugePages_Surp:		0
Hugepagesize:	   2048 kB
DirectMap4k:	  548416 kB
DirectMap2M:	 2990080 kB

Posté(e)

Le MemTotal du meminfo montre 3.4Go (en gros) de mémoire dispo, donc je suppose que c'est les 4Go - la partie pour la video.

MemTotal: 3478724 kB

MemFree: 414736 kB

Buffers: 451104 kB

Cached: 1427856 kB

Donc au 3.4Go on retire env 400Mo de mémoire libre, encore 400Mo de Buffers, et 1.4Go de Cache (sur les fichiers). Reste encore qqchose comme 1.1Go (1185028 kB) a expliquer. On avait trouver qqchose comme 350Mo pour les structures de gestion du slab (Slab: 370752 kB). On est plus qu'à 800Mo d'utilisation inexplicable. Bon apres faut retirer ce que tu avais compté avec tes PS même si cette methode est pas forcement fiable. Je pense aussi qu'on a peut etre oublié un autre truc, mais on s'en approche. T'avais genre 400Mo de programme, apres je sais pas ya peut etre les librairies partagées, et les librairies systemes, etc. C'est tellement pas évident de savoir comment la mémoire est concretement utilisée, qu'en général on s'inquiete que quand ça commence à swapper.

Ya aussi la commande pmap -x <pid> qui peut etre sympa.

Posté(e)

je vais p'tet dire une connerie mais.....

Le cache qu'on voit comme ça, c'est pas des programmes qui ont tournés et qui sont resté en cache ? + une partie du cache du disque dur ?

J'ai le souvenir d'avoir lu une explication...

Posté(e)

Ok.

Donc le noyau, quand il voit qu'il a beaucoup de RAM de libre, il met en RAM un maximum de choses pour accélérer les traitements.

D'où une valeur de RAM utilisée beaucoup plus élevée que sur une machine disposant de moins RAM.

C'est bien ça ?

Posté(e)

Oui, ce serait dommage d'avoir plein de mémoire libre inutilisée, d'où le bon vieux dicton "Free RAM is Wasted RAM" :iloveyou:, donc ya des phénomenes de mises en cache, buffers et autres readahead qui vont avoir tendance à utiliser cette mémoire disponible. Le but étant d'accélérer les tâches courantes et lentes tel que les IO sur disques, etc.

Alors que sur une machine avec moins de RAM, la proportion de mémoire inutilisée est plus faible, donc ce phénomène de cache est moins visible.

Après tout ça doit peut être pouvoir se paramétrer, la taille des buffers, le readahead sur les fichiers, le tendance au swap etc

Ya un nouveau système dans les kernels tout récent (>2.6.31), qui s'appelle KSM il me semble, qui vise à chercher les données en double en mémoire pour les regrouper, ça va être intéressant ça :)

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.

×
×
  • Créer...