Wie kann ich die Inode-Nutzung in HestiaCP überprüfen? Warum kann ich keine Dateien schreiben, obwohl ausreichend Speicherplatz vorhanden ist?

Vor ein paar Tagen schrieb mir ein Freund spät abends, dass sein Server abgestürzt sei.

Die konkreten Symptome waren besonders bizarr: Die Website fing plötzlich an, Fehler auszugeben, Protokolle konnten nicht geschrieben werden, und beim Erstellen neuer Dateien wurde sofort gemeldet, dass die Festplatte voll sei.

Als er jedoch mit `df -h` nachsah, war er schockiert: Die Festplatte hatte eindeutig Dutzende Gigabytes freien Speicherplatz. Wie konnte sie voll sein?

Ich sagte ihm direkt an Ort und Stelle: „Bruder, du hast nicht nur jede Menge Speicherplatz, dein Inode ist überlastet.“

Er antwortete mit einem Fragezeichen: Was genau ist ein Inode?

Tatsächlich reagieren viele Menschen genau so wie er, als sie zum ersten Mal in diese Falle getappt sind, weil ihnen das in der Schule nie beigebracht wurde.

Zunächst einmal sollten wir klären, was ein Inode ist.

Stellen Sie es sich wie eine Karteikarte in einer Bibliothek vor, dann ist es leicht zu verstehen.

Der Speicherplatz ist wie ein Bücherregal; wie viele Bücher man darauf stellen kann, hängt von seiner Kapazität ab, was für jeden leicht verständlich ist.

Ein Inode ist wie eine Karteikarte für jedes Buch, auf der dessen Name, Standort und derjenige, der es bewegt hat, vermerkt sind.

In Linux muss jede Datei und jedes Verzeichnis einen Inode belegen, egal wie klein die Datei ist.

Selbst wenn es sich um eine leere Datei handelt, verbraucht das System trotzdem eine Karteikarte dafür.

Das System hat eine Begrenzung hinsichtlich der Gesamtzahl der Dateien, die es erstellen kann; diese Begrenzung entspricht der Gesamtzahl der Innodes.

Sobald der Inode aufgebraucht ist, weigert sich das Betriebssystem, neue Dateien zu erstellen, selbst wenn auf Ihrer Festplatte noch Hunderte von Gigabytes freier Speicherplatz vorhanden sind.

Protokolle können nicht geschrieben, der Cache kann nicht erstellt werden und die Website stürzt komplett ab – das ist die bizarre Szene, die Sie gerade erleben.

Ehrlich gesagt ist das eine wirklich knifflige Situation, da die Fehlermeldung von einem Ort gesendet wird, den Sie nicht im Blick haben.

Der erste Trick besteht darin, mit `df -i` einen schnellen Überblick zu erhalten.

In der HestiaCP- Umgebung können Sie sich einfach per SSH in das Terminal einloggen und diese Zeile eingeben.

df -i

Es werden die Gesamtzahl der Innodes, die Anzahl der verwendeten Innodes und die verbleibende Anzahl für jede eingebundene Partition aufgelistet.

In der Ausgabe gibt es eine Spalte mit der Bezeichnung IUse%. Dies ist die wichtigste Kennzahl, die Sie im Auge behalten sollten.

Wenn die IUse% einer Partition 100% erreicht, kann diese Partition keine neuen Dateien oder Protokolle mehr erstellen, selbst wenn noch ausreichend Speicherplatz vorhanden ist.

Ich habe meinem Freund vorgeschlagen, dies zuerst auszuführen, damit innerhalb einer Sekunde festgestellt werden kann, ob das Problem beim Inode liegt , was wesentlich schneller wäre als bloßes Raten.

Die zweite Methode besteht darin, mit `find` einen bestimmten Benutzer genau zu zählen.

Nachdem bestätigt wurde, dass das Problem beim Inode liegt, gilt es im nächsten Schritt herauszufinden, wer die Indexkarte übermäßig nutzt.

HestiaCP verwendet für jeden Benutzer ein separates Home-Verzeichnis. Sie können die Gesamtzahl der Dateien und Verzeichnisse in einem bestimmten Website-Verzeichnis einfach zählen.

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

