Ursprungligen inskrivet av MBY
[B] Förlåt? För det första förstår du inte vad jag säger eller verkar inte förstå att en file-handle inte är en fil. Jag talar inte heller nödvändigtvis om startmenyn. För det andra, vad menar du med "såga av grenen du sitter på" i samma andetag som att "diskarna stannar är absolut inte något ovanligt"? Vad tusan menar du?
Öppna startmenyn var ett dåligt exempel, det var enbart det jag menade då du blandar in direkt filaccess.
Virtuellt minne är vidare precis vad det låter som, det vill säga "paged pool". Blanda inte ihop det med "virtualisering" som teknik för virtuella maskiner.
Det gör jag inte, dvs blandar ihop det med virtuella maskiner. Det är betydelsen av ordet virtuell och vad det kommit att betyda jag stör mig på. Att använda sig av virtuel som term är missvisande (ur datorsynpunkt), förståligt att det gjordes från början när man faktiskt skapade virtuellt minne i utökningssyfte. Nu för tiden används termen fel eftersom en pagefile inte längre har som enda syfte att utöka ramet (eller om ordet har bytt betydelse, men jag föredrar det förstnämnda). I så fall kunde vi även kalla t.ex. en db fil för virtuell vilket i sin tur skulle göra alla filer virtuella.
Således, själva felet är att hårddisken alltid är en "gren" som inte ska sågas av. Virtuellt minne är en förutsättning för modern minneshantering men ingenting säger att den behöver vara i bruk jämt. HDD1 [D, etc] har inget med saken att göra (om du har pagefilen på systemenheten) och den stannar inte sällan (ej heller ofta) när den ska. Däremot kan datorn mycket väl frysa innan den startar upp.
Stäng av program som läser ifrån disk och låt burken vara så stannar den (om du nu inte stängt av det). Men visst, självklart, använd något på disken och den kommer spinna upp, tex en applikation som tillåts lägga saker i din pagefile och aktivt jobbar.
För övrigt är inte pagefilen i bruk jämnt, bara när den behövs. Dock är det väldigt effektivt och används ofta. Även om pagefilen används och har lås, så betyder inte det att den läses ifrån konstant.
Precis som man skriver ut minnessidor till disk kan man vidare cacha filer, kluster och pekare i RAM. Så görs också. Men om du är erfaren användare av windows märker du att problemet inte riktigt ligger i att man måste adressera lnk-filer på disk utan att redan cachade menuitems är skrivna till pagefilen!
Du får jättegärna komma med mer fakta hurvida cachad fildata är skriven till pagefilen eller inte. Inte så att du menar att burken använder minnet och skickar ut något annat till pagefilen? För mig är det inte ett enda anrop mot pagefilen när jag öppnar start-menyn. Däremot så accessas registret, rättigheter, filsystem, mui-filer etc etc etc etc. Att få OS'et att helt cacha rubbet, dvs även rättigheter, filsystems etc. är... tycker du själv det är rimligt på ett OS som kan hantera fler än en användare lokalt och remote? Fast det kanske det är, men inte vidare stabila saker vi snackar om då.
Cache skriven till pagefilen är idiotiskt, det begriper vem som helst. Ändå sker det. Med windows som stängd kod är det inte lätt att peka ut var, när och varför men man kan samla in fall rent empiriskt.
Varför skulle det vara idiotiskt om cache är skriven till disk? Obehandlad data förstår jag att du tycker skulle vara idiotiskt (dvs en kopiering fyller ju inget större syfte mer än att det skulle ta lite extra pung), men behandlad data är väll helt ok att man lirar över på disken? Eller missförstår jag dig?
Att cacha allt är vanskligt då andra aktiviteter i teorin kan ändra alternativen på disk men är ju dels en måttlig risk väl värd att ta, dels kan operativet givetvis kommunicera sina filehandlers med sig självt och se vilka som är valida och inte (detta kan förutsätta diskaccess till filen men löser ändå problemet med utskrivna cache-pages).
Vilket OS i dagsläget är byggt för att chacha allt? Vi börjar iaf närma oss ramarna för SSD problemen nu =P
Däremot är det inte smart att lägga all data i RAM'et, kommer nog aldrig att vara så länge RAM'et är gone and away när strömmen går.
När du ser hur startmenyns alternativ "run", "help and support", "search" osv ritas upp på skärmen under ett enerverande diskarbete så förstår du att implementationen inte är lysande.
Betyder aboslut inte att det är pagefilen som är problemet.Använd process monitor samtidigt som du övervakar din pagefile så ser du vad som används och inte . En medvetet slö disk kommer självklart att göra systemet slött om du beslutat dig för att köra systemet ifrån disken. Som sagt, inga OS kör helt från ram.
Vidare har andra operativsystem haft dylika idiosynkrasier som har patchats.
Vilka OS, och när patchades dom så man kan läsa mer om problemen?
Ett annat problem är hur tabellen för page-miss och page-hit är uppbyggd. Man kan nästan misstänka att datorn ibland måste kolla på disk för att se om det där finns utskrivna pages! Det senare har jag inga belägg på utan är mer en magkänsla som byggts upp genom decennier av tramsande med windows.
Jo frågan är hur bra den magkänslan är, men intressant att du pressenterar det som fakta. Det är hur lätt som helst att tro men varför inte se efter vad det är?
Däremot skulle jag vilja läsa på lite mer om page-miss och page-hit om du har någon länk till en bra artikel. Skulle vara intressant att se mer om hur det kan påverka en vanlig MS klient i någon större utsträckning.
jag skulle nog kunna sätta en liten slant på om du bråkade lite med systemet (t.ex. slog på pooltags och tog poolsnaps och kolla om något verkar fel där), tog reda på vad som skapar ovannämnda idiosynkrasi (se jag kan också) så skulle du inte skylla på pagefilen (eller igentligen windows) längre.
Får man fråga om du upplever samma problem i 64bitars?
PS. Jag måste helt ärligt säga att jag har inte problemen du upplever och jag bootar nästan aldrig burken hemma.
Däremot upplever jag det på min jobblapptop men det beror på att diskarna i sig är kecka och t.o.m. linux är segt pga diskprestandan. Jag har även upplevt det tidigare men nästan uteslutande när diskarna är dåliga (inte tänkt på det innan). Frågan är vad i övrigt som påverkas av systemet pga sämre diskar, jag skulle tippa på att det du tror är relaterat till pagefile och minneshantering enbart är effekter av något annat. Vi trycker på runt 40-50 användare på 32 bitars windows servrar och övervakar burkarna, både minnesmässigt och övrig prestanda ganska seriöst. Vi borde märkt om det vore ett designfel ganska snart (och alla andra miljoner som kör det). Så olika är inte xp vs. w2k3 eller vista vs. w2k8. Däremot får vi liknande effekter vid minnesläckor (eller page faults, hårda) men det är ju en helt annan historia och helt vårt fel som tillåter skit drivare eller slarviga apps. Däremot behöver vi tweaka både pagepool size och pool usage maximum i prestanda syfte. Vad du skulle kunna testa är att stänga av Paging Executive (se nedan) och se ifall det har någon inverkan men igen så är det bara gissningar. Det finns gott om verktyg för att ta reda på vad som är fel, är det pagefilen som är så extremt använd, varför är den det osv, det är iaf inte by design.
([HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"DisablePagingExecutive"=dword:00000001)
Edit: Kom på en sak. Om jag virtualliserar disken (inte os, bara disken) på en XP maskin och lägger den på en nätenhet, dvs jag streamar OS'et över nätet, då borde vi kunna se hur stor datamängd som används. Lokalt på klienten (i ramet eller på lokal disk) kommer jag spara alla information som OS'et behöver för att fungera och enbart läsa/skriva data över nätet som är nytt eller förändrat. Det borde ge oss en rimlig indikation på hur mycket som skrivs över till disk och när (genom att kolla statistiken på image servern för hur mycket info som är skickat/mottaget), eller tänker jag fel? Borde ju bli bättre än att använda perfmon som själv cachar till disk =P
"You know what's fun to do? Rent an adult movie, take it home, record over it with The Wizard of Oz, then return it so the next guy that rents it is thinking. 'When is this Dorothy chick going to get naked?'"
- Mark Pitta
