Com puc comprovar l'ús de l'inode a HestiaCP? Què causa la impossibilitat d'escriure fitxers fins i tot quan hi ha molt d'espai en disc?

Fa un parell de dies, un amic em va enviar un missatge a altes hores de la nit dient que el seu servidor havia fallat.

Els símptomes específics eren particularment estranys: el lloc web va començar a generar errors de sobte, no es podien escriure registres i la creació de nous fitxers indicava immediatament que el disc estava ple.

Però quan ho va comprovar amb `df -h`, es va sorprendre en descobrir que el disc tenia clarament desenes de gigabytes d'espai lliure. Com podia estar ple?

Li vaig dir en aquell mateix moment: "Germà, no només estàs ple d'espai d'emmagatzematge, sinó que el teu Inode està sobrecarregat".

Va respondre amb un signe d'interrogació: Què és exactament un inode?

De fet, molta gent reacciona exactament de la mateixa manera que ell quan va caure en aquest parany, perquè ningú a l'escola els havia ensenyat mai aquestes coses.

Primer aclarim què és un inode.

Pensa-hi com una fitxa d'índex d'una biblioteca i serà fàcil d'entendre.

L'espai en disc és com una prestatgeria; la quantitat de llibres que hi pots posar depèn de la seva capacitat, cosa que tothom pot entendre fàcilment.

Un inode és com una fitxa d'índex per a cada llibre, que registra el seu nom, la ubicació i qui el va moure.

A Linux , cada fitxer i cada directori ha d'ocupar un inode, independentment de la mida del fitxer.

Fins i tot si és un fitxer buit, el sistema encara consumirà una fitxa d'índex.

El sistema té un límit al nombre total de fitxers que pot crear; aquest límit és el nombre total de nodes interns.

Un cop s'hagi esgotat l'inode, fins i tot si el disc encara té centenars de gigabytes d'espai lliure, el sistema operatiu es negarà a crear fitxers nous.

No es poden escriure registres, no es pot crear memòria cau i el lloc web es bloqueja completament: aquesta és l'escena estranya que esteu presenciant.

Sincerament, aquesta és una situació realment complicada perquè el missatge d'error s'envia des d'una ubicació que no esteu mirant.

El primer truc és utilitzar `df -i` per obtenir una visió general completa.

A l'entorn HestiaCP , simplement podeu connectar-vos al terminal per SSH i escriure aquesta línia.

df -i

Enumerarà el nombre total d'innodes, el nombre utilitzat i el nombre restant per a cada partició muntada.

A la sortida, hi ha una columna anomenada IUse%, que és la mètrica clau que heu de tenir en compte.

Si l'IUse% d'una partició arriba al 100%, fins i tot si aquesta partició encara té molt d'espai en disc, ja no podrà crear cap fitxer o registre nou.

Li vaig suggerir al meu amic que executés això primer, de manera que pogués determinar si el problema era amb l'inode en un segon , cosa que seria molt més ràpid que endevinar.

El segon mètode és utilitzar `find` per comptar amb precisió un usuari específic.

Després de confirmar que el problema és amb el node intern, el següent pas és esbrinar qui està consumint la targeta d'índex de manera excessiva.

HestiaCP té un directori d'inici separat per a cada usuari. Simplement podeu comptar el nombre total de fitxers i directoris sota un directori de lloc web específic.

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

Substitueix "nom d'usuari" i "el teu nom de domini" amb la teva ruta real. El nombre pur que retorna el terminal és la suma de tots els fitxers i carpetes d'aquest directori.

Cada fitxer o directori correspon a un inode, de manera que aquest número representa l'ús de l'inode.

Si et fa mandra comprovar-les totes individualment i vols veure la distribució d'ús de tots els usuaris de tot el lloc web alhora, també hi ha una ordre de bucle.

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

Aquesta línia imprimirà el nombre total de fitxers de cada directori d'usuari a /home, cosa que facilita la identificació de quin directori d'usuari té un nombre anormalment alt de fitxers.

La tercera estratègia és identificar els subdirectoris que consumeixen més iode.

De vegades saps que un lloc web té valors d'inode ridículament alts, però encara no pots esbrinar què passa amb la pantalla plena de fitxers.

En aquests casos, cal anar a un nivell inferior per trobar subcarpetes que continguin un gran nombre de fitxers petits, com ara directoris de memòria cau, directoris de sessió i directoris de registre; aquestes són les àrees més problemàtiques.

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

Aquesta ordre llistarà les 10 subcarpetes principals que consumeixen més fitxers.

La ruta que es troba a la part superior de la llista és on s'agrupen un gran nombre de fitxers petits.

Li vaig dir al meu amic que probablement era algun complement de memòria cau que generava en secret fitxers petits, i executar aquesta línia bàsicament ho confirmaria.

El quart consell és comprovar el límit de quota mitjançant repquota.

Si el vostre servidor té les quotes del sistema de fitxers de Linux habilitades, podeu veure el problema des d'una perspectiva diferent.

repquota -a

Aquesta ordre mostrarà el límit de fitxers i l'ús real de fitxers per a tots els usuaris.

Presteu molta atenció a la secció Límits de fitxers de la sortida; la columna utilitzada indica quants fitxers s'han utilitzat.

Les columnes "soft" i "hard" representen els llindars de límit "soft" i "hard". Un cop "used" arriba a "hard", el sistema rebutjarà directament crear nous fitxers.

Això és una història completament diferent de quant espai et queda al disc.

Per concloure, connectem els punts de la investigació.

Tornem a l'amic que va fer fallar el servidor a mitjanit al principi.

Va seguir els quatre passos que he descrit, començant amb `df -i` per confirmar que l'inode estava realment ple.

Aleshores, utilitzant find, vam localitzar el directori de memòria cau d'un lloc web antic abandonat que generava fitxers petits com una bogeria.

Finalment, en comprovar `repquota` es va confirmar que efectivament havia arribat al límit estricte.

Després de buidar aquella pila de memòria cau brossa, el lloc web va tornar a la vida immediatament.

Així que la propera vegada que us trobeu amb aquesta estranya situació on "el disc té espai però no podeu escriure fitxers", no us precipiteu a afegir un disc dur.

Primer, feu servir `df -i` per fer una ullada a l'inode; la veritat podria estar amagada en aquella targeta d'índex que no heu vist mai abans.

Crec sincerament que aquestes petites idees de sentit comú amagades al nucli del sistema són més útils que memoritzar centenars de llistes d'optimització.