-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] magick-files filling /tmp on microservices container #4391
Comments
Good catch. It sounds like libvips (the library calling Imagemagick) might not be cleaning up after it. It's worth checking if there's an issue there and making an issue if not. |
I just had to recreate the container again as it was using 43GB. I'll keep observing it. If you need more information I'm happy to provide anything I can. |
I just had to cleanup the folder again. Here are the attached logs of the microservices container: |
I just had the issue again on version 1.95.1. Can this be reopened? |
How much RAM does the server have, by chance? |
The server has 16 GB and currently 7640 MB available. |
I looked into this a bit more. I think Imagemagick has an internal limit for how much RAM it's willing to use. Once it goes above this, it starts serializing files to disk. It normally cleans these up after finishing, but based on your logs it could be that an error in an image means the file gets left behind. I can make an upstream issue for this and make it work in-memory only in the meantime. |
Oh, and you can probably avoid this for now by lowering your thumbnail generation concurrency. It will lower the RAM usage and help keep it below the limit. |
Okay, so it might be a bit harder to fix this on our end based on the discussion here. Lowering your concurrency is probably the best option for now. |
Thanks for looking into it and creating the upstream discussion. When I understand that correctly, there's no way around the temp files for RAW images though? I just set the thumbnail concurrency to 1 (down from 5) and will update here if it happens again. |
I just manually started the generate thumbnails where "missing" task. It was looking good until the following log snippet. docker-compose also tells me that the container has restarted. So it seems like there's some fatal error that's not logged and I now have a single file in /tmp that's not touched any more. After restarting manually again, I have 3 more files in there. Maybe a simple way would be to clear /tmp on startup? Or I could mount it to tmpfs instead? I'm not sure if that's cleared on container restart though. Is there a way I can provide more logs? Changing log level to verbose via the WebUI didn't change anything.
|
I just added the following tmpfs volume and will report back if anything happens:
|
I did not have any issues since adding the tmpfs volume. Would it make sense to add that to the default docker-compose? |
I recently migrated to the docker-compose without distinct microservices container and had the problem again today. Adding the tmpfs mount to the server fixed the problem for me again. |
Adding a tmpfs means that it is wiped on container restart. Can't the temp folder be cleaned on start or even regularly instead? |
The bug
I just ran out of storage on my server, because immich used everything as it became free. I found the culprit to be the microservices container storing loads of
magick-....
files in/tmp
.I found imagemagick - lot of temp magick files created in temporary folder - Stack Overflow, which might be somewhat relevant. I was low on diskspace anyways, so that might have something to do with it as well. I currently can see immich using 16GB already again though:
Current output of the /tmp folder
The OS that Immich Server is running on
Ubuntu 20.04
Version of Immich Server
unsure - just upgraded to 1.81.1
Version of Immich Mobile App
not relevant
Platform with the issue
Your docker-compose.yml content
not accessible right now. Will supply later.
Your .env content
Reproduction steps
Additional information
No response
The text was updated successfully, but these errors were encountered: