Når du lærer mer om datamaskiner og hvordan de fungerer, vil du av og til kjøre på noe som ikke ser ut til å være fornuftig. Med tanke på det, gjør tømming av diskplass faktisk datamaskiner raskere? Dagens SuperUser-spørsmål og svar har svaret på et forvirret leserspørsmål.
Dagens spørsmål og svar-økt kommer til oss med tillatelse fra SuperUser - en underavdeling av Stack Exchange, en samfunnsdrevet gruppe av spørsmål og svar-nettsteder.
Skjermbilde med tillatelse fra sand (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 på mange videoer og forstår nå hvordan datamaskiner fungerer litt bedre. Jeg forstår hva RAM er, om flyktig og ikke-flyktig minne, og prosessen med å bytte. Jeg forstår også hvorfor økende RAM fremskynder en datamaskin.
Det jeg ikke forstår er hvorfor opprydding av diskplass ser ut til å øke hastigheten på en datamaskin. Fremskynder det virkelig en datamaskin? I så fall, hvorfor gjør det det?
Har det noe å gjøre med å søke etter minneplass for å redde ting eller med å flytte ting rundt for å lage en lang nok sammenhengende plass til å spare noe? Hvor mye tom plass skal jeg la være ledig på en harddisk?
Hvorfor ser det ut til at tømming av diskplass fremskynder en datamaskin?
Svaret
SuperUser-bidragsyter Jason C har svaret for oss:
"Hvorfor fremskynder tømming av diskplass datamaskiner?"
Det gjør det ikke, i det minste ikke alene. Dette er en veldig vanlig myte. Grunnen til at det er en vanlig myte er at fylle opp harddisken ofte skjer samtidig som andre ting som tradisjonelt kan redusere datamaskinen din (EN) . SSD-ytelse har en tendens til å forringes når de fylles, men dette er et relativt nytt problem, unikt for SSD-er, og er ikke merkbart for tilfeldige brukere. Generelt er lite ledig diskplass bare en rød sild.
For eksempel ting som:
1. Filfragmentering. Filfragmentering er et problem (B) , men mangel på ledig plass, selv om det definitivt er en av mange medvirkende faktorer, er ikke den eneste årsaken til det. Noen viktige punkter her:
- Sjansene for at en fil blir 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 blokken med ledig plass på stasjonen (dvs. "hull" på ledig plass), som mengden ledig plass tilfeldigvis setter en øvre grense på . De er også relatert til hvordan filsystemet håndterer tildeling av filer ( mer nedenfor ). Ta i betraktning: En stasjon som er 95 prosent full med all ledig plass i en sammenhengende blokk, har null prosent sjanse for å fragmentere 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 data jevnt fordelt over stasjonen, har veldig stor sjanse for fragmentering.
- Husk at filfragmentering påvirker bare ytelsen når man får tilgang til de fragmenterte filene . Ta i betraktning: Du har en fin, defragmentert stasjon som fortsatt har mange gratis "hull" i seg. Et vanlig scenario. Alt går som det skal. Til slutt kommer du til et punkt der det ikke er flere store blokker med ledig plass igjen. Du laster ned en enorm film, filen ender med å bli sterkt fragmentert. Dette vil ikke redusere datamaskinen . Alle applikasjonsfilene dine og slike som tidligere var fine, blir ikke plutselig fragmenterte. Dette kan gjøre at filmen tar lengre tid å laste inn (selv om typiske filmhastigheter er så lave sammenlignet med harddiskens lesehastigheter at det sannsynligvis ikke blir lagt merke til), og det kan påvirke I / O-bundet ytelse mens filmen lastes inn, men annet enn det, endres ingenting.
- Mens filfragmentering absolutt er et problem, blir effekten ofte dempet av buffering og hurtigbufring av operativsystem og maskinvarenivå. Forsinket skriver, lese-foran, strategier som forbryter i Windows osv., hjelper alt med å redusere effekten av fragmentering. Det gjør du generelt ikke faktisk opplever betydelig innvirkning til fragmenteringen blir alvorlig (jeg vil til og med våge å si at så lenge byttefilen din ikke er fragmentert, vil du sannsynligvis aldri merke det).
2. Søkeindeksering er et annet eksempel. Si at du har slått på automatisk indeksering og et operativsystem som ikke takler dette elegant. Når du lagrer mer og mer indekserbart innhold på datamaskinen din (dokumenter og slikt), kan indeksering ta lengre tid og kan begynne å ha en innvirkning på datamaskinens opplevde hastighet mens den kjører, både i I / O- og CPU-bruk. . Dette er ikke relatert til ledig plass, det er relatert til mengden indekserbart innhold du har. Det å gå tom for ledig plass går imidlertid hånd i hånd med lagring av mer innhold, derfor trekkes en falsk forbindelse.
3. Antivirusprogramvare (ligner på søkeindekseringseksemplet). Si at du har installert antivirusprogramvare for å utføre bakgrunnsskanning av stasjonen. Ettersom du har mer og mer skannbart innhold, tar søket flere I / O- og CPU-ressurser, noe som muligens forstyrrer arbeidet ditt. Igjen, dette er relatert til mengden 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 lastes inn når datamaskinen starter, og dermed reduserer oppstartstidene. Denne bremsingen skjer fordi mye programvare lastes inn. Imidlertid tar installert programvare harddiskplass. Derfor reduseres ledig plass på harddisken samtidig som dette skjer, og igjen kan det lett opprettes en falsk forbindelse.
5. Mange andre eksempler i tråd med disse linjene, når de blir tatt sammen vises å nært knytte mangel på ledig plass med lavere ytelse.
Ovenstående illustrerer en annen grunn til at dette er en så vanlig myte: Selv om mangelen på ledig plass ikke er en direkte årsak til å redusere hastigheten, avinstallerer du 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 plass som er igjen. Men dette frigjør også naturlig harddiskplass. Derfor kan det igjen opprettes en tilsynelatende (men falsk) forbindelse mellom "mer ledig plass" og en "raskere datamaskin".
Ta i betraktning: Hvis du har en maskin som går sakte på grunn av mye installert programvare osv., Kloner du harddisken (nøyaktig) til en større harddisk, og utvider deretter partisjonene dine for å få mer ledig plass, maskinen vil ikke magisk øke hastigheten. Den samme programvaren lastes inn, de samme filene er fortsatt fragmenterte på samme måter, den samme søkeindeksøren kjører fortsatt, ingenting endres til tross for at det er mer ledig plass.
"Har det noe å gjøre med å søke etter minne for å redde ting?"
Nei det gjør det ikke. Det er to veldig viktige ting som er verdt å 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 lagring som blindt setter ting der operativsystemet ditt forteller det og leser hva som blir bedt om det. Moderne stasjoner har sofistikerte hurtigbufring og buffermekanismer designet for å forutsi hva operativsystemet kommer til å be om basert på erfaringen vi har fått over tid (noen stasjoner er til og med klar over filsystemet som er på dem), men tenk egentlig på kjør som bare en dum murstein med lagringsplass med sporadiske bonusytelsesfunksjoner.
2. Operativsystemet ditt søker heller ikke etter steder å sette ting på. Det er ingen leting. Mye innsats har gått for å løse dette problemet, da det er viktig for filsystemytelsen. Måten data faktisk er organisert på stasjonen din bestemmes av din filsystem . 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 fra typiske filsystemer - harddisker vet ingenting om de mystiske dyrene som kalles 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 etter ledig plass er under normale omstendigheter (dvs. filsystemer med god helse), unødvendig. Eksempler:
- NTFS har en master filtabell , som inkluderer spesialfilene $ Bitmap osv., og mange metadata som beskriver stasjonen. I hovedsak holder den oversikt over 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 alloker , en forbedring i forhold til ext2 og ext3 som i utgangspunktet hjelper den med å bestemme direkte hvor gratis blokker er i stedet for å skanne listen over gratis blokker. Ext4 støtter også forsinket tildeling , det vil si buffering av data i RAM av operativsystemet før du skriver det ut til stasjonen for å ta bedre beslutninger om hvor du skal plassere det for å redusere fragmentering.
- Mange andre eksempler.
"Eller med å flytte ting for å lage en lang nok kontinuerlig plass til å redde noe?"
Nei. Dette skjer ikke, i det minste ikke med noe filsystem jeg er kjent med. Filer blir bare fragmenterte.
Prosessen med å "flytte ting rundt for å utgjøre en lang nok sammenhengende plass til å redde noe" kalles defragmentering . Dette skjer ikke når filer skrives. Dette skjer når du kjører diskdefragmenteringen. I nyere versjoner av Windows skjer dette i det minste automatisk etter en tidsplan, men det utløses aldri ved å skrive en fil.
Være i stand til unngå å flytte ting som dette er nøkkelen til filsystemytelsen, og det er derfor fragmentering skjer og hvorfor defragmentering eksisterer som et eget trinn.
"Hvor mye tom plass skal 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 det være nok ledig plass til å bruke datamaskinen effektivt . Hvis du går tom for plass til å jobbe, vil du ønske deg en større kjøretur.
- Mange diskdefragmenteringsverktøy krever et minimum av ledig plass (jeg tror den med Windows krever 15 prosent, i verste fall) å jobbe i. De bruker denne ledige plassen til midlertidig å holde fragmenterte filer ettersom andre ting blir omorganisert.
- La det være plass til andre OS-funksjoner. For eksempel, hvis maskinen din ikke har mye fysisk RAM, og du har aktivert virtuelt minne med en sidefil med dynamisk størrelse, vil du legge igjen nok plass til sidefilens maksimale størrelse. Eller hvis du har en bærbar datamaskin som du setter i dvalemodus, trenger du nok ledig plass til dvalemodusfilen. Slike ting.
2. SSD-spesifikk:
- For optimal pålitelighet (og i mindre grad ytelse) krever SSD-er litt ledig plass, som de bruker uten å gå for mye i detalj for å spre data rundt stasjonen for å unngå å skrive til samme sted (som slites dem ut) . Dette konseptet med å forlate ledig plass kalles over-provisioning . Det er viktig, men i mange SSD-er eksisterer det allerede obligatorisk overordnet plass . Det vil si at stasjonene ofte har noen titalls flere GB enn de rapporterer til operativsystemet. Nedre stasjoner krever ofte at du forlater manuelt upartisjonert plass, men for stasjoner med obligatorisk OP, du trenger ikke å legge igjen ledig plass . En viktig ting å merke seg her er at over-avsatt plass er ofte bare hentet fra ikke-partisjonert rom . Så hvis partisjonen din tar opp hele stasjonen og du legger igjen litt ledig plass på den, gjør det ikke det bestandig telle. Mange ganger krever manuell overforsyning at du krymper partisjonen for å være mindre enn størrelsen på stasjonen. Se brukerhåndboken til SSD for mer informasjon. TRIM, søppeloppsamling og slikt har også effekter, men de er utenfor omfanget av dette svaret.
Personlig tar jeg vanligvis en større kjøretur når jeg har omtrent 20-25 prosent ledig plass igjen. Dette er ikke relatert til ytelse, det er bare det at når jeg kommer til det punktet, forventer jeg at jeg sannsynligvis snart vil gå tom for plass for data, og det er på tide å få en større stasjon.
Viktigere enn å se ledig plass er å sørge for at planlagt defragmentering er aktivert der det er hensiktsmessig (ikke på SSD-er), slik at du aldri kommer til det punktet hvor det blir alvorlig nok til å påvirke deg.
Det er en siste ting det er verdt å nevne. Et av de andre svarene her nevnte at SATAs halvdupleksmodus forhindrer lesing og skriving samtidig. Selv om det er sant, er dette sterkt forenklet og er stort sett ikke relatert til ytelsesproblemene som blir diskutert her. Hva dette enkelt betyr, er at data ikke kan overføres i begge retninger på ledningen samtidig. Imidlertid har SATA en ganske komplisert spesifikasjon involverer bittesmå maksimale blokkstørrelser (ca 8 kB per blokk på ledningen, tror jeg), lese- og skriveoperasjonskøer osv., og utelukker ikke at skriving til buffere skjer mens lesing pågår, sammenflettede operasjoner osv.
Enhver blokkering som oppstår, skyldes konkurranse om fysiske ressurser, vanligvis redusert av mye cache. Dupleksmodusen til SATA er nesten helt irrelevant her.
(EN) "Sakte ned" er et bredt begrep. Her bruker jeg den til å referere til ting som enten er I / O-bundet (dvs. hvis datamaskinen din sitter der og knuser tall, har innholdet på harddisken ingen innvirkning) eller CPU-bundet og konkurrerer med tangentielt relaterte ting som har høy CPU-bruk (dvs. antivirusprogramvare som skanner massevis av filer).
(B) SSD-er påvirkes av fragmentering ved at sekvensiell tilgangshastighet generelt er raskere enn tilfeldig tilgang, til tross for SSD-er som ikke har de samme begrensningene som en mekanisk enhet (selv da garanterer mangel på fragmentering ikke sekvensiell tilgang på grunn av slitasjeutjevning osv.). Imidlertid, i nesten alle generelle bruksscenarier, er dette et ikke-problem. Ytelsesforskjeller på grunn av fragmentering på SSD-er er vanligvis ubetydelige for ting som å laste applikasjoner, starte datamaskinen osv.
(C) Anta at et sunt 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? Lyd av i kommentarene. Vil du lese flere svar fra andre teknologikyndige Stack Exchange-brukere? Sjekk ut hele diskusjonstråden her .
