Lesen Sie Speicher- und Festplattenwarnungen vor einem Upgrade.

Erfassen Sie eine kleine Baseline mit Kontext

Verwenden Sie ein Linux-Konto, das berechtigt ist, die von Ihnen betriebene Anwendung zu inspizieren. Die Befehle hier prüfen den Zustand; sie entfernen keine Dateien und ändern keine Speichergröße. Einige Verzeichnisse und Journale erfordern erhöhten Zugriff. Ersetzen Sie /var/lib/field-api, /opt/field-api und /opt/first-api durch echte Anwendungspfade und bestätigen Sie, dass diese Pfade existieren, bevor Sie die Ergebnisse interpretieren.

Notieren Sie die Zeit, das aktuelle Release und die Aktivität: normaler Verkehr, ein Upload, ein Berichtsjob oder ein Deployment-Build. Nehmen Sie eine weitere Messung während vergleichbarer Aktivität vor. Zwei unzusammenhängende Screenshots können einen gesunden Rechner inkonsistent erscheinen lassen. Wenn Benutzer bereits betroffen sind, erfassen Sie den ersten nützlichen Hinweis aus dem Leitfaden zur Anwendungsfehlerbehebung bevor Sie mehrere Änderungen gleichzeitig vornehmen.

Lesen Sie den verfügbaren Arbeitsspeicher und prüfen Sie dann die Workload

free -h
ps -eo pid,comm,rss --sort=-rss | head -n 12

In freeschätzt der verfügbare Arbeitsspeicher, was für neue Anwendungen ohne Swap verwendet werden könnte. Er berücksichtigt rückgewinnbaren Cache und beantwortet daher eine andere Frage als der völlig ungenutzte „freie“ Arbeitsspeicher. Siehe das upstream free-Handbuch. Linux verwendet Arbeitsspeicher für Dateicaching; ein großer Cache allein ist kein Beweis für ein Leck. Die Kernel-Speicherübersicht erklärt, warum Cache und Anwendungsspeicher koexistieren.

Illustrativer Messwert, keine Servermessung: ein kleiner Host hat etwa 1.9 GiB nutzbaren Arbeitsspeicher, 80 MiB frei und 850 MiB verfügbar. Der niedrige freie Wert allein rechtfertigt kein Upgrade. Wenn der verfügbare Arbeitsspeicher während eines Berichts wiederholt nahe Null fällt, Anfragen langsamer werden und relevante Allokations- oder Out-of-Memory-Meldungen erscheinen, verdient diese kombinierte Evidenz eine Untersuchung.

Das ps Befehl listet Prozess-RSS in KiB auf, größte zuerst. RSS beschreibt residenten Speicher, keine vollständige Abrechnung exklusiven Eigentums; gemeinsam genutzte Seiten können in mehreren Prozessen erscheinen. Addieren Sie nicht jede RSS-Zahl und behandeln Sie das Ergebnis nicht als exakte Host-Nutzung. Die upstream ps-Referenz definiert RSS und Sortierung. Notieren Sie den Prozessnamen und ob sein Fußabdruck nach Ende der Workload wieder auf sein früheres Niveau zurückkehrt.

Verwendeter Swap kann frühere Aktivität widerspiegeln; er beweist nicht für sich genommen aktuellen Druck. Unterscheiden Sie außerdem Host-Kapazität von Dienst- oder Container-Limits. Ein eingeschränkter Prozess kann fehlschlagen, während der Host noch verfügbaren Arbeitsspeicher hat. Prüfen Sie das konfigurierte Limit und den Zeitpunkt des Fehlers, bevor Sie die VPS-Größe erhöhen. Die proc-Dateisystem-Referenz des Kernels dokumentiert die Speicherfelder hinter diesen Beobachtungen.

Finden Sie das Dateisystem, das sich tatsächlich füllt

df -h / /opt/first-api
df -i / /opt/first-api

Der erste Befehl meldet den Speicherplatz auf den Dateisystemen, die diese Pfade enthalten. Der zweite meldet Inodes, also Dateisystemdatensätze, die für Dateien und Verzeichnisse benötigt werden. Eine Workload mit vielen winzigen Dateien kann Inodes erschöpfen, während Byte-Kapazität bleibt. Prüfen Sie den Mount und beide Arten von Kapazität, anstatt die Größe des gesamten VPS als einzige Zahl zu verwenden. Siehe das GNU df-Handbuch.

