☰

Ubuntu-Server füllt sich langsam

tag-icon • tag-icon ubuntu disk-space-utilization
Ubuntu-Server füllt sich langsam

Unser Samba-Server (Ubuntu 8.04 ltr) war neulich voll, aber als ich nachgesehen habe, konnte ich nicht sehen, dass auf einer der Freigaben zu viel los war.

Wir haben 5 Gruppenfreigaben und dann hat jeder Benutzer eine individuelle Freigabe

Ein Benutzer hat 22 GB an Material, ein paar andere haben 10-20 MB an Material und alle anderen sind leer

also vielleicht 26 Gigs insgesamt

Ich habe gestern ein paar Dateien gelöscht und etwa 250 MB Speicherplatz freigegeben. Als ich heute nachgesehen habe, war er schon wieder komplett voll. Ich habe ein paar ältere Dateien gelöscht und etwa 170 MB an Material freigegeben, aber ich kann zusehen, wie der freie Speicherplatz langsam schrumpft.

Ich führe weiterhin eindf -h

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1            241690180 229340500    169200 100% /
varrun                  257632       260    257372   1% /var/run
varlock                 257632         0    257632   0% /var/lock
udev                    257632        72    257560   1% /dev
devshm                  257632        52    257580   1% /dev/shm
lrm                     257632     40000    217632  16% /lib/modules/2.6.24-28-generic

/flüchtig

was kann ich tun, um herauszufinden, was so viel Platz auf meiner Festplatte einnimmt? (Ich bin ziemlich neu bei Unix im Allgemeinen, also entschuldige ich mich, wenn dies nicht gut erklärt ist)

Antwort1

(Dies ist eine auf Linux fokussierte Antwort. Bei anderen UNIX-Varianten kann es anders sein.)

Für Ihr Problem sind zwei Informationen relevant: (1) welche Dateien Ihr Dateisystem füllen und (2) welche Prozesse in diese Dateien schreiben.

Anmerkungen

Wenn ich das Zeichen unten $in Befehle einfüge, handelt es sich wahrscheinlich um einen Platzhalter, in den Sie einen echten Wert einsetzen müssen. Hoffentlich ist es offensichtlich, wo das zu tun ist und wo nicht.

Welche Dateien?

Beachten Sie, dass es in den meisten Dateisystemtypen eigentlich zwei Ressourcen gibt, die von einzelnen Dateien genutzt werden können: Metadaten (z. B. Inodes) und echte Daten. Sie können die Anzahl der Inodes (suchen Sie bei Google nach einer Definition, aber es handelt sich dabei um „Zeiger“ auf die Strukturen, aus denen Ihre Dateien bestehen) mit einem Befehl wie diesem anzeigen:

df -i

... und wie Sie bereits wissen, zeigt etwa Folgendes den von realen Daten genutzten Speicherplatz an:

df -h

Beachten Sie auch, dass Dateisystemspeicherplatz von Dateien belegt werden kann, die auf der Festplatte nicht vorhanden sind. Diese Dateien sind durch einen Prozess noch geöffnet, wurden aber entfernt (darauf gehen wir weiter unten ein).

Sobald Sie das/die vollständige(n) Dateisystem(e) identifiziert haben, müssen Sie nach vielen kleinen Dateien, einigen großen Dateien oder beidem suchen. Wenn die Metadatenressourcen knapp werden, liegt das normalerweise daran, dass viele kleine Dateien vorhanden sind, während die tatsächlichen Datenressourcen meist an einigen großen Dateien mangeln. Ich verwende gerne diesen Befehl, um die großen Dateien zu finden:

sudo find $file_system -mount -ls | awk '{print $7, $11}' | sort -rn > $output

... und dieser Befehl hilft beim Auffinden von Verzeichnissen mit vielen kleinen Dateien (Aktualisieren:: Nullterminierung hinzugefügt, um die Dateinamenverwaltung zu verbessern):

