How Many Concurrent Tasks Can Immich Handle Before Search Responsiveness Degrades?
Immich has no universal safe task count; search degrades when concurrent workers saturate the resource that interactive requests also need.
Two servers can run the same number of thumbnail, metadata, and machine-learning jobs yet produce very different search latency. The useful limit is therefore the highest mixed workload that keeps a defined interactive response target while the queue still drains.
A Task Count Does Not Describe the Workload
A concurrency value is only a worker allowance, not a direct measure of pressure. Thumbnail generation, video transcoding, metadata extraction, and machine-learning inference perform different amounts of computation and storage work. Four light metadata jobs may leave the interface responsive while two video jobs occupy the same host far more aggressively.
A community report about high machine-learning CPU use describes reducing concurrent jobs after a large import, which lowered load while extending completion time. That observation supports the central tradeoff: lower concurrency protects foreground responsiveness by allowing the backlog to drain more slowly, not by removing the underlying work.
Treat each queue as a workload class. Record which jobs are active, what media type they process, and whether acceleration is available. A safe total derived from small JPEGs cannot be transferred to RAW photos or long videos because the work represented by each slot has changed.
Search Degrades at the First Shared Saturation Point
Interactive search crosses several shared layers: the request reaches the application, the database selects results, thumbnails are read, and a client displays them. Background workers can compete at more than one layer. The first saturated layer becomes the practical concurrency ceiling even when every container remains healthy.
An Immich performance discussion describes delayed thumbnail loading on a host with adequate nominal bandwidth, illustrating why link speed alone cannot identify the bottleneck. CPU scheduling, database reads, filesystem latency, and client delivery remain candidates until measurements show which wait increases during the slow request.
Utilization must be paired with delay. High CPU with stable search latency can be productive saturation, while moderate CPU plus rising disk await may identify a storage queue. Memory pressure matters when reclaim or swap adds delay, not merely because the operating system uses available RAM for cache.
Searchability Can Lag Without Slow Search Queries
A fast query can return an incomplete searchable collection when new assets have not finished their indexing work. Conversely, every item may already be indexed while queries are slow because database or storage access is contended. Calling both conditions โsearch degradationโ hides two different endpoints and leads to the wrong concurrency adjustment.
The ZimaSpace explanation of the Immich data path separates upload acceptance, preview readiness, and semantic retrieval as distinct endpoints. That distinction is essential during load tests: the timestamp when a file arrives cannot substitute for the timestamp when its representation becomes eligible for search.
Track two clocks for a fixed import cohort. One measures interactive query latency against already indexed control photos; the other measures time until newly imported photos appear for predetermined searches. The former protects the active user experience, while the latter shows the throughput cost of lowering concurrency.
Find the Limit With a Step Test, Not a Guess
Create a representative media batch and choose three fixed searches that return known assets. Begin with one worker in each active queue, run the import, and record median plus slow-tail search latency, queue drain rate, CPU, memory pressure, network throughput, and storage await over the same observation window.
General bottleneck guidance recommends correlating workload changes with CPU, memory, disk, network, and dependency waits rather than selecting the busiest-looking chart. Increase only one concurrency control per run. Repeating the same search sequence and media cohort keeps the changed variable identifiable.
Stop at the first step where the slow-tail search target fails, the server swaps, storage wait remains elevated, errors appear, or the background queue stops gaining useful throughput. Retest the preceding step after a cold restart and again while warm. That lower, repeatable step is the defensible ceiling for this workload.
Recommended products
Tech & AI HUB
More to Read
What Is Immich State, and Which Parts Must Persist?
Immich state includes originals, database relationships, identity, configuration, and derivatives; persist each according to whether it is reconstructable.
How Does Immich Handle Authentication Across Local and Remote Sessions?
Immich uses server-side identity with client sessions, while proxy headers, origins, and OIDC redirects can make local and remote behavior differ.
What Causes Immich Search or Query Results to Slow as Data Grows?
Immich growth can enlarge indexes, evict hot pages, complicate filters, and delay media delivery; separate these stages before tuning.
