2015-08-07 04:17:19 +0000 2015-08-07 04:17:19 +0000
82
82

Windows 10, "System"-Prozess nimmt massiv RAM in Anspruch

Seit ich auf Windows 10 aktualisiert habe, verbraucht mein System übermäßig viel RAM

Ich habe ein bisschen gelesen und festgestellt, dass es wahrscheinlich ein Treiber ist, der Speicher leckt. Also besorgte ich mir das Windows Driver Kit und verfolgte die Speichernutzung mit poolmon:

Wie auch immer, ich weiß nicht wirklich, wie ich von hier aus weitermachen soll. Ist das Element mit der Bezeichnung “smNp” der Übeltäter in diesem Problem? Wie kann ich von dort aus vorgehen, um den Treiber tatsächlich zu identifizieren?

Ich habe einiges ausprobiert, z. B. “C:\Windows\System32\drivers>findstr /s smnp .”, aber es hat keine Ergebnisse geliefert. Ich habe auch einen Blick auf die Datei pooltag.txt geworfen und dies ist die Beschreibung, die ich dafür gefunden habe:

Also ja, jede Hilfe wäre willkommen. Vielen Dank im Voraus.

Antworten (4)

93
93
93
2015-08-07 04:20:09 +0000

Ich habe mir xperf-Spuren von mehreren Benutzern angesehen und hier beginnt die Funktion ntoskrnl.exe!SmKmStoreHelperWorker des Kernels, Speicher zu allozieren.

(Zum Vergrößern auf das Bild klicken)

Ich habe dies auf sysinternals entdeckt.

Ich habe bei Microsoft nachgefragt, und die Antwort ist, dass dies absichtlich so ist. Es hängt mit der Komprimierung des Systemspeichers zusammen.

In der Ankündigung von Windows 10 Build 10525 hat Microsoft es ein wenig erklärt :

In Windows 10 haben wir ein neues Konzept im Speichermanager hinzugefügt, das als Komprimierungsspeicher bezeichnet wird und eine speicherinterne Sammlung von komprimierten Seiten ist. Dies bedeutet, dass der Speichermanager, wenn er Speicherdruck spürt, unbenutzte Seiten komprimiert, anstatt sie auf die Festplatte zu schreiben. Dies reduziert die Menge an Speicher, die pro Prozess verwendet wird, und ermöglicht es Windows 10, mehr Anwendungen gleichzeitig im physischen Speicher zu halten. Dies trägt auch zu einer besseren Reaktionsfähigkeit in Windows 10 bei. Der Komprimierungsspeicher befindet sich in der Arbeitsgruppe des Systemprozesses. Da der Systemprozess den Speicher im Speicher hält, vergrößert sich sein Arbeitsset genau dann, wenn Speicher für andere Prozesse verfügbar gemacht wird. Dies ist im Task-Manager sichtbar und der Grund, warum der Systemprozess mehr Speicher zu verbrauchen scheint als frühere Versionen.

Anstatt also Speicherdaten in die Auslagerungsdatei zu schreiben, komprimiert er sie. Und dieser komprimierte Speicher wird im Systemprozess angezeigt.

Microsoft hat auch weitere Details im Inside Hub veröffentlicht. Winbeta hat einen Artikel erstellt der weitere Details enthält.

Anscheinend hat der Grund dafür damit zu tun, dass Microsoft UWP-Apps suspendiert, wenn sie nicht im Vordergrund sind, ganz ähnlich wie bei einigen Smartphone-OS-Verwaltungen. Windows 8-Benutzer verstanden (vielleicht auch nicht), dass Apps, die nicht auf dem Bildschirm waren, nicht ausgeführt wurden, bis der Benutzer wieder zu ihnen wechselte. Der “Alles-oder-Nichts”-Ansatz wird mit Windows 10 aktualisiert, indem eine Schicht zwischen der Auslagerungsdatei und der normalen Auslagerungsaktivität eingeführt wird. Jetzt bestimmt MM bei Speicherproblemen, welche Seiten in die modifizierte Liste verschoben werden sollen, und zwar in einem Prozess, der Trimming genannt wird.** Die modifizierte Liste ist eine sekundäre Liste von Auslagerungsdateien, die eine Liste von Standby-Auslagerungsdateien sichert. Eine Sicherungsliste wird für den Fall erfasst, dass ein anderer Prozess Speicher aus der Standby-Liste zurückfordert und der ursprüngliche Prozess nach seiner Seite sucht. Anstatt alles oder nichts zu tun, komprimiert Windows 10 MM unbenutzte Seiten, anstatt sie auf die Festplatte zu schreiben. Da weniger geschrieben wird, sollte das Ergebnis weniger Festplattenoperationen sein - dank der Komprimierung - und es können nun mehr Daten im Speicher abgelegt werden.

