Utilisation de la mémoire sous Linux

Support Debian
#1

Hello,

Je sais bien que c’est sujet récurent mais j’ai pas trouvé d’explications satisfaisantes.

Je n’arrive pas à comprendre comment je me retrouve à manquer de RAM sur mon laptop qui possède pourtant 8 Gb et à devoir rebooter toutes les 2/3 semaines uniquement pour cela.

Là ça fait 1 mois que je n’ai pas rebooté et voici ce que me renvoie la commande free :

               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       4.2Gi       792Mi       2.0Gi       2.7Gi       1.2Gi
Swap:          7.9Gi       5.6Gi       2.3Gi

Premier truc énervant: la RAM dispo n’est que de 7.7 Gb, on commence donc avec 300 MB perdus à cause du GPU intégré d’Intel que je n’arrive pas à désactiver (pas d’option dans le bios, j’ai le driver nvidia pour la Geforce qui est bien chargé… mais bon c’est un autre sujet).

Ensuite l’espace pris par la cache/buffer me parait un tantinet abusé en sachant qu’il ne me reste aussi d’espace libre (car sinon ok, autant utiliser la mémoire pour éviter des accès au disque).

Avec la commande suivante je ne récupère presque rien (100 MB):

root@entropy:~$free -h && sync && echo 3 > /proc/sys/vm/drop_caches && free -h
           total        used        free      shared  buff/cache   available
Mem:       7,7Gi       4,2Gi       799Mi       2,0Gi       2,7Gi       1,2Gi
Swap:      7,9Gi       5,6Gi       2,3Gi
           total        used        free      shared  buff/cache   available
Mem:       7,7Gi       4,2Gi       1,0Gi       2,0Gi       2,5Gi       1,3Gi
Swap:      7,9Gi       5,6Gi       2,4Gi

De plus 2.0 Gb pour l’espace shared ça m’énerve pas mal aussi, surtout que je ne comprend pas bien à quoi ça sert :slight_smile:

Voici un top trié par mémoire:

top - 22:52:11 up 30 days,  1:06,  8 users,  load average: 0,72, 0,98, 1,03
Tâches: 301 total,   2 en cours, 299 en veille,   0 arrêté,   0 zombie
%Cpu(s):  4,6 ut,  2,6 sy,  0,0 ni, 92,0 id,  0,0 wa,  0,0 hi,  0,8 si,  0,0 st
MiB Mem :   7849,2 total,    872,2 libr,   4376,4 util,   2600,5 tamp/cache
MiB Éch :   8131,0 total,   2410,8 libr,   5720,2 util.   1179,5 dispo Mem 

    PID UTIL.     PR  NI    VIRT    RES    SHR S  %CPU  %MEM    TEMPS+ COM.                                                                                   
2542576 turman    20   0 5197344 772596 353332 S   0,7   9,6 192:59.57 firefox-esr                                                                            
2791382 turman    20   0 2941960 567708 384432 S   0,3   7,1   3:38.98 Web Content                                                                            
2785799 turman    20   0 3272068 566408 123584 S   1,0   7,0   2:00.14 Web Content                                                                            
   8262 turman    20   0 7747656 543864 110848 S   0,0   6,8 245:57.46 soffice.bin                                                                            
2542640 turman    20   0 3279912 472892 294672 S   0,0   5,9  87:54.81 Web Content                                                                            
2554621 turman    20   0 3523132 412604 178524 S   0,3   5,1  53:41.97 Web Content                                                                            
    893 root      20   0 1876972 336952 268320 S   5,3   4,2 402:12.63 Xorg                                                                                   
1872143 turman    20   0 8515492 332156  53992 S   0,3   4,1  38:45.37 skrooge                                                                                
   4682 turman    20   0   37,2g 288500  68592 S  24,8   3,6   7719:45 signal-desktop                                                                         
   1315 turman    20   0 4903168 277636  34116 S   1,7   3,5   2426:32 plasmashell                                                                            
2542669 turman    20   0 3116868 269636 110616 S   0,3   3,4   7:11.94 Web Content                                                                            
   1414 turman    20   0 4505236 181496  11412 S   0,0   2,3 126:07.11 nextcloud                                                                              
