Hoe kin ik it gebrûk fan inode kontrolearje yn HestiaCP? Wat feroarsaket it ûnfermogen om bestannen te skriuwen, sels as der genôch skiifromte is?

In pear dagen lyn stjoerde in freon my let yn 'e jûn in berjocht dat syn server crasht wie.

De spesifike symptomen wiene benammen bizar: de webside begon ynienen flaters te jaan, logs koene net skreaun wurde, en it oanmeitsjen fan nije bestannen joech fuortendaliks oan dat de skiif fol wie.

Mar doe't er kontrolearre mei `df -h`, wie er skrokken om te ûntdekken dat de skiif dúdlik tsientallen gigabytes oan frije romte hie. Hoe koe er fol wêze?

Ik sei him doe en dêr direkt: "Broer, do sitst net allinnich fol mei opslachromte, dyn Inode is oerladen."

Hy antwurde mei in fraachteken: Wat is no krekt in Inode?

Eins reagearje in protte minsken krekt itselde as hy doe't se foar it earst yn dizze fal foelen, om't nimmen op skoalle har dit guod ea leard hat.

Litte wy earst dúdlik meitsje wat in Inode is.

Tink derom as in bibleteek-yndekskaart, en it sil maklik te begripen wêze.

Skiifromte is as in boekenplank; hoefolle boeken jo derop sette kinne hinget ôf fan syn kapasiteit, wat foar elkenien maklik te begripen is.

In inode is as in yndekskaart foar elk boek, mei de namme, lokaasje en wa't it ferpleatst hat.

Yn Linux moat elk bestân en elke map in inode ynnimme, nettsjinsteande hoe lyts it bestân is.

Sels as it in leech bestân is, sil it systeem noch in yndekskaart derfoar brûke.

It systeem hat in limyt oan it totale oantal bestannen dat it oanmeitsje kin; dizze limyt is it totale oantal innodes.

As de inode ienris op is, sels as jo skiif noch hûnderten gigabytes oan frije romte hat, sil it bestjoeringssysteem wegerje om nije bestannen oan te meitsjen.

Logs kinne net skreaun wurde, cache kin net oanmakke wurde, en de webside crasht folslein - dat is it bizarre tafriel dat jo sjogge.

Earlik sein, dit is in echt lestige situaasje, om't it flaterberjocht ferstjoerd wurdt fan in lokaasje wêr't jo net nei sjogge.

De earste trúk is om `df -i` te brûken om in fluch oersjoch te krijen.

Yn 'e HestiaCP- omjouwing kinne jo gewoan SSH yn 'e terminal brûke en dizze rigel typen.

df -i

It sil it totale oantal innodes, it brûkte oantal en it oerbleaune oantal foar elke monteare partysje listje.

Yn 'e útfier is d'r in kolom mei de namme IUse%, dat is de kaaimetriek dy't jo yn 'e gaten hâlde moatte.

As it IUse% fan in partysje 100% berikt, sels as dy partysje noch genôch skiifromte hat, sil it gjin nije bestannen of logs mear oanmeitsje kinne.

Ik stelde myn freon foar om dit earst út te fieren, sadat it yn in sekonde koe fêststelle oft it probleem by de Inode lei , wat folle rapper wêze soe as rieden.

De twadde metoade is om `find` te brûken om in spesifike brûker presys te tellen.

Nei it befêstigjen dat it probleem by de innode leit, is de folgjende stap om út te finen wa't de yndekskaart oermjittich konsumearret.

HestiaCP hat in aparte thúsmap foar elke brûker. Jo kinne gewoan it totale oantal bestannen en mappen telle ûnder in spesifike websidemap.

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

Ferfang "brûkersnamme" en "jo domeinnamme" mei jo werklike paad. It suvere getal dat troch de terminal weromjûn wurdt, is de som fan alle bestannen en mappen yn dy map.

Elk bestân of map komt oerien mei ien inode, dus dit nûmer fertsjintwurdiget it inodegebrûk.

As jo ​​te lui binne om elk yndividueel te kontrolearjen en de gebrûksferdieling fan alle brûkers oer de hiele side tagelyk sjen wolle, is d'r ek in kommando foar in inkele lus.

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

Dizze rigel sil it totale oantal bestannen yn elke brûkersmap ûnder /home printsje, wêrtroch it maklik is om te sjen hokker brûkersmap in abnormaal heech oantal bestannen hat.

De tredde strategy is om de submappen te identifisearjen dy't it measte jodium konsumearje.

Soms wite jo dat in webside bespotlik hege Inode-wearden hat, mar jo kinne noch altyd net útfine wat der mis is mei it skerm fol mei bestannen.

Yn sokke gefallen moatte jo ien nivo nei ûnderen boarje om submappen te finen dy't in grut oantal lytse bestannen befetsje, lykas cache-mappen, sesjemappen en logmappen - dit binne de meast problematyske gebieten.

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

Dit kommando sil de top 10 submappen listje dy't de measte bestannen brûke.

It paad hielendal boppe-oan de list is wêr't in grut oantal lytse bestannen byinoar klustere binne.

Ik fertelde myn freon dat it wierskynlik in caching-plugin wie dy't yn it geheim lytse bestannen generearre, en it útfieren fan dizze rigel soe it yn prinsipe befêstigje.

De fjirde tip is om de kwotumlimyt te kontrolearjen mei repquota.

As jo ​​server Linux-bestânsysteemkwotas ynskeakele hat, kinne jo it probleem fanút in oar perspektyf besjen.

repquota -a

Dit kommando sil de bestânslimyt en it werklike bestânsgebrûk foar alle brûkers ophelje.

Jou goed omtinken oan de seksje Triemlimyten yn 'e útfier; de kolom brûkt jout oan hoefolle bestannen brûkt binne.

De kolommen "sêfte" en "hurde" fertsjintwurdigje de sêfte en hurde limytdrompelwearden. Sadree't "brûkt" "hurde" berikt, sil it systeem direkt wegerje om nije bestannen oan te meitsjen.

Dit is in hiel oar ferhaal as hoefolle romte jo oer hawwe op jo skiif.

Om de saken ôf te sluten, litte wy de punten fan it ûndersyk ferbine.

Litte wy weromgean nei de freon dy't de server midden yn 'e nacht oan it begjin crashte.

Hy folge de fjouwer stappen dy't ik beskreaun haw, begjinnend mei `df -i` om te befestigjen dat de inode yndie fol wie.

Doe, mei help fan find, fûnen wy de cache-map fan in ferlitten âlde webside dy't as gek lytse bestannen generearre.

Uteinlik befêstige it kontrolearjen fan `repquota` dat it yndie de hurde limyt berikt hie.

Nei it opromjen fan dy stapel ûnpostcache kaam de webside fuortendaliks wer ta libben.

Dus de folgjende kear dat jo dizze frjemde situaasje tsjinkomme wêr't "de skiif dúdlik romte hat, mar jo kinne gjin bestannen skriuwe", hoege jo net te haasten om in hurde skiif ta te foegjen.

Brûk earst `df -i` om nei de inode te sjen; de wierheid kin hiel goed ferburgen wêze op dy yndekskaart dy't jo noch noait earder opmurken hawwe.

Ik leau oprjocht dat dizze lytse stikjes sûn ferstân ferburgen yn 'e kearn fan it systeem nuttiger binne as it ûnthâlden fan hûndert optimalisaasjelisten.