Vi blev spurgt om det, og derfor syntes vi, vi ville skaffe nogle svar, og når vi siger 'nogle', så mener vi faktisk alle svarene. Det er et af de spørgsmål, der stikker sit grimme hoved op et par gange om året, alle laver en eller anden form for gryntelyd, ingen rigtige konklusioner nås, og alt bliver glemt om det, indtil det næste forvirrede offer spørger forfra igen.

Spørgsmålet var omkring Windows' swapfil, også kaldet sidefilen, alias virtuel hukommelse. Hen over årene har vi hørt alle de såkaldte bedste metoder: Ingen swapfil, fast swapfil, systemhåndteret fil, på hovedpartitionen, på sin egen partition, dobbelt så stor som systemhukommelsen, tre gange så stor som systemhukommelsen, fragmenteret, defragmenteret, det er værre end at vide, hvordan man kysser en pige for første gang.

En væsentlig grund til alt dette er den historiske måde, Microsoft har håndteret emnet på og implementeret virtuel hukommelse i Windows. Det faktum, at så mange mennesker kalder den det forkerte, vidner i sig selv om, hvor slemt misforstået emnet er, særligt når du tænker på, at virtuel hukommelse har været implementeret i Windows siden version 3.0 og har været omkring langt længere end det i beregningsverdenen.

Vi besluttede så, at det var på tide, at vi tog et omfattende kig på alle de forskellige scenarier og fandt ud af hvilket, om noget, der faktisk er optimalt. Undervejs vil vi lære en masse, og som vi vil se, vil vi finde på nogle ret ukendte løsninger, som er utroligt hjælpsomme med andet end bare det ene mål at optimere sidefilen.

Tilgang til sidefilen bliver ret hektisk når først det bliver knapt med hukommelsen.

Så uanset om du tror, du ved det hele, eller om du aldrig har hørt om en sidefil før, så tror vi, at du vil lære noget nyt hen ad vejen. Fra hvordan man bedst sætter sin sidefil op, og hvordan man undgår de sædvanlige faldgruber, til nogle fascinerende tricks, som bare er enormt bekvemme at kende til.

Når nogen nævner swapfil eller sidefil for dig, hvad taler de så om? Altså, teknisk set har Windows 9x en WIN386 swapfil, mens Windows NT/2000/XP/Vista/7 bruger en SIDEFILs fil. Du kan nok se, hvorfor de to fraser bruges på skift.

Forvirringen slutter dog ikke her. Alt dette er forbundet til Windows' virtuelle hukommelsessystem, som er, hvad vi virkelig taler om her. Virtuel hukommelse gør et operativsystem i stand til at virtualisere det fysiske hukommelsesområde til et andet lagringsmedie, sædvanligvis en harddisk. For at gøre dette, skal både operativsystemets kerne og processoren understøtte funktionen. For over 20 år siden var dette måske ikke et problem, men sådan er det ikke i dag.

Hele pointen er, at når et program spørger efter en hukommelsesblok, så tror det, at det får en blok rigtig hukommelse. I virkeligheden kunne kun en del, eller intet, af dette være 'rigtigt' med resten gemt midlertidigt virtualiseret på harddisken. Hvis et program spørger efter hukommelse, der er gemt væk i denne virtuelle verden, bliver en 'sidefejl' genereret, den virtuelle hukommelse bliver byttet om med rigtig hukommelse i klumper kaldet 'sider', og alting fortsætter.

Ups. Undskyld 32bit brugere, I hænger på 4GB hukommelse, faktisk mindre.

Den vigtigste grund til, at dette er en hjælpsom ting, kan findes tilbage, da mængden af rigtig hukommelse, en processor kunne tilgå, var begrænset til kun megabytes. Det virtuelle hukommelsessystem arbejder typisk med sider på 4k, som bliver byttet ind og ud af den rigtige hukommelse som et hele.

Dette satte en processor, som var begrænset til bare 4MB rigtig fysisk hukommelse, i stand til at adressere potentielt gigabytes af virtuel hukommelse, selvom datalageret var på en harddisk. Selv i dag kan systemer med 2GB hukommelse nemt have brug for virtuel hukommelse, og når størstedelen af mennesker kører 32bit versioner af Windows, så er 4GB det praktisk tilgængelige fysiske hukommelse.

Selvom dette er meget hukommelse, så kan det, at køre krævende programmer, såsom en e-mailklient, produktivitetssuite, billedredigeringssoftware, viruskontrol og så videre, gøre, at systemet stadig kan løbe tør for fysisk hukommelse.

