Hvorfor tømmer diskplassen fart på datamaskiner?

Når du lærer mer om datamaskiner og hvordan de fungerer, vil du av og til løpe over noe som ikke ser ut til å være fornuftig. Med det i tankene, tømmer diskplass faktisk hastigheten på datamaskiner? Dagens SuperUser Q & A-innlegg har svaret på en forvirret leserens spørsmål.

Dagens Spørsmål & Svar-sesjon kommer til oss med høflighet av SuperUser-en underavdeling av Stack Exchange, en fellesskapsdrevet gruppering av Q & A-nettsteder.

Skjermbilde høflighet av nchenga (Flickr).

Spørsmålet

SuperUser-leser Remi.b vil vite hvorfor tømming av diskplass ser ut til å øke hastigheten på en datamaskin:

Jeg har sett mange videoer og forstår nå hvordan datamaskiner fungerer litt bedre. Jeg forstår hva RAM er, om volatilt og ikke-flyktig minne, og prosessen med bytte. Jeg forstår også hvorfor å øke RAM-hastigheten på en datamaskin.

Hva jeg ikke forstår er hvorfor å rydde opp diskplassen ser ut til å øke hastigheten på en datamaskin opp. Går det virkelig fart på en datamaskin? Hvis ja, hvorfor gjør det så?

Har det noe å gjøre med å søke etter minnesplass for å spare ting eller å flytte ting rundt for å få nok nok tid til å lagre noe? Hvor mye ledig plass skal jeg la være ledig på en harddisk?

Hvorfor synes tømming av diskplass å øke hastigheten på en datamaskin?

Svaret

SuperUser-bidragsyteren Jason C har svaret for oss:

"Hvorfor tømmer diskplassen fart på datamaskiner?"

Det gjør det ikke, i hvert fall ikke alene. Dette er en veldig vanlig myte. Årsaken til at det er en vanlig myte, er at det ofte skjer samtidig med andre ting som tradisjonelt kan redusere datamaskinen din (EN). SSD-ytelsen har en tendens til å nedbrytes mens de fyller, men dette er et relativt nytt problem, unikt for SSD-er, og er ikke særlig merkbart for uformelle brukere. Generelt er lav ledig diskplass bare en rød sild.

For eksempel, ting som:

1. Filfragmentering. Filfragmentering er et problem (B), men mangel på ledig plass, men definitivt en av mange bidragende faktorer, er ikke den eneste årsaken til det. Noen viktige poeng her:

Sjansene for at en fil er fragmentert er ikke relatert til hvor mye ledig plass som er igjen på stasjonen. De er relatert til størrelsen på den største sammenhengende blokk av ledig plass på stasjonen (dvs. "hull" av ledig plass), som mengden ledig plass skjer for å legge en øvre grense på. De er også relatert til hvordan filsystemet håndterer filallokering (mer nedenfor). Ta i betraktning: En stasjon som er 95 prosent full med all ledig plass i en enkelt sammenhengende blokk har null prosent sjanse for fragmentering av en ny fil (C) (og sjansen for å fragmentere en vedlagt fil er uavhengig av ledig plass). En stasjon som er fem prosent full, men med dataspredning jevnt over stasjonen, har en meget stor sjanse for fragmentering.

Husk at filfragmentering påvirker bare ytelsen når de fragmenterte filene blir tilgjengelige. Ta i betraktning: Du har en fin, defragmentert stasjon som fortsatt har mange gratis "hull" i den. Et vanlig scenario. Alt går glatt. Til slutt kommer du til et punkt der det ikke er flere store blokker med ledig plass igjen. Du laster ned en stor film, filen slutter å være svært fragmentert. Dette vil ikke redusere datamaskinen din. Alle dine søknadsfiler og slike som tidligere var fine, vil ikke plutselig bli fragmentert. Dette kan føre til at filmen tar lengre tid å laste inn (selv om de typiske filmbitene er så lave sammenlignet med harddiskleser som det mest sannsynlig vil være unnoticeable), og det kan påvirke I / O-bundet ytelse mens filmen lastes, men annet enn det, ingenting endres.