Ersetzen Sie „Benutzername“ und „Ihr Domänenname“ durch Ihren tatsächlichen Pfad. Die vom Terminal zurückgegebene Zahl entspricht der Summe aller Dateien und Ordner in diesem Verzeichnis.

Jede Datei bzw. jedes Verzeichnis entspricht einem Inode, daher stellt diese Zahl die Inode-Belegung dar.

Falls Sie zu faul sind, jeden einzelnen Eintrag zu überprüfen und die Nutzungsverteilung aller Benutzer auf der gesamten Website auf einmal sehen möchten, gibt es auch einen einzigen Schleifenbefehl.

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

Diese Zeile gibt die Gesamtzahl der Dateien in jedem Benutzerverzeichnis unter /home aus, sodass man leicht erkennen kann, welches Benutzerverzeichnis eine ungewöhnlich hohe Anzahl von Dateien enthält.

Die dritte Strategie besteht darin, die Unterverzeichnisse zu identifizieren, die den größten Jodverbrauch aufweisen.

Manchmal weiß man, dass eine Website extrem hohe Inode-Werte hat, aber man kann trotzdem nicht herausfinden, was mit dem Bildschirm voller Dateien nicht stimmt.

In solchen Fällen müssen Sie eine Ebene tiefer gehen, um Unterordner zu finden, die eine große Anzahl kleiner Dateien enthalten, wie z. B. Cache-Verzeichnisse, Sitzungsverzeichnisse und Protokollverzeichnisse – dies sind die problematischsten Bereiche.

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

Dieser Befehl listet die 10 Unterordner auf, die die meisten Dateien belegen.

Der Pfad ganz oben in der Liste ist derjenige, in dem eine große Anzahl kleiner Dateien zusammengefasst ist.

Ich sagte meinem Freund, dass es sich wahrscheinlich um ein Caching-Plugin handelt, das heimlich kleine Dateien erzeugt, und dass das Ausführen dieser Zeile dies im Grunde bestätigen würde.

Der vierte Tipp lautet, das Quotenlimit mit repquota zu überprüfen.

Wenn auf Ihrem Server Linux-Dateisystemquoten aktiviert sind, können Sie das Problem aus einer anderen Perspektive betrachten.

repquota -a

Dieser Befehl zeigt das Dateilimit und die tatsächliche Dateinutzung für alle Benutzer an.

Beachten Sie den Abschnitt „Dateibeschränkungen“ in der Ausgabe genau; die Spalte „Verwendet“ gibt an, wie viele Dateien verwendet wurden.

Die Spalten „Soft“ und „Hard“ stellen die weichen und harten Grenzwerte dar. Sobald der Wert für „Used“ den Wert für „Hard“ erreicht, verweigert das System die Erstellung neuer Dateien.

Das ist eine ganz andere Geschichte als die Frage, wie viel Speicherplatz Sie noch auf Ihrer Festplatte haben.

Zum Abschluss wollen wir die einzelnen Puzzleteile der Ermittlungen zusammensetzen.

Kommen wir zurück zu dem Freund, der mitten in der Nacht den Server zum Absturz gebracht hat.

Er befolgte die vier von mir beschriebenen Schritte, beginnend mit `df -i`, um zu bestätigen, dass der Inode tatsächlich voll war.

Anschließend lokalisierten wir mithilfe von find das Cache-Verzeichnis einer verlassenen alten Website, die in Scharen kleine Dateien erzeugte.

Die abschließende Überprüfung mit `repquota` bestätigte schließlich, dass das Limit tatsächlich erreicht war.

Nachdem der Berg an Datenmüll aus dem Cache entfernt worden war, funktionierte die Website sofort wieder.

Wenn Sie also das nächste Mal in diese seltsame Situation geraten, in der „die Festplatte eindeutig Speicherplatz hat, Sie aber keine Dateien schreiben können“, sollten Sie nicht vorschnell eine Festplatte einbauen.

Verwenden Sie zunächst `df -i`, um einen Blick auf den Inode zu werfen; die Wahrheit könnte sich durchaus auf jener Karteikarte verbergen, die Sie bisher noch nie bemerkt haben.

Ich bin der festen Überzeugung, dass diese kleinen, im Kern des Systems verborgenen Elemente des gesunden Menschenverstands nützlicher sind als das Auswendiglernen hunderter Optimierungslisten.