Så, når virtuel hukommelse stadig er relevant, selv for computere med 4GB fysisk hukommelse installeret, står det oprindelige spørgsmål stadig ved magt: Hvad er den bedste konfiguration til din Windows sidefil, hvis du overhovedet behøver en? Planen her er at teste en hel række af scenarier, nogle af dem typiske og andre knapt så almindelige, for at afdække den optimale konfiguration til dig.

Vores første problem er, hvordan man lige tester og benchmarker swapfilen. Vi vil teste en hel række af situationer fra 1GB-installationer til 6GB-installationer. Det betyder en 64bit Vista-installation for at holde alting konsistent. Da vi behøver en lavhukommelses-situation, vil vi basere det på en 1GB Windows Vista installation.

For at benchmarke dette har vi brug for noget, der kræver en stor blok hukommelse og så manipuleret data. For at gøre dette kører vi en benchmark, som skaber en stor billedfil i hukommelsen, og så manipulerer vi billedet på forskellige måder, fra ganske enkelt at scrolle i det og flytte på det til at rotere det. Vi tager tid på, hvor lang tid det tager at fuldføre hvert stadie og får resultater på færdiggørelse af læsning og skrivning af billedet og roteringshastighed taget i sekunder og MB/s alt efter operationen.

Du har måske opdaget noget her, er dette ikke bare en drevhastighedstest? Tjah, ja og nej. Vi tester swapfilens hastighed her, og det er tilfældigvis sådan, at den er afhængig af hastigheden på det medie, den er gemt på, men den måde swapfilen er gemt på, spiller stadig en rolle, lige så meget som hvad den er gemt på.

Til testrummet!

Til at begynde med har vi brug for en kontrol, og det bliver en standard Windows Vista 64bit installation med en håndteret sidefil, alt sammen kørende fra den samme partition på et Hitachi 250GB Deskstar drev. Vi vil blot installere operativsystemet, opdatere driverne og lade Windows håndtere sidefilen på en hvilken som helst måde, den finder passende.

Med bare 1GB hukommelse laver systemet en 1,3GB sidefil og i hvile bruger det omkring 660MB af sidefilen, med den smule der faktisk kører. Tjekker man op på filen, er den allerede delt i to fragmenter. Under benchmarkbetingelser øges sidefilen til 3,2GB og er nu fragmenteret til fem dele, og husk at dette er på en ren 250GB installation, så der er hundreder af gigabytes tom plads at bruge. Du kan forestille dig, hvordan fragmentering, på et drev ude i det virkelige liv, kunne blive langt værre over tid, efterhånden som disponibel ledig plads bliver begrænset.

Dette er den første, af hvad der er de konventionelle ’roterende skive' test, og alt i alt er det, hvad vi ville forvente, at langt størstedelen af folk vil køre. De næste fire tests er alle baseret på forskellige variationer omkring enkelt- og dobbeltdrevkonfigurationer.

Den mest nærliggende første test er at køre en brugerdefineret sidefil med fast størrelse, det er denne mulighed, der har det med at være den mest favoriserede af folk, og tanken bag giver god mening; at lave en sidefil med fast størrelse, når Windows først er installeret, eliminerer risikoen for fragmentering, så det giver en optimal fortløbende fil. Hvis du gør denne stor nok, så er der ingen rigtig bagside, bortset fra at du mister et par gigabyte drevplads.

Vores næste scenarie kører lidt i samme spor, men gør det med en sidefil, der er gemt på sin egen partition på samme drev. Dette er blevet foreslået som en optimal løsning, men det har været pointeret, at det unødigt opmuntrer overdreven brug af drevets læsehoved.

Den bedste måde at gemme din sidefil på er i en enkelt, defragmenteret tilstand.

Det betyder jo, at den ender op med, at sidefilen fysisk flyttes fra det arbejdende datasæt. Dette lyder i al fald rigtigt for os, vi kan forestille os visse situationer, hvor det ville være fint med store fortløbende skrivninger og læsninger i sidefilen, men i det virkelige liv kunne vi forestille os, at dette mindre er tilfældet, særligt når det kommer til multiopgavekørsel. Desværre er dette et område, som vores benchmark ikke vil teste særlig stærkt, men vi kan se, hvordan den yder under massiv enkeltstående belastning af hukommelsen.

