Hoe controleer ik het inode-gebruik in HestiaCP? Waarom kan ik geen bestanden schrijven, zelfs niet als er voldoende schijfruimte is?

Een paar dagen geleden stuurde een vriend me 's avonds laat een berichtje dat zijn server was vastgelopen.

De specifieke symptomen waren bijzonder bizar: de website begon plotseling foutmeldingen te geven, logbestanden konden niet worden geschreven en bij het aanmaken van nieuwe bestanden werd direct gemeld dat de schijf vol was.

Maar toen hij het controleerde met `df -h`, was hij geschokt te ontdekken dat de schijf duidelijk tientallen gigabytes aan vrije ruimte had. Hoe kon die vol zijn?

Ik zei hem toen meteen: "Broer, je hebt niet alleen een overschot aan opslagruimte, je inode is overbelast."

Hij antwoordde met een vraagteken: Wat is een inode precies?

Sterker nog, veel mensen reageren precies hetzelfde als hij toen ze voor het eerst in deze val trapten, omdat niemand op school ze dit ooit heeft geleerd.

Laten we eerst eens verduidelijken wat een inode is.

Zie het als een indexkaartje in een bibliotheek, dan is het makkelijk te begrijpen.

Schijfruimte is als een boekenplank; hoeveel boeken je erop kunt zetten, hangt af van de capaciteit, wat voor iedereen makkelijk te begrijpen is.

Een inode is als een indexkaart voor elk boek, waarop de naam, de locatie en de persoon die hem heeft verplaatst, staan ​​vermeld.

In Linux moet elk bestand en elke map een inode innemen, ongeacht hoe klein het bestand is.

Zelfs als het een leeg bestand is, zal het systeem er toch een indexkaart voor aanmaken.

Het systeem heeft een limiet aan het totale aantal bestanden dat het kan aanmaken; deze limiet is gelijk aan het totale aantal innodes.

Zodra de inode vol is, zal het besturingssysteem weigeren nieuwe bestanden aan te maken, zelfs als er nog honderden gigabytes aan vrije ruimte op uw schijf beschikbaar zijn.

Er kunnen geen logbestanden worden geschreven, er kan geen cache worden aangemaakt en de website crasht volledig – dat is het bizarre tafereel dat u ziet.

Eerlijk gezegd is dit een erg lastige situatie, omdat het foutbericht wordt verzonden vanaf een locatie waar je niet naar kijkt.

De eerste truc is om `df -i` te gebruiken voor een snel overzicht.

In de HestiaCP -omgeving kunt u eenvoudig via SSH verbinding maken met de terminal en deze regel typen.

df -i

Het programma geeft een overzicht van het totale aantal innodes, het aantal dat in gebruik is en het aantal dat nog over is voor elke aangekoppelde partitie.

In de uitvoer is er een kolom met de naam IUse%, dit is de belangrijkste meetwaarde die u in de gaten moet houden.

Als het IUse%-percentage van een partitie 100% bereikt, zelfs als er nog voldoende schijfruimte beschikbaar is, kan die partitie geen nieuwe bestanden of logbestanden meer aanmaken.

Ik stelde mijn vriend voor om dit eerst uit te voeren, zodat het binnen een seconde kon vaststellen of het probleem bij de inode lag , wat veel sneller zou zijn dan gokken.

De tweede methode is om `find` te gebruiken om een ​​specifieke gebruiker nauwkeurig te tellen.

Nadat is vastgesteld dat het probleem bij de innode ligt, is de volgende stap om te achterhalen wie de indexkaart overmatig gebruikt.

HestiaCP heeft voor elke gebruiker een aparte thuismap. Je kunt eenvoudig het totale aantal bestanden en mappen in een specifieke website-directory tellen.

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

Vervang "gebruikersnaam" en "uw domeinnaam" door het daadwerkelijke pad. Het getal dat de terminal weergeeft, is de som van alle bestanden en mappen in die directory.

Elk bestand of elke map komt overeen met één inode, dus dit getal geeft het inodegebruik weer.

Als je te lui bent om ze allemaal afzonderlijk te controleren en de gebruiksverdeling van alle gebruikers over de hele site in één oogopslag wilt zien, is er ook een enkele lusopdracht beschikbaar.

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

Deze regel print het totale aantal bestanden in elke gebruikersmap onder /home, waardoor het gemakkelijk is om te zien welke gebruikersmap een abnormaal hoog aantal bestanden bevat.

De derde strategie is het identificeren van de subdirectories die het meeste jodium verbruiken.

Soms weet je dat een website belachelijk hoge Inode-waarden heeft, maar kun je nog steeds niet achterhalen wat er mis is met het scherm vol bestanden.

In dergelijke gevallen moet u een niveau dieper graven om submappen te vinden die een groot aantal kleine bestanden bevatten, zoals cachemappen, sessiemappen en logmappen – dit zijn de meest problematische gebieden.

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

Met dit commando worden de 10 submappen weergegeven die de meeste bestanden bevatten.

Het pad helemaal bovenaan de lijst is waar een groot aantal kleine bestanden bij elkaar staan.

Ik vertelde mijn vriend dat het waarschijnlijk een of andere caching-plugin was die stiekem kleine bestanden genereerde, en dat het uitvoeren van deze regel dat in principe zou bevestigen.

De vierde tip is om de quotalimiet te controleren met behulp van repquota.

Als uw server Linux-bestandssysteemquota heeft ingeschakeld, kunt u het probleem vanuit een ander perspectief bekijken.

repquota -a

Met dit commando worden de bestandslimiet en het actuele bestandsgebruik voor alle gebruikers weergegeven.

Let goed op het gedeelte 'Bestandslimieten' in de uitvoer; de kolom 'Gebruikt' geeft aan hoeveel bestanden er zijn gebruikt.

De kolommen "soft" en "hard" geven de zachte en harde limietdrempels aan. Zodra "used" de waarde "hard" bereikt, weigert het systeem direct nieuwe bestanden aan te maken.

Dit is een totaal ander verhaal dan hoeveel schijfruimte je nog hebt.

Laten we tot slot de verschillende onderdelen van het onderzoek samenvatten.

Laten we teruggaan naar de vriend die midden in de nacht de server platlegde, zoals we aan het begin al zagen.

Hij volgde de vier stappen die ik beschreef, te beginnen met `df -i` om te bevestigen dat de inode inderdaad vol was.

Vervolgens werd met behulp van de zoekmethode vastgesteld dat een cachemap van een verlaten, oude website op een ongekende schaal kleine bestanden genereerde.

Tot slot bevestigde een controle van `repquota` dat de harde limiet inderdaad was bereikt.

Nadat ik die berg rommel in de cache had opgeruimd, was de website meteen weer online.

Dus als je de volgende keer in de vreemde situatie terechtkomt dat "er duidelijk ruimte op de schijf is, maar je geen bestanden kunt schrijven", ga dan niet meteen een extra harde schijf installeren.

Gebruik eerst `df -i` om de inode te bekijken; de waarheid zou wel eens verborgen kunnen liggen op dat indexkaartje dat je nog nooit eerder hebt opgemerkt.

Ik ben er oprecht van overtuigd dat deze kleine stukjes gezond verstand, verborgen in de kern van het systeem, nuttiger zijn dan het uit het hoofd leren van honderd optimalisatielijsten.