PSA: If the first Smart Search in Immich takes a while
-
Your ML model cache volume is getting blown up during restart and the model is being re-downloaded during the first search post-restart. Either set it to a path somewhere on your storage, or ensure you're not blowing up the dynamic volume upon restart.
In my case I changed this:
immich-machine-learning: ... volumes: - model-cache:/cacheTo that:
immich-machine-learning: ... volumes: - ./cache:/cacheI no longer have to wait uncomfortably long when I'm trying to show off Smart Search to a friend, or just need a meme pronto.
That'll be all.
It's not normal for
- model-cache:/cacheto be deleted on restart or even upgrade. You shouldn't need to do this. -
It's not normal for
- model-cache:/cacheto be deleted on restart or even upgrade. You shouldn't need to do this.wrote last edited by [email protected]Yes, it depends on how you're managing the service. If you're using one of the common patterns via systemd, you may be cleaning up everything, including old volumes, like I do.
E: Also if you have any sort of lazy prune op running on a timer, it could blow it up at some point.
-
Is this something that would be recommended if self-hosting off a Synology 920+ NAS?
My NAS does have extra ram to spare because I upgraded it, and has NVME cache
wrote last edited by [email protected]That's a Celeron right? I'd try a better AI model. Check this page for the list. You could try the heaviest one. It'll take a long time to process your library but inference is faster. I don't know how much faster it is. Maybe it would be fast enough to be usable. If not usable, choose a lighter model. There's execution times in the table that I assume tell us how heavy the models are. Once you change a model, you have to let it rescan the library.
-
That's a Celeron right? I'd try a better AI model. Check this page for the list. You could try the heaviest one. It'll take a long time to process your library but inference is faster. I don't know how much faster it is. Maybe it would be fast enough to be usable. If not usable, choose a lighter model. There's execution times in the table that I assume tell us how heavy the models are. Once you change a model, you have to let it rescan the library.
That’s a Celeron right?
Yup, the Intel J4125 Celeron 4-Core CPU, 2.0-2.7Ghz.
I switched to the ViT-SO400M-16-SigLIP2-384__webli model, same as what you use. I don't worry about processing time, but it looks like a more capable model, and I really only use immich for contextual search anyway, so that might be a nice upgrade.
-
Your ML model cache volume is getting blown up during restart and the model is being re-downloaded during the first search post-restart. Either set it to a path somewhere on your storage, or ensure you're not blowing up the dynamic volume upon restart.
In my case I changed this:
immich-machine-learning: ... volumes: - model-cache:/cacheTo that:
immich-machine-learning: ... volumes: - ./cache:/cacheI no longer have to wait uncomfortably long when I'm trying to show off Smart Search to a friend, or just need a meme pronto.
That'll be all.
wrote last edited by [email protected]Doing a volume like the default Immich docker-compose uses should work fine, even through restarts. I'm not sure why your setup is blowing up the volume.
Normally volumes are only removed if there is no running container associated with it, and you manually run
docker volume prune -
That’s a Celeron right?
Yup, the Intel J4125 Celeron 4-Core CPU, 2.0-2.7Ghz.
I switched to the ViT-SO400M-16-SigLIP2-384__webli model, same as what you use. I don't worry about processing time, but it looks like a more capable model, and I really only use immich for contextual search anyway, so that might be a nice upgrade.
Did you run the Smart Search job?
-
That seems like a bad idea
It's not.
-
Doing a volume like the default Immich docker-compose uses should work fine, even through restarts. I'm not sure why your setup is blowing up the volume.
Normally volumes are only removed if there is no running container associated with it, and you manually run
docker volume pruneBecause I clean everything up that's not explicitly on disk on restart:
[Unit] Description=Immich in Docker After=docker.service Requires=docker.service [Service] TimeoutStartSec=0 WorkingDirectory=/opt/immich-docker ExecStartPre=-/usr/bin/docker compose kill --remove-orphans ExecStartPre=-/usr/bin/docker compose down --remove-orphans ExecStartPre=-/usr/bin/docker compose rm -f -s -v ExecStartPre=-/usr/bin/docker compose pull ExecStart=/usr/bin/docker compose up Restart=always RestartSec=30 [Install] WantedBy=multi-user.target -
Its convenient because your data is stored in the same folder that your docker-compose.yaml file is in, making backups or migrations simpler.
Yup. Everything is in one place and there's no hardcoded paths outside of the work dir making it trivial to move across storage or even machines.
-
Because I clean everything up that's not explicitly on disk on restart:
[Unit] Description=Immich in Docker After=docker.service Requires=docker.service [Service] TimeoutStartSec=0 WorkingDirectory=/opt/immich-docker ExecStartPre=-/usr/bin/docker compose kill --remove-orphans ExecStartPre=-/usr/bin/docker compose down --remove-orphans ExecStartPre=-/usr/bin/docker compose rm -f -s -v ExecStartPre=-/usr/bin/docker compose pull ExecStart=/usr/bin/docker compose up Restart=always RestartSec=30 [Install] WantedBy=multi-user.targetBut why?
why not just down up normally and have a cleanup job on a schedule to get rid of any orphans?
-
That seems like a bad idea
wrote last edited by [email protected]As other stated it’s not a bad way of managing volumes. In my scenario I store all volumes in a
/configfolder.For example on my SearXNG instance I have a volume like such:
services: searxng: … volumes: - ./config/searx:/etc/searxng:rwThis makes the files for SearXNG two folders away. I also store these in the
/home/YourUserdirectory so docker avoids using sudoers access whenever possible. -
But why?
why not just down up normally and have a cleanup job on a schedule to get rid of any orphans?
But why?
I a world where we can't really be sure what's in an upgrade, a super-clean start that burns any ephemeral data is about the best way to ensure a consistent start.
And consistency gives reliability, as much as we can get without validation (validation is "compare to what's correct", but consistency is "try to repeat whatever it was").
-
That’s a Celeron right?
Yup, the Intel J4125 Celeron 4-Core CPU, 2.0-2.7Ghz.
I switched to the ViT-SO400M-16-SigLIP2-384__webli model, same as what you use. I don't worry about processing time, but it looks like a more capable model, and I really only use immich for contextual search anyway, so that might be a nice upgrade.
wrote last edited by [email protected]What's your consideration for choosing this one? I would have thought ViT-B-16-SigLIP2__webli to be slightly more accurate, with faster response and all that while keeping a slightly less RAM consumption (1.4GB less I think).
-
As other stated it’s not a bad way of managing volumes. In my scenario I store all volumes in a
/configfolder.For example on my SearXNG instance I have a volume like such:
services: searxng: … volumes: - ./config/searx:/etc/searxng:rwThis makes the files for SearXNG two folders away. I also store these in the
/home/YourUserdirectory so docker avoids using sudoers access whenever possible.So why would you not write out the full path? I frequently rerun compose commands from various places, if I'm troubleshooting an issue.
-
Did you run the Smart Search job?
Running now.
-
What's your consideration for choosing this one? I would have thought ViT-B-16-SigLIP2__webli to be slightly more accurate, with faster response and all that while keeping a slightly less RAM consumption (1.4GB less I think).
Seemed to be the most popular. LOL The smart search job hasn't been running for long, so I'll check that other one out and see how it compares. If it looks better, I can easily use that.
-
So why would you not write out the full path? I frequently rerun compose commands from various places, if I'm troubleshooting an issue.
wrote last edited by [email protected]So why would you not write out the full path?
The other day my raspberry pi decided it didn’t want to boot up, I guess it didn’t like being hosted on an SD card anymore, so I backed up my
composefolder and reinstalled Rasp Pi OS under a different username than my last install.If I specified the full path on every container it would be annoying to have to redo them if I decided I want to move to another directory/drive or change my username.
-
So why would you not write out the full path?
The other day my raspberry pi decided it didn’t want to boot up, I guess it didn’t like being hosted on an SD card anymore, so I backed up my
composefolder and reinstalled Rasp Pi OS under a different username than my last install.If I specified the full path on every container it would be annoying to have to redo them if I decided I want to move to another directory/drive or change my username.
I'd just do it with a simple search and replace. Have done. I feel like relative paths leave too much room for human error.
-
./will be the directory you run your compose fromI'm almost sure that
./is the directory of the compose.yaml.Normally I just run
docker compose up -din the project directory, but I could rundocker compose up -d -f /somewhere/compose.yamlfrom another directory, and then the./would be/somewhere, and not the directory where I started the command. -
Running now.
Let me know how inference goes. I might recommend that to a friend with a similar CPU.