Det fjerde scenarie kører sidefilen fra en sekundær SATA harddisk. Før du griber til våben, så er det en lignende 250GB 7.200rpm Hitachi Deskstar lavet inden for seks måneder af det andet drev, så rå ydelse burde være meget tilsvarende.

I øvrigt kører vi en brugerdefineret sidefil med fast størrelse ligesom i de andre scenarier. Vi ville forvente ydelsen her til at være blandt de bedste af de ’roterende disk’ test, da den dedikerede SATA-linje vil hjælpe til at eliminere overdreven læsning på drevet forårsaget af, at sidefilen og systemadgang til drevet er delt. Dette fører til det endelige scenarie, der er med mere som en intellektuel test.

Vi var interesserede i at se, om det at køre to sidefiler over to drev gjorde Windows i stand til at yde nogen form for intelligent cacheing eller endda RAID-agtigt spænd. Hvis den balancerer lagring op mod ledig tilgangskapacitet, kunne det tilbyde nogle fordele, og Microsoft Knowledge Base artiklen ser ud til at hentyde til den slags praksis.

Et solidt svar

Efter at have testet er vi glade for at se, at ganske rigtigt ydede vores foretrukne sidefil med brugerdefineret fast størrelse i hvert fald godt. Til vores overraskelse ydede den en smule bedre end det dedikerede drev i nogle tests, men den blev overhalet i andre af det dedikerede; det mest påfaldende var lagringstesten. Bortset fra det fuldførte den en række tests 20 til 25 sekunder hurtigere end den håndterede mulighed.

Den store overraskelse er, at den delte sidefil var den, der faktisk ydede bedst alt i alt. Som forventet var den mindst lige så god som på det dedikerede drev i de fleste tilfælde, men i andre trak den sig langt foran de brugerdefinere og dedikerede drev-muligheder.

Selvom vi ikke har nogen direkte grund til, hvorfor det skulle være sådan, så nævnede vi, at Microsoft hentyder til det faktum, at Windows intelligent fordeler byrden hen over flere sidefiler, alt efter hvilke drev der bliver brugt mindst. Uanset om det bliver gjort historisk eller i farten, ser det ud til, at noget virker, og for størstedelen af brugere kunne vi forestille os, at det er den bedst mulige og mest opnåelige løsning.

Hvor meget vi end elsker vores roterende harddisk-venner og deres forkærlighed for at gemme groteske mængder af video i alle dens mange kødfulde former, så er de stadig pokkers langsomme. De spejlende, roterende overflader ser måske nok skinnende og attraktive ud, men kom for tæt på og den gruopvækkende erkendelse, at deres tilgangstider kan måles i geologiske tider, gnaver i vore sjæle lige så meget som vores egne spejlede, fortrukne ansigter.

Selvom de stadig er dyre sammenlignet med ’roterende plader’, så kan du i hvert fald sagtens få fat i 32GB solid state diske for under 1.000 kroner nu, og endda de nyere 80GB drev sniger sig ind i 2.000 kroners prisgruppen. Dette sætter klart en solid state drevløsning inden for de fleste mennesker økonomiske rækkevidde. Spørgsmålet er, hvilken indflydelse denne teknologi har på sidefilsydelsen.

Vi besluttede at køre to scenarier, da vi allerede havde fastslået, at en brugerdefineret fast sidefil er vejen frem. De to muligheder, vi vil teste, er med en fuld Windows-installation og som et almindeligt drev med en fast sidefil på det.

Som man kunne håbe, så undertrykker moderne solid state arkitektur effektivt mekaniske drevs tilfældighed og giver i de fleste tilfælde den dobbelte ydelse, med en halvering af de fleste tider og en tredobling af gennemløbsmængden på scroll-testen.

Som man også kunne forvente, tilbød den dedikerede driver-mulighed også en smule forbedret ydelse, selvom solid state tilgangessystemets rene og skære effektivitet betød, at Windows’ håndterede fil var næsten lige så effektiv.

Hukommelse i stakkevis

Vi kommer endelig til det scenarie, vi har set en masse mennesker med en anselig mængde ram agitere for: Slå virtuel hukommelse fra og afskaf sidefilen. Hvad vi gerne vil vide, er, hvor god en ting, det faktisk er!

For at besvare disse sidste spørgsmål, kigger vi på et højhukommelsessystem, og det involverede at installere 6GB hukommelse i vores 64bit-system. Tydeligvis vil det hurtigste scenarie være det, der kører helt uden sidefil, ikke? Det lader ikke til det. Ved et tilfælde efterlod vi faktisk sidefilen oppe og kørte en benchmarkcyklus.

