Hallo allerseits, nachdem ich sonst ratlos bin, hoffe ich dass mir vielleicht hier jemand einen tipp geben kann... ich habe beim Kunden einen (virtualisierten) Windows 2016er Server stehen, bei dem der Speicher immer weniger wird. Process Explorer zeigt einen Wert für "Kernel Nonpaged Memory" von knapp 11 GB an, der memory Graph von VMware zeigt einen über die Wochen stetig und konstant steigenden Speicherverbrauch an. Es ist kein "normaler" Speicherverbrauch eines Prozesses; wenn man die zusammenzählt kommt man niemals auf die Summe. Google meint, dieser Effekt wäre auf ein Speicherleck in einem Hardware-Treiber zurückzuführen (deswegen auch "Kernel memory"), und "nonpaged " tut natürlich doppelt weh, weil für die Applikationen immer weniger übrig bleibt. Workaround ist derzeit, regelmäßig den Server am WE neu zu starten, dann ist wieder für 4-6 Wochen Ruhe (aber der Speicherverbrauch steigt wieder kontinuierlich an) Das Witzige ist: Wir hatten vor ca. einem halben Jahr genau denselben Effekt auf einem anderen Server (damals 2012er), wie konnten die Ursache niemals finden, haben uns aber auch nicht mehr wirklich bemüht, da der alte Server ja genau durch den jetzigen ersetzt werden sollte (und mittlerweile ersetzt ist). jetzt haben wir den Salat... Ich wäre für Ideen wirklich sehr dankbar!
Beitrag #5331615 wurde von einem Moderator gelöscht.
Wurden denn Hardwarekomponenten oder Treiber bzw. Einstellungen über Backup oder "Wiederherstellungstools" auf den neuen Server mitgenommen, und es ist ggf. einfach nur der selbe "alte" Fehler?? Irgend ne doofe Software? Und der neue Unterbau "unterstützt" diesen Fehler einfach weiterhin!!???
:
Bearbeitet durch User
Michael R. schrieb: > da der alte Server ja genau durch den jetzigen ersetzt werden sollte Der Speicherfresser sollte einen Namen haben? Bei mir war es eine *.log, die täglich fetter wurde und letztendlich das ganze System bei der Arbeit behinderte. Suche mal die Deine größten Dateien.
Tim S. schrieb: > Wurden denn Hardwarekomponenten oder Treiber bzw. Einstellungen > über > Backup oder "Wiederherstellungstools" auf den neuen Server mitgenommen, > und es ist ggf. einfach nur der selbe "alte" Fehler?? Irgend ne doofe > Software? Und der neue Unterbau "unterstützt" diesen Fehler einfach > weiterhin!!??? Nein, der neue Server wurde komplett "from scratch" neu aufgesetzt. Natürlich läuft (zumindest teilweise) die gleiche Software drauf. Alles was ich über "kernel nonpaged memory" weiss, ist dass es kein Software- bzw. User-Prozess-problem sein sollte... Der Speicher wird auch nicht mehr freigegeben, wenn man so ziemlich alles beendet was so läuft... oszi40 schrieb: > Suche mal die Deine größten Dateien. ich kann mich irren, aber große sollten keinen kernel memory und schon gar keinen nonpaged verbrauchen...
https://www.red-gate.com/simple-talk/sysadmin/general/troubleshooting-nonpaged-and-paged-pool-errors-in-windows/ https://blogs.technet.microsoft.com/markrussinovich/2009/03/10/pushing-the-limits-of-windows-paged-and-nonpaged-pool/ https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/poolmon
Michael R. schrieb: > Nein, der neue Server wurde komplett "from scratch" neu aufgesetzt. > Natürlich läuft (zumindest teilweise) die gleiche Software drauf. Ist es geheim, welche? Sind Virenscanner installiert?
Danke an prx, poolmon.exe ist mal installiert. Gestern Abend wurde der Server neu gestartet, derzeit liegt der Nonpaged pool bei (normalen) 400k... ich denke mit dem poolmon haben wir gute Chancen, den Übeltäter zu identifizieren, wir werden halt ein paar tage warten bis der Verbrauch wieder ansteigt.
Michael R. schrieb: > Das Witzige ist: Wir hatten vor ca. einem halben Jahr genau denselben > Effekt auf einem anderen Server (damals 2012er), wie konnten die Ursache > niemals finden, haben uns aber auch nicht mehr wirklich bemüht, da der > alte Server ja genau durch den jetzigen ersetzt werden sollte (und > mittlerweile ersetzt ist). jetzt haben wir den Salat... Vorweg: ich kenne mich mit Windows überhaupt nicht aus. Aber als erfahrener Systemtechniker würde ich da mal ein paar Fragen ins Blaue stellen: Kann es sein, daß die Software direkt mit Treibern interagiert, und dabei nicht korrekt aufräumt? Das sollte bei einem sauberen Systemkonzept nicht möglich sein und halt ich bei einem aktuellen Windows für ausgeschlossen. Gibt es eventuell ähnliche Hardware und / oder ähnliche Treiber auf beiden Servern? Windows ist mittlerweile recht stabil, so daß ich Memory Leaks im Windows-Kernel mittlerweile sicher ausschließen würde. Gibt es irgendwas Exotisches an Hardware, Treibern, oder Applikation(en)? Was ist der Hypervisor der Virtualisierung? Gibt es irgendwelche Spezialitäten wie Passthrough, PCIe, PCI oder USB?
Sheeva P. schrieb: > Kann es sein, daß die Software direkt mit Treibern interagiert, und > dabei nicht korrekt aufräumt? Nein, zumindest keine von der ich wüsste. Das ist ein "ganz normaler" Applikationsserver, der ~600 Clients bedient, und mit einer SQL-Datenbank (auf einem anderen Server) spricht. nichts hardware-nahes... > Gibt es eventuell ähnliche Hardware und / oder ähnliche Treiber auf > beiden Servern? Jein. Das Ding läuft (mit vielen anderen Servern) auf einem Blade Center, die sind also hardwaremäßig praktisch alle identisch. > Gibt es irgendwas Exotisches an Hardware, Treibern, oder > Applikation(en)? Definiere "exotisch" :-) Aber nein, mir viele nichts ein. Die Art des App-Servers haben wir in (sehr) ähnlicher Konstellation bei fast allen Kunden so laufen, auf unterschiedlichsten Umgebungen (mal virtuell, mal Blech) Sheeva P. schrieb: > Was ist der Hypervisor der Virtualisierung? VMware, das "Große" (also irgendein ESX oder so, da kenn ich mich zu wenig aus, muss mich eigentlich auch nciht interessieren, ich krieg nur einen Server "zur Verfügung gestellt" > Gibt es irgendwelche Spezialitäten wie Passthrough, PCIe, PCI oder USB? Nicht dass ich wüsste. Am alten Server war ein USB-Lizenzdongle über einen USB-to-LAN Adapter (Silex) eingebunden, den hatten wir damals zwar auch im Verdacht, aber der aktuelle Server hat das nicht mehr.
Michael R. schrieb: > VMware, das "Große" (also irgendein ESX oder so, da kenn ich mich zu > wenig aus, muss mich eigentlich auch nciht interessieren, ich krieg nur > einen Server "zur Verfügung gestellt" Wenn bei ESXi die VMware Tools installiert sind, dann gibt es einen "Balloon Driver", der auf Wunsch des Hypervisors bei Speicherknappheit dem Gastsystem Speicher klaut. Allerdings dürfte das kaum in kleinen Häppchen ansteigend erfolgen. Und es lässt sich über die Ressourcen-Statistik in der Management-Oberfläche des ESXi feststellen.
A. K. schrieb: > Wenn bei ESXi die VMware Tools installiert sind, dann gibt es einen > "Balloon Driver", der auf Wunsch des Hypervisors bei Speicherknappheit > dem Gastsystem Speicher klaut. Allerdings dürfte das kaum in kleinen > Häppchen ansteigend erfolgen. Und es lässt sich über die > Ressourcen-Statistik in der Management-Oberfläche des ESXi feststellen. Guter Hinweis, Danke! Dem werden wir nachgehen... aber: soweit ich weiss ist Balooning auf 65% Guest Memory begrenzt, uns fehlt signifikant mehr. Weiters arbeitet Balooning doch nicht mit Nonpaged Kernel memory, oder? Sondern eher mit "ganz normalem" user-memory von der free list, es geht ja nur darum derzeit vom Gast nicht benutzten Speicher dem Host zurückzugeben... korrigiere mich, wenn ich falsch lieg.
:
Bearbeitet durch User
Michael R. schrieb: > Weiters arbeitet Balooning doch nicht mit > Nonpaged Kernel memory, oder? Sondern eher mit "ganz normalem" > user-memory von der free list, es geht ja nur darum derzeit vom Gast > nicht benutzten Speicher dem Host zurückzugeben... korrigiere mich, wenn > ich falsch lieg. Auf diesen Speicher darf durch das Gastsystem in keinem Fall zugegriffen werden. Es darf auch nicht auf die Idee kommen, ihn rauszupagen. Also kommt nur nonpaged memory in Frage. Es geht bei diesem Verfahren darum, den Speicher-Druck an das Gastsystem weiterzugeben. Gastsysteme neigen sinnvollerweise dazu, fast allen Speicher zu nutzen, und sei es als Disk-Dache. Also wird per Balloon Driver Speicher angefordert und das Betriebssystem darf sich überlegen, wo es den herholt. Ob das ungenutzter Speicher ist, reduzierter Disk-Cache, oder was auch immer.
:
Bearbeitet durch User
Michael R. schrieb: > Sheeva P. schrieb: >> Gibt es eventuell ähnliche Hardware und / oder ähnliche Treiber auf >> beiden Servern? > > Jein. Das Ding läuft (mit vielen anderen Servern) auf einem Blade > Center, die sind also hardwaremäßig praktisch alle identisch. Das heißt, der neue Server läuft auf identischer Hardware und ist nur größer dimensioniert? Dann könnte es natürlich irgendeinen Treiber betreffen, der ein Memory Leak hat. Leider (in diesem Fall) kenne ich mich mit Windows nicht gut genug aus, um Tipps zu geben, wie man das debuggen könnte. Ansonsten habe ich aber noch so eine Idee: kann es sein, daß da vielleicht viele Netzwerkverbindungen offengehalten werden? Das Problem kenne ich von einigen Loadbalancern und Firewalls: wenn ein Client die Connection beendet, geben LB oder FW das nicht korrekt weiter, so daß die Verbindung zwischen LB/FW und Server weiterhin bestehen bleibt und dann natürlich serverseitig weiterhin Ressourcen belegt.
> Michael Reinelt (fisa) >Nein, zumindest keine von der ich wüsste. Das ist ein "ganz normaler" >Applikationsserver, der ~600 Clients bedient, und mit einer >SQL-Datenbank (auf einem anderen Server) spricht. nichts >hardware-nahes... Läuft da vielleicht ein Appl-Server-Trace mit? Wenn das File immer weiter wächst, und nie geschlossen wird, wird auch Speicher im nonpaged Pool allokiert. Wenn mich nicht alles täuscht, waren es zu 32bit Zeiten wohl so 4k pro 1MB Filegröße, was aufgrund des limits von 200MB damals dann ein Filesizelimit von einigen 10GB bedeutete, die gleichzeitig offen sein konnten (ich meine nicht einfach offene Files, sondern paar 10GB gelesene Filepages, die evtl. nicht wieder geschlossen werden). Also mal rumgucken, ob da nicht irgendwo irgendein File irgendwo rumliegt, was vom App-Server nach Reboot immer wieder neu beschrieben (oder gescant) wird, und dabei permanent offen bleibt.
Angehängte Dateien:
-
TaskMgr_Mem.png
32 KB -
TaskMrg_CPU.png
37 KB -
Poolmon.png
47 KB -
ProcessExplorer.png
8,5 KB -
McAffee.png
99 KB
So, wir haben grad wieder einen Fast-Stillstand. Das System ist praktisch tot, mit ewigem Warten konnte ich ein paar Screenshots anfertigen... interessanterweise ist das problem diesmal ein etwas anderes: Nonpaged Memory liegt bei (nur) etwa 2 GB, aber der restliche Speicher ist faktisch aufgebraucht. Zufällig bin ich über die Anzeige "Threads" gestolpert, weit über 100.000, was mir dann doch etwas viel vorkommt... Nach 15 Minuten Warten auf den task-Manager war der Übeltäter schnell identifiziert: McAffee, zwei Prozesse mit jeweils grob 85.000 Threads, und 5 bzw. 6 GB Commit Charge. Ist das normal? Kann sich jemand einen Reim darauf machen?
Michael R. schrieb: > Nach 15 Minuten Warten auf den task-Manager war der Übeltäter schnell > identifiziert: McAffee, zwei Prozesse mit jeweils grob 85.000 Threads, > und 5 bzw. 6 GB Commit Charge. Ich habe nicht umsonst gefragt: Icke ®. schrieb: > Sind Virenscanner installiert?
Hallo Leute, ich denke das Problem ist gelöst: Seit der McAfee deinstalliert ist, bleibt auch der NonPaged-Pool recht konstant bei knapp über 300 kB. Der Kunde ist eh begrenzt unglücklich über die Deaktivierung des McAfee: Laut denen ist das mehr Fluch als Segen, die hatten in der vergangenheit immer wieder massivste Probleme mit dem Ding...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.