Mens filfragmentering er absolutt et problem, ofte blir effektene redusert av OS- og maskinvarenivåbuffering og caching. Forsinket skriver, leser frem, strategier som forforfatteren i Windows, etc., alle bidrar til å redusere effektene av fragmentering. Du gjør det vanligvis ikke faktisk opplever betydelig innflytelse til fragmenteringen blir alvorlig (jeg vil selv risikere å si at så lenge swapfilen ikke er fragmentert, vil du sannsynligvis aldri merke).

2. Søk indeksering er et annet eksempel. Si at du har automatisk indeksering slått på og et operativsystem som ikke håndterer dette grasiøst. Når du sparer mer og mer indekserbart innhold på datamaskinen din (dokumenter og lignende), kan indeksering ta lengre tid og lenger, og kan begynne å påvirke hastigheten på datamaskinen din mens den kjører, både i I / O- og CPU-bruk . Dette er ikke relatert til ledig plass, det er relatert til mengden av innhold som du kan indeksere. Det går imidlertid hånd i hånd med å løpe mer ledig plass, og dermed blir en falsk forbindelse trukket.

3. Antivirusprogramvare (ligner på søkindekseringseksemplet). Si at du har antivirusprogramvare satt opp for å gjøre bakgrunnsskanning av stasjonen. Siden du har mer og mer skannbart innhold, tar søket mer I / O- og CPU-ressurser, noe som muligens forstyrrer arbeidet ditt. Igjen, dette er relatert til mengden av skannbart innhold du har. Mer innhold tilsvarer ofte mindre ledig plass, men mangelen på ledig plass er ikke årsaken.

4. Installert programvare. Si at du har mye programvare installert som laster når datamaskinen starter, og dermed senker oppstartstidene. Denne tregningen skjer fordi mye programvare lastes inn. Installert programvare tar imidlertid opp plass på harddisken. Derfor reduseres harddiskfri ledig plass samtidig som dette skjer, og igjen kan en falsk tilkobling lett gjøres.

5. Mange andre eksempler langs disse linjene som, når de tas sammen, vises å nært forbinde mangel på ledig plass med lavere ytelse.

Ovenstående illustrerer en annen grunn til at dette er en vanlig myte: Selv om mangelen på ledig plass ikke er en direkte årsak til sakte nedgang, avinstallerer forskjellige applikasjoner, fjerner indeksert eller skannet innhold, etc. noen ganger (men ikke alltid, utenfor omfanget av dette svaret) øker ytelsen igjen av grunner som ikke er relatert til mengden ledig ledig plass igjen. Men dette frigjør også naturlig harddiskplass. Derfor kan igjen en tilsynelatende (men falsk) forbindelse mellom "mer ledig plass" og en "raskere datamaskin" gjøres.

Ta i betraktning: Hvis du har en maskin som kjører sakte på grunn av mye installert programvare, osv., Klone harddisken (akkurat) til en større harddisk, og utvide partisjonene for å få mer ledig plass, maskinen vil ikke komme seg raskere. Samme programvare laster, de samme filene er fortsatt fragmentert på samme måter, den samme søkeindeksen kjører fortsatt, ingenting endres til tross for at du har mer ledig plass.

"Har det noe å gjøre med å søke etter minnesplass for å spare ting?"

Nei det gjør det ikke. Det er to svært viktige ting å merke seg her:

1. Harddisken din søker ikke rundt for å finne steder å sette ting på. Harddisken din er dum. Det er ingenting. Det er en stor blokk med adressert lagringsplass som blindt legger ting der OS forteller det og leser det som blir spurt om det. Moderne stasjoner har sofistikerte caching og buffermekanismer designet rundt å forutse hva operativsystemet skal be om basert på erfaringen vi har oppnådd over tid (noen stasjoner er selv klar over filsystemet som er på dem), men i hovedsak tenk på din Kjør som bare en stor dum oppbevaringsplass med sporadiske bonusfunksjoner.

