Ich habe Munin kürzlich auf einem Entwicklungs-Webserver installiert, um die Systemnutzung zu verfolgen. Mir ist aufgefallen, dass die Inode-Nutzung des Systems täglich um etwa 7-8 % steigt, obwohl die Festplattennutzung kaum zugenommen hat. Ich vermute, dass irgendetwas eine Menge kleiner Dateien schreibt, aber ich kann nicht herausfinden, was/wo.
Ich weiß, wie ich die Festplattenspeichernutzung ermitteln kann, aber ich kann scheinbar keine Möglichkeit finden, die Inode-Nutzung zusammenzufassen.
Gibt es eine gute Möglichkeit, die Inode-Nutzung nach Verzeichnis zu ermitteln, sodass ich die Quelle der Nutzung ermitteln kann?
Antwort1
Erwarten Sie nicht, dass es schnell geht ...
Wechseln Sie mit cd in ein Verzeichnis, in dem Sie ein Unterverzeichnis mit vielen Inodes vermuten. Wenn dieses Skript sehr viel Zeit in Anspruch nimmt, haben Sie wahrscheinlich bereits herausgefunden, wo im Dateisystem Sie suchen müssen. /var ist ein guter Anfang ...
Andernfalls, wenn Sie in das oberste Verzeichnis in diesem Dateisystem wechseln, dies ausführen und warten, bis es beendet ist, finden Sie das Verzeichnis mit allen Inodes.
find . -type d |
while
read line
do
echo "$( find "$line" -maxdepth 1 | wc -l) $line"
done |
sort -rn | less
Ich mache mir keine Sorgen über die Kosten für das Sortieren. Ich habe einen Test durchgeführt und das Sortieren der unsortierten Ausgabe anhand von 350.000 Verzeichnissen dauerte 8 Sekunden. Die erste Suche dauerte . Die wirklichen Kosten entstehen durch das Öffnen all dieser Verzeichnisse in der While-Schleife. (Die Schleife selbst dauert 22 Sekunden.) (Die Testdaten wurden in einem Unterverzeichnis mit 350.000 Verzeichnissen ausgeführt, von denen eines eine Million Dateien enthielt, der Rest hatte zwischen 1 und 15 Verzeichnisse).
Verschiedene Leute haben darauf hingewiesen, dass ls dafür nicht so gut ist, weil es die Ausgabe sortiert. Ich habe es mit echo versucht, aber das ist auch nicht so toll. Jemand anderes hat darauf hingewiesen, dass stat diese Informationen (Anzahl der Verzeichniseinträge) liefert, aber nicht portierbar ist. Es hat sich herausgestellt, dass find -maxdepth Verzeichnisse sehr schnell öffnet und .files zählt, also... hier ist es... Punkte für alle!
Antwort2
Wenn das Problem darin besteht, dass ein Verzeichnis zu viele Dateien enthält, gibt es hier eine einfache Lösung:
# Let's find which partition is out of inodes:
$ df -hi
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda3 2.4M 2.4M 0 100% /
...
# Okay, now we know the mount point with no free inodes,
# let's find a directory with too many files:
$ find / -xdev -size +100k -type d
Die Idee hinter dieser findZeile ist, dass die Größe eines Verzeichnisses proportional zur Anzahl der Dateien ist, die sich direkt in diesem Verzeichnis befinden. Daher suchen wir hier nach Verzeichnissen, die jede Menge Dateien enthalten.
Wenn Sie keine Zahl erraten möchten und lieber alle verdächtigen Verzeichnisse nach „Größe“ sortiert auflisten möchten, ist das auch ganz einfach:
# Remove the "sort" command if you want incremental output
find / -xdev -size +10k -type d -printf '%s %p\n' | sort -n
Antwort3
Grrr, zum Kommentieren sind 50 Wiederholungen erforderlich. Diese Antwort ist also eigentlich ein Kommentar zu Chris‘ Antwort.
Da sich der Fragesteller wahrscheinlich nicht für alle Verzeichnisse interessiert, sondern nur für die schlechtesten, ist die Verwendung von sort wahrscheinlich ein sehr kostspieliger Overkill.
find . -type d |
while
read line
do
echo "$(ls "$line" | wc -l) $line"
done |
perl -a -ne'next unless $F[0]>=$max; print; $max=$F[0]' | less
Dies ist nicht so vollständig wie Ihre Version, druckt aber Zeilen, wenn sie größer als das vorherige Maximum sind. Dadurch wird die Menge des ausgedruckten Rauschens erheblich reduziert und der Sortieraufwand gespart.
Der Nachteil dabei ist, dass Sie das zweite Verzeichnis nie sehen werden, wenn Sie zwei sehr große Verzeichnisse haben und das erste zufällig einen Inode mehr hat als das zweite.
Eine umfassendere Lösung wäre, ein intelligenteres Perl-Skript zu schreiben, das die 10 am häufigsten angezeigten Werte aufzeichnet und diese am Ende ausgibt. Aber das ist zu lang für eine schnelle Serverfehler-Antwort.
Außerdem könnten Sie mit etwas intelligenterem Perl-Skripting die while-Schleife überspringen - auf den meisten Plattformen sortiert ls die Ergebnisse, und das kann bei großen Verzeichnissen ebenfalls sehr aufwändig sein. Die ls-Sortierung ist hier nicht erforderlich, da uns nur die Anzahl interessiert.
Antwort4
Dies ist keine direkte Antwort auf Ihre Frage, aber die Suche nach kürzlich geänderten Dateien mit geringer Größe mithilfe von „find“ könnte Ihre Suche eingrenzen:
find / -mmin -10 -size -20k