Forum Linux.debian/ubuntu Utilisation de la RAM

Posté par  . Licence CC By‑SA.
Étiquettes :
5
21
mai
2013

Bonjour,

Sur mon serveur sous Debian Wheezy, j'ai une différence sur la quantité de RAM affichée par free et celle trouvée par ps, et je n'arrive pas à trouver la cause.

free (ou htop) me donne 1409Mo d'utilisé (bien sûr en ne comptant pas le cache).
ps ax -eo rss | awk '{s+=$1} END {print s}' me donne 500Mo.

Je n'ai que peu de données en tmpfs.
Sys. fich. Taille Util. Dispo Uti% Monté sur
udev 10M 0 10M 0% /dev
tmpfs 394M 200K 394M 1% /run
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 2,7G 0 2,7G 0% /run/shm

Ou sont donc cachés ces 900Mo de différence ?

  • # Parce que tu ne peux pas juste additionner la colonne RSS

    Posté par  (site web personnel) . Évalué à 2.

    http://virtualthreads.blogspot.fr/2006/02/understanding-memory-usage-on-linux.html

    • [^] # Re: Parce que tu ne peux pas juste additionner la colonne RSS

      Posté par  . Évalué à 2.

      Ça ne m'aide vraiment pas. L'article parle de la mémoire partagée qui est inclue dans la valeur retournée dans la colonne RSS.
      Ça serait valable si mon problème était que le total de RSS dépasse le total donnée par free, sauf que c'est l'inverse.

  • # Non libéré ?

    Posté par  . Évalué à 0.

    Bonjour,

    De ce que j'ai compris, la mémoire n'est pas entièrement libérée tant qu'il en reste suffisamment. C'est utilisé en cache disque en lecture je crois.
    Ca doit correspondre à l'augmentation croissance de l'utilisation la mémoire très faible au boot et qui augmente après chaque lancement de programme sans diminuer lorsque l'on ferme le programme.

    • [^] # Re: Non libéré ?

      Posté par  . Évalué à 1.

      Non la valeur de free que j'ai donné est bien celle sans le cache disque.

  • # free n'est pas fiable

    Posté par  . Évalué à 2.

    Mais pas du tout.
    Que donnent:

    free -m

    et

    cat /proc/meminfo

    • [^] # Re: free n'est pas fiable

      Posté par  . Évalué à 1.

      free -m

                   total       used       free     shared    buffers     cached
Mem:          3936       2790       1145          0        700        658
-/+ buffers/cache:       1432       2503
Swap:         9703          0       9703

      cat /proc/meminfo

      MemTotal:        4030728 kB
MemFree:         1180624 kB
Buffers:          716916 kB
Cached:           674124 kB
SwapCached:            0 kB
Active:          1276148 kB
Inactive:         429560 kB
Active(anon):     314524 kB
Inactive(anon):      332 kB
Active(file):     961624 kB
Inactive(file):   429228 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       9936164 kB
SwapFree:        9936164 kB
Dirty:               200 kB
Writeback:             0 kB
AnonPages:        314496 kB
Mapped:            44620 kB
Shmem:               408 kB
Slab:            1090788 kB
SReclaimable:    1075068 kB
SUnreclaim:        15720 kB
KernelStack:        1800 kB
PageTables:        12672 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    11951528 kB
Committed_AS:    1031612 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      282592 kB
VmallocChunk:   34359447911 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       52928 kB
DirectMap2M:     3059712 kB
DirectMap1G:     1048576 kB

      Donc on retrouve les valeurs de free avec MemTotal - MemFree - Bufers - Cached.
      La mémoire active est plus bas à 1,2Go. Ça fait toujours 700Mo d’écart avec ce que me donne ps.

      • [^] # Re: free n'est pas fiable

        Posté par  . Évalué à 4.

        Pour savoir ce qui est réellement alloué, il faut regarder Committed_AS.

        Après, la différence est déjà dans la mémoire inactive: il s'agit probablement de process qui ont fait des mmap, soit file-backed read-only (donc pas besoin de swapper pour réclamer), soit anonymous mais pas encore écrit dedans (donc pas non plus besoin de swapper pour réclamer), et après quelque temps, le noyau les a dégagés de la RAM pour faire de la place pour le page cache (le degré dépend de la swapinness). Du coup ils n'apparaissent pas dans RSS, mais sont toujours pris en compte par free.

        J'ai aussi déjà eu des cas où, en ext3 monté avec data=ordered, supprimer un fichier déjà ouvert va laisser les entrées correspondantes dans le page cache, du coup ils apparaissent en inactive dans /proc/meminfo, free les rapporte toujours, mais on ne voit évidemment rien dans ps.

        En gros, tant que ton Committed_AS n'augmente pas, pas de souci…

  • # ps bizarre

    Posté par  . Évalué à 2.

    Effectivement, les valeurs obtenues avec ps sont surprenantes. J'ai testé sur quelques machines et j'ai bien des valeurs supérieures en additionnant les rss de ps par rapport à ce que donne free.

    J'ai routé de même été dérouté par la syntaxe que tu utilises avec ps (mélange de syntaxe BSD et de syntaxe standard). Ça ne semble pas gênant, mais j'aurais plutôt mis
    ps axo rss
    ou
    ps -eo rss

    J'ai aussi pensé à une différence due au swap, mais celui-ci ne semble pas du tout utilisé (mais, près de 10GO de swap, ça me semble énôrme !)

    Sinon, est-il possible que des modules noyaux utilisent cette RAM manquante ? Je n'ai pas de méthode précise pour mesurer ça, mais lsmod ou slabtop peuvent peut-être donner des éléments de réponse. En particulier, dans le cas de machines virtuelles, le mécanisme de memory ballooning peut être très gourmand en RAM, surtout s'il y a saturation des ressources physiques.

  • # Le « classique » des fichiers supprimés ?

    Posté par  . Évalué à 2.

    Je ne sais pas si c'est ton cas, mais plusieurs fois sur ce forum on a découvert que cette mémoire « fantôme » était en fait utilisée par des fichiers mappés en RAM mais effacés du FS. Je ne sais pas si c'est censé apparaître dans le meminfo quand-même, mais regarde avec lsof et consorts.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.