Hoe kan ek inode-gebruik in HestiaCP nagaan? Wat veroorsaak die onvermoë om lêers te skryf selfs wanneer daar genoeg skyfspasie is?

'n Paar dae gelede het 'n vriend my laat in die nag 'n boodskap gestuur en gesê dat sy bediener ineengestort het.

Die spesifieke simptome was besonder bisar: die webwerf het skielik foute begin gee, logs kon nie geskryf word nie, en die skep van nuwe lêers het onmiddellik aangedui dat die skyf vol is.

Maar toe hy met `df -h` nagegaan het, was hy geskok om te vind dat die skyf duidelik tientalle gigagrepe vrye spasie gehad het. Hoe kon dit vol wees?

Ek het hom daar en dan gesê: "Broer, jy is nie net vol stoorplek nie, jou Inode is oorlaai."

Hy het met 'n vraagteken geantwoord: Wat presies is 'n Inode?

Trouens, baie mense reageer presies dieselfde as hy toe hulle die eerste keer in hierdie strik geval het, want niemand op skool het hulle ooit hierdie dinge geleer nie.

Kom ons verduidelik eers wat 'n Inode is.

Dink daaraan as 'n biblioteekindekskaart, en dit sal maklik wees om te verstaan.

Skyfspasie is soos 'n boekrak; hoeveel boeke jy daarop kan sit, hang af van die kapasiteit daarvan, wat vir almal maklik is om te verstaan.

'n Inode is soos 'n indekskaart vir elke boek, wat die naam, ligging en wie dit geskuif het, opteken.

In Linux moet elke lêer en elke gids 'n inode beset, ongeag hoe klein die lêer is.

Selfs al is dit 'n leë lêer, sal die stelsel steeds 'n indekskaart daarvoor gebruik.

Die stelsel het 'n beperking op die totale aantal lêers wat dit kan skep; hierdie beperking is die totale aantal innodusse.

Sodra die inode opgebruik is, selfs al het jou skyf nog honderde gigagrepe vrye spasie, sal die bedryfstelsel weier om enige nuwe lêers te skep.

Logboeke kan nie geskryf word nie, kasgeheue kan nie geskep word nie, en die webwerf stort heeltemal in duie – dis die bisarre toneel wat jy sien.

Eerlikwaar, dit is 'n baie moeilike situasie, want die foutboodskap word gestuur vanaf 'n plek waarna jy nie kyk nie.

Die eerste truuk is om `df -i` te gebruik om 'n vinnige oorsig te kry.

In die HestiaCP- omgewing kan jy eenvoudig SSH in die terminaal invoer en hierdie lyn tik.

df -i

Dit sal die totale aantal innodusse, die aantal wat gebruik word en die aantal wat oorbly vir elke gemonteerde partisie lys.

In die uitvoer is daar 'n kolom genaamd IUse%, wat die sleutelmetriek is wat jy moet dophou.

As die IUse% van 'n partisie 100% bereik, selfs al het daardie partisie steeds genoeg skyfspasie, sal dit nie meer enige nuwe lêers of logs kan skep nie.

Ek het aan my vriend voorgestel dat hy dit eers laat loop, sodat dit binne 'n sekonde kon vasstel of die probleem met die Inode was , wat baie vinniger sou wees as om te raai.

Die tweede metode is om `find` te gebruik om 'n spesifieke gebruiker presies te tel.

Nadat bevestig is dat die probleem met die innode is, is die volgende stap om uit te vind wie die indekskaart oormatig verbruik.

HestiaCP het 'n aparte tuisgids vir elke gebruiker. Jy kan eenvoudig die totale aantal lêers en gidse onder 'n spesifieke webwerfgids tel.

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

Vervang "gebruikersnaam" en "jou domeinnaam" met jou werklike pad. Die suiwer getal wat deur die terminaal teruggegee word, is die som van alle lêers en gidse in daardie gids.

Elke lêer of gids stem ooreen met een inode, dus verteenwoordig hierdie getal die inode-gebruik.

As jy te lui is om elkeen individueel na te gaan en die gebruiksverspreiding van alle gebruikers oor die hele webwerf gelyktydig wil sien, is daar ook 'n enkele lusopdrag.

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

Hierdie lyn sal die totale aantal lêers in elke gebruikersgids onder /home druk, wat dit maklik maak om te sien watter gebruikersgids 'n abnormaal hoë aantal lêers het.

Die derde strategie is om die subgidse te identifiseer wat die meeste jodium verbruik.

Soms weet jy 'n webwerf het belaglik hoë Inode-waardes, maar jy kan steeds nie uitvind wat fout is met die skerm vol lêers nie.

In sulke gevalle moet jy een vlak afwaarts boor om subgidse te vind wat 'n groot aantal klein lêers bevat, soos kasgidse, sessiegidse en loggidse – dit is die mees problematiese areas.

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

Hierdie opdrag sal die top 10 subgidse lys wat die meeste lêers verbruik.

Die pad heel bo-aan die lys is waar 'n groot aantal klein lêers saamgegroepeer is.

Ek het vir my vriend gesê dat dit waarskynlik 'n kas-inprop was wat in die geheim klein lêers genereer, en om hierdie lyn uit te voer, sou dit basies bevestig.

Die vierde wenk is om die kwotalimiet met behulp van repquota na te gaan.

As jou bediener Linux-lêerstelselkwotas geaktiveer het, kan jy die probleem vanuit 'n ander perspektief beskou.

repquota -a

Hierdie opdrag sal die lêerlimiet en werklike lêergebruik vir alle gebruikers opspoor.

Gee noukeurig aandag aan die afdeling Lêerlimiete in die uitvoer; die kolom wat gebruik is, dui aan hoeveel lêers gebruik is.

Die "sagte" en "harde" kolomme verteenwoordig die sagte en harde limietdrempels. Sodra "gebruik" "hard" bereik, sal die stelsel direk weier om nuwe lêers te skep.

Dit is 'n heeltemal ander storie as hoeveel spasie jy op jou skyf oor het.

Om dinge af te sluit, kom ons verbind die kolletjies van die ondersoek.

Kom ons gaan terug na die vriend wat die bediener in die middel van die nag aan die begin laat neerstort het.

Hy het die vier stappe wat ek beskryf het, gevolg, beginnende met `df -i` om te bevestig dat die inode inderdaad vol was.

Toe, met behulp van find, het ons die kasgids van 'n verlate ou webwerf opgespoor wat klein lêers soos mal gegenereer het.

Uiteindelik het die kontrolering van `repquota` bevestig dat dit inderdaad die harde limiet bereik het.

Nadat daardie hoop rommelkasgeheue uitgevee is, het die webwerf onmiddellik weer lewendig geword.

So volgende keer as jy hierdie vreemde situasie teëkom waar "die skyf duidelik spasie het, maar jy kan nie lêers skryf nie," moenie haastig wees om 'n hardeskyf by te voeg nie.

Gebruik eers `df -i` om na die inode te kyk; die waarheid mag dalk versteek wees op daardie indekskaart wat jy nog nooit tevore opgemerk het nie.

Ek glo werklik dat hierdie klein stukkies gesonde verstand wat in die kern van die stelsel versteek is, nuttiger is as om 'n honderd optimaliseringslyste te memoriseer.