Cum verific utilizarea inode-urilor în HestiaCP? Ce cauzează incapacitatea de a scrie fișiere chiar și atunci când există suficient spațiu pe disc?

Acum câteva zile, un prieten mi-a trimis un mesaj târziu în noapte spunând că serverul lui s-a blocat.

Simptomele specifice erau deosebit de bizare: site-ul web a început brusc să afișeze erori, jurnalele nu puteau fi scrise, iar crearea de fișiere noi semnala imediat că discul era plin.

Dar când a verificat cu `df -h`, a fost șocat să constate că discul avea în mod clar zeci de gigaocteți de spațiu liber. Cum ar putea fi plin?

I-am spus chiar atunci: „Frate, nu ești doar plin de spațiu de stocare, ci și Inode-ul tău e supraîncărcat.”

El a răspuns cu un semn de întrebare: Ce este mai exact un Inode?

De fapt, mulți oameni reacționează exact la fel cum a reacționat el când au căzut prima dată în această capcană, pentru că nimeni din școală nu i-a învățat vreodată aceste lucruri.

Să clarificăm mai întâi ce este un Inode.

Gândește-te la asta ca la o fișă de bibliotecă și va fi ușor de înțeles.

Spațiul pe disc este ca un raft de cărți; câte cărți poți pune pe el depinde de capacitatea sa, ceea ce este ușor de înțeles pentru toată lumea.

Un inode este ca o fișă index pentru fiecare carte, înregistrând numele acesteia, locația și cine a mutat-o.

În Linux , fiecare fișier și fiecare director trebuie să ocupe un inode, indiferent cât de mic este fișierul.

Chiar dacă este un fișier gol, sistemul va consuma în continuare o fișă index pentru acesta.

Sistemul are o limită a numărului total de fișiere pe care le poate crea; această limită este numărul total de innoduri.

Odată ce inode-ul este epuizat, chiar dacă discul mai are sute de gigaocteți de spațiu liber, sistemul de operare va refuza să creeze fișiere noi.

Jurnalele nu pot fi scrise, memoria cache nu poate fi creată, iar site-ul web se blochează complet - aceasta este scena bizară la care asistați.

Sincer, aceasta este o situație foarte dificilă, deoarece mesajul de eroare este trimis dintr-o locație la care nu te uiți.

Primul truc este să folosești `df -i` pentru a obține o imagine de ansamblu rapidă.

În mediul HestiaCP , puteți pur și simplu să vă conectați la terminal prin SSH și să tastați această linie.

df -i

Va lista numărul total de innoduri, numărul utilizat și numărul rămas pentru fiecare partiție montată.

În rezultat, există o coloană numită IUse%, care este metrica cheie pe care ar trebui să o urmăriți.

Dacă IUse%-ul unei partiții ajunge la 100%, chiar dacă acea partiție mai are suficient spațiu pe disc, nu va mai putea crea fișiere sau jurnale noi.

I-am sugerat prietenului meu să ruleze asta mai întâi, astfel încât să poată identifica într-o secundă dacă problema era la Inode , ceea ce ar fi mult mai rapid decât o ghicire.

A doua metodă este de a folosi comanda `find` pentru a număra cu precizie un anumit utilizator.

După confirmarea faptului că problema este la nodul respectiv, următorul pas este de a afla cine consumă excesiv fișa index.

HestiaCP are un director principal separat pentru fiecare utilizator. Puteți pur și simplu număra numărul total de fișiere și directoare dintr-un anumit director de site web.

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

Înlocuiți „nume de utilizator” și „numele domeniului dvs.” cu calea dvs. reală. Numărul pur returnat de terminal este suma tuturor fișierelor și folderelor din directorul respectiv.

Fiecare fișier sau director corespunde unui inode, deci acest număr reprezintă utilizarea inode-ului.

Dacă ești prea leneș să le verifici pe fiecare în parte și vrei să vezi distribuția utilizării de către toți utilizatorii pe întregul site simultan, există și o comandă single loop.

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

Această linie va afișa numărul total de fișiere din fiecare director de utilizator din /home, facilitând identificarea directorului de utilizator care are un număr anormal de mare de fișiere.

A treia strategie este de a identifica subdirectoarele care consumă cel mai mult iod.

Uneori știi că un site web are valori Inode ridicol de mari, dar tot nu poți să-ți dai seama ce este în neregulă cu ecranul plin de fișiere.

În astfel de cazuri, trebuie să detaliați un nivel în jos pentru a găsi subfoldere care conțin un număr mare de fișiere mici, cum ar fi directoarele cache, directoarele de sesiune și directoarele de jurnale - acestea sunt cele mai problematice zone.

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

Această comandă va lista primele 10 subfoldere care consumă cele mai multe fișiere.

Calea din partea de sus a listei este locul unde sunt grupate împreună un număr mare de fișiere mici.

I-am spus prietenului meu că probabil era un plugin de caching care genera în secret fișiere mici, iar rularea acestei linii ar confirma practic acest lucru.

Al patrulea sfat este să verificați limita cotei folosind repquota.

Dacă serverul dvs. are activate cotele sistemului de fișiere Linux, puteți privi problema dintr-o perspectivă diferită.

repquota -a

Această comandă va afișa limita de fișiere și utilizarea reală a fișierelor pentru toți utilizatorii.

Acordați o atenție deosebită secțiunii Limite fișiere din rezultat; coloana utilizată indică câte fișiere au fost utilizate.

Coloanele „soft” și „hard” reprezintă pragurile limitelor soft și hard. Odată ce „used” ajunge la „hard”, sistemul va refuza direct crearea de fișiere noi.

Aceasta este o poveste complet diferită de cât spațiu ți-a mai rămas pe disc.

Pentru a încheia, haideți să facem legătura între aspectele anchetei.

Să ne întoarcem la prietenul care a stricat serverul în toiul nopții, la început.

El a urmat cei patru pași pe care i-am descris, începând cu `df -i` pentru a confirma că inode-ul era într-adevăr plin.

Apoi, folosind funcția „find”, am localizat directorul cache al unui site web vechi abandonat care genera fișiere mici la nebunie.

În cele din urmă, verificarea parametrului `repquota` a confirmat că într-adevăr atinsese limita maximă.

După ce ați golit grămada de memorie cache nedorită, site-ul web a revenit imediat la viață.

Așadar, data viitoare când te confrunți cu această situație ciudată în care „discul are în mod clar spațiu, dar nu poți scrie fișiere”, nu te grăbi să adaugi un hard disk.

Mai întâi, folosește `df -i` pentru a arunca o privire asupra inode-ului; adevărul s-ar putea foarte bine să fie ascuns pe acea fișă index pe care nu ai observat-o niciodată.

Cred cu adevărat că aceste mici fărâme de bun simț ascunse în miezul sistemului sunt mai utile decât memorarea a o sută de liste de optimizare.