docker system prune --volumes
WARNUNG! Dies wird Folgendes entfernen:
- alle gestoppten Container
- alle Netzwerke, die von keinem Container verwendet werden
- alle Volumes, die von keinem Container verwendet werden
- alle hängenden Images
- den gesamten hängenden Build-Cache
Sind Sie sicher, dass Sie fortfahren möchten? [j/N] j
Gesamter belegter Speicherplatz: 0B
root@DO-Discourse:/#
Nicht wirklich, das ist ziemlich aussagekräftig, dass der Speicherplatz von Docker für Ihre Container verbraucht wird. Nach einer Bereinigung sind meine Zahlen sehr ähnlich wie Ihre, was vielleicht (aber nicht unbedingt) darauf hindeutet, dass es nur darum geht, wie viel es verbraucht.
Ich hatte zwar Probleme mit einem 25 GB Linode, aber das war mit 500 MB+ Backups. Das Löschen von zwei oder drei Backups gab mir genug Platz zum Wiederaufbauen. Ich habe mich entschieden, auf die nächste Stufe mit 50 GB zu wechseln, da es nur noch einschränkender werden würde und ich jeden Monat einen Wiederaufbau per Cronjob durchführen wollte.
Das war jedoch vor dem Wechsel zu Ember CLI, könnte das die Dinge erheblich vergrößert haben?
Diese 9 GB große Überlagerung scheint das Problem zu sein. Aber ich habe eine mit ähnlicher Größe in einer anderen Instanz, die ich gerade überprüft habe. Mit 25 GB war es schon immer schwierig. Ich empfehle Ihnen, in den sauren Apfel zu beißen und mehr SSD zu bekommen. Als Nächstes könnten Sie versuchen, ob es auf Betriebssystemebene Dinge gibt, die Sie entfernen können (Protokolle, unnötige Programme, Indizes von find, vielleicht?).
Eine andere Idee wäre, einfach eine neue 25-GB-VM zu starten und dorthin zu wechseln, in der Hoffnung, dass das, was die alte gefüllt hat, dieses Mal kein Problem darstellt.
Keine dieser Antworten scheint besonders befriedigend zu sein. Ich habe in den letzten ein oder zwei Wochen hart mit einem 25-GB-Droplet auf ein oder zwei Instanzen gekämpft, die ich verwalte, aber ich glaube, Sie haben alles getan, was ich auch getan habe.
Ich glaube nicht
Nachdem ein vollständiges Backup heruntergeladen wurde, können Sie snap list ausführen, um zu überprüfen, welche Snaps installiert sind, und wenn keine vorhanden sind, sudo apt purge snapd
Hallo Andy, entschuldige die Verzögerung.
Zu diesem Zeitpunkt sei bitte daran erinnert, dass es ohne Einblick in dein Host-System leicht ist, dich in die Irre zu führen, also sichere/erstelle Snapshots/usw. (oder erstelle sogar ein Backup, starte eine neue Instanz und teste den Wiederherstellungsprozess, es war eine gute Übung für mich)
Angenommen, du hast keine Verwendung für lxd (lxc list sollte installierte Container anzeigen) snap remove lxd (und dann core18 und 20)
Vielen Dank für Ihre Hilfe. Ja, ich weiß so wenig über Linux, dass ich den Ratschlag, ein Backup zu erstellen, voll und ganz schätze. Ich habe einen automatischen Snapshot und mache manuell einen, wann immer ich herumspiele wie jetzt.
Ich habe keine Ahnung, was lxd ist. Ich brauche nichts auf diesem Droplet, was Discourse/Docker nicht braucht, da es sich ausschließlich um ein Discourse-Droplet handelt.
root@DO-Discourse:/var/discourse# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
local_discourse/app latest 3dac608caa92 4 months ago 3.17GB
root@DO-Discourse:/var/discourse#
root@DO-Discourse:/var/discourse# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9abaf4517b7e local_discourse/app “/sbin/boot” 4 months ago Up 4 months 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp app
root@DO-Discourse:/var/discourse#
Ich denke, es ist sicher, all diese Bilder zu löschen. Wenn Sie sie benötigen, werden sie ersetzt, wenn Sie neu erstellen.
Einen Snapshot zu machen, ist keine schlechte Idee.
Was ich tun würde, ist, einfach eine neue Instanz zu starten; das ist am sichersten und wahrscheinlich schneller als ein Snapshot, aber wenn Sie nicht wissen, wie das geht, oder es nicht lehrreich ist, ist Ihre Idee in Ordnung.