Ein Pfad auf einem separat eingebundenen Volume kann sich unabhängig vom Root-Dateisystem füllen. Umgekehrt können zwei aufgeführte Pfade zum selben Dateisystem gehören, sodass ihr verfügbarer Speicherplatz nicht additiv ist. Dateisystem-Reservierungen, Quotas und Speicherschichten können ebenfalls beeinflussen, was die App schreiben kann. Ein einzelner angezeigter Prozentsatz identifiziert nicht den Verursacher des Wachstums.

Ordnen Sie das Wachstum Logs, Uploads oder Artefakten zu

sudo du -xhd1 /var/lib/field-api
sudo du -xhd1 /var/log
sudo du -xhd1 /opt/field-api
sudo journalctl --disk-usage

GNU du schätzt den belegten Speicher unter jedem Verzeichnis. Hier -x vermeidet das Überqueren in ein anderes Dateisystem, -h verwendet lesbare Einheiten und -d1 begrenzt die angezeigte Tiefe. Große Verzeichnisbäume können dennoch Zeit und Festplattenaktivität zum Scannen benötigen. Berechtigungsfehler bedeuten, dass die Ansicht unvollständig ist. Siehe das GNU du-Handbuch. Der Journal-Befehl meldet den Journal-Speicher, einschließlich aktiver und archivierter Dateien, wie dokumentiert von journalctl.

Vergleichen Sie die größten Verzeichnisse mit ihrem Zweck:

• Logs: hat ein wiederholter Fehler das Volumen erhöht, und ist die Rotation konfiguriert?
• Uploads: wachsen aufbewahrte Benutzerdateien wie erwartet, und sind abgebrochene Teil-Uploads berücksichtigt?
• Release-Artefakte: sammeln sich alte Builds über die Rollback-Richtlinie hinaus an?
• Datenbankdateien: erklärt das eigene Tooling der Datenbank das Wachstum und den Wartungsbedarf?

Löschen Sie kein unbekanntes Datenbankverzeichnis und verwenden Sie keine breite Container-Volume-Bereinigung als Untersuchungsschritt. Identifizieren Sie zuerst Eigentümerschaft, Aufbewahrungsanforderungen und eine wiederherstellbare Kopie. Wenn df und Verzeichnissummen erheblich voneinander abweichen, prüfen Sie Mount-Grenzen, Zugriffsfehler und Dateien, die nach dem Löschen noch offen gehalten werden, mit einem erfahrenen Betreiber; wiederholtes Löschen sichtbarer Dateien kann den belegten Speicher verfehlen.

Überführen Sie die Messwerte in eine konkrete nächste Aktion

Illustrativer Fall: Der verfügbare Arbeitsspeicher bleibt komfortabel, aber ein Upload-Verzeichnis wächst an zwei beobachteten Tagen um jeweils etwa 400 MiB. Das Dateisystem hat etwa 2 GiB verfügbar. Teilt man den verbleibenden Speicher durch dieses kurzfristige Wachstum, ergeben sich nur etwa fünf Tage bei gleicher Rate, bevor betrieblicher Spielraum berücksichtigt wird. Das ist eine Planungsschätzung, keine Prognose und keine sichere Frist, bis zu der man warten sollte; Uploads und temporäre Arbeit können ungleichmäßig eintreffen.

Die nächste Aktion besteht darin, die Upload-Aufbewahrung und den erwarteten Bedarf zu prüfen, bei Bedarf zusätzlichen Speicher zu planen und eine Warnung früh genug einzurichten. Mehr RAM würde diesen Befund nicht beheben. In einem anderen Fall könnte ein Deployment-Build einen kurzen Speicherpeak erzeugen, während der Dienst klein bleibt; das Verlagern des Builds vom VPS könnte nützlicher sein als eine dauerhafte Vergrößerung der Laufzeitumgebung.

Wiederholen Sie nach einer gerechtfertigten Änderung dieselben Messwerte und eine Anwendungsaktion. Bestätigen Sie, dass Speicherplatz tatsächlich verfügbar ist und die vorgesehenen Daten noch funktionieren. Behalten Sie Löschen und Größenänderung als geplante Vorgänge mit Wiederherstellungsschritten bei, nicht als automatische Reaktionen auf eine rote Zahl. Verwenden Sie den Ressourcenbudget-Leitfaden , um einen nachgewiesenen Bedarf in Konfigurationsentscheidungen umzusetzen, und üben Sie Wiederherstellung , bevor Sie sich auf eine Bereinigung oder Migration verlassen.