sudo find . -mount -print0 | xargs -0n 1 dirname | sort | uniq -c | sort -rn > $output

... seien Sie sich bewusst, dass die Ausführung dieser Befehle eine Weile dauern kann und je nach Ausführung viele I/O-Vorgänge erfordert. Nach der Ausführung können Sie alles durchlesen, $outputum die fehlerhaften Dateien oder Verzeichnisse zu finden. Der Name und der Speicherort der einzelnen Dateien können Ihnen einen Hinweis darauf geben, woher die Daten stammen, erfordern jedoch etwas Linux-Erfahrung.

Sobald Sie die Täter identifiziert haben, können Sie rm $filedas Problem beseitigen.

Welche Prozesse?

Der einfachste Weg, die Prozesse zu finden, die möglicherweise Ihr Dateisystem füllen, besteht darin, einen Befehl wie den folgenden auszuführen:

fuser -c $file_system 2>/dev/null

... das Ihnen die PID von Prozessen mit offenen Dateideskriptoren (Dateien und Netzwerk-Sockets) für das angegebene Dateisystem anzeigt (der 2>/dev/nullTeil entfernt einige Informationen, die Sie nicht benötigen). Sie können möglicherweise allein anhand dieser PIDs ableiten, welcher Prozess Ihr Dateisystem füllt. Suchen Sie nach den Prozessen mit:

ps -ef | grep $pid

Sie können auch versuchen, den folgenden Befehl auszuführen, der Ihnen noch mehr Details liefert (und dabei hilft, geöffnete Dateien ohne entsprechenden Dateinamen auf der Festplatte zu identifizieren – das habe ich oben erwähnt):

sudo lsof $file_system | grep $directory_filling_up

... und wenn Sie anhand des Befehls eine verdächtige PID identifiziert haben fuser, können Sie Folgendes tun:

sudo lsof -p $pid

Das Problem mit fuserund lsofist, dass sie Ihnen nur einen Snapshot des Systems zum Zeitpunkt der Ausführung des Befehls geben. Wenn der fehlerhafte Prozess nicht gerade schreibt, wenn Sie sie ausführen, haben Sie Pech gehabt. Sie können dem entgegenwirken, indem Sie sie im Laufe der Zeit wiederholt ausführen und die Ausgabe speichern. Dazu müssen Sie die Ausgabe durchlesen, um Muster zu finden, oder ein Programm schreiben, das dies für Sie erledigt. Eine Alternative ist die Verwendung eines Tools wieSystemTap. SystemTap ermöglicht es Ihnen, alle möglichen nützlichen Informationen abzufangen, und ist „programmierbar“. Es wird sogar mit einigen Beispielquelldateien geliefert, mit denen Sie sehen können, welche Prozesse über einen bestimmten Zeitraum in welche Dateien schreiben. Es wäre perfekt, aber es ist ein fortgeschrittenes Tool und erfordert viel Linux-Wissen.

Sobald Sie die fehlerhaften Prozesse identifiziert haben, können Sie sie beenden (und eventuell neu starten). Wenn der Prozess mit dem Betriebssystem oder einer gut verpackten Software verknüpft ist, gibt es wahrscheinlich einen Mechanismus zum Neustarten, aber das hängt von Ihrer Linux-Distribution ab (ich glaube, Ubuntu erlaubt es Ihnen, etwas wie auszuführen /etc/init.d/$init_script restart, aber Sie müssen die Dokumentation Ihrer Distribution prüfen). Andernfalls können Sie ihn mit kill $pidoder beenden kill -9 $pid, wenn er sich nicht verhält. Achten Sie darauf, wie der Prozess ausgeführt wurde (z. B. welche Argumente in angezeigt wurden ps -ef), falls Sie ihn neu starten müssen (möglicherweise müssen Sie die Dokumentation dieser Software zu Rate ziehen).

Antwort2

