Is 30GB now too small to upgrade?

I have a Digital Ocean droplet running. I’m currently on v2.1.0.beta1 +149 & was prompted to upgrade docker (successful) before moving onto Discourse. I now can’t upgrade because of lack of space (reports 27GB/30GB & needs min 5GB).

It’s a small site & a handful of users & very few media attachments. Listing out the biggest directories gives me:

  • 16M bin
  • 1.1G boot
  • 2.1G swapfile
  • 3.4G usr
  • 5.1G lib
  • 19G var

then in /var:

1.7M backups
24M log
66M cache
2.4G discourse
16G lib

then in lib/

42M mlocate
125M dpkg
144M apt
16G docker

Does anything look out of order in these?

Can anyone suggest where I might save enough space to get the upgrade working? Moving up from a 30GB droplet in Digital Ocean doesn’t seem straightforward.

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
7 Likes

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?

4 Likes