2542740 turman    20   0 2759156 171304 135900 S   0,0   2,1   1:08.87 Web Content                                                                            
2542695 turman    20   0 2696100 160808  78544 S   0,3   2,0   3:55.02 Web Content                                                                            
2555128 turman    20   0 3716684 151312  75768 S   0,3   1,9   0:44.84 kontact                                                                                
2790685 turman    20   0 1579560 138340 106524 R  11,3   1,7   4:22.27 systemmonitor                                                                          
2542774 turman    20   0 2535300 134768 111948 S   0,0   1,7   0:34.40 Privileged Cont                                                                        
2542714 turman    20   0 2614296 133500 114732 S   0,0   1,7   1:55.51 Web Content                                                                            
   4506 turman    20   0 9408620 129836  44576 S   0,0   1,6  22:18.58 signal-desktop                                                                         
   1233 turman    20   0 3978732  86316  22164 S   4,6   1,1 330:26.85 kwin_x11                                                                               
   1646 turman    20   0 3084824  72936   6292 S   0,3   0,9 165:02.44 mysqld                                                                                 
   1351 turman    20   0 2256544  72400  20172 S   0,0   0,9  40:07.46 korgac                                                                                 
2555689 turman    20   0  383816  67424  55520 S   0,0   0,8  53:33.89 RDD Process                                                                            
1421489 turman    20   0 1676028  55292  26768 S   0,3   0,7   4:51.39 dolphin                                                                                
   4607 turman    20   0  805608  51640  29276 S   0,0   0,6  40:17.18 signal-desktop                                                                         
2542825 turman    20   0 2463568  51416  31620 S   0,0   0,6   1:07.69 WebExtensions                                                                          
   1409 turman    20   0 1362556  50584  39896 S   5,3   0,6  11:16.72 konsole                                                                                
   2077 turman    20   0 2410548  41516   6804 S   0,0   0,5  73:40.77 akonadi_imap_re                                                                        
   2075 turman    20   0  511144  27912   9732 S   0,0   0,3   8:49.89 akonadi_davgrou

Si on regarde la colonne RES (mémoire résidente) aucun processus n’en abuse. Sous ksysguard, qui n’affichent pas tout à fait les mêmes valeurs, je vois aussi qu’aucun processus ne dépasse les 500 Mb.

Mais au final je me retrouve avec tellement peu de mémoire libre/disponible qu’il suffit que j’abuse un peu de mon navigateur ou d’un google earth pour me retrouver avec un système suffoquant. Tout se met à ramer et je met plusieurs minutes à réussir à fermer des apps et revenir à une situation normale.

J’ai donc un laptop avec 8 Gb qui est au bord de l’explosion alors que j’ai aucun processus qui abusent de la mémoire. J’ai envie de dire que c’est pas normal et j’aimerais qu’on éclaircisse un peu ma lanterne.

Merci, Vincent.

#2

Bonjour,
peut-être que tu as des gros systèmes de fichiers en RAM ?
Tu peux vérifier avec cette commande par exemple: df -h -t tmpfs

#3

Cela ne provient pas forcément seulement du GPU intégré, cela peut aussi être de la mémoire perdue à cause du « trou PCI » (PCI hole) si elle n’est pas remappée.
S’agit-il de GPU combinés (technologie Optimus de Nvidia) ou indépendants ? Avec Optimus le GPU intégré ne peut pas être désactivé car c’est lui qui pilote l’affichage, le GPU Nvidia ne faisant que calculer les images et les transférer dans la mémoire du GPU intégré.

Si tu te bases sur la colonne « available » pour dire cela, c’est normal : elle compte déjà la mémoire qui peut être libérée avec drop_caches.

Une partie de la mémoire partagée, qu’on retrouve aussi dans le cache, peut correspondre à de la mémoire occupée par les tmpfs.

#4

Hello !
La RAM ça doit être utilisé !

Pour autant, il y a des outils pour améliorer le comportement de l’ordi et du navigateur :

#5

Merci pour vos réponses.

J’ai pas l’impression:

root@entropy:~$df -h -t tmpfs
 Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
 tmpfs              785M    1,7M  784M   1% /run
 tmpfs              3,9G    813M  3,1G  21% /dev/shm
 tmpfs              5,0M    4,0K  5,0M   1% /run/lock
 tmpfs              785M    3,3M  782M   1% /run/user/1000

