Partager via

Résoudre les problèmes de fuite de mémoire native dans un pool d’applications IIS 7.x

S’applique à : Internet Information Services 7.0 et versions ultérieures

Cet article vous aide à identifier la cause de la fuite de mémoire native dans un pool d’applications IIS.

Vue d’ensemble

Il est important de garder à l’esprit qu’il est normal d’allouer une mémoire élevée en tant qu’application web répond aux demandes.

Lorsque la fuite de mémoire dans un pool d’applications IIS se produit, l’augmentation de la mémoire physique (RAM) n’est pas efficace, car la mémoire dans ce scénario n’est pas la mémoire physique (RAM), mais une mémoire virtuelle. Le tableau suivant récapitule la mémoire virtuelle adressable à partir de l’application web.

Process Windows Mémoire adressable (avec un processus ample prenant en compte les adresses) Limite pratique pour les octets virtuels Limite pratique pour les octets privés
32 bits 32 bits 2 Go 1 400 Mo 800 Mo
32 bits 32 bits avec /3 Go 3 Go 2 400 Mo 1 800 Mo
32 bits 64 bits 4 Go 3 400 Mo 2 800 Mo
64 bits 64 bits 8 To Non applicable Non applicable

Scénario

Vous voyez constamment que les octets Processus\Octets privés et Processus\Octets virtuels augmentent ou Traitent\Octets privés et Processus\Ensemble de travail de w3wp.exe augmentent et la mémoire\Octets disponibles diminue.

Cela peut entraîner une exception de mémoire insuffisante sur un pool d’applications dans IIS.

Pour récupérer, le pool d’applications doit être redémarré, mais après cela, l’utilisation de la mémoire passe de nouveau à un niveau élevé. Lorsque vous voyez l’erreur ci-dessus, le pool d’applications a déjà redémarré automatiquement.

Collecte de données

La première chose à faire lorsque vous rencontrez l’utilisation élevée de la mémoire consiste à déterminer si la mémoire d’un processus de travail sur un pool d’applications dans IIS fuit ou non. Vous pouvez utiliser l’Analyseur de performances. Pour plus d’informations sur l’utilisation de Analyseur de performances, consultez Analyse des données de performances.

Conseil

Si vous devez identifier le pool d’applications associé à un processus w3wp.exe particulier, ouvrez une invite de commandes d’administration, basculez dans le dossier %windir%\System32\inetsrv (cd %windir%\System32\inetsrv) et exécutez appcmd list wp. Cela montre l’identificateur de processus (PID) du processus de w3wp.exe entre guillemets. Vous pouvez faire correspondre ce PID avec le PID disponible dans le Gestionnaire des tâches.

Une fois que vous avez confirmé qu’un processus de w3wp.exe connaît une utilisation élevée de la mémoire, vous devez disposer de deux informations pour déterminer ce qui provoque le problème.

  • Un ensemble de collecteurs de données de l’Analyseur de performances.
  • Vidage de mémoire en mode utilisateur du processus de w3wp.exe .

Ces deux éléments doivent être collectés à partir de l’utilisation faible de la mémoire, comme démarrer le processus jusqu’à ce que l’utilisation élevée de la mémoire, comme l’exception de mémoire insuffisante.

Récolte d’un ensemble de collecteurs de données de l’Analyseur de performances

Les données de l’Analyseur de performances (Perfmon) peuvent être affichées en temps réel ou récoltées dans un ensemble de collecteurs de données qui peut être examiné ultérieurement. Pour résoudre un problème de mémoire élevé, nous devons récolter un ensemble de collecteurs de données. Pour créer un jeu de collecteurs de données pour résoudre les problèmes de mémoire élevée, procédez comme suit :

  1. Ouvrez Les outils d’administration à partir de Windows Panneau de configuration.
  2. Double-cliquez sur Analyseur de performances.
  3. Développez le nœud Jeux de collecteurs de données.
  4. Cliquez avec le bouton droit sur Défini par l’utilisateur et sélectionnez Nouveau>jeu de collecteurs de données.
  5. Entrez la mémoire élevée comme nom du jeu de collecteurs de données.
  6. Sélectionnez la case d’option Créer manuellement (avancé).
  7. Cliquez sur Suivant.
  8. Sélectionnez la case d’option Créer des journaux de données.
  9. Cochez la case *Compteur de performances.
  10. Cliquez sur Suivant.
  11. Cliquez sur le bouton Ajouter.
  12. Développez Processus à partir de la liste des compteurs.
  13. Sélectionnez Octets privés, Octets virtuels et Ensemble de travail à partir de l’objet Thread.
  14. Sélectionnez <TOUTES les instances> dans la liste des instances.
  15. Sélectionnez Ajouter.
  16. Développez la mémoire à partir de la liste des compteurs.
  17. Sélectionnez Octets disponibles dans l’objet Thread .
  18. Sélectionnez Ajouter.
  19. Cliquez sur OK.
  20. Définissez l’intervalle d’échantillonnage sur 1 secondes , puis sur Suivant et Terminer.