Da vi opdagede vores fejl, kørte vi testen igen uden sidefilen og opdagede, at den var langsommere. Kun lidt langsommere, men dog langsommere. Under alle omstændigheder er resultaterne stadig forbløffende med hensyn til hastighedsforøgelsen over enhver afhængighed af at bruge sidefilen, det er en 10-dobbelt reduktion i ventetid og en 40-dobbelt vækst i gennemløb over de roterende diske.

Igen, mere ud fra interesse end nogen praktisk løsning, skabte vi et 5GB ram drev og lavede en fast sidefil i dette for at se hvilke slags omkostninger, det ville pålægge. Det omtrent halverede gennemløbshastigheden, hvilket viser, at der er noget af en omkostning ved bare at køre sidefilen, men i sammenhæng med de langsomme drev den normalt er gemt på, er det sædvanligvis ikke et problem.

Her ser vi PCMark opgive, når sidefilen er slået fra.

Hvad har vi så lært? Tydeligvis er det en fremragende ting at have meget hukommelse, så hvis du kan eliminere Windows behov for at bruge sidefilen vil dit liv blive meget forbedret. Ikke at have nogen sidefil kan, selv om det måske ser smart ud på overfladen, gøre ting en lille smule langsommere, og hvis du nogen sinde rammer en lavhukommelses-situation, vil det skabe problemer.

Sidefilen bruges også som et dumpområde, hvis der sker et systemnedbrud, og at slå den fra fjerner den egenskab. Vi kan se, at enhver med en solid state disk vil klare det fint enten med en håndteret eller en fast sidefil. For resten af os er den bedste løsning at vælge en brugerdefineret fast sidefil, og da mange mennesker højst sandsynligt har et ekstra drev, så vælg at gemme to brugerdefinerede faste sidefiler på begge drev. Hvis swapping opstår, burde dette i det mindste holde tiderne på et minimum.

Et fast resultat

Da det kom til vores ’roterende disk’ resultater, var vi noget overraskede og også bekræftede. Det er tydeligt, at Windows’ håndterede sidefil er langt den langsomste mulighed, der kan vælges. Benchmarken i sig selv er måske nok ikke fuldstændig centreret i den rigtige verden, vi tester det Windows-håndterede scenarie under de bedst mulige betingelser, efter dens mening, i al fald.

Så med den kørende op til 70 sekunder langsommere end de hurtigste ’roterende disk’ scenarier er det et potentielt slæb, endda endnu mere under potentielt mere fragmenterede betingelser. Det står også klart, at den faste samme-drev partitionsløsning heller ikke er et godt valg; enhver fordel, vundet ved den garanterede defragmentering, er derefter tabt ved den fysiske partitionsadskillelse og øgningen i drevhovedsøgetider og er som det mindste ikke bedre end et systemhåndteret valg.

Da vi slog sidefilen fra, fik det vores benchmark til hurtigt at komme med denne fejl.

Vi ville også anfægte ideen om, at det at slå sidefilen fra på et højhukommelsessystem hjælper til at forbedre ydelsen. Vores resultater peger faktisk, om noget, på det modsatte, selvom det at slå den virtuelle hukommelse fra, gør et system sårbart over for en lavhukommelsessituation, der kan få programmer til at gå ned og nægte Windows muligheden for at lave hukommelsesdump i tilfælde af nedbrud. Noget, der slår os som en situation, hvor der kun er noget at tabe.

Tidligere anbefalede vi altid en fast sidefil som det mest fornuftige valg. Windows gør dig i stand til at specificere en minimum- og en maksimumstørrelse, så det giver mening at lave en større minimumstørrelse, som du er glad for. Vi anbefaler mindst 2GB eller endnu bedre 4GB og så vælge et større maksimum i tilfælde af kriser, enten 6GB eller 8GB. Plus, i lyset af vore resultater, hvis du kan gøre dette over to forskellige drev, så vil det være endnu bedre og sikre dig den maksimale hastighed fra dine knirkende drev.

Fiks filen

