次の方法で共有

Mémoire & Recyclage sous IIS 6

  • [アーティクル]

Bonjour à toutes et à tous, voici le premier article rédigé par l'équipe de support IIS Microsoft France. Nous espérons qu'il sera le premier d'une longue série…

Mémoire & Recyclage sous IIS 6

La mémoire sous IIS est un sujet très vaste et souvent obscur. Je vais donc tâcher d'éclairer quelques points importants pour comprendre le recyclage d'un « application pool » en particulier le recyclage lié à la consommation mémoire.

Sous IIS, vous pouvez recycler selon différents critères :

  • Le nombre de minutes écoulées
    • 1740 minutes par défaut soit 29 heures
  • Le nombre de requêtes exécutées
  • Une heure prédéfinie

Pour certaines applications qui consomment trop de mémoire, souvent en raison d'un problème de « fuite mémoire », IIS fournit un mécanisme de recyclage en fonction de la mémoire utilisée :

  • « Maximum virtual memory (in megabytes) »
  • « Maximum used memory (in megabytes) »

Cela amène un ensemble de questions :

  • A quoi correspond « virtual memory » et « used memory » ?
  • Pourquoi IIS recycle alors que la valeur indiquée par le gestionnaire de tâches est inférieure à celle que j'ai renseignée dans IIS ?
  • Si on utilise « Debug Diagnostic », à quoi correspondent les valeurs « Private Bytes » et « Virtual Bytes » à utiliser pour déclencher la génération d'un dump
  • De plus, l'onglet « Processes » de «Debug Diagnostic » ne montre pas les mêmes valeurs que celles du gestionnaire de tâches

  • Quelles sont ces différences ?
  • Comment savoir ce qu'il faut regarder ?
  • …

Comme vous pouvez le voir, la confusion règne ! Selon les outils utilisés, les termes utilisés et les valeurs renseignées sont différents. Il est donc important d'apporter des éclaircissements pour ne pas être perdu dans la configuration et la surveillance de son serveur IIS.

La « Virtual Memory »

Tout d'abord il faut savoir que la « Virtual memory » d'un processus (Fig. 1) correspond à l'endroit où tout le code et toutes les données d'un processus existent. Elle peut être sous trois états différents : « free », « reserved » ou « committed ». La « Virtual memory » est allouée en pages de 4Kb pour un système 32-bit. Elle est également connue sous le nom de « Virtual Address Space » qui peut varier selon les options que l'on active et l'architecture utilisée :

  • Sur un système 32-bit, la taille du « Virtual Adress Space (user mode) » est de 2Gb par défaut
  • Si le processus EXE a été prévu pour utiliser /LARGEADDRESSAWARE et que le système démarre avec l'option /3Gb, sa taille sera de 3Gb
  • Par contre, si on se retrouve avec un processus 32-bit sur un system 64-bit, sa taille sera de 4Gb (user mode)

Figure 1

La « Virtual memory » comme valeur de recyclage indiquée dans IIS n'a rien à voir. Elle correspond aux  « Virtual Bytes ». Quand à la « Used memory », elle correspond aux « Private Bytes ». Fort heureusement ces deux termes indiquent la même chose sous IIS et « Debug Diagnostic ».

Mais que sont les "Virtual Bytes" (VB) et les "Private Bytes" (PB) d'un processus ?

Les VB (Fig. 2) d'un processus correspondent au nombre d'octets qui ont été réservés (donc qui ne sont pas « free ») au niveau du « Virtual Address Space » du processus. Veuillez noter que ceci inclut également les parties de la « Virtual Address Space » qui ont été « committées » (La mémoire peut être réservée sans être « committée »).

Figure 2

Les PB d'un processus (Fig. 3 & 4) correspondent aux nombres d'octets du « Virtual Address Space » qui ont été « committés ». C'est uniquement quand une page a été « committée », que le gestionnaire de la mémoire virtuelle va effectivement allouer physiquement cette page en RAM ou sur le fichier de pagination (PageFile). La RAM utilisée par un processus est appelée « Working Set ». Notez que le « Working Set » est extrêmement variable : par exemple, si vous minimisez une application Windows, le Working Set va être réduit au minimum car les pages de cette application présentes dans le « Working Set » vont être déplacées dans le PageFile.

    

Figure 3 Figure 4

Résumons nous (Fig. 5) :

Figure 5

Valeurs affichées dans le gestionnaire de tâches, « Debug Diagnostic » et IIS…

Les valeurs affichées dans le gestionnaire de tâches peuvent être trompeuses et déroutantes même si le gestionnaire de tâches Windows Vista/Windows Server 2008 affiche des valeurs plus cohérentes que dans les précédentes versions de Windows. Les deux colonnes les plus souvent utilisées pour vérifier la mémoire dans le gestionnaire de tâches sont « Memory Usage » (Mem Usage) et « Virtual Memory Size » (VMSize). On pourrait s'attendre à ce que « Memory Usage » corresponde à « Private Bytes » et « Virtual Memory Size » à « Virtual Bytes ». Malheureusement, ce n'est pas tout à fait le cas comme vous pouvez le voir ci-dessous :

  • gestionnaire de tâches
    • Mem Usage = 560Mb            VMSize = 575 Mb
  • Debug Diagnostic
    • Private Bytes = 575 Mb         Virtual Bytes = 736 Mb

« Mem Usage » est approximativement égal au « Working Set ».

« VMSize » est approximativement égal aux « Private bytes » mais en incluant en plus l'espace occupé par les fichiers images (DLL) mappées dans l'espace d'adressage du processus. A noter que si une DLL est utilisée par 10 processus, on ne va pas charger 10 fois la DLL dans chaque processus, mais uniquement « pointer » vers cette DLL. On parle alors de pages de mémoire partagée (« Shared Pages ») qui ne sont pas comptées dans les « Private Bytes ».

Je sens qu'un petit schéma récapitulatif serait le bienvenu J (Fig. 6)

Figure 6

Vous devriez donc maintenant être capable de gérer le recyclage de IIS sans vous demander sur quel type de mémoire vous allez recycler, comment la retrouver et quel outil indique quoi. Il vous reste également la possibilité d'utiliser l'analyseur de performance qui propose des compteurs plus précis et plus détaillés.

J'espère que cet article vous aura été utile.

@ Bientôt

Sylvain Lecerf et L'équipe de support IIS Microsoft France

Comments