Wie bestimme ich, bei welcher Anwendung nicht ausgelagerter Speicher verloren geht?

Wir hatten kürzlich ein Problem auf unserem Live-Server, das dazu führte, dass unsere Web-App nicht mehr reagierte. Alles, was wir bekamen, waren 503 Fehler, bis wir den Server neu starteten, dann war es in Ordnung. Schließlich habe ich es auf das httperr.log zurückgeführt und eine ganze Reihe von 1_Connections_Refused-Fehlern gefunden.

Weitere Untersuchungen schienen darauf hinzudeuten, dass wir das nicht ausgelagerte Poollimit erreicht hatten. Seitdem überwachen wir den nicht ausgelagerten Poolspeicher mit Poolmon.exe und glauben, das Tag identifiziert zu haben, das das Problem verursacht.

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

Wenn wir poolmon.exe / g verwenden, wird der zugeordnete Treiber als [<unbekannt> Ereignisobjekte] angezeigt.

Das ist so ziemlich keine Hilfe. Mein Team hat viel Zeit damit verbracht, dieses Problem zu untersuchen, und konnte keinen Prozess finden, um dies auf eine bestimmte Anwendung oder einen bestimmten Dienst einzugrenzen. Ich habe das Gefühl, dass die meisten Leute das Problem zu lösen scheinen, indem sie Prozesse auf der Maschine beenden, bis sie sehen, dass der nicht ausgelagerte Speicher zurückgesetzt wird. Dies ist nicht genau das, was Sie sehen möchten, wenn Sie an einer Produktionsmaschine arbeiten.

Wenn ich den Task-Manager öffne und die Prozessliste ansehe. Ich sehe MailService.exe mit einem NP-Pool-Wert von 105 KB, der 36 KB höher ist als der Wert des als zweites aufgeführten Prozesses. Da wir in der Vergangenheit einige Probleme mit unserem Mailserver hatten (die möglicherweise mit diesem Problem zusammenhängen oder nicht), ist mein Bauchgefühl, dass dies das Problem verursacht.

Bevor wir jedoch mit dem Neustart der Dienste beginnen, möchte ich etwas mehr Sicherheit haben als nur ein "Bauchgefühl".

Ich habe auch versucht, poolmon.exe / c zu verwenden, aber dies gibt immer den Fehler zurück:

unable to load msvcr70.dll/msvcp70.dll

und es wird keine localtag.txt erstellt. Mein Kollege musste pooltag.txt aus dem Internet herunterladen, da wir nicht herausfinden können, wo es sich befindet. Wir haben weder den Win-Debugger noch das Win-DDK installiert (das kann ich sehen). Vielleicht liegt der obige Fehler vor, weil wir keines davon installiert haben - aber ich weiß es nicht.

Schließlich habe ich versucht:

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

Dies ergab eine ziemlich große Liste von .sys-Dateien und war bei dem vorliegenden Problem wiederum überhaupt nicht hilfreich.

Meine Frage lautet also: Gibt es eine andere Möglichkeit, die Ursache für diesen Speicherverlust einzugrenzen?

AKTUALISIEREN:

Wie unten vorgeschlagen, habe ich den Pool Nonpaged Bytes für den letzten Tag oder so protokolliert, um festzustellen, ob ein Prozess im Trend liegt. Zum größten Teil scheinen alle Prozesse in ihrer Verwendung ziemlich statisch zu sein. Zwei von ihnen scheinen leicht gestiegen zu sein. Ich werde dies in den nächsten Tagen weiter überwachen.

Ich habe auch vergessen zu erwähnen, dass keiner der Prozesse eine übermäßige Anzahl von Handles zu verwenden scheint.

UPDATE 2:

Ich habe dies in den letzten Wochen überwacht. Sowohl der Pool nicht ausgelagerter Bytes für einzelne Prozesse als auch der gesamte Pool nicht ausgelagerter Bytes sind während dieser Zeit relativ stabil geblieben. Während dieser Zeit wurde Windows aktualisiert und der Server neu gestartet, sodass ich mich frage, ob das Problem dadurch behoben wurde. Ich sehe definitiv kein beständiges Wachstum im Nonpaged Bytes Pool, jetzt wo ich vorher war.

