HD space (root) zu 93% voll

A

Abby2017

Member
Mar 17, 2024
61
31
23
Hallo zusammen,
wir haben bei uns ein PM Mailgateway laufen, der uns ein paar Mails von internen Servern an unsere Firewall weitergibt.

Nun ist uns aufgefallen, das 93% Speicher von den 16 GB voll sind. Ich muss allerdings zugeben, das wir nach dem Aufsetzen nicht drauf geachtet hatte, wie da die Auslastung aussah. Das System läuft jetzt seit ungefähr 3 Monaten.

hat da jemand eine Idee?
 

Attachments

  • Screenshot 2026-05-27 101230.png
    Screenshot 2026-05-27 101230.png
    24.5 KB · Views: 10
Läuft das als VM oder warum ist die Festplatte so klein? Ich würde empfehlen du schaust dich mal um und prüfst was den Platz belegt
Bash: 
apt -yU install gdu
gdu /
 
Last edited:
Ja, ist eine VM, muss gleich mal schauen, ob ich den Speicher erhöhen kann, denn die installation geht nicht und jetzt ist die Paltte auf 99,57% vollgelaufen

Code: 
root@alvpmg1:~# apt -yU install gdu
Hit:1 http://download.proxmox.com/debian/pmg trixie InRelease
Hit:2 http://deb.debian.org/debian trixie InRelease
Hit:3 http://security.debian.org/debian-security trixie-security InRelease
Hit:4 http://deb.debian.org/debian trixie-updates InRelease
9 packages can be upgraded. Run 'apt list --upgradable' to see them.
You might want to run 'apt --fix-broken install' to correct these.
Unsatisfied dependencies:
 proxmox-kernel-6.17 : Depends: proxmox-kernel-6.17.13-11-pve-signed but it is not going to be inst                                               alled or
                                proxmox-kernel-6.17.13-11-pve
 proxmox-kernel-7.0 : Depends: proxmox-kernel-7.0.2-6-pve-signed but it is not going to be installe                                               d or
                               proxmox-kernel-7.0.2-6-pve
Error: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
Error: The following information from --solver 3.0 may provide additional context:
   Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
 
Möglicherweise lässt es sich wieder zum Laufen bringen, indem Sie den apt package cache leeren: apt autoclean.