Votre boîte de dialogue doit maintenant ressembler à la suivante :

Capture d’écran de la boîte de dialogue Propriétés du collecteur de données 01. L’onglet Compteurs de performances est ouvert.

Création d’une règle Debug Diagnostics 1.2

Le moyen le plus simple de collecter les vidages de processus en mode utilisateur lorsqu’une condition de mémoire élevée se produit consiste à utiliser Les diagnostics de débogage (DebugDiag.) Vous pouvez télécharger l’outil de diagnostic de débogage v2 Update 3.

Installez DebugDiag sur votre serveur et exécutez-le. (Vous le trouverez sur le Menu Démarrer après l’installation.)

Les informations les plus importantes pour déterminer la fonction à l’origine de la fuite de mémoire sont les traces de pile des allocations de tas. Par défaut, ces traces de pile ne sont pas acquises. Vous pouvez activer cette fonctionnalité par processus. Utilisez la commande suivante pour activer le suivi de pile :

gflags -i w3wp.exe +ust

La commande n’active pas le suivi de pile pour un processus déjà en cours d’exécution. Par conséquent, pour les processus que vous ne pouvez pas redémarrer (par exemple, les services, lsass, Winlogon), vous devez redémarrer votre ordinateur de test.

Utilisez les commandes suivantes pour vérifier quels paramètres ont été définis pour un processus spécifique :

gflags -i w3wp.exe

Lorsque vous exécutez DebugDiag, il affiche la boîte de dialogue Sélectionner le type de règle. Procédez comme suit pour créer une règle de fuite pour votre pool d’applications :

  1. Sélectionnez La fuite>de handle de mémoire>native (non-.NET) suivante.

  2. Sélectionnez un processus, puis sélectionnez Suivant.

  3. Sélectionnez Configurer.

  4. Définissez la règle comme indiqué dans l’image suivante :

    Vous pouvez ajuster ces valeurs si nécessaire, mais veillez à ne pas spécifier un petit nombre de Mo pour générer les tonnes de fichiers de vidage. Générez un fichier userdump lorsque les octets privés atteignent 800 Mo et chaque octet supplémentaire de 100 Mo par la suite. Générez un userdump lorsque les octets virtuels atteignent 1 024 Mo et chaque fois que 200 Mo supplémentaires sont ensuite générés.

    Capture d’écran de la boîte de dialogue Configurer les vidages utilisateur pour la règle de fuite. Toutes les options sont cochées.

  5. Cliquez sur Enregistrer et fermer.

  6. Cliquez sur Suivant.

  7. Donnez un nom à votre règle si vous le souhaitez et notez l’emplacement où les sauvegardes seront enregistrées. Vous pouvez modifier cet emplacement si vous le souhaitez.

  8. Cliquez sur Suivant.

  9. Sélectionnez Activer la règle maintenant> terminée.

Si vous obtenez l’erreur de mémoire insuffisante même lorsque vous obtenez les vidages de mémoire, vous pouvez obtenir manuellement les vidages de mémoire.

  1. Sélectionnez l’onglet Processus .
  2. Cliquez avec le bouton droit sur le processus cible.
  3. Sélectionnez Créer un userdump complet.

Analyse des données

Après avoir obtenu l’erreur de mémoire insuffisante ou la création des vidages de mémoire, vous disposez de deux ensembles de données à examiner ; le jeu de collecteurs de données Perfmon et les vidages de mémoire. Commençons par examiner les données Perfmon.

Analyse des données de performances

Pour passer en revue les données Perfmon de votre problème, cliquez avec le bouton droit sur le jeu de collecteurs de données mémoire élevée répertorié sous le nœud Défini par l’utilisateur et sélectionnez Dernier rapport. Vous pouvez voir quelque chose de similaire à l’image suivante :

Capture d’écran des données de performances sur le jeu de collecteurs de données mémoire élevée.

Pour accéder à la racine de ce qui provoque le problème élevé du processeur, passez en revue les vidages créés à l’aide de DebugDiag.

Analyse de vidage avec DebugDiag

DebugDiag est en mesure de reconnaître de nombreux problèmes en effectuant une analyse de sauvegarde automatisée. Pour ce problème particulier, les Analyseur de performances de DebugDiag sont bien adaptées pour aider à identifier la cause racine du problème élevé du processeur. Pour utiliser l’analyseur, procédez comme suit :

  1. Sélectionnez l’onglet Analyse avancée dans DebugDiag.
  2. Sélectionnez Analyseurs de pression de mémoire. Veillez à utiliser MemoryAnalysis.asp au lieu de DotNetMemoryAnalysis-BETA.asp.
  3. Sélectionnez Ajouter des fichiers de données.
  4. Accédez à l’emplacement où les vidages ont été créés. Par défaut, il s’agit d’un sous-dossier du dossier C :\Program Files\DebugDiag\Logs .
  5. Sélectionnez l’un des vidages, puis sélectionnez Ctrl+A pour sélectionner tous les vidages dans ce dossier.
  6. Sélectionnez Ouvrir.
  7. Sélectionnez Démarrer l’analyse.