Ich beobachte dies jetzt seit ungefähr 6-7 Wochen und kann endlich eine endgültige Antwort auf das Problem geben.

Erstens sagten mir die nicht ausgelagerten Bytes für einzelne Prozesse nichts Nützliches, da sie alle in ihrer Verwendung ziemlich statisch zu sein schienen. Es gab Spitzen, aber die Verwendung kehrte danach immer zur Basislinie zurück.

Die Gesamtspeichermenge für nicht ausgelagerte Bytes war ebenfalls eine Weile statisch, stieg dann jedoch allmählich an und stieg dann an. Nach einer Spitze wurde etwa die Hälfte des Speichers freigegeben und blieb dann eine Weile wieder statisch (auf der höheren Ebene), bis sich das Muster wiederholte. Als ich mir die Grafik ansah, bemerkte ich, dass diese Spitzen ziemlich regelmäßig verteilt zu sein schienen und wie sich herausstellte, dass sie im Abstand von 2 Wochen und immer an einem Sonntag auftraten.

Die nächste Frage war also: Was läuft sonntags zweiwöchentlich? Ich habe mir die Ereignisanzeige angesehen und jedes Mal, wenn ein Spike auftrat, wurde McAfee ausgeführt . Ich denke auch, dass wir uns durch häufiges Anmelden am Server, um das Problem zu überwachen, versehentlich verschlimmert haben, da McAfee über einen Echtzeitscanner verfügt und ich glaube, dass dies die kleineren Erhöhungen verursacht hat, die wir gesehen haben.

Ich denke, dass die Scans als geplante Aufgaben auch erklären, warum wir gesehen haben, dass der NP-Speicher an das Ereignisobjekt-Tag in PoolMon anstelle des McAfee-spezifischen Tags angehoben wurde. Dies war die Hauptsache, die uns wirklich den Gartenweg entlang führte.

Jetzt, da wir endlich wissen, was die Lecks verursacht, können wir etwas dagegen tun. Es ist unglaublich, dass es so lange gedauert hat, es aufzuspüren.

UPDATE : Nur als letzte Anmerkung. McAfee's wurde am Wochenende aktualisiert und dies hat unser Problem mit nicht ausgelagertem Speicher vollständig gelöst.

UPDATE 2 : Da ich gerade eine Abstimmung dafür erhalten habe, werde ich ein weiteres Update hinzufügen. Ursprünglich schien das Update auf McAfee unser Problem zu beheben, dh wir sehen nicht mehr in regelmäßigen Abständen die massiven Spitzen im NP-Speicher. Ich habe auch festgestellt, dass McAfee seit dem Update anscheinend standardmäßig keine Protokolle mehr in die Ereignisanzeige schreibt, die sich beim aktiven Scannen verbirgt.

Wir sehen jedoch immer noch einen allmählichen Anstieg der NP-Speichernutzung. Es ist an einem Punkt angelangt, an dem wir unseren Server jetzt etwa alle zwei Wochen neu starten müssen. Es ist so schlimm, dass wir kürzlich einen neuen Server erworben haben, in der Hoffnung, dass durch aktualisierte Hardware und Software dieses Problem behoben wird, ABER unser komplett neuer Server, auf dem nur Windows Server 2008, SQL Server 2008 R2 und McAfee installiert sind, zeigte NOCH einen NP-Speicherverlust . Erst nachdem ich McAfee vollständig entfernt hatte, hörte das Leck auf und es blieb statisch, selbst nachdem wir den Server mit all unserer Software in Vorbereitung auf die Umstellung darauf eingerichtet hatten.

Ich habe seitdem gelesen und weiß nicht, ob dies zutrifft, dass das Problem nicht bei McAfee liegt, sondern bei einer von McAfee verwendeten Windows-Routine, die dazu führt, dass NP-Speicher verloren geht. Anscheinend ist die Netzwerkaktivität die Ursache für das Leck, dh mehr Netzwerkaktivität => größere Lecks. Dies scheint mit unserer Erfahrung übereinzustimmen, da sich das Leck verschlimmert hat, da unser Server ausgelastet ist.