For at få det meste ud af din sidefil er du nødt til at vide, hvordan du kontrollerer den. Fra Windows 95 til Windows 7 er sidefilen altid blevet kontrolleret gennem sektionen med avancerede indstillinger i panelet for Egenskaber for system, tryk [Windows] + [Break] for at åbne denne. Vista- og 7-brugere er yderligere nødt til at klikke på linket med Avancerede systemindstillinger. For alle versioner af Windows XP/Vista/7 klikkes på knappen ’Indstillinger’, fanen Avanceret vælges, og i området med Virtuel hukommelse klikkes ’Skift’-knappen.

Her vil du se en liste over alle kvalificerede, tilsluttede drev, hvilken, hvis nogen, sidefil de for tiden har og Windows’ egne anbefalinger. Windows Vista- og 7-systemer har yderligere en afkrydsningsboks i toppen af dialogboksen, som forcerer en systemhåndteret sidefil, og som det er nødvendigt at rydde. Du kan vælge hvert drev, og der få mulighed for at skabe en brugerdefineret sidefil, muliggøre at Windows håndterer sin egen fil eller forcere, at der slet ikke skal være nogen sidefil. Det vigtige er at sikre dig, at du klikker ’Definer’-knappen efter hvert valg, ellers vil eventuelle ændringer ikke være permanente.

Denne enkle indstilling har tjent os godt i mangen et år.

Windows har et par svagheder, der er værd at påpege. Som standard vil det lave sin egen systemhåndterede sidefil på opstartsdrevet, og det vil vælge 1,5 gange den fysiske hukommelse og flytte op til tre gange af dette, alt afhængig af hukommelsesbelastningerne. Det vil ikke drage fordel af andre partitioner eller drev med mere plads.

Dette er især mærkeligt, når du tænker på, at selv Microsoft indrømmer, at det ikke er en optimal konfiguration ovre i denne Knowledge Base artikel: support.microsoft.com/kb/314482. Den oplyser, at det at køre sidefilen på en separat harddisk, er en bedre mulighed, men den fortsætter også med at oplyse, at en sidefil på opstartsdrevet er nødvendig for fejlregistrering, selvom Windows sideløbende med dette har sine egne algoritmer for at konstatere, hvilke drev der bliver brugt mindst og vil prioritere disse til sidefilsbrug over andre partitioner eller drev.

Teknisk analyse

Benchmarkresultater: Hvad de er, og hvad de betyder

Som vi beskrev, skaber vi et stort billede i hukommelsen og manipulerer det på forskellige måder, for eksempel som at åbne, gemme, rotere og flytte rundt i det. Kører man på et 1GB system, overstiger dette langt den tilgængelige ledige hukommelse og tvinger Windows til at stole på sidefilen for op til 3GB ekstra hukommelse. Vi tager tid på, hvor længe hver operation tager, da vi kan se, hvor hurtigt systemet er til at udføre hver af dem, samt den tilgængelige båndbredde sidefilen har. For hvert scenarie foretog vi flere kørsler for at hjælpe med at eliminere generel systemstøj fra ligningen.

Forstør Tid i sekunder: hurtigere er bedre
6GB hukommelse – lille side 3
6GB Hukommelse – ingen side 3,24
Ram-drev 7
Dedikeret SSD 49,08
SSD komplet installation 60,65
Delt over to drev 116,16
Brugerdefineret 169,28
Dedikeret sata-drev 119,94
Dedikeret partition 183
Windows-håndteret 185,61

Gem Tid i sekunder: hurtigere er bedre
6GB hukommelse – lille side 10,36
6GB Hukommelse – ingen side 11,18
Ram-drev 17,24
Dedikeret SSD 27,73
SSD komplet installation 32,36
Delt over to drev 72,52
Brugerdefineret 110,19
Dedikeret sata-drev 58,97
Dedikeret partition 118
Windows-håndteret 105,3

Åbn Tid i sekunder: hurtigere er bedre
6GB hukommelse – lille side 10,91
6GB Hukommelse – ingen side 11,51
Ram-drev 11,81
Dedikeret SSD 71,04
SSD komplet installation 46,07
Delt over to drev 69,49
Brugerdefineret 95,97
Dedikeret sata-drev 124,77
Dedikeret partition 118,36
Windows-håndteret 122,04

Roter Tid i sekunder: hurtigere er bedre
6GB hukommelse – lille side 8,56
6GB Hukommelse – ingen side 10,63
Ram-drev 16,21
Dedikeret SSD 102,37
SSD komplet installation 110,69
Delt over to drev 218,39
Brugerdefineret 239,39
Dedikeret sata-drev 241,02
Dedikeret partition 255,6
Windows-håndteret 258,29