2. Operativsystemet søker ikke etter steder å sette ting, heller ikke. Det er ingen søking. Mye innsats har gått på å løse dette problemet, da det er kritisk for filsystemet ytelse. Måten dataene faktisk er organisert på stasjonen din, bestemmes av filsystemet ditt. For eksempel, FAT32 (gamle DOS og Windows-PCer), NTFS (senere utgaver av Windows), HFS + (Mac), ext4 (noen Linux-systemer) og mange andre. Selv begrepet "fil" og "katalog" er bare produkter av typiske filsystemer - harddisker vet ingenting om de mystiske dyrene som heter filer. Detaljer er utenfor omfanget av dette svaret. Men i hovedsak har alle vanlige filsystemer måter å spore hvor ledig plass er på en stasjon, slik at et søk på ledig plass, under normale omstendigheter (dvs. filsystem i god helse), er unødvendig. eksempler:

NTFS har en master filtabell, som inneholder de spesielle filene $ Bitmap, etc., og masse metadata som beskriver stasjonen. I det vesentlige følger det med hvor de neste gratis blokkene er, slik at nye filer kan skrives direkte til gratis blokker uten å måtte skanne stasjonen hver gang.

Et annet eksempel: Ext4 har det som kalles bitmap allokering, en forbedring over ext2 og ext3 som i utgangspunktet hjelper det direkte å bestemme hvor gratis blokker er i stedet for å skanne listen over gratis blokker. Ext4 støtter også forsinket allokering, det vil si buffering av data i RAM ved operativsystemet før du skriver det ut til stasjonen for å kunne ta bedre beslutninger om hvor du skal sette det for å redusere fragmentering.

Mange andre eksempler.

"Eller med å flytte ting rundt for å gjøre en lang nok kontinuerlig plass for å spare noe?"

Nei. Dette skjer ikke, i hvert fall ikke med noe filsystem jeg er klar over. Filene bare ende opp fragmentert.

Prosessen med å flytte ting rundt for å gjøre opp en lang nok sammenhengende plass for å lagre noe kalles defragmentering. Dette skjer ikke når filer skrives. Dette skjer når du kjører diskdefragmenteren din. På nyere versjoner av Windows, i det minste, skjer dette automatisk på en tidsplan, men det utløses aldri ved å skrive en fil.

Være i stand til unngå å flytte ting rundt som dette er nøkkelen til filsystemet ytelse, og det er derfor fragmentering skjer og hvorfor defragmentering eksisterer som et eget trinn.

"Hvor mye tomt mellomrom bør jeg la være ledig på en harddisk?"

Dette er et vanskeligere spørsmål å svare på (og dette svaret har allerede blitt til en liten bok).

Tommelfingerregel:

1. For alle typer stasjoner:

Viktigst, la nok ledig plass til du bruker datamaskinen effektivt. Hvis du går tom for plass til jobb, vil du ha en større stasjon.

Mange diskdefragmenteringsverktøy krever minimum fri ledig plass (jeg tror at Windows med 15 prosent, verste fall) skal fungere. De bruker dette ledig plass til midlertidig å holde fragmenterte filer, ettersom andre ting er omorganisert.

La plass til andre OS-funksjoner. Hvis for eksempel maskinen din ikke har mye fysisk RAM, og du har virtuelt minne aktivert med en dynamisk størrelse sidefil, vil du legge til nok plass til sidefilens maksimale størrelse. Eller hvis du har en bærbar datamaskin som du legger i dvalemodus, trenger du nok ledig plass til dvalemodusfilen. slike ting.

2. SSD-spesifikke:

