windows - hvorfor er ikke låste sider tælles i arbejdsstørrelsen størrelse?

Indlæg af Hanne Mølgaard Plasc

Problem



Formålet med VirtualLock WinAPI-opkaldet er at låse sider ind i arbejdssæt for en proces. Imidlertid tæller WorkingSet64 API uforklarligt disse sider. [8] [9]


Muligvis skyldes hverken Process Explorer eller Standard Task Manager låsede sider i deres per-process-hukommelsesbrugsstatistik. [10] [11]


Hvad er der med dette? Kan nogen, der er fortrolig med den virtuelle hukommelse i WinNT, kaste lys over denne inkonsekvens, hvilket kan medføre, at gigabyte af brugt RAM går i det væsentlige uopdaget? (Tænk på SQL Server eller VirtualBox)

Bedste reference


Åh, det er nemt at forklare: Du bruger den forkerte API. GetProcessWorkingSetSize spørger minimum og maksimale arbejdsstørrelsesstørrelser. Det er kvoter og ikke acutale værdier.


Den mindste arbejdsstørrelse er, hvad Windows vil garantere for at blive låst i RAM, så længe verden ikke slutter. Den maksimale arbejdssætstørrelse er den mængde hukommelse, som Windows tillader din proces, før sider flyttes til puljen (de er ikke nødvendigvis væk, men adgang til dem forårsager en fejl og omlægning).


Du vil have GetProcessMemoryInfo
[12]


EDIT :

Da det nu er klart, at du ikke brugte den forkerte API (kun kaldet den forkerte func), har jeg lavet nogle test (VirtualAlloc og hukommelseskortede filer, både i kombination med VirtualLock) på min XP-system. Ved første øjekast så det ud som om du har det helt rigtigt. At tildele 512 MB eller 512 MB memory mapping ud af en 650 MB-fil, tilføjede 512 MB til den virtuelle størrelse, men øgede ikke arbejdssættet. Følgende med en VirtualLock(512MB) påvirker arbejdssættet overhovedet!


Så skete der for mig, at VirtualLock tog netop nultid i alle tilfælde, hvilket ikke forekom sandsynligt f.eks. for at skulle hente en halv gigabyte fra disken. Så jeg kontrollerede returkoden og gætte hvad. Windows tror ikke, at låsning af 512 MB er en god ide, og vil nægte at gøre det.


Gentag eksperimentet med kun 64 MB, og se, at arbejdssættet straks steg op med 64 MB, lige som det skulle. Så i ét ord: 'virker for mig'.


Bare for at være sikker, har du tjekket returkoden?


På et andet udseende er denne adfærd selv veldefineret og veldokumenteret. Dokumenterne til VirtualLock angiver eksplicit:



  Det maksimale antal sider, der a
  processen kan låse er lig med
  Antal sider i sit minimumsarbejde
  sæt minus en lille overhead.



Med og uden låsning, efter passende indstilling af WS-kvoterne:



VirtualBox er en anden sag, hvad du ser i opgaveadministratoren er kun det arbejdssæt af 'Interface' -programmet og 'Manager' -fronten, som begge vedligeholder arbejdssætstørrelser under 64M til enhver tid. Selv om jeg ikke er sikker på, hvilken hukommelse den måske tildeler i nogle drivere, eller hvis de lader hukommelse overhovedet.


Jeg kører i øjeblikket 2 virtuelle maskiner med hver 1.6 GB hovedhukommelse. Se, hvordan min 32-bit Windows kun ser 3.25 GB, det ville kun forlade 50 MB, hvis hukommelsen tilhørende VM'erne er låst. Process Explorer fortæller desuden mig at Firefox alene har et arbejdssæt på 474 MB og går op, mens jeg skriver dette (hellig ...? !!). Det gør det ikke sandsynligt, at al hukommelse i de virtuelle maskiner virkelig er låst, fordi sådanne figurer ville være helt umulige da.


Som ønsket, er der et skud af VMMap:
Indtast billedbeskrivelse her


Tallene er ganske vist sjove ... VM'en har 1,6 M, hvoraf ifølge VMMap 821MiB er reserveret og 772MiB er forpligtet, henholdsvis Process Explorer viser kun 163MiB og 54MiB. Noget er definitivt fisket der, men jeg formoder, at det nok er noget uklart VirtualBox hackeri snarere end et Windows-problem.