Aller au contenu

vmstat

Présentation de l’outil

vmstat (Virtual Memory Statistics) est un utilitaire en ligne de commande pour les systèmes Unix et Linux qui fournit des informations sur les ressources système, y compris la mémoire, les processus, les interruptions et l’activité d’E/S disque. vmstat est particulièrement utile pour les administrateurs système qui cherchent à surveiller et diagnostiquer les problèmes de performance du système.

Installation

Sur Debian/Ubuntu

vmstat est généralement préinstallé sur les systèmes Debian et Ubuntu. Il fait partie du paquet procps.

Si, pour une raison quelconque, il n’est pas installé, vous pouvez installer le paquet procps :

  1. Mettez à jour la liste des paquets :

    sudo apt update
    
  2. Installez le paquet procps :

    sudo apt install procps
    

Sur CentOS

De même, vmstat est généralement préinstallé sur CentOS. Il fait également partie du paquet procps-ng.

Si ce n’est pas le cas, vous pouvez installer le paquet procps-ng :

  1. Mettez à jour la liste des paquets :

    sudo yum update
    
  2. Installez le paquet procps-ng :

    sudo yum install procps-ng
    

Exemple d’utilisation

Exemple 1

Après l’installation, vous pouvez utiliser vmstat pour surveiller les performances de votre système. Voici quelques exemples :

  • Pour afficher un rapport sur les statistiques de la mémoire virtuelle :

    vmstat
    
  • Pour afficher un rapport toutes les 2 secondes :

    vmstat 2
    
  • Pour afficher un rapport sur les statistiques de disque :

    vmstat -d
    

Exemple 2

Un exemple d’utilisation et les conclusions qu’on peut en tirer :

$ vmstat 1
 procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
  3  4    160 435540 1619832 6934704    0    0    28   357    1     7  9  1 81  8
  1  4    160 489876 1619836 6878872    0    0    16     0 1631   446 14  4 60 21
  2  4    160 547220 1619836 6820936    0    0    32     0 1634   292 16  4 56 25
  0  4    160 595860 1619836 6791424    0    0     0     0 1608   254 17  2 56 25
  0  4    160 597076 1619836 6791084    0    0     0     0 1428   162  0  0 70 29
  1  4    160 602900 1619836 6787480    0    0     0    92 1523   285  3  0 62 35

Nous pouvons déduire de cette sortie que :

  • 4 processus attendent l’accès à un périphérique (colonne b) ; Cette colonne indique le nombre de processus en cours d’appel système bloquant (c’est l’état Uninterruptible Sleep, ou D dans ps). Signalons au passage que c’est le seul état dans lequel un processus reste insensible à kill -9, avec l’état Zombie (Z). C’est probablement du disque, mais cela peut aussi être du lecteur de bandes par exemple (mais pas du réseau) ;
  • le serveur dispose d’au moins 435 Mo de mémoire immédiatement libre (colonne free) ; Le système maintient toujours un pool de quelques Mo au moins de libre afin de répondre immédiatement aux demandes d’allocation. Si cette mémoire est consommée, un peu du cache est recyclé en mémoire libre ;
  • le noyau Linux utilise 7 Go pour son cache disque ; C’est normal avec Linux, qui a tendance à être très agressif sur l’utilisation du cache. Même les données du swap sont cachées au moment où le système les écrit, afin de pouvoir les récupérer rapidement s’il s’était trompé.
  • le noyau utilise 1,6 Go de mémoire pour les buffers. Il s’agit d’espace utilisé temporairement pour stocker des blocs disques. C’est une forme de cache aussi, mais au niveau des devices, pas des fichiers ;
  • le serveur n’utilise pas du tout le swap, ce qui signifie que la pression d’éviction de pages mémoires n’a pas été suffisamment forte pour que le système décide de swapper des processus. C’est-à-dire que le mécanisme qui décide si le système a besoin de libérer de la mémoire (pour augmenter le cache ou les buffers, ou bien pour fournir davantage de mémoire aux processus ou au noyau) n’a pas eu besoin pour le moment de déposer des pages dans le swap ;
  • pratiquement pas de lectures, quelques écritures, ce qui, là aussi, n’est guère étonnant, les 7 Go de cache de Linux permettant probablement de stocker une énorme partie des informations nécessaires au fonctionnement du serveur (colonnes bi et bo) ;
  • enfin, la colonne wa (waiting for io) nous montre que le processeur est souvent en attente d’entrées/sorties disque. Le temps wa correspond au temps pendant lequel le processeur est inactif, et qu’il aurait pu passer à travailler si les entrées sorties étaient plus performantes.

vmstat permet donc de répondre aux questions suivantes :

  • Le système a-t-il assez de mémoire pour la charge actuelle ? C’est si / so qui va nous le dire. Surtout pas la quantité de swap utilisée. Un serveur peut très bien avoir 4 Go de données en swap et fonctionner très bien, si il contient des processus qui allouent de la mémoire et ne s’en servent pas ou ne s’en sont servis qu’une fois ;
  • Le système a-t-il assez de processeurs : est-il principalement en idle ? quelle est la taille de la runqueue (r) ? Si la runqueue est en permanence supérieure au nombre de cœurs de la machine, c’est mauvais signe. Des pics ponctuels sont par contre tout à fait normaux ;
  • Le système est il assez équipé en disque ? C’est wa qui va nous le dire : si wa est élevé, le serveur passe son temps à attendre les disques. Le principal axe d’amélioration dans ce cas est donc les disques : plus d’axes, répartition différente, SSD, FusionIO ;
  • Certaines autres choses peuvent dénoter des anomalies :
    • cs élevé (+ de 20000) signifie que chaque seconde, 20000 changement de contexte d’exécution (thread, processus) sont effectués. On dirait donc que vous avez des processus qui se gênent les uns les autres (attentes sur sémaphores par exemple), ou des processus qui communiquent via de tous petits pipes et passent leur temps à attendre la réponse de l’autre ;
    • in élevé (+ de 5000) signifie que vous avez un périphérique qui génère un grand nombre d’interruptions. C’est signe d’une activité réseau bizarre, d’un driver bugué…
    • sy supérieur à 15% : vous avez quelque chose qui fait trop d’appels systèmes. Une fork bomb, un script bash qui fait 10 000 fois une boucle dans laquelle il appelle 3 sed, 2 awk et 5 cut, une base sur un système de fichiers NFS… En résumé quelque chose qui fait travailler le système d’exploitation pour rien.
    • b qui ne retombe jamais à 0 : mauvaise nouvelle, un des disques est cassé et l’erreur n’est pas encore remontée de la couche SCSI. Ou bien votre lecteur de bandes est HS.

Bibliographie

  1. Site web officiel de procps : Lien vers le site