Immich in a Multi-App Home Server: How Shared Resources Change Results

Immich results change on a multi-app server because containers share finite CPU, memory, storage, and network capacity despite separate process boundaries.

A photo search may be fast at noon and slow during another application’s backup, scan, or transcode. The Immich configuration did not change, but the available resource budget and cache contents did, so a useful explanation must include the entire host workload.

Containers Separate Processes, Not Physical Capacity

Containers provide namespaces and controllable limits, but they ultimately execute on the same processors and usually reach the same memory controller, disks, and network interfaces. An Immich service can remain within its own limit while waiting behind unrelated work at a shared physical device or kernel scheduler.

A multi-container Immich field report describes a low-power host running dozens of containers with modest usual CPU use. That does not promise identical results elsewhere; it shows why service count alone is weak evidence and why actual overlapping work must be observed at the host level.

Inventory every scheduled and bursty neighbor: backups, media scans, downloads, databases, and video transcodes. Record their start times with Immich latency. Correlation does not prove causation, but repeated alignment identifies a controlled pause or reschedule experiment that can test the suspected interference.

Memory Competition Changes Cache Residency

Immich benefits when frequently used database pages, thumbnails, and model data remain resident in memory. A neighboring service that expands its working set can evict those pages without causing an out-of-memory event. The next request then pays storage or model-load costs that were absent while the data was warm.

Kingston’s server-memory discussion explains that sufficient capacity reduces reliance on slower storage for memory-heavy applications. Applied here, the point is not that every home server needs enterprise memory; it is that cache loss can convert an apparently identical Immich request into a different physical workload.

Compare page-cache activity, swap, major faults, and storage reads before and after the neighbor starts. If pausing it restores warm-request behavior without changing Immich, memory residency is implicated. A high total RAM percentage alone is insufficient because healthy filesystem caching intentionally consumes otherwise idle memory.

Storage Queues Couple Unrelated Services

A backup can stream large files while Immich performs small database and thumbnail operations. Even when aggregate bandwidth remains below a drive’s advertised maximum, queueing can increase completion time for latency-sensitive requests. Network-mounted storage adds another scheduler and network path to the same contention chain.

The ZimaSpace Immich data-path article shows that search selection and displayed media are separate steps with different dependencies. That distinction helps identify storage coupling: quick result identifiers followed by delayed thumbnails point later in the path than a database selection that is itself slow.

Measure device latency and queue depth per mount while reproducing the same request. Pause only the suspected I/O-heavy neighbor, then repeat after caches settle. If the improvement survives multiple alternating runs, scheduling or storage separation is justified; if not, return to CPU, memory, or network hypotheses.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Use a Pause-and-Replay Isolation Test

Choose a fixed endpoint, such as loading the same timeline window or running a known smart search, and define cold or warm conditions. Capture three runs with the full service mix. Then pause one candidate neighbor without restarting Immich and repeat the same client sequence and observation window.

A report of Immich competing heavily during post-update processing describes another photo service failing uploads while the host was busy. It is one configuration, not a universal limit, but it demonstrates that a healthy background queue can still consume enough shared capacity to impair another interactive service.

Accept interference only when the pause produces a repeatable latency change and the relevant resource wait falls with it. Next test a narrow mitigation—lower concurrency, a schedule window, CPU quota, memory reservation, or separate storage. Preserve rollback settings because isolating one neighbor can expose a second limit.