Fuite de mémoire lors de l'utilisation de DirectorySearcher.FindAll()

J'ai un long processus en cours d'exécution qui doit faire beaucoup de requêtes sur Active Directory assez souvent. Pour cet effet, j'ai été en utilisant le Système.DirectoryServices espace de noms, à l'aide de la DirectorySearcher et DirectoryEntry classes. J'ai remarqué une fuite de mémoire dans l'application.

Il peut être reproduite avec ce code:

while (true)
{
    using (var de = new DirectoryEntry("LDAP://hostname", "user", "pass"))
    {
        using (var mySearcher = new DirectorySearcher(de))
        {
            mySearcher.Filter = "(objectClass=domain)";
            using (SearchResultCollection src = mySearcher.FindAll())
            {
            }            
         }
    }
}

La documentation de ces classes-dire qu'ils auront une fuite de mémoire si dispose() n'est pas appelée. J'ai essayé sans disposer du bien, c'est juste des fuites plus de la mémoire dans ce cas. J'ai testé avec les deux versions framework 2.0 et 4.0 quelqu'un A rencontré ce avant? Existe-il des solutions?

Mise à jour: j'ai essayé d'exécuter le code dans un autre domaine d'application, et il ne semble pas aider non plus.

  • while(true)... ?
  • C'est juste pour illustrer le problème, dans le réel de l'application, il n'est pas comme ça, évidemment.
  • Comment pouvez-vous remarqué une fuite de mémoire dans l'application"?
  • Malheureusement, en utilisant while(true)... à cet endroit permettrait de prévenir la DirectorySearcher et la DirectoryEntry être éliminés correctement. Vous pourriez le mettre au premier niveau de "l'aide" à la place, et de vérifier ce qui se passe.
  • en fait, j'ai essayé que le premier, avec les mêmes résultats. Il donne le même résultat dans les deux cas. Édité mon code en question et si déplacé à l'extérieur de la boucle.
  • Gencer - avez-vous essayé d'inspecter l'utilisation de la mémoire avec WinDebug et les extensions gérées? J'ai réussi à troubleshooted des fuites de mémoire de l'utiliser.
  • J'ai utilisé WinDbg et aussi Ants profiler, et le problème semble être dans la mémoire non managée partie, qui ne cesse de croître.
  • Gencer - vous dire "dans le réel de l'application, il n'est pas comme ça, évidemment". Ce qui pourrait ne pas être si évident, c'est que nous ne pouvons pas vraiment d'indices, à moins que nous savons ce que votre code réel, c'est comme.
  • dans mon précédent code de la boucle while a été autour de la findall(), qui n'est pas un scénario réaliste. Le point du code ci-dessus est pour illustrer la fuite de mémoire, ce qui semble se produire chaque fois que FindAll() est appelée. Il n'est pas destiné à un morceau de l'application réelle.
  • Gencer de nouveau... sans voir le code réel, tout ce que nous faisons c'est de faire des suppositions sauvages dans l'obscurité.
  • Qui est le véritable code de la fuite de la mémoire. Vous pouvez l'exécuter, et il sera de fuite.. Si je peux éviter le code ci-dessus à partir de la fuite, alors je peux l'utiliser dans mon code, qui a beaucoup de code supplémentaire de ne pas pertinent pour cette question, c'est pourquoi j'ai sauté dessus.
  • lequel de ces objets est une fuite? Avez-vous trouver de l'aide SOS.dll f.e.?
  • Ants profiler montre "une mémoire non managée" que la partie qui est en augmentation. Il n'est pas directement quelque chose à l'intérieur de la GC de l'atteindre..
  • Je me souviens que j'ai frappé ce problème dans le .net 2 jours, vous pourriez être mieux d'utiliser le LDAP classes de parler à ActiveDirectory, plutôt que de la vieille ADSI gâchis!!!
  • Ringrose, qui LDAP classes parlez-vous?

