free et vmstatQuand un système Unix manque de mémoire, cela a des conséquences souvent catastrophiques : l'ensemble du système se met à fonctionner au ralenti jusqu'à la paralysie complète de la machine ! Le manque de mémoire est donc un problème majeur à traiter sans délai. Il faut donc avant tout être capable de repérer ce phénomène.
Note : ce tutoriel est tiré d'un article sur les bases de l'administration système qui est téléchargeable ici : admin_unix.pdf.
freePour mesurer la consommation de la mémoire, il existe plusieurs commandes, chacune avec sa spécificité. La commande free fournit des informations détaillées sur la façon dont la mémoire est consommée :
$ free -m
total used free shared buffers cached
Mem: 4054 3893 161 0 179 3322
-/+ buffers/cache: 390 3663
Swap: 4095 0 4095
La première ligne indique la consommation de la mémoire physique, c'est à dire celle fournie par les barettes de mémoire :
total used free shared buffers cached
Mem: 4054 3893 161 0 179 3322
total indique la quantité de mémoire physique totale.
used indique la quantité de mémoire physique consommée par le système dans son ensemble.
free indique la quantité de mémoire physique inutilisée.
shared est obsolete et doit être ignoré.
buffers et cached renseignent sur la mémoire utilisée pour (essentiellement) optimiser les performances du système. Cette mémoire peut être rendue disponible à tout moment.
Dans l'exemple ci-dessus, le système dispose en tout de 4054 Mo de mémoire. Sur ce total, 3893 Mo sont utilisés et 161 Mo sont inutilisés. A première vue, toute la mémoire est consommée et la machine est donc dans un état critique. Pourtant, ça n'est pas du tout le cas. Attention à ne pas confondre mémoire inutilisée et mémoire disponible ! Le système consomme un maximum de mémoire pour optimiser au mieux ses performances via l'utilisation de caches, et il n'y a donc que très peu de mémoire inutilisée (colonne free). Mais la mémoire utilisée par les caches (colonnes buffers et cached) peut être libérée à tout moment.
La deuxième ligne indique la quantité de mémoire réellement consommée par les applications (colonne used) et la mémoire réellement disponible (colonne free) :
-/+ buffers/cache: 390 3663
En cessant d'utiliser les caches, le système ne consommerait donc plus que 390 Mo de mémoire alors que 3663 Mo seraient disponibles. Finalement, ce serveur a encore beaucoup de mémoire disponible en réserve !
A quoi servent les buffers / cached ?
Lire un fichier, le modifier, écrire dedans... toutes ces actions ont des répercutions importantes sur les performances du système car les accès disques sont très lents comparés aux accès en mémoire. Pour minimiser les accès disques en lecture et en écriture, le noyau conserve en mémoire aussi longtemps que possible les informations lues ou écrites. Travailler sur une copie en mémoire est alors très rapide. Mais attention au crash ! Pour ne pas perdre l'ensemble de ces données en cas de panne du système, elles sont écrites sur le disque à intervalle régulier (généralement 5 secondes).
La dernière ligne indique la consommation de mémoire swap :
Swap: 4095 0 4095
Le swap est une partition particulière du disque dur utilisée par le noyau pour étendre la mémoire physique. Ce besoin découle de la différence entre le prix de la mémoire qui est beaucoup plus cher que celui des disques. Pourquoi dans ce cas ne pas se servir du disque comme si c'était de la mémoire physique ? C'est exactement le rôle du swap qui permet d'étendre considérablement la mémoire utilisable par le système. En revanche les accès disques étant beaucoup plus lents, cet espace ne sera utilisé qu'en cas d'extrème nécessité, quand la mémoire physique est épuisée.
Quand le système se met à utiliser son swap (on dit alors qu'il "swappe"), les conséquences sur les performances globales du système sont très visibles car celui-ci est alors considérablement ralenti. Le swap doit donc essentiellement être vu comme une mémoire de secours, à utiliser le moins possible. Dans l'exemple ci-dessus, la colonne used avec une valeur de 0 indique que le swap n'est pas utilisé, ce qui est plutôt rassurant pour cette machine.
Notez que certains noyau utilisent une petite portion du swap pour y entreposer de façon temporaire des informations. Cela n'a rien d'alarmant tant que cette consommation est modérée et qu'il reste suffisament de mémoire physique de libre.
vmstatLa commande vmstat permet de suivre en temps réel l'utilisation de la mémoire :
$ vmstat 1 procs ----------memory--------- --swap-- ----io---- --system-- -----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 68 171036 184020 3399464 0 0 30 9 0 1 2 1 86 10 0 0 1 68 168184 184020 3399464 0 0 0 1500 1908 1013 2 1 75 22 0 0 0 68 170416 184028 3399492 0 0 0 1760 1775 1327 2 2 79 18 0 0 0 68 170416 184028 3399492 0 0 0 464 1315 832 2 1 92 5 0 0 1 68 168432 184032 3399488 0 0 4 636 1521 1426 3 1 91 4 0 0 1 68 170788 184032 3399488 0 0 4 1132 1384 770 1 1 82 16 0
Dans l'exemple ci-dessus, une nouvelle ligne de rapport est affichée par vmstat toutes les secondes. La première ligne de rapport ne fournit que des informations statistiques et doit être ignorée. Les lignes suivantes fournissent en revanche de très nombreuses informations relatives notamment à la consommation de CPU et de mémoire. Nous n'examinerons ici que les informations relatives à cette dernière.
Les colonnes free, buff et cache sont très importantes car ce sont elles qui nous renseignent sur la mémoire physique encore disponible (en kilo-octets). La colonne free indique la quantité de mémoire inutilisée, les colonnes buff et cache indiquent les quantités utilisées par les buffers et le cache. Comme les buffers et le cache sont libérables à tout moment, la mémoire réellement disponible correspond à la somme de ces trois indicateurs.
La colonne swpd montre la quantité de swap utilisée. Dans le cas présent, les 68 Ko utilisés n'ont rien d'alarmant car la mémoire physique disponible est encore très importante et cette consommation n'est donc pas liée à une quelconque pénurie. Elle sert juste au noyau à entreposer temporairement quelques informations.
Les deux colonnes suivantes, si et so, nous fournissent de très précieux renseignements quant à la santé du système. Nous avons vu plus haut qu'en cas de pénurie de mémoire physique, le noyau pioche dans le swap. En fait, le swap n'est pas utilisé exactement comme de la mémoire physique mais plutôt comme un entrepôt intermédiaire. Quand le noyau souhaite utiliser une information en swap, il doit d'abord la transférer en RAM. Ce type de transferts est signalé par la colonne si (swap in memory). Mais... n'avons nous pas dit qu'il n'y avait plus assez de RAM libre ? Exactement, et c'est pourquoi le noyau doit d'abord faire un peu de place en transférant des informations de la RAM vers le swap. Ces transferts sont signalés par la colonne so (swap out of memory). La présence de ces transferts est un indicateur fort de la pénurie de mémoire physique. Un système qui utilise son swap passe son temps à faire de couteux allers et retours entre le disque et la RAM. C'est donc un système aux performances très dégradées.
La pénurie de mémoire sur un serveur est rapidement dramatique en termes de performances. L'utilisation de l'espace de swap n'est qu'une solution de secours pour continuer d'assurer le fonctionnement du système et l'empécher de crasher directement. Mais son utilisation est en soi un problème majeur. Autrement dit, votre serveur est en danger et il est temps d'agir !
Il y a en général deux raisons qui peuvent expliquer cette pénurie de mémoire :
Le premier cas concerne une machine dont le fonctionnement ne comporte pas d'anomalie notable, elle manque juste de mémoire. Dans ce cas là, il est rare que le fonctionnement soit complètement ralenti, il faudra juste planifier une intervention afin de rajouter de la mémoire.
Le second problème concerne un processus qui se met à consommer de façon anormale toute la mémoire. Un memory leak (fuite de mémoire) se rapporte au fonctionnement d'un processus qui consomme de la mémoire sans jamais la rendre au système. Il s'agit en général d'un bug (une erreur de programmation) qui doit à terme être corrigé par une mise à jour du programme ou du package. Le graphe d'utilisation de la mémoire du serveur permet de mettre facilement en évidence l'existence d'un memory leak. Ces graphes ont un aspect en "dent de scie" avec une consommation mémoire qui augmente linéairement jusqu'à épuisement complet de celle-ci.
En cas de memory leak, il n'y a en général qu'une seule chose à faire : arrêter le processus fautif et le relancer. Toutefois, il s'agit juste d'une action à très court terme qui ne peut que temporairement soulager la machine.