Når du lærer mere om computere, og hvordan de fungerer, vil du lejlighedsvis løbe over noget, der ikke synes at give mening. Med det i tankerne fremskynder tømning af diskplads faktisk computere? Dagens SuperUser Q & A-indlæg har svaret på en forvirret læsers spørgsmål.
Dagens spørgsmål og svar-session kommer til os med tilladelse fra SuperUser - en underinddeling af Stack Exchange, en community-driven gruppe af Q&A websteder.
Skærmbillede med tilladelse til sand (Flickr) .
Spørgsmålet
SuperUser-læser Remi.b vil vide, hvorfor tømning af diskplads synes at fremskynde en computer:
Jeg har set mange videoer og forstår nu, hvordan computere fungerer lidt bedre. Jeg forstår, hvad RAM er, om flygtig og ikke-flygtig hukommelse, og processen med at bytte. Jeg forstår også, hvorfor stigende RAM fremskynder en computer.
Hvad jeg ikke forstår, er, hvorfor oprydning af diskplads ser ud til at fremskynde en computer. Fremskynder det virkelig en computer? Hvis ja, hvorfor gør det det?
Har det noget at gøre med at søge efter hukommelsesplads for at redde ting eller med at flytte ting rundt for at skabe et langt nok sammenhængende rum til at gemme noget? Hvor meget tom plads skal jeg have fri på en harddisk?
Hvorfor ser det ud til, at tømning af diskplads fremskynder en computer?
Svaret
SuperUser-bidragsyder Jason C har svaret til os:
"Hvorfor fremskynder computere tømning af diskplads?"
Det gør det ikke, i det mindste ikke alene. Dette er en rigtig almindelig myte. Årsagen til, at det er en almindelig myte, er, at udfyldning af din harddisk ofte sker på samme tid som andre ting, der traditionelt kunne bremse din computer (EN) . SSD-ydelse har en tendens til at blive dårligere, når de udfyldes, men dette er et relativt nyt problem, der er unikt for SSD'er, og det bemærkes ikke rigtig for afslappede brugere. Generelt er lav ledig diskplads kun en rød sild.
F.eks. Ting som:
1. Fil fragmentering. Filfragmentering er et problem (B) , men mangel på ledig plads, selvom det bestemt er en af mange medvirkende faktorer, er ikke den eneste årsag til det. Nogle vigtige punkter her:
- Chancerne for, at en fil bliver fragmenteret, er ikke relateret til mængden af ledig plads, der er tilbage på drevet. De er relateret til størrelsen på den største sammenhængende blok med ledig plads på drevet (dvs. "huller" i ledig plads), som mængden af ledig plads tilfældigvis lægger en øvre grænse på . De er også relateret til, hvordan filsystemet håndterer filallokering ( mere nedenfor ). Overveje: Et drev, der er 95 procent fuldt med al ledig plads i en enkelt sammenhængende blok, har nul procent chance for at fragmentere en ny fil (C) (og chancen for at fragmentere en tilføjet fil er uafhængig af den ledige plads). Et drev, der er fem procent fuldt, men med data jævnt fordelt over drevet, har en meget stor chance for fragmentering.
- Husk, at fil fragmentering påvirker kun ydeevnen, når der er adgang til de fragmenterede filer . Overveje: Du har et dejligt, defragmenteret drev, der stadig har mange gratis "huller" i sig. Et almindeligt scenario. Alt kører gnidningsløst. Til sidst kommer du dog til et punkt, hvor der ikke er flere store blokke med ledig plads tilbage. Du downloader en kæmpe film, filen ender med at blive meget fragmenteret. Dette bremser ikke din computer . Alle dine ansøgningsfiler og sådanne, der tidligere var fine, bliver ikke pludselig fragmenterede. Dette kan få filmen til at tage længere tid at indlæse (skønt typiske filmbithastigheder er så lave sammenlignet med harddiskens læsehastigheder, at det sandsynligvis ikke kan ses), og det kan påvirke I / O-bundet ydeevne, mens filmen indlæses, bortset fra det, ændres intet.
- Mens filfragmentering helt sikkert er et problem, mildnes effekterne ofte af buffering og caching af OS og hardwareniveau. Forsinket skriver, read-ahead, strategier som forhænger i Windows osv. hjælper alle med at reducere virkningerne af fragmentering. Det gør du generelt ikke rent faktisk oplever betydelig indflydelse, indtil fragmenteringen bliver svær (jeg vil endda vove at sige, at så længe din swap-fil ikke er fragmenteret, vil du sandsynligvis aldrig bemærke det).
2. Søgeindeksering er et andet eksempel. Sig, at du har aktiveret automatisk indeksering og et operativsystem, der ikke behandler dette yndefuldt. Når du gemmer mere og mere indekserbart indhold på din computer (dokumenter og lignende), kan indeksering tage længere og længere tid og kan begynde at have en effekt på din computers opfattede hastighed, mens den kører, både i I / O og CPU-brug . Dette er ikke relateret til ledig plads, det er relateret til mængden af indekserbart indhold, du har. At løbe tør for ledig plads går imidlertid hånd i hånd med lagring af mere indhold, og der er derfor en falsk forbindelse.
3. Antivirussoftware (svarer til eksemplet på søgningsindeksering). Sig, at du har konfigureret antivirussoftware til at foretage baggrundsscanning af dit drev. Da du har mere og mere scanneligt indhold, tager søgningen flere I / O- og CPU-ressourcer, hvilket muligvis forstyrrer dit arbejde. Igen er dette relateret til mængden af scanneligt indhold, du har. Mere indhold svarer ofte til mindre ledig plads, men manglen på ledig plads er ikke årsagen.
4. Installeret software. Sig, at du har installeret en masse software, der indlæses, når din computer starter, hvilket bremser opstartstiderne. Denne afmatning sker, fordi masser af software indlæses. Imidlertid tager installeret software plads på harddisken. Derfor mindskes ledig plads på harddisken på samme tid, som dette sker, og igen kan der let oprettes en falsk forbindelse.
5. Mange andre eksempler i denne retning, som når de tages sammen, komme til syne at tæt forbinde mangel på ledig plads med lavere ydeevne.
Ovenstående illustrerer en anden grund til, at dette er sådan en almindelig myte: Selv om manglen på ledig plads ikke er en direkte årsag til afmatning, afinstallation af forskellige applikationer, fjernelse af indekseret eller scannet indhold osv. Undertiden (men ikke altid; uden for anvendelsesområdet for dette svar) øger ydeevnen igen af årsager, der ikke er relateret til den resterende ledige plads. Men dette frigør naturligvis også plads på harddisken. Derfor kan der igen oprettes en tilsyneladende (men falsk) forbindelse mellem "mere ledig plads" og en "hurtigere computer".
Overveje: Hvis du har en maskine, der kører langsomt på grund af masser af installeret software osv., Kloner du harddisken (nøjagtigt) til en større harddisk og udvider derefter dine partitioner for at få mere ledig plads, maskinen vil ikke magisk fremskynde. Den samme software indlæses, de samme filer er stadig fragmenteret på de samme måder, den samme søgeindekserer kører stadig, intet ændrer sig på trods af at der er mere ledig plads.
"Har det noget at gøre med at søge efter hukommelsesplads for at redde ting?"
Nej det gør ej. Der er to meget vigtige ting, der er værd at bemærke her:
1. Din harddisk søger ikke rundt for at finde steder at placere ting på. Din harddisk er dum. Det er intet. Det er en stor blok med adresseret opbevaring, der blindt placerer ting, hvor dit operativsystem fortæller det til, og læser det, der bliver bedt om. Moderne drev har sofistikerede caching- og buffermekanismer designet til at forudsige, hvad operativsystemet vil bede om baseret på den erfaring, vi har fået over tid (nogle drev er endda opmærksomme på det filsystem, der findes på dem), men tænk i det væsentlige på dit kør som bare en stor dum mursten med opbevaring med lejlighedsvise bonusydelsesfunktioner.
2. Dit operativsystem søger heller ikke efter steder at placere ting på. Der er ingen søgning. Der er lagt en stor indsats i at løse dette problem, da det er afgørende for filsystemets ydeevne. Den måde, hvorpå data faktisk er organiseret på dit drev, bestemmes af din filsystem . For eksempel FAT32 (gamle DOS- og Windows-pc'er), NTFS (senere udgaver af Windows), HFS + (Mac), ext4 (nogle Linux-systemer) og mange andre. Selv begrebet "fil" og "bibliotek" er blot produkter fra typiske filsystemer - harddiske ved intet om de mystiske dyr, der kaldes filer . Detaljer er uden for dette svar. Men i det væsentlige har alle almindelige filsystemer måder til at spore, hvor den ledige plads er på et drev, så en søgning efter ledig plads under normale omstændigheder (dvs. filsystemer med godt helbred) er unødvendig. Eksempler:
- NTFS har en master filtabel , som inkluderer de specielle filer $ Bitmap osv. og masser af metadata, der beskriver drevet. I det væsentlige holder det styr på, hvor de næste gratis blokke er, så nye filer kan skrives direkte til gratis blokke uden at skulle scanne drevet hver gang.
- Et andet eksempel: Ext4 har det, der kaldes bitmap-tildeler , en forbedring i forhold til ext2 og ext3, der dybest set hjælper det med at bestemme direkte, hvor gratis blokke er i stedet for at scanne listen over gratis blokke. Ext4 understøtter også forsinket tildeling dvs. buffering af data i RAM af operativsystemet, før det skrives ud på drevet for at træffe bedre beslutninger om, hvor de skal placeres for at reducere fragmentering.
- Mange andre eksempler.
"Eller med at flytte tingene rundt for at skabe et langt nok sammenhængende rum til at redde noget?"
Nej. Dette sker ikke, i det mindste ikke med noget filsystem, jeg er opmærksom på. Filer ender bare fragmenteret.
Processen med at ”flytte ting rundt for at udgøre et tilstrækkeligt langt sammenhængende rum til at gemme noget” kaldes defragmentering . Dette sker ikke, når filer skrives. Dette sker, når du kører din diskdefragmentering. I nyere udgaver af Windows sker det i det mindste automatisk efter en tidsplan, men det udløses aldrig ved at skrive en fil.
Være i stand til undgå at flytte ting som dette er nøglen til filsystemets ydeevne, og det er grunden til fragmentering, og hvorfor defragmentering eksisterer som et separat trin.
"Hvor meget tomt sted skal jeg efterlade ledig på en harddisk?"
Dette er et vanskeligere spørgsmål at besvare (og dette svar er allerede blevet til en lille bog).
Tommelfingerregler:
1. Til alle typer drev:
- Vigtigst af alt skal du lade nok plads til dig til at bruge din computer effektivt . Hvis du løber tør for plads til arbejde, vil du have et større drev.
- Mange diskdefragmenteringsværktøjer kræver et minimum af ledig plads (jeg tror, den med Windows kræver 15 procent, i værste fald) at arbejde i. De bruger denne ledige plads til midlertidigt at indeholde fragmenterede filer, da andre ting omarrangeres.
- Giv plads til andre OS-funktioner. For eksempel, hvis din maskine ikke har meget fysisk RAM, og du har aktiveret virtuel hukommelse med en sidefil med dynamisk størrelse, vil du gerne have plads nok til sidefilens maksimale størrelse. Eller hvis du har en bærbar computer, som du sætter i dvaletilstand, har du brug for nok ledig plads til dvaletilstandsfilen. Ting som.
2. SSD-specifik:
- For optimal pålidelighed (og i mindre grad ydeevne) kræver SSD'er noget ledig plads, som de bruger til at sprede data rundt om drevet for at undgå konstant at skrive til det samme sted (som slides dem ud) uden at gå for meget i detaljer. . Dette koncept om at forlade ledig plads kaldes over-provisioning . Det er vigtigt, men i mange SSD'er eksisterer der allerede obligatorisk overudnyttet plads . Det vil sige, at drevne ofte har et par dusin flere GB, end de rapporterer til operativsystemet. Drev i lavere ende kræver ofte, at du forlader manuelt upartitioneret plads, men til drev med obligatorisk OP, du behøver ikke at efterlade ledig plads . En vigtig ting at bemærke her er, at over-tilvejebragt plads er ofte kun taget fra ikke-opdelt rum . Så hvis din partition optager hele dit drev, og du efterlader noget ledig plads på det, gør det ikke altid tælle. Mange gange kræver manuel overadministration, at du krymper din partition for at være mindre end drevets størrelse. Se din SSDs brugervejledning for at få flere oplysninger. TRIM, affaldsindsamling og lignende har også effekter, men de er uden for dette svar.
Personligt tager jeg normalt et større drev, når jeg har omkring 20-25 procent ledig plads tilbage. Dette er ikke relateret til ydeevne, det er bare, at når jeg kommer til det punkt, forventer jeg, at jeg sandsynligvis snart vil løbe tør for plads til data, og det er tid til at få et større drev.
Vigtigere end at se ledig plads er at sikre, at planlagt defragmentering er aktiveret, hvor det er relevant (ikke på SSD'er), så du aldrig kommer til det punkt, hvor det bliver dybt nok til at påvirke dig.
Der er en sidste ting værd at nævne. Et af de andre svar her nævnt, at SATAs halv-duplex-tilstand forhindrer læsning og skrivning på samme tid. Selvom det er sandt, er dette meget forenklet og hænger for det meste ikke sammen med de præstationsproblemer, der diskuteres her. Hvad dette betyder, er, at data ikke kan overføres i begge retninger på ledningen på samme tid. SATA har dog en ret kompleks specifikation involverer små maksimale blokstørrelser (ca. 8 kB pr. blok på ledningen, tror jeg), læse og skrive operationskøer osv. og udelukker ikke, at skrivning til buffere sker, mens læsning er i gang, sammenflettede operationer osv.
Enhver blokering, der opstår, skyldtes konkurrence om fysiske ressourcer, normalt mildnet af masser af cache. SATA's duplex-tilstand er næsten fuldstændig irrelevant her.
(EN) ”Langsomt ned” er et bredt udtryk. Her bruger jeg det til at henvise til ting, der enten er I / O-bundet (dvs. hvis din computer sidder der og knuser tal, har indholdet af harddisken ingen indflydelse) eller CPU-bundet og konkurrerer med tangentielt relaterede ting, der har høj CPU-brug (dvs. antivirussoftware, der scanner masser af filer).
(B) SSD'er påvirkes af fragmentering, idet sekventiel adgangshastighed generelt er hurtigere end tilfældig adgang, på trods af SSD'er, der ikke står over for de samme begrænsninger som en mekanisk enhed (selv da garanterer manglende fragmentering ikke sekventiel adgang på grund af slidudjævning osv.). Men i stort set alle generelle brugsscenarier er dette et ikke-problem. Ydelsesforskelle på grund af fragmentering på SSD'er er typisk ubetydelige for ting som f.eks. At indlæse applikationer, starte computeren osv.
(C) Antages et sundt filsystem, der ikke fragmenterer filer med vilje.
Sørg for at læse resten af den livlige diskussion på SuperUser via nedenstående link!
Har du noget at tilføje til forklaringen? Lyd fra i kommentarerne. Vil du læse flere svar fra andre teknisk kyndige Stack Exchange-brugere? Tjek den fulde diskussionstråd her .
