Hur kontrollerar jag inode-användning i HestiaCP? Vad orsakar oförmågan att skriva filer även när det finns gott om diskutrymme?

För ett par dagar sedan skickade en vän ett meddelande till mig sent på kvällen och sa att hans server hade kraschat.

De specifika symptomen var särskilt bisarra: webbplatsen började plötsligt visa felmeddelanden, loggar kunde inte skrivas och när nya filer skapades visade det sig omedelbart att disken var full.

Men när han kontrollerade med `df -h` blev han chockad över att disken uppenbarligen hade tiotals gigabyte ledigt utrymme. Hur kunde den vara full?

Jag sa till honom just då och där: "Broder, du har inte bara fullt av lagringsutrymme, din Inode är överbelastad."

Han svarade med ett frågetecken: Vad är egentligen en inode?

Faktum är att många människor reagerar precis på samma sätt som han gjorde när de först föll i den här fällan, eftersom ingen i skolan någonsin lärde dem detta.

Låt oss först klargöra vad en inode är.

Tänk på det som ett registerkort från biblioteket, så blir det lätt att förstå.

Diskutrymme är som en bokhylla; hur många böcker du kan lägga på den beror på dess kapacitet, vilket är lätt för alla att förstå.

En inode är som ett indexkort för varje bok, där dess namn, plats och vem som flyttade den anges.

I Linux måste varje fil och varje katalog uppta en inode, oavsett hur liten filen är.

Även om det är en tom fil kommer systemet fortfarande att använda ett indexkort för den.

Systemet har en gräns för det totala antalet filer det kan skapa; denna gräns är det totala antalet innoder.

När inoden är slut, även om din disk fortfarande har hundratals gigabyte ledigt utrymme, kommer operativsystemet att vägra att skapa några nya filer.

Loggar kan inte skrivas, cache kan inte skapas och webbplatsen kraschar helt – det är den bisarra scenen du bevittnar.

Ärligt talat är det här en riktigt knepig situation eftersom felmeddelandet skickas från en plats du inte tittar på.

Det första knepet är att använda `df -i` för att få en snabb översikt.

I HestiaCP- miljön kan du helt enkelt SSH-a in i terminalen och skriva den här raden.

df -i

Den listar det totala antalet innoder, antalet som används och antalet som återstår för varje monterad partition.

I utdata finns en kolumn som heter IUse%, vilket är det viktigaste måttet du bör hålla koll på.

Om IUse% för en partition når 100%, även om partitionen fortfarande har gott om diskutrymme, kommer den inte längre att kunna skapa några nya filer eller loggar.

Jag föreslog för min vän att han skulle köra detta först, så att den kunde fastställa om problemet låg i inoden på en sekund , vilket skulle vara mycket snabbare än att gissa.

Den andra metoden är att använda `find` för att exakt räkna en specifik användare.

Efter att ha bekräftat att problemet ligger i innoden är nästa steg att ta reda på vem som konsumerar indexkortet i överdrivet hög grad.

HestiaCP har en separat hemkatalog för varje användare. Du kan helt enkelt räkna det totala antalet filer och kataloger under en specifik webbplatskatalog.

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

Ersätt "användarnamn" och "ditt domännamn" med din faktiska sökväg. Det rena numret som returneras av terminalen är summan av alla filer och mappar i den katalogen.

Varje fil eller katalog motsvarar en inod, så detta nummer representerar inodanvändningen.

Om du är för lat för att kontrollera var och en individuellt och vill se användningsfördelningen för alla användare över hela webbplatsen samtidigt, finns det också ett single loop-kommando.

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

Den här raden skriver ut det totala antalet filer i varje användarkatalog under /home, vilket gör det enkelt att se vilken användarkatalog som har ett onormalt högt antal filer.

Den tredje strategin är att identifiera de underkataloger som förbrukar mest jod.

Ibland vet man att en webbplats har löjligt höga Inode-värden, men man kan fortfarande inte lista ut vad som är fel med skärmen full av filer.

I sådana fall behöver du gå ner en nivå för att hitta undermappar som innehåller ett stort antal små filer, till exempel cachekataloger, sessionskataloger och loggkataloger – det här är de mest problematiska områdena.

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

Det här kommandot listar de 10 undermappar som använder flest filer.

Sökvägen högst upp i listan är där ett stort antal små filer är klustrade tillsammans.

Jag sa till min vän att det förmodligen var någon cachning-plugin som i hemlighet genererade små filer, och att köra den här raden skulle i princip bekräfta det.

Det fjärde tipset är att kontrollera kvotgränsen med hjälp av repquota.

Om din server har aktiverade Linux-filsystemskvoter kan du se på problemet från ett annat perspektiv.

repquota -a

Det här kommandot visar filgränsen och den faktiska filanvändningen för alla användare.

Var noga med avsnittet Filgränser i utdata; kolumnen "Använda" anger hur många filer som har använts.

Kolumnerna "mjuk" och "hård" representerar tröskelvärdena för mjuk och hård gräns. När "använd" når "hård" kommer systemet direkt att vägra att skapa nya filer.

Det här är en helt annan historia än hur mycket utrymme du har kvar på din disk.

För att sammanfatta saken, låt oss koppla ihop punkterna i utredningen.

Låt oss gå tillbaka till vännen som kraschade servern mitt i natten i början.

Han följde de fyra stegen jag beskrev, och började med `df -i` för att bekräfta att inoden verkligen var full.

Sedan, med hjälp av find, lokaliserade vi cachekatalogen för en övergiven gammal webbplats som genererade små filer som galningar.

Slutligen bekräftade kontrollen av `repquota` att den verkligen hade nått den hårda gränsen.

Efter att ha rensat bort den där högen med skräpcache, väcktes webbplatsen omedelbart till liv igen.

Så nästa gång du stöter på den här konstiga situationen där "disken uppenbarligen har utrymme men du kan inte skriva filer", skynda dig inte att lägga till en hårddisk.

Använd först `df -i` för att titta på inoden; sanningen kan mycket väl vara dold på det där indexkortet du aldrig lagt märke till förut.

Jag tror verkligen att dessa små bitar av sunt förnuft som är gömda i systemets kärna är mer användbara än att memorera hundra optimeringslistor.