Laut dem Windows-Team, “ in der Praxis nimmt der komprimierte Speicher etwa40% der unkomprimierten Größe ein, und als Ergebnis eines typischen Geräts, das eine typische Arbeitslast ausführt, schreibt Windows 10 Seiten nur 50% so oft auf die Festplatte wie frühere Versionen des Betriebssystems. ” Wenn alles nach Plan läuft, könnten Windows-Benutzer kürzere Wartezeiten für alle Geräte sowie eine längere Lebensdauer auf Systemen erleben, die Flash-basierte Festplatten haben.

Dekomprimierung ist auch etwas, das Windows 10 gut machen soll. Windows 10 nutzt die Kombination aus Parallelisierbarkeit und sequenziellem Lesen, um einmal aufgerufene Seiten im Speicher zu erzeugen. Die neue Dekomprimierung sollte zu einem schnelleren Erlebnis führen, da Windows 10 die Daten gleichzeitig dekomprimiert und sie parallel mit mehreren CPUs liest. Ältere Windows-Versionen haben sich aufgrund der Übertragungsraten zwischen den Festplatten möglicherweise träge angefühlt.

Microsoft hat auch ein Video auf Channel9 veröffentlicht, das das Feature erklärt.

Speicherkomprimierung in Windows 10 RTM https://channel9.msdn.com/Blogs/Seth-Juarez/Memory-Compression-in-Windows-10-RTM

In diesem Video hat Mehmet Iyigun einige Zeit damit verbracht, zu diskutieren, warum der Systemprozess in Windows 10 etwas mehr Speicher benötigt und warum das eine gute Sache ist. Ein Prozess, der mehr Speicher beansprucht, hört sich nach einer schlechten Sache an - das heißt, bis ich mehr über Speicherverwaltung, Paging und Hard-/Soft-Page-Fehler verstanden habe. Es stellte sich heraus, dass das Betriebssystem einige clevere Optimierungen vornimmt, die es den Prozessen erlauben, einen Teil des Speichers abzuschneiden, ihn aber nicht unbedingt auf die Festplatte auszulagern. Der Speicher bleibt nicht nur im RAM erhalten, sondern wird auch komprimiert, wodurch harte Auslagerungsfehler seltener vorkommen. Das Ergebnis sollte für ein schnelleres Arbeiten sorgen.

In den letzten TH2-Builds hat Microsoft die Beschreibung im Task-Manager aktualisiert und zeigt nun auch an, dass der SYSTEM-Prozess das compressed memory hostet:

, um Verwirrungen über die “hohe” Nutzung zu vermeiden.

Im Window 10 Anniversary Update, das im August 2016 veröffentlicht wurde, hat Microsoft die Komprimierung in einen Pseudo-Prozess namens Memory Compression extrahiert, um die Benutzer nicht mehr zu verwirren, warum SYSTEM einen so hohen Speicherverbrauch hat:

Aber es sieht so aus, als ob Taskmgr diesen Prozess nicht anzeigt, nur ProcessExplorer/ProcessHacker sind in der Lage, ihn anzuzeigen. Der Taskmgr zeigt die Menge des komprimierten Speichers nur in der Übersicht an:

Wenn Sie mit dem Mauszeiger über das Diagramm des verwendeten Speichers im Taskmgr fahren, sehen Sie einen Tooltip, der die Menge der komprimierten Daten anzeigt.

In dieser Demo werden 388MB auf 122MB komprimiert, so dass 267MB durch die Komprimierung eingespart werden.

