How can we optimize/clean disk usage from Docker and more?
-
I'm trying to understand how I can clean up the disk by lowering the disk usage. I applied
docker image prune -a
but it reclaimed all of 0 bytes, lol, so it didn't seem to work for me in the way I was hoping.The reason for this is I'm using the Public Cloud instance of OVH but specifically their "flexible" cloud instance so that the instance can be sized up and down for CPU and memory rather than only up. The downside is it gives only a 50 GB hard disk on a flexible instance which is fine with me though as block storage is pretty inexpensive. So I have
boxdata
andappsdata
on different external block storage disks with plenty of space.But the main disk is still quite consumed by Docker. Here's my current usage for the main disk:
/dev/sda1 mounted at / 41.1 GB used of 51.84 GB Speed: 1180 MB/sec This disk contains: docker 14.37 GB docker-volumes 5.51 GB platformdata 5.48 GB /apps.swap 4.29 GB Everything else (Ubuntu, etc) 11.45 GB
I have considered reducing the swap if possible since I have ample memory, but I'd rather keep it if needed.
The docker is over 14 GB, and docker-volumes just over 5 GB. Basically the main "Docker" tag is the main user and to some degree I think that makes sense as it's the main platform, but I'm curious if it should be that high still. I noticed another post where a user tried the
docker image prune -a
and reclaimed nearly 10 GB to squeeze it down to closer to 4 GB but that didn't do anything for me unfortunately.sudo docker image prune -a WARNING! This will remove all images without at least one container associated to them. Are you sure you want to continue? [y/N] y Deleted Images: untagged: registry.docker.com/cloudron/base:4.2.0 untagged: registry.docker.com/cloudron/base@sha256:46da2fffb36353ef714f97ae8e962bd2c212ca091108d768ba473078319a47f4 deleted: sha256:6ec7c1ab3983e1ebdbf75ced0e8089db363083aa4ed004be0022d45bafaef4f9 Total reclaimed space: 0B
It looks like the images are the main thing when I run the
docker system df
command (accounts for the full docker stat on the Cloudron disk usage chart):sudo docker system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 22 22 14.37GB 2.21GB (15%) Containers 87 64 0B 0B Local Volumes 162 134 5.537GB 1.667GB (30%) Build Cache 0 0 0B 0B
What's odd is that it shows nearly 3+ GB of reclaimable space, but it seems like that isn't actually recoverable to add back to available disk space, at least not in any way that I've found so far.
Is there anything I can do here to help conserve space, is there perhaps any commands I can run to clean things up further for Docker? Any guidance would be appreciated. If needed I may just get a small external block storage for the
platform data
but I am hoping to avoid that so I can keep all the DB stuff on the main higher-performing disk. -
Did you try to remove images individually? (I know this is not optimal, but on my system the prune doesn't free any new bytes, but removing images individually works to get space back)
-
@d19dotca can you try
docker volume prune -a
? Looks like we have some unused volumes storage from the past. -
@girish That worked well for the volumes, it cleared up the 1.666GB of storage space. Thank you!
What about the images though? It says over 2 GB is reclaimable but it doesn't seem like it is from what I can tell. If I tried to do a similar command specific to images such as
docker image prune -a
it still gave me a 0 byte response showing it cleaned up nothing. Am I missing something when it comes to reclaimable images in Docker? -
Here is my docker image list by the way in case this points to any issues at all:
$ sudo docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE cloudron/org.nodebb.cloudronapp 20240403-154317-254cac2fd 3b7a24812a6e 32 hours ago 2.86GB cloudron/com.invoiceninja.cloudronapp2 20240401-092303-3942cee63 dcda0788296b 3 days ago 3.6GB cloudron/io.gitea.cloudronapp 20240326-072227-110a2e6cd 7ed238e459fa 9 days ago 2.74GB cloudron/sh.ntfy.cloudronapp 20240326-072218-802b89e89 807661895891 9 days ago 2.26GB cloudron/org.wordpress.unmanaged.cloudronapp 20240319-202918-2976247a8 1117a989fc3a 2 weeks ago 2.3GB cloudron/org.radicale.cloudronapp2 20240319-154937-11289c349 036b57520b5b 2 weeks ago 2.22GB registry.docker.com/cloudron/postgresql 5.2.1 333f887a27f7 3 weeks ago 2.75GB cloudron/org.piwik.cloudronapp 20240308-102528-2182681db 3ddaa6276ff3 3 weeks ago 2.51GB cloudron/is.umami.cloudronapp 20240307-081949-7105f94d1 d0512bd1a4c1 4 weeks ago 6.57GB registry.docker.com/cloudron/sftp 3.8.6 b735f2120189 4 weeks ago 2.23GB cloudron/com.github.bitwardenrs 20240303-104654-927b1cf62 1393b91919fa 4 weeks ago 3.51GB registry.docker.com/cloudron/mail 3.12.1 ea18fc4dd1c7 5 weeks ago 2.96GB registry.docker.com/cloudron/mongodb 6.0.0 4b95d24318a2 8 weeks ago 2.69GB cloudron/net.roundcube.cloudronapp 20240121-133422-3162a79c7 29ad5d8091ed 2 months ago 2.23GB cloudron/louislam.uptimekuma.app 20240102-093304-840efe2c0 0e7aea4082d9 3 months ago 3.29GB cloudron/tech.ittools.cloudron 20231221-163307-91643bd95 961340a3d920 3 months ago 2.22GB cloudron/io.cloudron.surfer 20231216-181458-705d2061b 8a2725a40c45 3 months ago 2.39GB registry.docker.com/cloudron/graphite 3.4.3 dbd026164ada 5 months ago 2.28GB cloudron/net.jirafeau.cloudronapp 20231013-024132-1436ee8da 4155ebdab88f 5 months ago 2.21GB registry.docker.com/cloudron/redis 3.5.2 80e7a4079e6b 6 months ago 2.22GB registry.docker.com/cloudron/mysql 3.4.2 c7085a52532b 6 months ago 2.53GB registry.docker.com/cloudron/turn 1.7.2 152b1fb9690e 6 months ago 2.22GB
-
I'm curious why the Umami app is so massive. It's such a lightweight application... is it expected to be that large? I wonder if this is somehow a contributor to the issue of reclaimable space but not actually being removed since it's still active? Just throwing against a wall though, not sure if that's valid. haha.
-
@d19dotca for volumes, thee was a bug. I fixed this in master yesterday - https://git.cloudron.io/cloudron/box/-/commit/030e4688294d0ffe1c34468e6622c4b1b22fd357
-
-
@d19dotca said in How can we optimize/clean disk usage from Docker and more?:
docker image prune -a it still gave me a 0 byte response showing it cleaned up nothing.
Just to say, I'm pretty sure that in the past I've done this and got a 0 byte response too, but then there actually was more space available.
-
Just the node modules is 1.4G
root@aaa028f2-b8bc-41cf-82be-a23f59293d39:/app/code# du -hcs * 4.0K Dockerfile 4.0K LICENSE 4.0K README.md 4.0K app.json 36K cypress 4.0K cypress.config.ts 160K db 8.0K docker 4.0K docker-compose.yml 51M geo 4.0K jest.config.ts 4.0K jsconfig.json 4.0K lang-ignore.json 4.0K netlify.toml 4.0K next-env.d.ts 4.0K next.config.js 1.3G node_modules 4.0K package.components.json 8.0K package.json 4.0K postcss.config.js 68K prisma 4.5M public 4.0K rollup.components.config.mjs 4.0K rollup.tracker.config.mjs 60K scripts 3.2M src 4.0K tsconfig.json 532K yarn.lock 1.4G total
-
FWIW, I uninstalled the app so that the image would be removed, confirmed it was removed, and then re-installed. The image size changed slightly from 6.57 GB to 6.51 GB, but still quite large. I may be doing in the wrong area though if we don't think this is a huge concern, just really strange to me why it's so much larger than all the other images when it's supposedly a fairly lean app.
For the life of me I cannot seem to reclaim the over 2 GB of disk space from images in Docker, I am puzzled as to why that is happening.
-
@d19dotca it seems the yarn cache was note cleared. Clearing it brought down the size . It's in the new package.
-