DebugDiag prend quelques minutes pour analyser les vidages et fournir une analyse. Une fois l’analyse terminée, une page semblable à l’image suivante s’affiche :

Capture d’écran d’un rapport d’analyse DebugDiag.

Note

Le haut du rapport vous indique que la fuite de mémoire a été détectée. Dans la table des matières, vous verrez un lien vers les détails du rapport d’analyse des fuites. Sélectionnez ce lien et vous verrez des informations sur ce que ces 10 principaux modules en fonction du nombre d’allocations ou de la taille d’allocation. Voici l’exemple :

Capture d’écran des détails sur le module mémoire élevée.

À partir de cette analyse, vous pouvez voir que le composant leakcom est en cours d’exécution. Pour plus d’informations sur le module de leakcom, comme indiqué ci-dessous, vous pouvez voir que cette CFoo::crtheap méthode alloue la mémoire en attente.

Capture d’écran des détails de leakcom sur le module.

L’étape suivante consiste à passer en revue le code de CFoo::crtheap méthode. Lorsque vous effectuez cette opération, vous trouverez l’extrait de code suivant :

STDMETHODIMP CFoo::crtheap(void)
{
    malloc(1024 * 10);

    return S_OK;
}

Le code ci-dessus entraîne certainement une fuite de mémoire, car la mémoire allouée n’est pas libérée.

Conseil

Si vous activez le suivi de pile (gflags -i w3wp.exe +ust), vous pouvez voir la pile des appels suivante en analysant les vidages avec WinDBG. Vous ne verrez jamais la pile des appels suivante si vous désactivez le suivi de pile par défaut.

0:000> !heap -p -a 42ae5b28
    address 42ae5b28 found in
    _HEAP @ 6690000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        42ae5b28 0541 0000  [00]   42ae5b40    02800 - (busy)
        77e9df42 ntdll!RtlAllocateHeap+0x00000274
        75133db8 msvcr90!malloc+0x00000079
        513f3cc7 LeakTrack!CCRTMemoryLT::R90mallocDetour+0x00000067
        75933cef oleaut32!CTypeInfo2::Invoke+0x0000023f
        61f527b8 leakcom!ATL::IDispatchImpl::Invoke+0x00000058
        f05cb4d vbscript!IDispatchInvoke+0x00000059
        f053f40 vbscript!InvokeDispatch+0x000001a5
        f060795 vbscript!InvokeByName+0x00000043
        f06080d vbscript!CScriptRuntime::RunNoEH+0x000022cf
        f054122 vbscript!CScriptRuntime::Run+0x00000064
        f054099 vbscript!CScriptEntryPoint::Call+0x00000074
        f054279 vbscript!CSession::Execute+0x000000c8
        f0544c0 vbscript!COleScript::ExecutePendingScripts+0x00000146
        f052013 vbscript!COleScript::SetScriptState+0x0000014d
        513023c0 asp!CActiveScriptEngine::TryCall+0x00000019
        513027b3 asp!CActiveScriptEngine::Call+0x000000e7
        513022c7 asp!CallScriptFunctionOfEngine+0x0000003e
        513063d5 asp!ExecuteRequest+0x0000014a
        51302676 asp!Execute+0x000001c4
        513028f2 asp!CHitObj::ViperAsyncCallback+0x000003fc
        51302030 asp!CViperAsyncRequest::OnCall+0x0000006a
        563de19 comsvcs!CSTAActivityWork::STAActivityWorkHelper+0x00000032
        771304fb ole32!EnterForCallback+0x000000f4
        771284c7 ole32!SwitchForCallback+0x000001a8
        77126964 ole32!PerformCallback+0x000000a3
        7713df32 ole32!CObjectContext::InternalContextCallback+0x0000015b
        771f47ef ole32!CObjectContext::DoCallback+0x0000001c
        563dfbd comsvcs!CSTAActivityWork::DoWork+0x0000012f
        563e51b comsvcs!CSTAThread::DoWork+0x00000018
        563f24d comsvcs!CSTAThread::ProcessQueueWork+0x00000037
        563f4c0 comsvcs!CSTAThread::WorkerLoop+0x00000135
        773a1287 msvcrt!_endthreadex+0x00000044

Conclusion

En utilisant Perfmon et DebugDiag, vous pouvez facilement récolter des données qui peuvent être utiles pour déterminer la cause de la fuite de mémoire dans les pools d’applications. Si vous ne parvenez pas à trouver la cause racine à l’aide de ces techniques, vous pouvez ouvrir un ticket de support auprès de Microsoft. Veillez à inclure les données Perfmon et les vidages de suivi de pile dans votre ticket de support pour réduire le temps d’exécution.

Autres ressources