Auch ohne gdu lässt sich herausfinden, wo der Dateispeicherplatz belegt ist. Beginnen Sie mit: du -sh /* | sort -h,
dann für den größten Ordner (zum Beispiel /var) folgendes: du -sh /var/* | sort -h, usw.
 
Last edited:
Am besten als root mal folgendes ausführen:

Code: 
cd /
du -sh *

Dann kann man gut sehen, wo der Platz bleibt.

Ggfs. dann mit "cd" in die jeweiligen Folder wechseln und wie "du -sh *" ausführen. So kann man sich gut vorantasten.
 
Daanw hat das Prozedere doch bereits beschrieben? cd tut hier auch wirklich nicht not.
 
Hatte ich irgendwie übersehen, stimmt! :cool:

20 GB insgesamt ist aber wirklich sehr knapp bemessen.
Im Zeifelsfall im Hypervisor vergrößern und dann mit gparted oder ähnlichem die Partition größer ziehen.
 
Für ein Mailgateway, was eigentlich nur durchleitet, sollten 20GB mehr als genug sein.
Wir haben das Gateway in einen Container mit 8GB Plattenplatz seit mehr als einen Jahr laufen und brauchen keine 2GB.
Bei massig Mailaufkommen dürften Logs und Quarantäne den Großteil des Speicherplatzes ausmachen.
Einfach mal aufräumen. :)
 
Kann ich so nicht ganz bestätigen. Alleine die ganzen Spam-Verdachtsfälle belegen hier schon etliche GB. Kommt natürlich auch immer auf die Useranzahl und das Spamaufkommen an. Hier sind aktuell ca. 13GB belegt und die User räumen eigentlich regelmäßig auf.
Ansonsten die Retention-Zeit von der Spam-Quarantäne vlt. mal prüfen.
 
Bei uns räumt keiner seine Spam-Quarantäne auf. Wenn ich da nicht die Lebensdauer auf 7 Tage begrenzt hätte, wäre auch bei uns Platzmangel angesagt. :D
 
So, ich habe jetzt das Laufwerk habe ich jetzt erst einmal Vergrößert, damit habe ich genügend Platz.

Screenshot 2026-05-27 131719.png

Die Frage bleibt allerdings, warum ist die Platz so schnell vollgelaufen, was nutzt den Speicher ...
 
Nee, die Frage wäre bereits geklärt, wenn Du mal das machen würdest, was Impact und daanw vorgeschlagen haben... :rolleyes:
 
JensF said:
Nee, die Frage wäre bereits geklärt, wenn Du mal das machen würdest, was Impact und daanw vorgeschlagen haben... :rolleyes:
Click to expand...
Locker bleiben, bin ja schon dabei

Code: 
root@alvpmg1:/usr# du -sh /* | sort -h
du: cannot access '/proc/2439/task/2439/fd/4': No such file or directory
du: cannot access '/proc/2439/task/2439/fdinfo/4': No such file or directory
du: cannot access '/proc/2439/fd/3': No such file or directory
du: cannot access '/proc/2439/fdinfo/3': No such file or directory
0       /bin
0       /lib
0       /lib64
0       /proc
0       /sbin
0       /sys
0       /tmp
4.0K    /home
4.0K    /media
4.0K    /mnt
4.0K    /opt
4.0K    /srv
16K     /lost+found
64K     /root
856K    /run
1.1M    /dev
4.8M    /etc
1.3G    /boot
3.0G    /var
12G     /usr
root@alvpmg1:/usr# du -sh /usr/* | sort -h
4.0K    /usr/games
4.0K    /usr/lib64
4.0K    /usr/src
44K     /usr/include
60K     /usr/local
1.8M    /usr/libexec
28M     /usr/sbin
148M    /usr/bin
400M    /usr/share
11G     /usr/lib
root@alvpmg1:/usr# du -sh /usr/lib/* | sort -h
0       /usr/lib/sendmail
0       /usr/lib/sftp-server
4.0K    /usr/lib/depmod.d
4.0K    /usr/lib/environment.d
4.0K    /usr/lib/gnupg2
4.0K    /usr/lib/grub-legacy
4.0K    /usr/lib/os-release
4.0K    /usr/lib/sasl2
8.0K    /usr/lib/binfmt.d
8.0K    /usr/lib/cups
8.0K    /usr/lib/groff
8.0K    /usr/lib/modules-load.d
8.0K    /usr/lib/os-probes
8.0K    /usr/lib/pam.d
8.0K    /usr/lib/rsyslog
12K     /usr/lib/console-setup
12K     /usr/lib/runit-helper
16K     /usr/lib/bridge-utils
16K     /usr/lib/init
16K     /usr/lib/pmg
16K     /usr/lib/sysctl.d
16K     /usr/lib/valgrind
20K     /usr/lib/networkd-dispatcher
20K     /usr/lib/NetworkManager
24K     /usr/lib/libsupp.a
28K     /usr/lib/lsb
32K     /usr/lib/kernel
32K     /usr/lib/ssl
32K     /usr/lib/sysusers.d
36K     /usr/lib/dpkg
40K     /usr/lib/dhcpcd
56K     /usr/lib/dbus-1.0
60K     /usr/lib/mime
68K     /usr/lib/pcrlock.d
72K     /usr/lib/modprobe.d
76K     /usr/lib/klibc-cbxFsLVJ9bt_YYfJZGrxjofFc_w.so
84K     /usr/lib/dracut
128K    /usr/lib/tmpfiles.d
316K    /usr/lib/man-db
408K    /usr/lib/zfs-linux
544K    /usr/lib/klibc
744K    /usr/lib/gnupg
1.2M    /usr/lib/apt
2.3M    /usr/lib/postfix
3.3M    /usr/lib/locale
3.5M    /usr/lib/openssh
3.9M    /usr/lib/shim
6.4M    /usr/lib/systemd
6.9M    /usr/lib/7zip
9.9M    /usr/lib/file
12M     /usr/lib/memtest86+
23M     /usr/lib/python3
23M     /usr/lib/udev
26M     /usr/lib/grub
28M     /usr/lib/python3.13
45M     /usr/lib/postgresql
437M    /usr/lib/x86_64-linux-gnu
556M    /usr/lib/firmware
9.4G    /usr/lib/modules
root@alvpmg1:/usr# du -sh /usr/lib/modules/* | sort -h
592M    /usr/lib/modules/6.14.11-3-pve
592M    /usr/lib/modules/6.14.11-5-pve
592M    /usr/lib/modules/6.14.11-6-pve
592M    /usr/lib/modules/6.14.11-8-pve
594M    /usr/lib/modules/6.14.11-9-pve
934M    /usr/lib/modules/6.17.13-2-pve
934M    /usr/lib/modules/6.17.4-2-pve
934M    /usr/lib/modules/6.17.9-1-pve
935M    /usr/lib/modules/6.17.13-7-pve
940M    /usr/lib/modules/6.17.13-11-pve
970M    /usr/lib/modules/7.0.2-2-pve
970M    /usr/lib/modules/7.0.2-6-pve
root@alvpmg1:/usr#
 
Wenn mit Kernel 7 alles läuft würde ich an deiner Stelle mit
Code: 
apt remove proxmox-kernel-6* --purge
alle alten Kernel deinstallieren.
Edit: daanw war schneller. :)
 
  • Like
Reactions: news
Eigentlich blöd, dass die Update-Funktion bei den Proxmox-Tools nie selbst ein "autoremove" ausführt. Das ist weder beim PVE, noch beim PMG so.
Oder gibt es einen Grund, warum dies nicht getan wird? Autoremove sollte ja eigentlich safe sein, sofern alles sauber über Repos installiert wurde.
 
You must log in or register to reply here.
Top Bottom
Back