Wel, eerst iets, voor ik een meer gedetailleerd antwoord geef. In uw eerste screenshot staat uw Non-Paged Pool (een soort kernel geheugengebruik) op 1.3GB. Dat lijkt me ongewoon hoog, vooral voor slechts 30 minuten na het opstarten. Ik denk dat ik zou kunnen zien dat NP Pool zo hoog wordt na een lange tijd van gebruik of met een programma dat lekt als een zeef. Daarentegen is mijn NP Pool meestal tussen de 100 en 200 megabytes, en mijn paged pool kan oplopen tot 400 of 500 (en dat is nadat ik mijn systeem wekenlang zonder reboot heb laten draaien).
Je kunt een paar extra kolommen inschakelen in Taakbeheer door rechts te klikken op de kolomkoppen, en te kiezen voor kolommen selecteren. Je zou Working Set (private), Working Set (shared), Commit, en NP Pool moeten toevoegen. Ik zou al uw processen van alle gebruikers scannen, en kijken of een van hen een NP Pool heeft van meer dan ongeveer 256KB. Als u er ziet, vooral als ze aanzienlijk hoger zijn, kan dat de bron van het probleem zijn, of op zijn minst een deel ervan.
Uw totale werkset, de hoeveelheid fysiek geheugen in gebruik door een proces, is de combinatie van de privé en gedeelde werksets (WS). Private is meestal groter voor de meeste processen, maar er kunnen er zijn die een grotere hoeveelheid shared WS gebruiken. De som van de twee zou normaal gesproken de totale WS moeten zijn. Commit is de hoeveelheid van uw werkset die is vastgelegd in de backing store (in de meeste gevallen, het Windows paginabestand). Backgrounded applicaties hebben vaak een grotere Commit dan WS, wat aangeeft dat een groot deel van hun paged pool uit het geheugen is geswapt en in je paging file is gezet (wat vrij normaal is voor desktop apps die geminimaliseerd zijn en een tijdje niet gebruikt zijn).
De Non-Paged Pool is geheugen dat niet kan, en nooit zal, worden uitgewisseld uit het fysieke geheugen … dat is effectief uw permanente minimale fysieke geheugengebruik. NP Pool geheugen bevat vaak programma code en kritische secties die in fysiek geheugen moeten zijn om zich correct of veilig te gedragen, speciale heaps, enz. Van de 60 processen, als ze allemaal 256KB NP Pool-geheugen hebben, dan zou uw absoluut minimum fysiek geheugengebruik ongeveer 15.360KB zijn. In de meeste gevallen hebben één of twee apps een NP Pool van 256KB, terwijl de meeste minder hebben, vaak aanzienlijk minder (of geen). Het is hoogst onwaarschijnlijk dat het systeem ooit alle processen in hun geheel zou pagineren, dus verwacht niet dat het geheugengebruik ooit zo laag zal worden.
Tenslotte, het punt van het hebben van meer geheugen is om te voorkomen dat je gegevens van en naar extended memory space (swap, page file) op een fysieke schijf moet pagineren. Paging is een proces waarbij blokken van toegewezen fysiek geheugen worden verplaatst, waarbij sommige naar schijf worden geduwd, en andere vanaf schijf in het fysieke geheugen worden gebracht. Paging is, om het simpel te houden, zeer ongewenst. Het is niet per se “slecht”, maar het kan de prestaties behoorlijk belemmeren als het te vaak voorkomt. Het uiteindelijke doel van het verhogen van het totale fysieke RAM-geheugen in een systeem is om meer processen in staat te stellen om meer van hun vastleggingen in het fysieke geheugen te bewaren (grotere werkset). Het verbruiken van geheugen is geen probleem, en wanneer meer uitvoerende processen meer geheugen gebruiken, zullen de totale systeemprestaties en de prestaties van actieve processen meestal hoger zijn, omdat de fysieke schijfactiviteit in verband met geheugentoegang (paginafouten, in het bijzonder) lager zal zijn.
Windows beheert het geheugen voor u, en automatisch pagina’s gegevens in en uit het geheugen naar en van de pagina (swap) bestand voor je. Als je een proces draait dat 9 GB geheugen nodig heeft en je systeem gebruikt al 4 GB (van de 12 GB), dan zal het systeem automatisch uitzoeken welke processen niet onmiddellijk toegang hoeven te hebben tot hun hele werkset, en zal het sommige of alle van hun paged pool naar swap pagineren om die extra 1 GB vrij te maken. Als uw grote proces uiteindelijk meer geheugen nodig heeft, zal windows de werkset van andere processen verder verkleinen totdat het genoeg vrije ruimte heeft om het nieuw aangevraagde blok toe te wijzen. Uw grote proces kan uiteindelijk al het beschikbare geheugen verbruiken, behalve NP Pool en misschien wat extra minimale overhead voor periodiek uitvoerende processen die Windows niet toestaan om meer van hun werkset vrij te maken (dat wil zeggen dat ze in afwachting zijn van pagina fouten die Windows anders uit het fysieke geheugen zou swappen, maar omdat ze worden opgevraagd, kunnen ze niet worden verplaatst).
Als een proces meer geheugen nodig heeft dan het mag hebben (32bit processen hebben meestal toegang tot 2Gb, en sommige iets minder dan 4Gb met verbeterde technieken, terwijl 64bit processen meestal toegang hebben tot ongeveer 48Gb geheugen, elk), dan zal windows soms proberen om zijn geheugen te virtualiseren met swap space. Als een 32bit app zijn maximum toegestane 2Gb aan ruimte wil gebruiken, maar er is slechts 1.2Gb beschikbaar, dan zal windows de volledige 2Gb reserveren in de page file, en de eigen data van het proces in en uit de page file verplaatsen als dat nodig is om het geheugengebruik van de app te ondersteunen. Het totale “geheugen”-gebruik kan in dit geval groter lijken dan het beschikbare fysieke geheugen, wanneer men uitgaat van Totaal Vastleggen. Total Commit zal gewoonlijk een maximum bereiken bij de totale grootte van het paginabestand, dat wanneer beheerd door het systeem, gewoonlijk 2-3x de hoeveelheid fysiek geheugen is. In uw geval zou Total Commit ongeveer 24Gb zijn, of 2x uw 12Gb fysieke geheugen (en dit wordt aangegeven in uw eerste schermafdruk, waar staat: Commit (GB) 3 / 23).
Nog een laatste punt. Je zei in je antwoord dat je 16Gb RAM had, terwijl Taakbeheer slechts 12Gb RAM ziet. Een van de twee dingen hier. Of je systeem heeft echt maar 12Gb RAM, of een van je sticks wordt niet goed geregistreerd. Als een stick ram is (ik neem aan 4x 4Gb sticks), dan kan het zijn dat hij slecht is, dat hij niet helemaal goed in je moederbord zit, of dat je moederbord een probleem heeft met de geheugendetectie.
Om te controleren of het dat laatste is, moet je eerst je moederbord BIOS updaten naar de laatste versie. Ik had een soortgelijk probleem… mijn zes Tripple-Channel DDR3 ram sticks (6x 2Gb) waren allemaal goed, gebaseerd op het individueel testen van elke stick… maar mijn moederbord besloot willekeurig om de zoveel tijd een of twee van de sticks niet mee te tellen, waardoor ik vaak maar 8Gb ram overhield. Een BIOS update loste het probleem op, en ik heb nu betrouwbare toegang tot alle 12Gb van mijn geheugen.