13
13
13
2015-08-09 23:24:30 +0000

Indem Sie in services.msc gehen (über Win+R) und Superfetch deaktivieren, wird dies vollständig gelöst. Ich bin mir nicht sicher, ob Superfetch ab jetzt einfach nur kaputt ist oder ob es “by design” ist.

Außerdem hat das Entfernen der Auslagerungsdatei offenbar den gleichen Effekt, aber die obige Lösung ist sicherer.

0
0
0
2019-08-31 16:21:39 +0000

Ich habe einen Ausreißer gefunden, der eine hohe Systemspeichernutzung verursacht, und wollte ihn einfügen, falls diese Information jemandem nützt.

Wenn Sie Microsofts Volume Snapshots (den Software-Snapshot, nicht den Hardware-Snapshot) stark nutzen, verbraucht das System umso mehr RAM, je mehr Snapshots Sie in Kombination mit großen Datenänderungen behalten.

Normalerweise ist die Menge an RAM, die für Volumen-Snapshots verwendet wird, gering und wird nicht bemerkt, es sei denn, Sie haben ein riesiges Volume (z. B. 64 TB) mit Multi-Terabyte-Deltas zwischen den Snapshots. Standardmäßig löschen sich Snapshots einfach selbst, wenn die Schreib-IOs zu hoch werden, aber es gibt Möglichkeiten, das zu verhindern, wodurch Sie massive Deltas erreichen können.

Unten sehen Sie einen Extremfall, in dem der Systemprozess eines Servers 13 GB RAM verwendet. Dieser Server hat nur zwei Volumen-Snapshots, die im Abstand von 15 Tagen erstellt wurden, wobei zwischen jedem Snapshot etwa 10 TB an Daten geschrieben wurden.

Der obige Systemprozess war zuvor mit 24 GB belegt, und die folgenden drei Verhaltensweisen wurden beobachtet:

  1. Nach einem Neustart und der erneuten Anmeldung blieb das System für eine gewisse Zeit bei einem leeren Bildschirm hängen, bis der Desktop erschien.
  2. Während dieses Hängens zeigte das Aufrufen des Task-Managers (CTRL-SHIFT-ESC), dass die Systemspeichernutzung anstieg.
  3. Während dieses Hängers führte die Festplatte mit den Datei-Überblicken eine Menge Lesevorgänge aus, die nicht im Leistungsmonitor angezeigt wurden. Da die Festplatte jedoch iSCSI nutzte, zeigte die Netzwerkkarte einen stetigen Lesestrom von etwa 200 Mbps.

Ich vermutete Volumen-Snapshots, also versuchte ich, den ältesten Snapshot zu löschen, was die Speichernutzung des Systems sofort von 24 GB auf 13 GB senkte.

Unter diesen Umständen kann dies ein normales Verhalten sein, obwohl ich dies nicht mit Microsoft bestätigt habe. In der Zwischenzeit werde ich diesem Server zusätzliche 32 GB RAM hinzufügen, um den Snapshot-Overhead zu bewältigen.

(Hinweis: Dies ist ein hochvolumiger Backup-Server mit Windows 2016 und einem angeschlossenen 64 TB SSD iSCSI-Laufwerk. Er verwaltet durchschnittlich drei Volume-Snapshots zu jeder Zeit, wobei alle 15 Tage ein neuer Snapshot erstellt wird. Zwischen den einzelnen Snapshots werden etwa 10 TB an Daten geschrieben).

-1
-1
-1
2015-08-20 11:08:59 +0000

Deaktivieren Sie den Prefetcher im Regedit-Schlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters Sie haben wahrscheinlich Enable Prefetcher auf einem Wert von 2 oder 3, also ändern Sie ihn in 0

Als nächstes müssen Sie Superfetch in den Diensten deaktivieren

  1. Suchen Sie nach services.msc

  2. Finden Sie superfetch klicken Sie auf properties und beenden Sie den Dienst ebenfalls.

Ich mache diese Schritte und wenn ich spiele und den PC normal benutze, verbraucht der disabled Prozess nur 28k