Hoeveel gelijktijdige taken kan Immich verwerken voordat de zoekresponsiviteit afneemt?

Immich heeft geen universeel veilig aantal taken; zoeken wordt trager wanneer gelijktijdige workers de resource verzadigen die ook interactieve verzoeken nodig hebben.

Twee servers kunnen hetzelfde aantal taken voor miniaturen, metadata en machine learning uitvoeren en toch een heel verschillende zoeklatentie hebben. De bruikbare limiet is daarom de hoogste gemengde werklast waarbij een vastgesteld doel voor interactieve responstijd behouden blijft en de wachtrij nog steeds leegloopt.

Een aantal taken beschrijft de werklast niet

Een waarde voor gelijktijdigheid is alleen een toestaanbaar aantal workers, geen directe maat voor de belasting. Het genereren van miniaturen, videotranscodering, metadata-extractie en machine-learninginferentie voeren verschillende hoeveelheden reken- en opslagwerk uit. Vier lichte metadata-taken kunnen de interface responsief houden, terwijl twee videotaken dezelfde host veel zwaarder belasten.

Een communityrapport over hoog CPU-gebruik door machine learning beschrijft het verminderen van gelijktijdige taken na een grote import, waardoor de belasting daalde maar de voltooiing langer duurde. Die observatie ondersteunt de centrale afweging: een lagere gelijktijdigheid beschermt de responsiviteit op de voorgrond doordat de achterstand langzamer wordt verwerkt, niet doordat het onderliggende werk verdwijnt.

Behandel elke wachtrij als een werklastklasse. Noteer welke taken actief zijn, welk mediatype ze verwerken en of versnelling beschikbaar is. Een veilige totaallimiet die is afgeleid van kleine JPEG's kan niet worden toegepast op RAW-foto's of lange video's, omdat het werk dat elke positie vertegenwoordigt, is veranderd.

Zoeken wordt trager bij het eerste gedeelde verzadigingspunt

Interactief zoeken gaat door meerdere gedeelde lagen: het verzoek bereikt de applicatie, de database selecteert resultaten, miniaturen worden gelezen en een client geeft ze weer. Achtergrondworkers kunnen op meer dan één laag concurreren. De eerste verzadigde laag wordt de praktische bovengrens voor gelijktijdigheid, zelfs wanneer elke container gezond blijft.

Een discussie over Immich-prestaties beschrijft vertraagd laden van miniaturen op een host met voldoende nominale bandbreedte. Dat laat zien waarom alleen de verbindingssnelheid het knelpunt niet kan identificeren. CPU-planning, databaselezingen, bestandssysteemlatentie en levering aan de client blijven mogelijke oorzaken totdat metingen laten zien welke wachttijd tijdens het trage verzoek toeneemt.

Gebruik verbruik altijd samen met vertraging. Een hoge CPU-belasting met stabiele zoeklatentie kan een productieve verzadiging zijn, terwijl een matige CPU-belasting in combinatie met oplopende schijf-wachttijd op een opslagwachtrij kan wijzen. Geheugendruk is relevant wanneer reclaim of swap vertraging veroorzaakt, niet alleen omdat het besturingssysteem beschikbaar RAM voor cache gebruikt.

Doorzoekbaarheid kan achterlopen zonder trage zoekopdrachten

Een snelle zoekopdracht kan een onvolledige doorzoekbare verzameling opleveren wanneer nieuwe assets hun indexeringswerk nog niet hebben voltooid. Omgekeerd kan elk item al geïndexeerd zijn terwijl zoekopdrachten traag zijn doordat database- of opslagtoegang wordt belemmerd. Beide omstandigheden “verslechtering van het zoeken” noemen verbergt twee verschillende eindpunten en leidt tot de verkeerde aanpassing van de gelijktijdigheid.

De uitleg van ZimaSpace over het Immich-datapad onderscheidt het accepteren van uploads, de gereedheid van voorbeelden en semantisch ophalen als afzonderlijke eindpunten. Dat onderscheid is essentieel tijdens belastingtests: het tijdstip waarop een bestand binnenkomt, kan niet dienen als vervanging voor het tijdstip waarop de representatie ervan beschikbaar wordt voor zoeken.

Houd voor een vaste importcohort twee klokken bij. De ene meet de interactieve zoeklatentie voor al geïndexeerde controlefoto's; de andere meet de tijd totdat nieuw geïmporteerde foto's verschijnen in vooraf bepaalde zoekopdrachten. De eerste beschermt de actieve gebruikerservaring, terwijl de tweede de doorvoerkosten van een lagere gelijktijdigheid laat zien.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Vind de limiet met een stapsgewijze test, niet met een gok

Maak een representatieve mediabatch en kies drie vaste zoekopdrachten die bekende assets opleveren. Begin met één worker in elke actieve wachtrij, voer de import uit en noteer binnen hetzelfde observatievenster de mediane zoeklatentie en de latentie in de staart, de snelheid waarmee de wachtrij leegloopt, CPU-gebruik, geheugendruk, netwerkdoorvoer en de wachttijd van de opslag.

Algemene richtlijnen voor knelpunten adviseren om veranderingen in de werklast te correleren met wachttijden voor CPU, geheugen, schijf, netwerk en afhankelijkheden, in plaats van de grafiek te kiezen die er het drukst uitziet. Verhoog per run slechts één regeling voor gelijktijdigheid. Door dezelfde zoekreeks en mediacohort te herhalen, blijft de gewijzigde variabele identificeerbaar.

Stop bij de eerste stap waarbij het doel voor de zoeklatentie in de staart niet wordt gehaald, de server begint te swappen, de opslagwachttijd verhoogd blijft, er fouten optreden of de achtergrondwachtrij geen bruikbare extra doorvoer meer oplevert. Test de voorgaande stap opnieuw na een koude herstart en nogmaals terwijl het systeem warm is. Die lagere, herhaalbare stap is de verdedigbare bovengrens voor deze werklast.