For optimal pålitelighet (og i mindre utstrekning ytelse), krever SSDer litt ledig plass, som uten å gå inn i for mye detalj, bruker de til å spre data rundt stasjonen for å unngå å skrive kontinuerlig til samme sted (som sliter dem ut) . Dette konseptet om å forlate ledig plass kalles over-provisioning. Det er viktig, men i mange SSDer eksisterer allerede obligatorisk overbestemt plass. Det vil si at stasjonene ofte har noen få dusin flere GB enn de rapporterer til operativsystemet. Nedre endestasjoner krever ofte at du skal gå manuelt upartisjonert plass, men for stasjoner med obligatorisk OP, du trenger ikke å legge igjen ledig plass. En viktig ting å merke seg her er det Overbestemt plass tas ofte bare fra upartisjonert plass. Så hvis partisjonen tar opp hele stasjonen din, og du gir litt ledig plass på det, gjør det ikke alltid telle. Mange ganger krever manuell overlevering at du skal krympe partisjonen din for å være mindre enn størrelsen på stasjonen. Sjekk SSDs brukerhåndbok for detaljer. TRIM, søppelsamling og lignende har også effekter, men de er utenfor omfanget av dette svaret.

Personlig tar jeg vanligvis en større stasjon når jeg har omtrent 20-25 prosent ledig plass igjen. Dette er ikke relatert til ytelse, det er bare at når jeg kommer til det punktet, forventer jeg at jeg nok kommer til å løpe tom for plass til data snart, og det er på tide å få en større stasjon.

Viktigere enn å se ledig plass, sørger for at planlagt defragmentering er aktivert der det er hensiktsmessig (ikke på SSD-er), slik at du aldri kommer til det punktet der det blir dire nok til å påvirke deg.

Det er en siste ting verdt å nevne. En av de andre svarene her nevnte at SATAs halvdupleksmodus forhindrer lesing og skriving på samme tid. Selv sant, er dette sterkt oversimplified og er for det meste ikke relatert til ytelsesproblemene som diskuteres her. Dette betyr ganske enkelt at dataene ikke kan overføres i begge retninger på ledningen samtidig. Imidlertid har SATA en ganske komplisert spesifikasjon som involverer små maksimale blokkstørrelser (ca. 8kB per blokk på ledningen tror jeg), lese og skrive driftskøer, etc., og utelukker ikke at buffere skjer mens lesene pågår, interleaved operasjoner mv.

Enhver blokkering som oppstår vil skyldes å konkurrere om fysiske ressurser, vanligvis mildret av mye cache. Duplexmodusen til SATA er nesten helt irrelevant her.

(EN) "Slow down" er et bredt begrep. Her bruker jeg den til å referere til ting som er enten I / O-bundet (dvs. hvis datamaskinen sitter der knuste tall, innholdet på harddisken har ingen innvirkning) eller CPU-bundet og konkurrerer med tangentielt relaterte ting som har høy CPU bruk (dvs. anti-virus programvare skanning tonnevis av filer).

(B) SSD-er påvirkes av fragmentering ved at sekvensielle aksesshastigheter generelt er raskere enn tilfeldig tilgang, til tross for SSD-er som ikke står overfor de samme begrensningene som en mekanisk enhet (selv da garanterer mangel på fragmentering ikke sekvensiell tilgang på grunn av slitasje, etc.). Men i nesten alle generelle bruksscenarier er dette et ikke-problem. Prestasjonsforskjeller som skyldes fragmentering på SSD er vanligvis ubetydelige for ting som lasting av applikasjoner, oppstart av datamaskinen osv.

(C) Anta et sane filsystem som ikke fragmenterer filer med vilje.

Sørg for å lese gjennom resten av den livlige diskusjonen på SuperUser via lenken nedenfor!

Har du noe å legge til forklaringen? Lyder av i kommentarene. Vil du lese flere svar fra andre tech-savvy Stack Exchange-brukere? Sjekk ut hele diskusjonstråden her.