Hvordan sjekker jeg inode-bruk i HestiaCP? Hva forårsaker manglende evne til å skrive filer selv når det er rikelig med diskplass?

For et par dager siden sendte en venn meg en melding sent på kvelden der han sa at serveren hans hadde krasjet.

De spesifikke symptomene var spesielt bisarre: nettstedet begynte plutselig å gi feilmeldinger, logger kunne ikke skrives, og når man opprettet nye filer, varslet det umiddelbart om at disken var full.

Men da han sjekket med `df -h`, ble han sjokkert over å oppdage at disken tydeligvis hadde flere titalls gigabyte ledig plass. Hvordan kunne den være full?

Jeg sa til ham der og da: «Bror, du har ikke bare full av lagringsplass, inoden din er overbelastet.»

Han svarte med et spørsmålstegn: Hva er egentlig en inode?

Faktisk reagerer mange på akkurat samme måte som han gjorde da de først falt i denne fellen, fordi ingen på skolen noen gang lærte dem dette.

La oss først avklare hva en inode er.

Tenk på det som et bibliotekregisterkort, så blir det lett å forstå.

Diskplass er som en bokhylle; hvor mange bøker du kan legge på den avhenger av kapasiteten, som er lett for alle å forstå.

En inode er som et indekskort for hver bok, som registrerer navn, plassering og hvem som flyttet den.

I Linux må hver fil og hver katalog oppta en inode, uansett hvor liten filen er.

Selv om det er en tom fil, vil systemet fortsatt bruke et indekskort for den.

Systemet har en grense for det totale antallet filer det kan opprette; denne grensen er det totale antallet innoder.

Når inoden er brukt opp, selv om disken din fortsatt har hundrevis av gigabyte ledig plass, vil operativsystemet nekte å opprette nye filer.

Logger kan ikke skrives, hurtigbuffer kan ikke opprettes, og nettstedet krasjer fullstendig – det er den bisarre scenen du er vitne til.

Ærlig talt, dette er en veldig vanskelig situasjon fordi feilmeldingen sendes fra et sted du ikke ser på.

Det første trikset er å bruke `df -i` for å få en rask oversikt.

I HestiaCP- miljøet kan du ganske enkelt SSH-e inn i terminalen og skrive denne linjen.

df -i

Den vil liste opp det totale antallet innoder, antallet som brukes og antallet som gjenstår for hver monterte partisjon.

I utdataene er det en kolonne kalt IUse%, som er nøkkelmålingen du bør holde øye med.

Hvis IUse%-en til en partisjon når 100 %, selv om partisjonen fortsatt har god diskplass, vil den ikke lenger kunne opprette nye filer eller logger.

Jeg foreslo til vennen min at han skulle kjøre dette først, slik at den kunne finne ut om problemet var med inoden på et sekund , noe som ville være mye raskere enn å gjette.

Den andre metoden er å bruke «finn» for å telle en bestemt bruker nøyaktig.

Etter å ha bekreftet at problemet ligger i innoden, er neste trinn å finne ut hvem som bruker indekskortet i overkant.

HestiaCP har en egen hjemmekatalog for hver bruker. Du kan ganske enkelt telle det totale antallet filer og kataloger under en bestemt nettstedkatalog.

find /home/用户名/web/你的域名/public_html | wc -l

Erstatt «brukernavn» og «ditt domenenavn» med din faktiske bane. Det rene tallet som returneres av terminalen er summen av alle filer og mapper i den katalogen.

Hver fil eller katalog tilsvarer én inode, så dette tallet representerer inode-bruken.

Hvis du er for lat til å sjekke hver enkelt individuelt og vil se bruksfordelingen til alle brukere på hele nettstedet samtidig, finnes det også en kommando med én løkke.

for d in /home/*; do echo -n "$d: "; find "$d" 2>/dev/null | wc -l; done

Denne linjen vil skrive ut det totale antallet filer i hver brukerkatalog under /home, noe som gjør det enkelt å se hvilken brukerkatalog som har et unormalt høyt antall filer.

Den tredje strategien er å identifisere underkatalogene som forbruker mest jod.

Noen ganger vet du at et nettsted har latterlig høye inode-verdier, men du kan fortsatt ikke finne ut hva som er galt med skjermen full av filer.

I slike tilfeller må du bore deg ned ett nivå for å finne undermapper som inneholder et stort antall små filer, for eksempel hurtigbufferkataloger, øktkataloger og loggkataloger – dette er de mest problematiske områdene.

find /home/用户名/web/你的域名/public_html -type d -exec sh -c 'echo -n "{}: "; find "{}" -maxdepth 1 | wc -l' \; | sort -n -r -k 2 | head -n 10

Denne kommandoen vil liste opp de 10 undermappene som bruker flest filer.

Stien helt øverst på listen er der et stort antall små filer er gruppert sammen.

Jeg fortalte vennen min at det sannsynligvis var en eller annen hurtigbuffer-plugin som i hemmelighet genererte små filer, og at det å kjøre denne linjen i bunn og grunn ville bekrefte det.

Det fjerde tipset er å sjekke kvotegrensen ved hjelp av repquota.

Hvis serveren din har aktivert Linux-filsystemkvoter, kan du se på problemet fra et annet perspektiv.

repquota -a

Denne kommandoen vil hente opp filgrensen og faktisk filbruk for alle brukere.

Vær nøye med delen Filgrenser i utdataene; kolonnen «brukt» angir hvor mange filer som er brukt.

Kolonnene «myk» og «hard» representerer terskelverdiene for myk og hard. Når «brukt» når «hard», vil systemet direkte nekte å opprette nye filer.

Dette er en helt annen historie enn hvor mye plass du har igjen på disken din.

For å oppsummere, la oss koble sammen prikkene i etterforskningen.

La oss gå tilbake til vennen som krasjet serveren midt på natten i begynnelsen.

Han fulgte de fire trinnene jeg beskrev, og startet med `df -i` for å bekrefte at inoden faktisk var full.

Deretter, ved hjelp av finn-metoden, ble det funnet at en hurtigbufferkatalog på et forlatt gammelt nettsted genererte små filer som gale.

Til slutt bekreftet sjekkingen av `repquota` at den faktisk hadde nådd den harde grensen.

Etter å ha tømt den haugen med søppelbuffer, våknet nettsiden umiddelbart til liv igjen.

Så neste gang du støter på denne merkelige situasjonen der «disken tydeligvis har plass, men du kan ikke skrive filer», ikke forhast deg med å legge til en harddisk.

Bruk først `df -i` for å se på inoden; sannheten kan godt være skjult på det indekskortet du aldri har lagt merke til før.

Jeg tror virkelig at disse små bitene av sunn fornuft som er gjemt i systemets kjerne er mer nyttige enn å memorere hundre optimaliseringslister.