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

Windows 10, 'Systeem'-proces neemt enorme hoeveelheden RAM in beslag

Sinds ik een upgrade naar Windows 10 heb uitgevoerd, verbruikt mijn systeem buitensporig veel RAM-geheugen

Ik heb wat gelezen en ben tot de conclusie gekomen dat het waarschijnlijk een stuurprogramma is dat geheugen lekt. Dus heb ik de Windows Driver Kit aangeschaft en het geheugengebruik bijgehouden met poolmon:

Echter, ik weet niet echt hoe ik nu verder moet gaan. Is het item met de tag “smNp” de boosdoener in dit probleem? Hoe ga ik vanaf daar verder met het identificeren van de driver?

Ik heb wat dingen geprobeerd zoals “C:Windows:Systeem32:Drivers:>findstr /s smnp .” maar dat leverde geen resultaten op. Ik heb ook gekeken naar het pooltag.txt bestand en dit is de beschrijving die ik ervoor vond:

Dus ja, alle hulp zou gewaardeerd worden. Bij voorbaat dank.

Antwoorden (4)

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

Ik heb gekeken naar xperf sporen van verschillende gebruikers en hier begint de functie ntoskrnl.exe!SmKmStoreHelperWorker van de Kernel geheugen toe te wijzen.

(Klik op afbeelding om te vergroten)

Ik ontdekte dit op sysinternals .

Ik heb Microsoft er naar gevraagd en het antwoord is dat dit een ontwerp is. Het heeft te maken met systeemgeheugencompressie.

In de aankondiging van Windows 10 Build 10525, legde Microsoft het een beetje uit :

In Windows 10 hebben we een nieuw concept toegevoegd in de Memory Manager genaamd een compressie store, dat is een in-memory collectie van gecomprimeerde pagina’s. Dit betekent dat wanneer Memory Manager geheugendruk voelt, het ongebruikte pagina’s zal comprimeren in plaats van ze naar schijf te schrijven. Dit vermindert de hoeveelheid geheugen die per proces wordt gebruikt, waardoor Windows 10 meer toepassingen tegelijk in het fysieke geheugen kan houden. Dit zorgt ook voor een betere respons in Windows 10. De compressieopslag bevindt zich in de werkset van het systeemproces. Omdat het systeemproces de opslag in het geheugen bewaart, wordt zijn werkset groter precies op het moment dat geheugen beschikbaar wordt gemaakt voor andere processen. Dit is zichtbaar in Taakbeheer en de reden dat het Systeem proces meer geheugen lijkt te gebruiken dan vorige versies.

Dus in plaats van geheugengegevens naar het pagefile te schrijven, comprimeert het ze. En dit gecomprimeerde geheugen wordt getoond in het System proces.