Non c’est un classique UDH d’Intel (et la GeForce est une MX150) mais c’est intéressant.

Ok merci pour l’info.

Je ne vois pas toujours bien à quoi correspond ces tempfs mais visiblement ça n’est pas là le gros de mon problème au vu de la commande plus haut.

J’entends bien, ça ne me dérange absolument pas que Linux utilise à fond ma RAM pour mettre en place sa cache, mais tant qu’il en reste assez !

Mais là sur les 2.7Gb de buffer/cache seulement 300 Mb sont visiblement récupérables (puisque j’ai 1.0 Gb de free et 1.3 Gb de available). J’aimerais bien comprendre pourquoi il n’arrive pas à récupérer au moins la majorité de cache/buffer.

Car ça n’est clairement pas le cas: là je m’amuse avec Google Earth et au fur et à mesure que je vois ma mémoire libre diminuer et se rapprocher des 100 Mb, je ne vois pas la cache/buffer diminuer, elle est même passée de 2.9 Gb à 3.1 Gb!

total        used        free      shared  buff/cache   available
Mem:           7.7Gi       4.5Gi       144Mi       2.4Gi       3.1Gi       548Mi
Swap:          7.9Gi       7.7Gi       241Mi
#6

Je vois surtout le swap qui se remplit. Fuite de mémoire ?

#7

Bonjour,

Effectivement il y a un gros usage du swap. Parmi les applications visibles dans le retour de la commande top, signal-desktop est un coupable idéal :

#8

On peut ajouter l’affichage de l’utilisation du swap par chaque processus dans top.
Appuyer sur f pour entrer dans la gestion de champs.
Descendre le curseur sur « SWAP ».
Appuyer sur d pour le sélectionner comme colonne à afficher.
Appuyer sur flèche droit puis flèche haut pour déplacer le champ à côté de RES.
Appuyer sur Entrée pour valider la position.
Appuyer sur s pour trier sur la colonne.
Appuyer sur q pour revenir à l’affichage des processus.

1 J'aime
#9

Effectivement il y a aussi l’occupation du swap qui me parait également énorme puisque 7 Gb utilisé.

J’ai fermé signal-desktop et voici le retour de free maintenant:

               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       3.4Gi       1.4Gi       1.4Gi       2.9Gi       2.6Gi
Swap:          7.9Gi       6.2Gi       1.7Gi

On voit que ça a libéré un peu de mémoire swap mais pas tant que ça (et j’ai toujours ces 3 Gb de buff/cache qui ne descendent jamais).

Il serait effectivement intéressant de voir qui utilise le swap, voici l’affichage de top suite à la manip de Pascal:

top - 12:23:42 up 31 days, 14:37,  8 users,  load average: 1.34, 1.56, 1.14
Tasks: 303 total,   1 running, 302 sleeping,   0 stopped,   0 zombie
%Cpu(s):  4.3 us,  3.6 sy,  0.0 ni, 91.1 id,  0.0 wa,  0.0 hi,  1.0 si,  0.0 st
MiB Mem :   7849.2 total,   1182.9 free,   3786.9 used,   2879.3 buff/cache
MiB Swap:   8131.0 total,   1940.0 free,   6191.0 used.   2130.6 avail Mem 

    PID USER      PR  NI    VIRT    RES   SWAP    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                         
   1435 turman    20   0 4310812  25400   1.4g   2136 S   0.0   0.3  95:29.19 akonadiserver                                                                   
   8262 turman    20   0 7747656 269468 682904  86044 S   0.0   3.4 249:18.34 soffice.bin                                                                     
   1315 turman    20   0 4907900 246984 558636  49460 S   2.0   3.1   2451:07 plasmashell                                                                     
1872143 turman    20   0 8515492 186336 438120  30676 S   0.3   2.3  47:11.93 skrooge                                                                         
   2077 turman    20   0 2436240  31356 378700   6824 S   0.3   0.4  74:17.12 akonadi_imap_re                                                                 
   1646 turman    20   0 3084824  24800 317596   5788 S   0.0   0.3 165:43.86 mysqld                                                                          
   1414 turman    20   0 4505236 197592 298212  12520 S   0.3   2.5 132:16.27 nextcloud                                                                       
