Come faccio a controllare l'utilizzo degli inode in HestiaCP? Cosa impedisce la scrittura dei file anche in presenza di ampio spazio su disco?

Un paio di giorni fa, un amico mi ha mandato un messaggio a tarda notte dicendomi che il suo server era andato in crash.

I sintomi specifici erano particolarmente bizzarri: il sito web ha improvvisamente iniziato a generare errori, non era possibile scrivere i log e la creazione di nuovi file segnalava immediatamente che il disco era pieno.

Ma quando controllò con `df -h`, rimase scioccato nello scoprire che il disco aveva chiaramente decine di gigabyte di spazio libero. Com'era possibile che fosse pieno?

Gli dissi subito: "Fratello, non solo hai spazio di archiviazione esaurito, ma il tuo Inode è sovraccarico."

Lui rispose con un punto interrogativo: Che cos'è esattamente un Inode?

In realtà, molte persone reagiscono esattamente come lui quando cadono per la prima volta in questa trappola, perché nessuno a scuola ha mai insegnato loro queste cose.

Chiariamo innanzitutto cos'è un Inode.

Pensatela come una scheda di un catalogo di biblioteca, e vi sarà facile capirla.

Lo spazio su disco è come una libreria: il numero di libri che si possono riporre dipende dalla sua capacità, cosa che è facile da capire per tutti.

Un inode è come una scheda indice per ogni libro, che ne registra il nome, la posizione e chi lo ha spostato.

In Linux , ogni file e ogni directory devono occupare un inode, indipendentemente dalle dimensioni del file.

Anche se si tratta di un file vuoto, il sistema consumerà comunque una scheda indice per esso.

Il sistema ha un limite al numero totale di file che può creare; questo limite corrisponde al numero totale di innodi.

Una volta esaurito lo spazio occupato dall'inode, anche se sul disco sono ancora disponibili centinaia di gigabyte di spazio libero, il sistema operativo si rifiuterà di creare nuovi file.

Non è possibile scrivere i log, non è possibile creare la cache e il sito web si blocca completamente: questa è la bizzarra scena a cui state assistendo.

Onestamente, questa è una situazione davvero complicata perché il messaggio di errore viene inviato da una posizione che non stai guardando.

Il primo trucco è usare `df -i` per ottenere una panoramica completa.

Nell'ambiente HestiaCP , è sufficiente accedere al terminale tramite SSH e digitare questa riga.

df -i

Verrà visualizzato il numero totale di inno, il numero di inno, il numero di inno, e il numero di inno, per ciascuna partizione montata.

Nell'output è presente una colonna denominata IUse%, che rappresenta la metrica chiave da tenere d'occhio.

Se l'IUse% di una partizione raggiunge il 100%, anche se tale partizione dispone ancora di molto spazio su disco, non sarà più in grado di creare nuovi file o log.

Ho suggerito al mio amico di eseguire prima questo test, in modo da poter individuare in un secondo se il problema risiedeva nell'inode , il che sarebbe stato molto più veloce che procedere per tentativi.

Il secondo metodo consiste nell'utilizzare la funzione `find` per contare con precisione un utente specifico.

Dopo aver confermato che il problema risiede nell'innode, il passo successivo è scoprire chi sta utilizzando eccessivamente la scheda indice.

HestiaCP ha una directory home separata per ogni utente. È sufficiente contare il numero totale di file e directory presenti nella directory di un sito web specifico.

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

Sostituisci "username" e "your domain name" con il tuo percorso effettivo. Il numero puro restituito dal terminale è la somma di tutti i file e le cartelle presenti in quella directory.

Ogni file o directory corrisponde a un inode, quindi questo numero rappresenta l'utilizzo degli inode.

Se siete troppo pigri per controllare ognuno singolarmente e volete vedere la distribuzione di utilizzo di tutti gli utenti sull'intero sito contemporaneamente, esiste anche un singolo comando di ciclo.

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

Questa riga visualizzerà il numero totale di file in ogni directory utente sotto /home, rendendo facile individuare quale directory utente ha un numero di file insolitamente elevato.

La terza strategia consiste nell'identificare le sottocartelle che consumano più iodio.

A volte si nota che un sito web ha valori di Inode incredibilmente alti, ma non si riesce comunque a capire cosa c'è che non va in quella schermata piena di file.

In questi casi, è necessario scendere di un livello per trovare le sottocartelle che contengono un gran numero di file di piccole dimensioni, come le directory della cache, le directory di sessione e le directory dei log: queste sono le aree più problematiche.

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

Questo comando elencherà le 10 sottocartelle che occupano più file.

Il percorso in cima all'elenco è quello in cui sono raggruppati un gran numero di file di piccole dimensioni.

Ho detto al mio amico che probabilmente si trattava di qualche plugin di caching che generava segretamente piccoli file, e che eseguendo questa riga si avrebbe sostanzialmente la conferma.

Il quarto consiglio è di verificare il limite di quota utilizzando repquota.

Se sul tuo server sono abilitate le quote del file system Linux, puoi esaminare il problema da una prospettiva diversa.

repquota -a

Questo comando visualizzerà il limite di file e l'utilizzo effettivo dei file per tutti gli utenti.

Presta molta attenzione alla sezione Limiti file nell'output; la colonna "Utilizzato" indica quanti file sono stati utilizzati.

Le colonne "soft" e "hard" rappresentano le soglie limite, rispettivamente morbida e rigida. Una volta che il valore di "used" raggiunge il valore di "hard", il sistema si rifiuterà immediatamente di creare nuovi file.

Questa è una questione completamente diversa rispetto a quanto spazio libero hai sul disco.

Per concludere, colleghiamo i punti dell'indagine.

Torniamo all'amico che all'inizio ha mandato in crash il server nel cuore della notte.

Ha seguito i quattro passaggi che ho descritto, iniziando con `df -i` per confermare che l'inode fosse effettivamente pieno.

Successivamente, utilizzando il comando find, abbiamo individuato la directory della cache di un vecchio sito web abbandonato che generava file di piccole dimensioni a un ritmo allarmante.

Infine, controllando `repquota` è stato confermato che era stato effettivamente raggiunto il limite massimo.

Dopo aver eliminato quella montagna di file inutili dalla cache, il sito web è tornato immediatamente online.

Quindi, la prossima volta che vi imbattete in questa strana situazione in cui "il disco ha chiaramente spazio ma non è possibile scrivere file", non affrettatevi ad aggiungere un disco rigido.

Innanzitutto, usa il comando `df -i` per dare un'occhiata all'inode; la verità potrebbe benissimo essere nascosta su quella scheda che non avevi mai notato prima.

Credo sinceramente che questi piccoli accorgimenti di buon senso, nascosti nel cuore del sistema, siano più utili che memorizzare un centinaio di elenchi di ottimizzazione.