svmon est l’outil de réference sur AIX pour avoir une description détaillée de l’utilisation mémoire. Malheureusement, ces rapports sont relativement difficile à lire. Je vais décrire ici un des pièges qui m’a le plus ennuyé lors de l’utilisation de svmon. Il s’agit de la manière dont l’espace mémoire en paging space est décompté.

Description du “piège”

Lors que l’on utilise svmon pour lister les utilisateurs qui consomment le plus de mémoire sur le système, on peut tomber sur des lignes de ce type :

===============================================================================
User Inuse Pin Pgsp Virtual LPageCap
oracle 4115616 8370 2051075 4953757 -

...............................................................................
SYSTEM segments Inuse Pin Pgsp Virtual
 7836 5664 725 8490

 Vsid Esid Type Description LPage Inuse Pin Pgsp Virtual
 0 0 work kernel segment - 7836 5664 725 8490 

...............................................................................
EXCLUSIVE segments Inuse Pin Pgsp Virtual
 210714 2706 90191 304157

 Vsid Esid Type Description LPage Inuse Pin Pgsp Virtual
 296c51 70000000 work default shmat/mmap - 42155 0 31861 52843

Le but ici était de savoir quel quantité de mémoire utilisée par l’utilisateur Oracle était actuellement en paging space.

Si on prend comme base :

• Inuse : mémoire physique en cours d’utilisation par l’utilisateur.
• Pgsp : espace utilisé en paging space par l’utilisateur.
• Pin : espace en mémoire physique ne pouvant pas être swappé sur le paging space.
• Virtual : mémoire virtuelle consommé par l’utilisateur.

La réponse rapide serait donc de dire 2051075 pages de 4ko.

Mais le problème est que lorsque l’on additionne Pgsp et Inuse, on dépasse Virtual :

4115616 + 2051075 = 6166691

Explication

L’explication tient dans l’algorithme d’allocation du paging space utilisé par AIX. Par défaut à partir d’AIX 5.2, l’algorithme Deferred Paging Space Allocation est utilisé. Une description rapide serait de dire qu’il consiste à allouer une page mémoire en paging space au moment où la page mémoire d’un processus est paginé et à conserver la réservation pour la page en paging space jusqu’à la fin du processus.

Donc avec cet algorithme, il suffit d’avoir eu à un moment des processus qui ont été swappé puis sont revenu en mémoire physique pour que lorsqu’on additionne Inuse et Pgsp cela dépasse Virtual.

On peut donc calculer la quantité de mémoire réellement swappé à un moment donné de la manière suivante : Virtual - Inuse

Cela permet aussi de comprendre pourquoi on peut avoir un paging space utilisé alors que toute la mémoire physique n’est pas utilisée, comme dans le graphique ci-dessous :

Cette image tiré de ganglia illustre bien cette réservation du paging space par les processus. On voit que le paging space diminue uniquement quand certains processus s’arrêtent (ici vers 20h) et que lorsque l’occupation du paging space augmente, elle ne diminue plus et ce même si la mémoire physique n’est plus entiérement utilisée. Le serveur ici est un serveur avec des bases Oracle donc typiquement avec des processus associés à des grandes quantités de mémoire(SGA) durant longtemps.

Conclusion

Je dois admettre que j’ai cherché un bon moment l’explication du phénomène la première fois où j’ai remarqué ça :-).

L’autre point important est que j’ai pu enfin glisser un graphique extrait de Ganglia. Il s’agit de mon outil de monitoring/capacity planning favori en ce moment et je compte bien en parler plus souvent à l’avenir.