Comment déterminer quelle application perd de la mémoire non paginée?

Nous avons récemment rencontré un problème sur notre serveur en direct qui a empêché notre application Web de répondre. Tout ce que nous obtenions, c'était 503 erreurs jusqu'à ce que nous redémarrions le serveur, alors ça allait. Finalement, je l'ai retracé dans le httperr.log et j'ai trouvé beaucoup d'erreurs 1_Connections_Refused.

Une enquête plus approfondie a semblé indiquer que nous avions atteint la limite du pool non paginé. Depuis lors, nous surveillons la mémoire du pool non paginé à l'aide de Poolmon.exe et nous pensons avoir identifié la balise à l'origine du problème.

Tag   Type    Allocs       Frees       Diff       Bytes      Per Alloc
Even  Nonp  51,231,806   50,633,533   684,922   32,878,688      48

Si nous utilisons poolmon.exe / g, il affiche le pilote mappé comme [<inconnu> objets d'événement].

Ce n'est pratiquement pas du tout utile. Mon équipe a passé beaucoup de temps à rechercher ce problème et n'a pas été en mesure de trouver un processus pour le réduire à une application ou un service spécifique. J'ai l'impression que la plupart des gens semblent résoudre le problème en tuant les processus sur la machine jusqu'à ce qu'ils voient la mémoire non paginée réinitialisée. Ce n'est pas exactement ce que vous voulez voir lorsque vous travaillez sur une machine de production.

Si j'ouvre le Gestionnaire des tâches et affiche la liste des processus. Je vois MailService.exe avec une valeur de pool NP de 105 Ko, c'est 36 Ko de plus que la valeur du processus indiqué en deuxième. Comme nous avons eu quelques problèmes avec notre serveur de messagerie dans le passé (qui peuvent ou non être liés à ce problème), mon instinct est que cela est à l'origine du problème.

Cependant, avant de quitter le redémarrage des services, j'aimerais avoir un peu plus de certitude qu'un simple «sentiment d'intestin».

J'ai également essayé d'utiliser poolmon.exe / c mais cela renvoie toujours l'erreur:

unable to load msvcr70.dll/msvcp70.dll

et il ne crée pas localtag.txt. Mon collègue a dû télécharger pooltag.txt depuis Internet car nous ne pouvons pas déterminer où il se trouve. Nous n'avons pas de débogueur win ou le DDK win installé (que je peux voir). Peut-être que l'erreur ci-dessus est donnée parce que nous n'avons installé aucun de ceux-ci - mais je ne sais pas.

Enfin j'ai essayé:

C:\windows\system32\driver\findstr /m /l Even *.sys

Cela a renvoyé une liste assez importante de fichiers .sys et encore une fois n'a pas été du tout utile avec le problème à portée de main.

Ma question est donc la suivante: existe-t-il un autre moyen de réduire la cause de cette fuite de mémoire?

MISE À JOUR:

Comme suggéré ci-dessous, j'enregistre les octets non paginés du pool depuis environ un jour pour voir si un processus a tendance à augmenter. Pour la plupart, tous les processus semblent être relativement statiques dans leur utilisation. Deux d'entre eux semblent avoir légèrement augmenté. Je continuerai de surveiller cela pendant les prochains jours.

J'ai également oublié de mentionner plus tôt qu'aucun des processus ne semble utiliser un nombre excessif de poignées non plus.

MISE À JOUR 2:

Je surveille cela depuis quelques semaines. Le pool d'octets non paginés pour les processus individuels et le pool total d'octets non paginés sont restés relativement stables pendant cette période. Pendant ce temps, Windows a été mis à jour et le serveur a redémarré, donc je me demande si cela a résolu le problème. Je ne vois certainement pas la croissance constante du pool d'octets non paginés maintenant que j'étais avant cela.

Je surveille cela depuis environ 6-7 semaines maintenant et je peux enfin donner une réponse définitive au problème.

Premièrement, les octets non paginés pour les processus individuels ne m'ont vraiment rien dit d'utile car ils semblaient tous assez statiques dans leur utilisation. Il y avait des pointes mais l'utilisation revenait toujours à la ligne de base par la suite.

Le total de mémoire d'octets non paginés était également statique pendant un certain temps, mais a ensuite commencé à augmenter progressivement puis à augmenter. Après un pic, environ la moitié de la mémoire a été libérée, puis elle est restée à nouveau statique (au niveau supérieur) pendant un certain temps jusqu'à ce que le motif se répète. En regardant le graphique, j'ai remarqué que ces pointes semblaient être assez régulièrement espacées et il se trouve qu'elles se produisaient à 2 semaines d'intervalle et toujours un dimanche.

La question suivante était donc la suivante: que se passe-t-il le dimanche toutes les deux semaines? Je suis allé voir l'Observateur d'événements et chaque fois qu'un pic s'est produit, McAfee était en cours d'exécution . Je pense également qu'en nous connectant fréquemment au serveur pour surveiller le problème, nous avons aggravé le problème par inadvertance, car McAfee a un scanner en temps réel et je pense que cela provoquait les augmentations plus faibles que nous observions.

Je pense que les analyses planifiées expliquent également pourquoi nous avons vu les augmentations de la mémoire NP attachées à la balise Object Events dans PoolMon au lieu de la balise McAfee spécifique. C'était la principale chose qui nous a vraiment conduit sur le chemin du jardin.

Maintenant que nous savons enfin ce qui cause les fuites, nous pouvons y remédier. C'est incroyable qu'il ait fallu si longtemps pour le retrouver.

MISE À JOUR : Juste comme une note finale. McAfee a été mis à jour le week-end et cela a complètement résolu notre problème de mémoire non paginée.

MISE À JOUR 2 : Puisque je viens d'obtenir un vote pour cela, je vais ajouter une nouvelle mise à jour à cela. Initialement, la mise à jour de McAfee a semblé résoudre notre problème, c'est-à-dire que nous ne voyons plus les pics massifs de la mémoire NP à intervalles réguliers. J'ai également remarqué que depuis la mise à jour, il semble que McAfee n'écrit plus de journaux dans l'Observateur d'événements par défaut maintenant, qui se cache lorsqu'il analyse activement.

Mais nous constatons toujours une augmentation progressive de l'utilisation de la mémoire NP. C'est arrivé au point où nous devons maintenant redémarrer notre serveur toutes les 2 semaines environ. C'est tellement mauvais que nous avons récemment acquis un nouveau serveur dans l'espoir que le matériel et les logiciels mis à jour feront disparaître ce problème MAIS notre tout nouveau serveur avec uniquement Windows Server 2008, SQL Server 2008 R2, et McAfee installé montrait TOUJOURS une fuite de mémoire NP . Ce n'est qu'après avoir complètement supprimé McAfee que la fuite s'est arrêtée et elle est restée statique même après avoir configuré le serveur avec tous nos logiciels en préparation pour y basculer.

J'ai lu depuis, et je ne sais pas si c'est vrai, que le problème n'est pas avec McAfee, mais avec certaines routines Windows que McAfee utilise et qui provoquent des fuites de mémoire NP. Apparemment, l'activité réseau est à l'origine de la fuite, c'est-à-dire plus d'activité réseau => des fuites plus importantes. Cela semble cohérent avec notre expérience, dans la mesure où la fuite s'est aggravée à mesure que notre serveur est devenu plus occupé.