2554621 turman    20   0 3570676 365612 144260 157000 S   0.3   4.5  81:41.29 Web Content                                                                     
    893 root      20   0 1880328 284384  92856 242804 S  11.6   3.5 437:26.72 Xorg                                                                            
2542576 turman    20   0 5194452 836596  81948 313728 S   1.7  10.4 351:56.15 firefox-esr                                                                     
2785799 turman    20   0 3826556 728268  75304 340244 S   1.0   9.1  28:33.86 Web Content                                                                     
2555128 turman    20   0 3723112 146644  65540  68072 S   0.0   1.8   1:46.97 kontact                                                                         
2542695 turman    20   0 3440640 263960  55964 125736 S   0.3   3.3  39:28.65 Web Content                                                                     
2542640 turman    20   0 3251472 279924  52240  78764 S   0.3   3.5 103:11.17 Web Content                                                                     
   1351 turman    20   0 2256544  56504  51432  10224 S   0.0   0.7  42:07.65 korgac                                                                          
2542669 turman    20   0 3247892 248736  50744  76100 S   1.0   3.1  46:26.70 Web Content                                                                     
   2093 turman    20   0  522104   5152  49172   1348 S   0.0   0.1   8:46.31 akonadi_notes_a                                                                 
2542714 turman    20   0 3015168 224700  39724 146448 S   0.0   2.8  31:03.29 Web Content                                                                     
2542740 turman    20   0 3251100 201432  37248 121156 S   0.0   2.5   9:38.42 Web Content                                                                     
   1233 turman    20   0 3992912  84120  34160  25192 S   8.3   1.0 351:18.23 kwin_x11                                                                        
3032431 turman    20   0 2140740  34924  32532  26048 S   0.0   0.4   0:07.54 kinfocenter                                                                     
1421489 turman    20   0 1676076  80420  32496  45564 S   0.3   1.0   5:45.12 dolphin                                                                         
   2081 turman    20   0 1141524   5704  28488   3944 S   0.0   0.1   1:41.15 akonadi_mailfil                                                                 
   2098 turman    20   0 1066752   2132  25840   1176 S   0.0   0.0   1:33.56 akonadi_unified                                                                 
   1538 turman    20   0  249064  11404  25320   5332 S   0.0   0.1  28:46.11 wicd-client                                                                     
   2074 turman    20   0 1141324   5520  24404   1936 S   0.0   0.1   1:41.97 akonadi_archive                                                                 
   1716 turman    20   0 1298172   6288  23604   2824 S   0.0   0.1   0:25.87 kwalletd5                                                                       
   1356 root      20   0  364164   9596  22724   2744 S   0.0   0.1   2:08.76 packagekitd                                                                     
   2078 turman    39  19  402876   8000  22060   5040 S   0.0   0.1   2:22.27 akonadi_indexin

C’est très intéressant !

Akanodiserver est connu pour ses fuites mémoires, d’habitude j’ai même un script qui le redémarre toutes les heures mais là j’avais oublié de le lancer. En tuant le process j’ai récupéré carrément 2 Gb de swap (alors que top disait qu’il n’utilisait « que » 1.4 Gb):

               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       3.6Gi       1.4Gi       1.6Gi       2.7Gi       2.2Gi
Swap:          7.9Gi       4.1Gi       3.9Gi

Après avoir quitté LibreOffice (soffice.bin était le 2e process qui utilisait le plus de swap) j’ai récupéré 600 Mb en plus de swap, ce qui pour le coup correspondait bien à l’affichage de top:

               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       3.5Gi       1.5Gi       1.5Gi       2.7Gi       2.4Gi
Swap:          7.9Gi       3.4Gi       4.5Gi

Donc ok, au bout d’un mois dans reboot, j’avais donc quelques process qui abusaient clairement de la mémoire swap. J’imagine que l’on peut parler de fuite mémoire pour Akonadi ou LibreOffice.

Mais ça veut donc dire que l’espace swap utilisé par les processus ne se visualise pas dans la colonne « mémoire » de l’activité système de KDE (ksysguard) où aucun process ne dépassent les 500 Mb. A croire qu’il ne compte que la mémoire résidente en mémoire physique, toute comme la colonne RES de top (les valeurs sont un peu différentes quand même). C’est dommage qu’il n’y ait pas un moyen simple de voir toute la mémoire vraiment utilisée par les processus, quelle soit en RAM ou en swap.

