[Speicherplatz] Server Control Panel zeigt anderen Wert als df -h

  • Hallöchen zusammen.


    Ich hab schon die Suche bemüht, aber nichts gefunden, was mir bei meinem Problem/meiner Frage hilft (wenn doch, dann gebt mir gern nen Link ^^).


    Heute morgen stand im SCP noch folgendes:

    Speichernutzung 105 GB von 234 GB belegt


    Ich habe ein paar Einträge in den Datenbanken gelöscht, die nicht mehr gebraucht werden.

    Als ich dann wieder ins SCP guckte, stand folgendes:

    Speichernutzung 220 GB von 234 GB belegt


    Das steht seitdem auch weiterhin so da - ich kann mir nicht erklären, warum plötzlich angeblich so viel Speicher belegt ist :huh:


    Wenn ich in der Konsole

    Code
    df -h

    eintippe, dann sehe ich folgendes:

    Code
    Filesystem                                              Size  Used Avail Use% Mounted on
    rootfs                                                  229G   16G  202G   8% /
    udev                                                     10M     0   10M   0% /dev
    tmpfs                                                   1.2G  224K  1.2G   1% /run
    /dev/disk/by-uuid/06a6ce66-e8c9-4167-ade5-93bee20abf1a  229G   16G  202G   8% /
    tmpfs                                                   5.0M     0  5.0M   0% /run/lock
    tmpfs                                                   2.7G     0  2.7G   0% /run/shm


    Wenn ich

    Code
    lsblk

    nutze, dann kommt das raus:

    Code
    NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
    vda    254:0    0   234G  0 disk
    |-vda1 254:1    0   1.4G  0 part [SWAP]
    `-vda2 254:2    0 232.6G  0 part /
    sr0     11:0    1  1024M  0 rom


    Nun bin ich total verwirrt und weiß nicht, was richtig ist und wieso es SO extreme Abweichungen gibt!? :/


    Kann mir vielleicht dabei jemand auf die Sprünge helfen oder mir sagen, was ich tun kann/machen muss, damit das "richtig" ist!? ^^


    Ich nutze aktuell den Rootserver Root-Server L SSD v6 mit 240GB SSD Speicher.


    Dankeschön schonmal im Voraus! :)

  • Hay,


    man fstrim



    und falls als filesystem btrfs im Einsatz ist, alte Snapshots löschen...


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Danke schonmal für die Antworten, werd ich mir mal genauer angucken dieses fstrim :)


    Einen Snapshot gibt es aktuell allerdings nicht mehr, den hab ich gelöscht - daraufhin kam ich von 111 auf 105 runter.

    Aber das erklärt halt dennoch nicht, wieso es dann plötzlich 220 sind laut SCP ^^

  • fstrim wirkt mit etwas Verzögerung. Es werden auch nicht alle Blöcke als frei markiert, nur Stellen ab einer gewissen Größe.


    Führe bitte mal 'fstrim -va' aus. Manchmal gibt es da noch komische Bugs.

    "Security is like an onion - the more you dig in the more you want to cry"

  • fstrim wirkt mit etwas Verzögerung. Es werden auch nicht alle Blöcke als frei markiert, nur Stellen ab einer gewissen Größe.


    Führe bitte mal 'fstrim -va' aus. Manchmal gibt es da noch komische Bugs.

    Das sollte ich vermutlich nicht im laufenden Betrieb machen, oder? :D

    Sorry für die dumme Frage - ich bin nur etwas übervorsichtig bei sowas ?



    Eventuell zusätzlich mal im SCP defragmentieren, das hilft manchmal auch.

    Selbe Frage wie oben - dafür am besten den Server einmal runterfahren oder? :/

  • fstrim kann man auch im laufenden Betrieb ausführen, genau dafür ist es gedacht. ;)

    Selbe Frage wie oben - dafür am besten den Server einmal runterfahren oder? :/

    Dazu wird der Server automatisch mittels ACPI-Event heruntergefahren. Das sollte aber afaik eh dabei stehen.


    Achtung: Das kann je nach HDD-Größe und Belegung auch mal mehrere Stunden dauern!

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Ich bin mir nicht sicher, ob fstrim mit vda funktioniert. vda indiziert emuliertes IDE/SATA, während der im scp empfohlene Treiber scsi, virtio-scsi (Devicename dann „sda“) emuliert. Meines Wissens reicht nur scsi oder virtio-scsi trim-Befehle an den Controller durch. Ist das hier anders?


    Shirisu das Umstellen des Treibers bitte noch nicht machen. Ist vorerst nur eine Frage an die Mitposter.

  • Du hast den ersten Beitrag sehr aufmerksam gelesen, eripek. Und damit völlig recht. fstrim wird so nicht nutzbar sein. Ohne Treiberumstellung bleibt also nur die Defragmentierung im SCP übrig.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Ah okay, also fällt fstrim also eh (erstmal) weg? Okay :/

    fstrim kann man auch im laufenden Betrieb ausführen, genau dafür ist es gedacht. ;)

    Dazu wird der Server automatisch mittels ACPI-Event heruntergefahren. Das sollte aber afaik eh dabei stehen.


    Achtung: Das kann je nach HDD-Größe und Belegung auch mal mehrere Stunden dauern!

    Hmm, die Platte hat 240GB und laut df -h sind 16GB belegt - ich tippe aber mal, dass man dazu nicht wirklich eine ungefähre Zeitschätzung machen kann? ?

  • Shirisu ich bin mir ob Deiner Vorkenntnisse nicht sicher, ob wir eine Umstellung auf den anderen Treiber wagen sollten. Sofern Deine /etc/fstab nicht von "/dev/vda" [1-x] spricht, sondern Einträge mit "UUID=" beinhaltet, und auch der Bootloader Deines Debian mit "UUID=" (siehe auch /etc/default/grub) arbeitet, solltest Du gefahrlos auf den SCSI-Treiber im SCP umstellen können. Sollte Linux dennoch nicht mehr booten, müsstest Du den Wert zurückstellen auf virtio. Wenn in grub etwas von "vda" steht, dann lass bitte vorerst die Finger davon und gib Bescheid, dann werden wir uns etwas Zeit nehmen müssen. Ein Backup hast Du ja -wie immer- parat - oder?

    Gelingt die Umstellung, steht Dir fortan fstrim zur Verfügung. Traust Du Dir das zu? Hast Du da noch Fragen dazu? Frag lieber einmal mehr als einmal zu wenig.

  • ich bin mir ob Deiner Vorkenntnisse nicht sicher, ob wir eine Umstellung auf den anderen Treiber wagen sollten. Sofern Deine /etc/fstab nicht von "/dev/vda" [1-x] spricht, sondern Einträge mit "UUID=" beinhaltet, und auch der Bootloader Deines Debian mit "UUID=" (siehe auch /etc/default/grub) arbeitet, solltest Du gefahrlos auf den SCSI-Treiber im SCP umstellen können. Sollte Linux dennoch nicht mehr booten, müsstest Du den Wert zurückstellen auf virtio. Wenn in grub etwas von "vda" steht, dann lass bitte vorerst die Finger davon und gib Bescheid, dann werden wir uns etwas Zeit nehmen müssen. Ein Backup hast Du ja -wie immer- parat - oder?

    Gelingt die Umstellung, steht Dir fortan fstrim zur Verfügung. Traust Du Dir das zu? Hast Du da noch Fragen dazu? Frag lieber einmal mehr als einmal zu wenig.

    Einen Snapshot kann ich aktuell leider nicht machen, weil dazu nicht genügend Speicher vorhanden ist (laut SCP), den alten hatte ich gelöscht.


    Spricht denn grundsätzlich etwas gegen die Defragmentierung (ohne Treiberumstellung)?

    Dann würd ichs erstmal vielleicht damit versuchen? Da geht hoffentlich nichts kaputt!? :D

  • Kaputt gehen kann immer was bei IT… :P


    Mir ist allerdings kein Fall bekannt, bei dem die Defragmentierungsfunktion im SCP etwas zerstört hat. In diesem Sinne: Go for it! :)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Kaputt gehen kann immer was bei IT… :P


    Mir ist allerdings kein Fall bekannt, bei dem die Defragmentierungsfunktion im SCP etwas zerstört hat. In diesem Sinne: Go for it! :)

    Ich hab da so ein gewisses Talent... :D

    Aber ich guck mir das morgen nochmal an - und sonst werd ich mir doch einfach einen neuen Server holen und da alles neu einrichten (was eigentlich eh der Plan war) - nur wollte ich vorher eben gucken, wie viel Platz denn nun WIRKLICH benutzt wird und welches Paket ich dann dafür nehme ^^

  • Wie viel du „wirklich“ nutzt siehst du ja mit df :)

    Okay, super - danke :):thumbup:


    Es hat mich alles so mega verwirrt, weil da SO extreme Unterschiede waren zum SCP.

    Dann reicht also locker die 60GB SSD Variante.


    Ein wenig schade ist's ja schon um die 240GB SSD, die ich grad hab... ^^

  • Bedenke, dass das direkte Einspielen eines Snapshots vom größeren auf den kleineren Server scheitern würde (Partitionsgrößen). Aber Du installierst jetzt ja einfach nur neu und richtest drüben Alles neu ein oder? Dann ist das kein Problem.

  • Bedenke, dass das direkte Einspielen eines Snapshots vom größeren auf den kleineren Server scheitern würde (Partitionsgrößen). Aber Du installierst jetzt ja einfach nur neu und richtest drüben Alles neu ein oder? Dann ist das kein Problem.

    Genau :)

    Ich wollte am neuen alles komplett neu einrichten und dann die Dateien und Datenbanken hochladen und alles anpassen, dass es dort genauso läuft.


    Ohne Snapshots oder sonstigem.