هل أصبحت سعة 30 جيجابايت صغيرة جدًا للترقية؟

لديك Droplet من Digital Ocean قيد التشغيل. أنا حاليًا على الإصدار v2.1.0.beta1 +149، وتم تنبيهي لترقية Docker (تم بنجاح) قبل الانتقال إلى Discourse. الآن لا يمكنني الترقية بسبب نقص المساحة (يُبلغ عن 27 جيجابايت من أصل 30 جيجابايت، مع حاجة إلى حد أدنى 5 جيجابايت).

إنه موقع صغير بعدد قليل من المستخدمين وملفات وسائط قليلة جدًا. عند سرد أكبر المجلدات، أحصل على:

  • 16 ميجابايت bin
  • 1.1 جيجابايت boot
  • 2.1 جيجابايت swapfile
  • 3.4 جيجابايت usr
  • 5.1 جيجابايت lib
  • 19 جيجابايت var

ثم في /var:

1.7 ميجابايت backups
24 ميجابايت log
66 ميجابايت cache
2.4 جيجابايت discourse
16 جيجابايت lib

ثم في lib/:

42 ميجابايت mlocate
125 ميجابايت dpkg
144 ميجابايت apt
16 جيجابايت docker

هل يبدو أي شيء غير طبيعي في هذه الأرقام؟

هل يمكن لأحد اقتراح أين يمكنني توفير مساحة كافية لجعل الترقية تعمل؟ لا يبدو الانتقال من Droplet بحجم 30 جيجابايت في Digital Ocean أمرًا مباشرًا.

I believe there are existing topics on this, how to clear up space. The TL;DR version is:

/var/discourse/launcher cleanup
apt-get autoclean
apt-get autoremove

I was updating a droplet so here’s a before and after those three commands

root@talk:/var/discourse# df
Filesystem     1K-blocks     Used Available Use% Mounted on
udev             1005384        0   1005384   0% /dev
tmpfs             204812    21136    183676  11% /run
/dev/vda1       41153856 15600148  23440172  40% /
tmpfs            1024040      584   1023456   1% /dev/shm
tmpfs               5120        0      5120   0% /run/lock
tmpfs            1024040        0   1024040   0% /sys/fs/cgroup
cgmfs                100        0       100   0% /run/cgmanager/fs
tmpfs             204812        0    204812   0% /run/user/1000
none            41153856 15600148  23440172  40% /var/lib/docker/aufs/mnt/2a8
shm               524288        8    524280   1% /var/lib/docker/containers/f8f

here’s the result

root@talk:/var/discourse# df
Filesystem     1K-blocks     Used Available Use% Mounted on
udev             1005384        0   1005384   0% /dev
tmpfs             204812    21152    183660  11% /run
/dev/vda1       41153856 11923676  27116644  31% /
tmpfs            1024040     1304   1022736   1% /dev/shm
tmpfs               5120        0      5120   0% /run/lock
tmpfs            1024040        0   1024040   0% /sys/fs/cgroup
cgmfs                100        0       100   0% /run/cgmanager/fs
tmpfs             204812        0    204812   0% /run/user/1000
none            41153856 11923676  27116644  31% /var/lib/docker/aufs/mnt/2a8
shm               524288        8    524280   1% /var/lib/docker/containers/f8f

Thank you very much @codinghorror . Docker cleanup gave me back 6 GB or so & the Ubuntu cleanup showed up plenty of old kernels, so another 4GB or so. It’s now maintainable:

Filesystem     1K-blocks     Used Available Use% Mounted on
udev              487940        0    487940   0% /dev
tmpfs             101608    10880     90728  11% /run
/dev/vda1       30428648 14770996  15641268  49% /
tmpfs             508028     1028    507000   1% /dev/shm
tmpfs               5120        0      5120   0% /run/lock
tmpfs             508028        0    508028   0% /sys/fs/cgroup
tmpfs             101608        0    101608   0% /run/user/0
none            30428648 14770996  15641268  49% /var/lib/docker/aufs/mnt/800
shm               524288        8    524280   1% /var/lib/docker/containers/618

Doing this manually once a year or so seems painless enough, but could I configure unattended upgrades to deal with the kernels & docker? Is this wise on an instance that does nothing but run vanilla Discourse or might it conflict with Discourse upgrade scripts?