La bonne nouvelle c’est que maintenant 2.4 Gb sont available pour 1.5 Gb de free. Une partie importante de buff/cache semble donc maintenant être « récupérable » (près de 1 Gb sur 2.7 Gb). Mais je ne comprend toujours pas pourquoi ça ne serait pas l’intégralité (ou presque) qui pourrait être récupérable puisque ça n’est que de la cache…

#10

Pour moi, non.
Les programmes et bibliothèques qui sont placés en swap sont ceux qui sont les moins utilisés.

Si tu veux savoir quelle application sature la mémoire il faut surveiller son occupation au cours du temps.

#11

Il est incorrect de dire qu’un processus abuse du swap. Un processus ne voit que sa mémoire virtuelle, il ne sait pas si une page est en RAM, en swap, les deux (swapcache), mappée à partir d’un fichier (notamment binaire exécutable ou bibliothèque) ou pas allouée du tout (jamais utilisée). Il peut seulement demander qu’une page ne soit pas swappée, par exemple parce qu’elle contient des données sensibles (clé secrète…) qui ne doivent pas être écrites dans le swap.

Pour dire s’il s’agit d’une fuite de mémoire, il faut savoir si cette occupation mémoire est normale ou non, si elle augmente avec l’uptime ou pas…

Je ne sais pas à quoi sert akonadiserver, mais 1,4 Go de mémoire ça me paraît quand même beaucoup. Ce qui est curieux, c’est que le processus occupe très peu de mémoire résidente en comparaison (25 Mo) donc soit il n’utilise jamais les données qui sont en swap (et il peut s’agir de fuite), soit il est lui-même inactif. Même remarque pour mysqld.

Que LibreOffice ait desfuites de mémoire, ça ne me choque pas vraiment de la part d’une usine à gaz qui n’a pas vocation à tourner en permanence.

En première approximation on peut additionner RES+SWAP, mais ça reste une approximation. La gestion de la mémoire est quelque chose d’extrêmement complexe en partie à cause de toutes les optimisations mises en oeuvre, et il est difficile d’évaluer la quantité de mémoire occupée par un processus. Une partie de la mémoire résidente peut être à la fois en RAM et dans le swap (swapcache), partagée avec d’autres processus (mémoire partagée, bibliothèques partagées, fichiers mappés…)

Non, ce n’est pas « que du cache » qu’on peut jeter à tout moment. Comme je l’ai écrit, le cache contient aussi tous les fichiers mappés dans la mémoire virtuelle des processus, ce qui inclut notamment les portions des binaires exécutables et les bibliothèques partagées qu’ils utilisent. J’ignore dans quelle mesure cette partie du cache est récupérable. Il y a aussi le contenu « sale » (modifications du système de fichiers en attente d’écriture sur disque) mais il me semble qu’un sync devrait le réduire.

Aussi, par défaut depuis Debian stretch free additionne le cache et les buffers dans une même colonne. En général le cache est bien plus gros que les buffers, mais ces derniers peuvent grossir lorsqu’il y a de l’activité disque. Pour les afficher séparément il faut ajouter l’option -w.

#12

Désolé d’insister mais le premier retour montre bien qu’il y a un problème avec signal-desktop.

4682 turman    20   0   37,2g 288500  68592 S  24,8   3,6   7719:45 signal-desktop

Je ne suis pas assez calé en matière de gestion de la mémoire, mais AMHA le fait qu’une application utilise le swap n’indique en rien qu’elle présente une fuite mémoire.
Pour moi, si une application présente une fuite mémoire elle va réclamer de la RAM sans en libérer et le système va déplacer les pages mémoire peu ou pas utilisées vers le swap, donc a priori celle des autres applications .

#13

Si tu fais allusion aux 37 Go de mémoire virtuelle, je t’accorde que ça me paraît complètement délirant mais ça reste de la mémoire virtuelle, donc potentiellement du vide. La mémoire résidente n’est « que » de 288 Mo et on ne voit pas le swap.

Certes, mais ça peut être un signe, surtout si les données mises en swap n’en sortent jamais, signe que le processus ne les utilise pas.

Dans un premier temps, oui. Ensuite quand le système va à nouveau avoir besoin de réclamer de la mémoire, il va voir que les pages liées à la fuite ne sont jamais utilisées et les swapper à leur tour.