Microsoft heeft ook meer details gepost in de inside hub. Winbeta heeft een artikel gemaakt ](http://www.winbeta.org/news/microsoft-educates-insiders-windows-10-handles-memory) dat meer details bevat.

Blijkbaar had de reden hiervoor te maken met het feit dat Microsoft ervoor koos om UWP apps op te schorten als ze niet op de voorgrond stonden, erg vergelijkbaar met het beheer van sommige smartphone OS. Windows 8-gebruikers begrepen (misschien niet) dat als apps niet op het scherm stonden, ze niet werden uitgevoerd totdat de gebruiker er weer naar overschakelde. De ‘alles of niets’-benadering wordt bijgewerkt met Windows 10 dat een laag introduceert tussen het pagefile en de normale paging-activiteit. Bij problemen met de geheugendruk bepaalt MM nu welke pagina’s naar de gewijzigde lijst moeten worden verplaatst in een proces dat trimmen wordt genoemd. De gewijzigde lijst is een secundaire lijst van pagefiles die een back-up vormt van een lijst met stand-by pagefiles. Een back-up lijst wordt vastgelegd voor het geval geheugen wordt teruggehaald van de stand-by lijst door een ander proces, en het oorspronkelijke proces komt op zoek naar zijn pagina. In plaats van alles of niets zal Windows 10 MM ongebruikte pagina’s comprimeren in plaats van ze naar schijf te schrijven. Met minder schrijven zou het resultaat minder schijfbewerkingen moeten zijn - dankzij de compressie - en nu kunnen er meer gegevens in het geheugen worden opgeslagen.

Volgens het Windows-team “ In de praktijk neemt gecomprimeerd geheugen ongeveer 40% van de ongecomprimeerde grootte in beslag, en als gevolg van een typisch apparaat dat een typische werkbelasting uitvoert, schrijft Windows 10 pagina’s slechts 50% zo vaak weg naar schijf als vorige versies van het OS.” Als alles volgens plan verloopt, Windows-gebruikers zouden kortere wachttijden voor alle apparaten kunnen ervaren, evenals een langere levensduur op systemen die flash-gebaseerde harde schijven hebben.

Decompressie is ook iets waarvoor Windows 10 is ontworpen om het goed te doen. Windows 10 maakt gebruik van de combinatie van parallelliseerbaarheid en sequentiële leest om pagina’s in het geheugen te produceren zodra ze worden aangeroepen. De nieuwe decompressie zou moeten resulteren in een snellere ervaring omdat Windows 10 tegelijkertijd gegevens decomprimeert en parallel leest met gebruik van meerdere CPU’s. Oudere versies van Windows kan hebben gevoeld traag als gevolg van de overdrachtssnelheden tussen de schijf.

Microsoft heeft ook een video uitgebracht op channel9 waarin de functie wordt uitgelegd.

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

In deze video bespreekt Mehmet Iyigun waarom het Systeemproces in Windows 10 een beetje meer geheugen inneemt en waarom dat goed is. Een proces dat meer geheugen inneemt klinkt als een slechte zaak - dat is totdat ik meer begreep over geheugenbeheer, paging, en hard / soft page fouten. Het blijkt dat het OS een aantal slimme optimalisaties uitvoert die het mogelijk maken dat je processen een deel van het geheugen innemen, maar het niet noodzakelijkerwijs op schijf hoeven te plaatsen. Het geheugen blijft niet alleen bewaard in RAM, maar wordt ook gecomprimeerd - waardoor hard page faults minder vaak voorkomen. Het resultaat zou een snellere ervaring moeten zijn.

In de laatste TH2 Builds heeft Microsoft de beschrijving in het taakbeheer bijgewerkt en laat nu ook zien dat het SYSTEM proces de compressed memory host:

om verwarring over het “hoge” gebruik te voorkomen.

In de Window 10 Anniversary Update die in augustus 2016 werd uitgebracht, haalde Microsoft de Compressie eruit in nu getoond in een pseudo proces genaamd Memory Compression om gebruikers niet langer te verwarren waarom SYSTEM zo'n groot geheugengebruik heeft:

Maar het lijkt erop dat Taskmgr dit proces niet laat zien, alleen ProcessExplorer/ProcessHacker zijn in staat om het te laten zien. De Taskmgr toont alleen de hoeveelheid gecomprimeerd geheugen in het overzicht:

Als je met de muis over de gebruikte geheugengrafiek in Taskmgr gaat, zie je een tooltip die de hoeveelheid gecomprimeerde data laat zien.

In deze demo is 388MB gecomprimeerd tot 122MB, dus 267MB wordt bespaard door de compressie.

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

Door naar services.msc te gaan (via Win+R) en Superfetch uit te schakelen is dit helemaal opgelost. Ik weet niet zeker of Superfetch vanaf nu gewoon kapot is of dat het “by design” is.

Bovendien, blijkbaar heeft het verwijderen van de paging file hetzelfde effect, maar de bovenstaande oplossing is een veiliger gok.

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

Ik heb een uitzonderlijk geval gevonden dat een hoog geheugengebruik van het Systeem veroorzaakt, en ik wilde het toevoegen voor het geval dat deze informatie iemand ten goede komt.

Als je veel gebruik maakt van Microsoft’s Volume Snapshots (de software snapshot, niet de hardware snapshot), hoe meer snapshots je houdt in combinatie met grote data veranderingen, dan zal System meer RAM verbruiken.

Normaal gesproken is de hoeveelheid RAM die gebruikt wordt voor Volume Snapshots klein en zal niet opgemerkt worden, tenzij je een gigantisch volume hebt (b.v. 64 TB) met multi-terabyte delta’s tussen snapshots. Standaard zullen snapshots zichzelf verwijderen als de schrijf IO’s te hoog worden, maar er zijn manieren om dat te voorkomen, zodat je enorme delta’s kunt bereiken.

Hieronder zie je een extreem geval van een server’s System proces dat 13GB RAM gebruikt. Deze server heeft slechts twee Volume Snapshots, 15 dagen na elkaar genomen, met ongeveer 10 TB aan data weggeschreven tussen elke snapshot.

Het System proces hierboven zat eerder op 24GB gebruik, en de volgende drie gedragingen werden waargenomen:

  1. Na een reboot en het opnieuw inloggen bleef het systeem een tijd op een leeg scherm hangen tot het bureaublad verscheen.
  2. Tijdens dit hangen toonde het oproepen van Taakbeheer (CTRL-SHIFT-ESC) een groeiend gebruik van het systeemgeheugen.
  3. Tijdens deze hang, heeft de schijf met de Volume Snapshots veel gelezen, wat niet te zien was in Performance Monitor. Maar omdat de schijf iSCSI gebruikte, toonde de netwerkkaart een gestage leesstroom rond de 200 Mbps.

Ik vermoedde Volume Snapshots, dus probeerde ik het oudste snapshot te verwijderen, waardoor het geheugengebruik van het systeem onmiddellijk van 24 GB naar 13 GB daalde.

Onder deze omstandigheden kan dit normaal gedrag zijn, hoewel ik dit niet met Microsoft heb bevestigd. In de tussentijd zal ik een extra 32 GB RAM aan deze server toevoegen om de Snapshot overhead aan te kunnen.

(Opmerking: dit is een hoogvolume back-upserver waarop Windows 2016 draait met een 64 TB SSD iSCSI-schijf aangesloten. Het onderhoudt een gemiddelde van drie volume snapshots op elk gegeven moment, met een nieuwe die elke 15 dagen wordt gemaakt. Er wordt ongeveer 10 TB aan gegevens weggeschreven tussen elke snapshot).

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

Schakel prefetcher uit in regedit key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters je hebt waarschijnlijk Enable Prefetcher op een waarde van 2 of 3 dus verander het in 0

Vervolgens moet je Superfetch uitschakelen in services

  1. Zoek naar services.msc

  2. Zoek superfetch klik op properties zet het dan op disabled en stop de service ook.

Ik doe deze stappen en wanneer ik aan het gamen ben en normaal PC gebruik en het system proces gebruikt slechts 28k