How can we optimize/clean disk usage from Docker and more?
-
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.
--
Dustin Dauncey
www.d19.ca -
@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 -ait still gave me a 0 byte response showing it cleaned up nothing. Am I missing something when it comes to reclaimable images in Docker? -
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.
-
@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 -ait still gave me a 0 byte response showing it cleaned up nothing. Am I missing something when it comes to reclaimable images in Docker?@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 -
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.
-
G girish referenced this topic on
-
cleaning up the docker images as mentioned above basically works.
On my instance, there however are two app docker images that are much larger than the others:
rallly (almost 6GB), loomio (>6GB)
Is this size "normal"?
Is the "normal" size of the apps' docker images documented anywhere? -
@andreasb you can check the sizes of docker images here - https://hub.docker.com/u/cloudron . But looks like it lists only the compressed size. Size of docker images is not documented anywhere . The 6GB includes many layers and the layers are "shared" across apps (the way docker works).
We also hvae images on quay - https://quay.io/organization/cloudron . But I think this requires login, despite images being public . These sizes differ from dockerhub
-
After being inspired by @timconsidine's AppsMonitor and noticing higher than usual disk usage, here is the perplexing af play-by-play of how I saved over 20GB of space in terminal commands.
54GB seems high for this smaller server.
d;-/root@zvuk:~# docker system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 53 49 54.14GB 393.4MB (0%) Containers 130 110 625.5MB 625.5MB (100%) Local Volumes 244 244 9.686GB 0B (0%) Build Cache 0 0 0B 0B root@zvuk:~# docker image prune -f Total reclaimed space: 0MB root@zvuk:~# docker container prune -f Total reclaimed space: 625.5MB root@zvuk:~# docker volume prune -f Deleted Volumes: ... Total reclaimed space: 3.422GB root@zvuk:~# docker system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 53 42 54.14GB 17.79GB (32%) Containers 110 110 0B 0B Local Volumes 224 224 6.263GB 0B (0%) Build Cache 0 0 0B 0B root@zvuk:~# docker image prune -f Deleted Images: ... Total reclaimed space: 2.36kBWhat? That's it?
How did volume prune find 3+GB when 0% was reclaimable?
Then this took a while of staring & pondering:
root@zvuk:~# docker system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 51 42 54.14GB 17.99GB (33%) Containers 110 110 0B 0B Local Volumes 224 224 6.263GB 0B (0%) Build Cache 0 0 0B 0B root@zvuk:~# docker image prune -af Deleted Images: ... (long list) Total reclaimed space: 20.16GB root@zvuk:~# docker system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 42 42 33.97GB 0B (0%) Containers 110 110 0B 0B Local Volumes 224 224 6.263GB 0B (0%) Build Cache 0 0 0B 0BI learned that the -af flag is important at least for images.
The long list of deleted images contained old surfer images, wordpress.unmanaged images, many untagged images, including the cloudron 5.0.0 base image, custom apps and apps I tried once and deleted long ago.
@girish Do we need box to include more checks across volumes, containers and images now that we're dealing with so many custom apps and base images updates?
-
After being inspired by @timconsidine's AppsMonitor and noticing higher than usual disk usage, here is the perplexing af play-by-play of how I saved over 20GB of space in terminal commands.
54GB seems high for this smaller server.
d;-/root@zvuk:~# docker system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 53 49 54.14GB 393.4MB (0%) Containers 130 110 625.5MB 625.5MB (100%) Local Volumes 244 244 9.686GB 0B (0%) Build Cache 0 0 0B 0B root@zvuk:~# docker image prune -f Total reclaimed space: 0MB root@zvuk:~# docker container prune -f Total reclaimed space: 625.5MB root@zvuk:~# docker volume prune -f Deleted Volumes: ... Total reclaimed space: 3.422GB root@zvuk:~# docker system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 53 42 54.14GB 17.79GB (32%) Containers 110 110 0B 0B Local Volumes 224 224 6.263GB 0B (0%) Build Cache 0 0 0B 0B root@zvuk:~# docker image prune -f Deleted Images: ... Total reclaimed space: 2.36kBWhat? That's it?
How did volume prune find 3+GB when 0% was reclaimable?
Then this took a while of staring & pondering:
root@zvuk:~# docker system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 51 42 54.14GB 17.99GB (33%) Containers 110 110 0B 0B Local Volumes 224 224 6.263GB 0B (0%) Build Cache 0 0 0B 0B root@zvuk:~# docker image prune -af Deleted Images: ... (long list) Total reclaimed space: 20.16GB root@zvuk:~# docker system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 42 42 33.97GB 0B (0%) Containers 110 110 0B 0B Local Volumes 224 224 6.263GB 0B (0%) Build Cache 0 0 0B 0BI learned that the -af flag is important at least for images.
The long list of deleted images contained old surfer images, wordpress.unmanaged images, many untagged images, including the cloudron 5.0.0 base image, custom apps and apps I tried once and deleted long ago.
@girish Do we need box to include more checks across volumes, containers and images now that we're dealing with so many custom apps and base images updates?
-
@d19dotca it seems the yarn cache was note cleared. Clearing it brought down the size . It's in the new package.
@girish Hi, i was looking at the umami Dockerfile and i think we could save another 200MB here on top.
The pnpm install is not adding --prod here https://git.cloudron.io/packages/umami-app/-/blob/master/Dockerfile?ref_type=heads#L23
So it's also adding all the devDependencies to node_modules (i.e. vitest, etc)
Skipping those slims the node_modules slightly (200MB)There's one small problem though the "pnpm run build:geo" part fails then as it uses the tar module which is only in devDependencies. Adding tar manually there as a workaround get's it to work.
I did a quick "cloudron builder build" and also cloudron install (as quite a bit of the build process is on start time) and with just that tar workaround it went through and can login to the app.I didn't report that tar bug upstream or did any more testing (as i don't actually use umami). Was just curious myself if we could same some more space here.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better π
Register Login