#14

Oui c’est bien à cela que je faisais allusion.
J’ai regardé sur une machine de bureau et j’ai trouvé un processus (Firefox webextensions) qui occupe plus de 24 Go de mémoire virtuelle.
Ce n’est donc pas exceptionnel. Mais j’ai du mal à comprendre ce concept de mémoire virtuelle et la page de man de top en donne une explication plus que succincte.
Merci pour tes explications complémentaires.

Concernant akonadi je l’utilise depuis des années (c’est un composant de kmail/kontact) et je n’ai jamais constaté de fuite mémoire.

#15

La mémoire virtuelle est avant tout un concept, un mode de fonctionnement des processeurs et systèmes d’exploitation « modernes » comme Linux, qui permet l’isolation des processus et la gestion efficace de la mémoire. Chaque processus « voit » un espace d’adressage virtuel indépendant des autres processus et de l’espace d’adressage de la mémoire physique (autrement dit, le contenu de la mémoire à l’adresse X d’un processus n’a potentiellement rien à voir avec le contenu de la mémoire à la même adresse d’un autre processus ou de la mémoire physique).

Dans cet espace d’adressage virtuel, le noyau « mappe » tout ce dont le processus a besoin :

  • le programme exécutable
  • les bibliothèques partagées
  • les fichiers de données mappés en mémoire (moyen alternatif aux entrées-sorties classiques pour l’accès à un fichier, cf. mmap)
  • la mémoire de travail du processus
  • les données swappées
  • la mémoire partagée avec d’autres processus à des fins de communication ou synchronisation
    j’en oublie peut-être d’autres

Tout cela constitue ce qui est compté comme la mémoire virtuelle. Cependant l’occupation réelle peut être inférieure car seules les zones de mémoire de travail ou des fichiers mappés auxquelles le processus a accédé occupent réellement de la mémoire. En effet le noyau alloue la mémoire pour une page donnée seulement lors du premier accès à celle-ci. Cela évite les entrées-sorties (dans le cas d’un fichier mappé) et les allocations de mémoire inutiles. D’autre part le noyau fait de l’« overcommit » : il peut allouer plus de mémoire virtuelle qu’il n’y a de mémoire physique disponible, en pariant sur le fait que les processus n’utiliseront pas toute la mémoire qu’ils ont demandée.

2 J'aime
#16

Merci pour ces infos, c’est très intéressant.

Après avoir donc fermé les applications qui consommaient le plus de swap je me retrouve dans un état pas trop mal:

               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       3.2Gi       840Mi       1.5Gi       3.6Gi       2.6Gi
Swap:          7.9Gi       403Mi       7.5Gi

Je suis bien content d’avoir cette astuce pour voir la swap consommée par processus dans top, et du coup pouvoir estimer la taille de mémoire occupée par chacun d’entre eux en additionnant swap+ res. C’est pas ultra pratique mais il doit y avoir moyen de configurer top pour au moins avoir l’affichage de la colonne swap par défaut.

Pour revenir à mes différentes sorties de free j’ai quand même une question ultra basique: pourquoi total != used + free ? Dans mon cas on dirait qu’il faut rajouter buffer/cache pour arriver au total mais pour moi used est censé contenir tout ce qui n’est pas free, y compris le buffer/cache.

#17

C’est la définition même de la valeur « used » figurant dans la page de manuel de free:

used Used memory (calculated as total - free - buffers - cache )

#18

Effectivement. J’ai été feinté par la page postée plus haut où on peut voir cette sortie de free où total = used + free:

  $ free -m
                total        used        free      shared  buff/cache   available
  Mem:           1504        1491          13           0         855      792
  Swap:          2047           6        2041

Surprenant n’est ce pas ?

#19

Oui, ça correspond à la valeur de « used » affichée par les anciennes versions de free. Mais celles-ci n’affichaient pas de colonne « available » ni de colonne « buff/cache » combinée :

             total       used       free     shared    buffers     cached
Mem:          1,5G       1,2G       258M        44M        47M       351M
-/+ buffers/cache:       853M       657M
Swap:         954M       240M       714M
#20

Intéressant, ça marche sur htop ?
(j’ai appuyé sur f et ça n’a rien donné)