InformationsquelleAutor Can Gencer | 2011-04-12
  1. 14

    Aussi étrange que cela puisse être, il semble que la fuite de mémoire se produit uniquement si vous ne le faites pas n'importe quoi avec les résultats de la recherche. Modifier le code dans la question suivante n'a pas de fuite de mémoire:

    using (var src = mySearcher.FindAll())
{
   var enumerator = src.GetEnumerator();
   enumerator.MoveNext();
}

    Ce qui semble être causée par interne searchObject champ ayant l'initialisation tardive , en regardant SearchResultCollection avec Réflecteur :

    internal UnsafeNativeMethods.IDirectorySearch SearchObject
{
    get
    {
        if (this.searchObject == null)
        {
            this.searchObject = (UnsafeNativeMethods.IDirectorySearch) this.rootEntry.AdsObject;
        }
        return this.searchObject;
    }
}

    L'éliminer ne fermera pas non managé poignée à moins que searchObject est initialisé.

    protected virtual void Dispose(bool disposing)
{
    if (!this.disposed)
    {
        if (((this.handle != IntPtr.Zero) && (this.searchObject != null)) && disposing)
        {
            this.searchObject.CloseSearchHandle(this.handle);
            this.handle = IntPtr.Zero;
        }
    ..
   }
}

    L'appel de la méthode MoveNext sur le ResultsEnumerator appelle la SearchObject sur la collection ainsi faire en sorte qu'il est disposé correctement.

    public bool MoveNext()
{
  ..
  int firstRow = this.results.SearchObject.GetFirstRow(this.results.Handle);
  ..
}

    La fuite dans mon application est en raison de certaines autres non géré tampon pas libérée correctement et le test que j'ai fait était trompeuse. Le problème est résolu maintenant.

    • À partir de votre explication, il ressemble à un bug dans le .NET-library. Vous devriez envisager de fileing Connecter un bug: connect.microsoft.com/VisualStudio
    • yep déjà fait..
    • N'est-ce pas à l'aide de l'agent recenseur le même que le fait de faire un foreach sur le SearchResultCollection?
    • oui il n'y a pas de différence. Il était juste là pour illustrer le bug.
    InformationsquelleAutor Can Gencer
  2. 6

    Le wrapper géré n'a pas vraiment de fuite de quoi que ce soit. Si vous n'appelez pas Dispose des ressources non utilisées pourront encore être récupérés lors de la collecte des ordures.

    Cependant, le code managé est un wrapper sur le dessus de la COM ADSI API et lorsque vous créez un DirectoryEntry le code sous-jacent qui fera appel à la ADsOpenObject function. Le retour de l'objet COM est libéré lorsque le DirectoryEntry est disposé ou au cours de finalisation.

    Il est documenté fuite de mémoire lorsque vous utilisez le ADsOpenObject API avec un ensemble d'informations d'identification et un WinNT fournisseur:

    • Cette fuite de mémoire se produit sur toutes les versions de Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7 et de Windows Server 2008 R2.
    • Cette fuite de mémoire se produit uniquement lorsque vous utilisez le dossier WinNT fournisseur avec des informations d'identification. Le fournisseur LDAP n'est pas une fuite de mémoire de cette manière.

    Cependant, la fuite n'est que de 8 octets et et aussi loin que je peux voir vous utilisez le fournisseur LDAP et non pas le dossier WinNT fournisseur.

    Appel DirectorySearcher.FindAll permettra d'effectuer une recherche qui requiert beaucoup de nettoyage. Ce nettoyage est effectué dans DirectorySearcher.Dispose. Dans votre code, ce nettoyage est effectué à chaque itération de la boucle et non pas lors de la collecte des ordures.

    À moins qu'il y est vraiment un sans-papiers fuite de mémoire dans le LDAP ADSI API la seule explication que je peux trouver, c'est la fragmentation du segment non géré. L'ADSI API est mis en œuvre par un processus de serveur COM et chaque recherche ne sera probablement allouer de la mémoire sur le segment non géré de votre processus. Si cette mémoire est fragmentée le tas peut se développer lorsque l'espace est alloué pour de nouvelles recherches.

    Si mon hypothèse est vraie, une option serait d'exécuter les recherches dans un autre domaine d'application qui peuvent ensuite être récupérée pour décharger ADSI et de recycler la mémoire. Cependant, même si la fragmentation de la mémoire peut augmenter la demande de mémoire non managée je m'attends à ce qu'il y aurait une limite supérieure à la quantité de mémoire non managée est nécessaire. Sauf si bien sûr vous avez une fuite.

    Aussi, vous pouvez essayer de jouer avec le DirectorySearcher.CacheResults de la propriété. En fixant à false éliminer la fuite?

    • jolie trouvaille! c'est exactement ça. Il est très peu à chaque fois, mais s'accumule au fil du temps et il y avait certainement une fuite quelque part et je n'ai créer un nouveau DirectoryEntry à chaque fois (avec références).
    • en fait la lecture de nouveau le lien, je n'utilise pas le WinNNT fournisseur, c'est à l'aide du fournisseur LDAP au lieu de cela.. Aussi la fuite semble se produire lorsque vous effectuez une recherche, ne pas utiliser un DirectoryEntry.. (si je change la boucle tant que tel). Semble que je suis excité un peu prématurément. Mais il y a probablement certains autres de fuite de mémoire dans l'API COM..
    • CacheResults ne semble pas avoir d'effet. Chaque FindAll appel semble augmenter l'utilisation de la mémoire par autour de 500 à 600 octets en moyenne (plus de 1000 pistes), (mesurée à l'aide de l'appel de Gc.Collect(), GC.WaitForPending() juste avant la mesure de la mémoire), et à l'aide de Processus.Fonction getcurrentprocess().PrivateMemorySize64 pour obtenir la taille de la mémoire.
    • Un autre domaine d'application ne serait pas de l'aide, comme la mémoire est recueilli sur un processus à base large, donc un autre processus serait nécessaire.
    • Ringrose: Déchargement d'un domaine d'application permettra également de décharger les DLL de COM qui a été chargé dans ce domaine d'application. Cependant, je ne suis pas tout à fait sûr de ce qui va arriver avec n'importe quel segment de mémoire non géré affectés par cette DLL. Les Chances sont qu'il s'appuie sur une bibliothèque C++ pour l'allocation de la mémoire et de cette bibliothèque et de ses ressources peuvent encore être chargés dans le processus après le domaine d'application est déchargé. Évidemment, la COM DLL delete/free la mémoire quand il décharge (sauf s'il a une fuite), mais le segment peut encore être mappés dans le processus.
    • Depuis que je poste en tant que programmeur C++, je me souviens que la plupart des supprimer/free imp ne pas donner de la mémoire au système d'exploitation et ne pas faire face à fagments. Vous avez aussi l'espoir d'une autre dll COM qui utilise le même C/C++ runtime n'a pas été chargé par un autre domaine d'application beaucoup trop de "si" à mon goût!
    • le mystère est résolu. Il semble à une fuite de mémoire que si vous n'avez rien faire d'autre que le résultat de la recherche. Voir ma réponse.
    • J'ai été dispoding tout, mais mon programme n'était pas encore la fuite de la mémoire signalé par un outil générateur de profils. Réglage DirectorySearcher.CacheResults de faux a fait le tour. Merci

    InformationsquelleAutor Martin Liversage
  3. 3

    En raison de la mise en œuvre de restrictions, le SearchResultCollection classe ne peut pas libérer l'ensemble de ses ressources non managées, quand il est de ces ordures. Pour éviter une fuite de mémoire, vous devez appeler la méthode dispose lors de la SearchResultCollection objet n'est plus nécessaire.

    http://msdn.microsoft.com/en-us/library/system.directoryservices.directorysearcher.findall.aspx

    EDIT:

    J'ai été en mesure de reproduire le de fuite apparente à l'aide de l'analyseur de performances, et en ajoutant un compteur Octets Privés sur le nom de processus de l'application de test (Expériences.vshost pour moi )

    le compteur Octets Privés permettra d'augmenter de façon constante, tandis que l'application est en boucle, ça commence autour de 40 000 000, puis croît d'environ un million d'octets toutes les quelques secondes. La bonne nouvelle, c'est que le compteur revient à la normale (35,237,888) lorsque vous mettez fin à l'application, donc une sorte de nettoyage est enfin passé.

    J'ai joint une capture d'écran de ce que perfmon ressemble quand sa fuiteFuite de mémoire lors de l'utilisation de DirectorySearcher.FindAll()

    Mise à jour:

    J'ai essayé quelques solutions de contournement, comme désactiver la mise en cache sur le DirectoryServer objet, et il n'a pas aidé.

    La FindOne() la commande n'a pas de fuite de mémoire, mais je ne suis pas sûr de ce que vous avez à faire pour rendre cette option de travail pour vous, sans doute modifier le filtre en permanence, sur mon contrôleur AD, il y a juste un seul domaine, de sorte findall & findone donnent le même résultat.

    J'ai aussi essayé de files d'attente de 10 000 threadpool les travailleurs à faire la même DirectorySearcher.FindAll(). Il a fini beaucoup plus vite, mais il a encore une fuite de mémoire, et en fait octets privés sont allés jusqu'à environ 80 mo, au lieu de 48 mo pour le "normal" de fuite.

    Donc, pour cette question, si vous pouvez faire FindOne() le travail pour vous, vous avez une solution de contournement. Bonne Chance!

    • l' "l'aide" de champ est équivalent à l'appel de disposer, et aussi il n'a aucun effet pour appeler dispose plus d'une fois.
    • J'espère que votre droite, le MSDN document semble indiquer explicitement disposer d'appel est nécessaire parce que la collection a des ressources non managées. Je vais le tester ce matin.
    • il semble que le manuel de disposer ou de l'aide ne fait pas de différence sur la fuite. Je vais voir si je peux comprendre exactement quel type de mémoire est une fuite.
    • J'ai aussi vérifié que si vous en commentaire l'appel à FindAll(), la fuite s'arrête. Bien sûr, le code est inutile à ce point 🙂
    • J'ai résolu le problème maintenant, voir ma réponse.
    InformationsquelleAutor Ivan Bohannon
  4. 2

    Avez-vous essayé using et Dispose()?
    Info de ici

    Mise à jour

    Essayez d'appeler de.Close(); avant la fin de l'aide.

    Je n'ai pas vraiment avoir un Domaine Actif de Service pour le tester sur, désolé.

    • puttng le jeter dans l'utilisation de bloc est en effet l'appel de Disposer de deux fois.. et il ne semble pas avoir d'effet (comme prévu). Moi aussi je suis passé par la dispose de code pour les classes à l'aide .NET de Réflecteur à la fois de vérifier si l'objet est déjà éliminés et ne rien faire sinon.
    • Il serait aussi intéressant de vérifier votre code source, ce qui est en votre moins le niveau de l'Aide: l'exemple de la liaison montre d'autres objets AD qui a également besoin d'une Dispose(), comme les Propriétés de l'objet.
    • Les Propriétés de l'objet n'est pas de mettre en œuvre IDispoable, c'est juste DirectorySearcher, DirectoryEntry et SearchResultCollection.
    • Mise à jour de ma réponse
    • La clôture n'a aucun effet. J'ai vérifié cela à l'aide de Réflecteur. À la fois Close() et dispose() appel de la Unbind() et la fonction sont essentiellement les mêmes.
    • Est-il un test de Domaine Active de Services, nous pourrions vous connecter à quelque part sur la toile pour tester le code nous-mêmes? Ou est-il simple à installer localement?
    • Non pas que je suis au courant de. Ce que vous pouvez faire est de télécharger le Serveur 2008 R2 180 jours d'essai de la machine Virtuelle de Microsoft et d'ajouter "contrôleur de domaine" rôle du serveur. microsoft.com/windowsserver2008/en/us/trial-software.aspx

    InformationsquelleAutor William Mioch
  5. 0

    Trouvé une façon rapide et sale autour de ce.

    J'ai eu un problème similaire dans mon programme avec la croissance de la mémoire, mais en changeant .GetDirectoryEntry().Propriétés("cn").Valeur à

    .GetDirectoryEntry().Propriétés("cn").De la valeur.ToString avec un si avant la main afin de s'en assurer .la valeur n'était pas nulle

    j'ai été en mesure de dire GC.Recueillir de se débarrasser de la valeur temporaire dans mon foreach. Il ressemble à l' .la valeur a fait l'objet vivant, plutôt que de les lui permettant d'être recueillies.

    InformationsquelleAutor user2407166