Verwenden Sie es du, um das Verzeichnis zu finden, das die Dateien enthält, die die Festplatte füllen.

cd /
du -h --max-depth 1

zeigt Ihnen, welches Verzeichnis in / den meisten Speicherplatz beansprucht. Durchsuchen Sie das Dateisystem mit dem Befehl du, um den Übeltäter zu finden.

z.B

cd /
du -h --max-depth 1

zeigt, dass /usr 2,3 GB der im System verwendeten 3,5 GB nutzt.

cd /usr
du -h --max-depth 1

zeigt, dass /usr/lib 1,1 G der 2,3 G in /usr verwendet …

Die Ursache kann auch eine geöffnete Datei sein, die gelöscht wurde.

Sie könnenlsofum Dateien zu finden, die geöffnet, aber nicht verknüpft (gelöscht) sind

lsof +L1

sollte funktionieren. Wie auf der Manpage steht:

Eine Spezifikation dieses Formulars +L1wählt offene Dateien aus, deren Verknüpfung aufgehoben wurde. Eine Spezifikation dieses Formulars +L1 <file_system>wählt offene Dateien aus, deren Verknüpfung aufgehoben wurde, im angegebenen Dateisystem aus.

Antwort3

Die /-Partition ist vollgestopft. Wahrscheinlich ist es etwas in /var/logoder in /home. Dies hängt von Ihrem Setup ab. Suchen Sie auch an Orten, auf die Ihre Benutzer Zugriff haben.

Führen Sie in jedem der betroffenen Verzeichnisse den folgenden Befehl aus. Dadurch werden Ihnen die Unterverzeichnisse angezeigt, die den größten Speicherplatz verbrauchen.

cd /directory
du -cks -x * .* |sort -n

Diese Idee ist dem ducksSkript ( du -cks) vonLinux-Server-Hacksvon O'Reilly. Ich führe diesen Befehl oft aus.

Meiner Erfahrung nach liegt das fast immer an großen, wachsenden Logdateien. In diesem Fall verwenden SieLogrotate, UndVerwenden Sie unbedingt die Komprimierung. Wenn Sie die Gzip-Komprimierung mit der Standardkomprimierungsrate verwenden, werden Ihre Protokolldateien um 80-95 % kleiner (eine 1 GB große Datei /var/log/messages kann problemlos auf 200 MB oder weniger komprimiert werden). Dies führt zu einer moderaten Belastung der CPU, aber ich habe selten erlebt, dass dies die tatsächliche Leistung eines Servers beeinträchtigt. Manche Leute bevorzugen die Bzip2-Komprimierung oder verwenden, gzip --bestaber meiner Erfahrung nach verursacht dies eine Menge CPU-Overhead mit wenig zusätzlichem Nutzen. gzipDie Standardkomprimierungsrate ist normalerweise gut genug.

Und offensichtlich liegt dieses Problem manchmal daran, dass ein Benutzer etwas Falsches tut. Verwenden Sie den duobigen Befehl, um den Schuldigen zu finden.

Antwort4

Die Ursache liegt wahrscheinlich in den Protokollen, aber hier ist ein Befehl, der kürzlich geänderte (oder erstellte) Dateien nach Größe sortiert:

D=$(date --rfc-3339 date);
sudo sh -c 'find / -xdev -mtime -1 -type f -print0 |xargs -0 du -0sbc' \
  |tee ~/recent-files.$D |sort -zn |tee ~/recent-by-size.$D |xargs -0n1

Sie könnten diesen Befehl täglich ausführen; es gibt wahrscheinlich eine Möglichkeit, mit SQL diese Dateien nach täglichem Wachstum zu sortieren.

(Bearbeiten) Um das Wachstum zu überwachen, verwenden Siegt5

sudo aptitude install gt5
cd /
gt5

Einen Tag später; suchen Sie nach ± ​​Zeichen

gt5

verwandte Informationen