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.
