Så avgör du om Immich begränsas av CPU, RAM, lagring eller nätverk
Visa vad som begränsar Immich genom att återskapa en fast arbetsbelastning för uppladdning, bläddring, sökning eller bakgrundsjobb och koppla slutförandegraden till CPU-belastning, minnestryck, lagringslatens och nätverkets genomströmning under samma tidsintervall.
En hög procentsats är inte ensam ett tecken på en flaskhals: full CPU-belastning kan vara normalt under maskininlärning, hög RAM-användning kan bero på filsystemscache och en långsam uppladdning kan orsakas av telefonen eller Wi-Fi-nätverket. Mät från klienten genom containern till värdsystemet, följ köförloppet och ändra sedan en misstänkt begränsning innan du upprepar testet. Den resurs vars avlastning förbättrar samma arbetsbelastning är den styrande begränsningen.
Bygg ett repeterbart test och en tidslinje
Välj det symtom du behöver förbättra: import av en fast mediebatch, öppning av ocachade original, generering av miniatyrbilder, körning av Smart Search eller omkodning av en video. Anteckna starttid, första användbara resultat, slutförande, fel och förändringar i jobbkön. Om du blandar uppgifter får du resursgrafer utan något beslutunderlag.
En användarundersökning beskriver en ovanligt långsam Immich-distribution där man sökte belägg för CPU, minne, disk och nätverk. Dess diagnostiska helhetsperspektiv på resurser är användbart, men ditt fasta test måste fastställa orsaken på din server.
Upprepa testet en gång när cacheminnet är uppvärmt. Om den andra körningen är mycket snabbare ska du ange cachetillståndet i stället för att kalla maskinvaran inkonsekvent. Om båda körningarna stannar vid samma steg ska du matcha den tidpunkten mot mätvärden från värdsystemet och containern samt det ansvariga jobbet.
Identifiera CPU- och minnessignaturer
CPU-begränsning visar sig som ihållande körbar arbetsbelastning på de relevanta kärnorna medan jobbet fortskrider proportionellt; lägre samtidighet kan förbättra interaktiviteten men förlänga tömningstiden. Om en tråd är fullt belastad medan den totala CPU-användningen ser måttlig ut ska du granska vyn per process och kärna innan du antar att det finns ledig kapacitet.
En minnesbegränsning kräver belägg för minnestryck: växande växlingsanvändning, återvinning, allvarliga sidfel, OOM-avslutningar eller omstarter av containrar. Hög minnesanvändning med stabil cache, ingen växlingsanvändning och normal latens klarar inte testet. Kör om testet med en worker med lägre samtidighet eller en mindre modell och jämför slutförandet.
Ett rapporterat fall med miniatyrbilder i Immich v2.5.5 förbrukade extremt mycket minne i en distribution. Minnesrapporten för den angivna versionen stöder att du kontrollerar det felande jobbet och versionen; den fastställer inte ett normalt RAM-behov.
Särskilj lagringslatens från nätverkets genomströmning
För lagring ska du observera enhetens latens, ködjup, genomströmning, ledigt filsystemutrymme och tillgängliga inoder medan det exakta jobbet körs. Låg megabyte per sekund kan fortfarande innebära att lagringen är flaskhalsen när många små databas- och miniatyrbildsåtgärder väntar på en disk med hög latens.
För nätverket ska du mäta både på klient- och serversidan och sedan jämföra lokala och fjärranslutna sökvägar. En mättad länk, omsändningar, Wi-Fi-försök eller en VPN-begränsning som sammanfaller med överföringen tyder på en nätverksbegränsning. Om uppladdningstrafiken upphör men bearbetningen fortfarande går långsamt ska du i stället följa kön på serversidan.
ZimaSpaces översikt över tjänster på äldre maskinvara ger sammanhang för systemplanering; den här diagnosen bör ändå bygga på observerad latens och arbetstakt, inte på åldersetiketter.
Avlasta en begränsning och verifiera samma arbetsbelastning
Ändra en säker variabel: minska samtidigheten för ett jobb, lägg till ett tillfälligt test med minnesgräns, flytta en kopia av aktiva data till snabbare lagring eller testa via trådbundet lokalt nätverk. Håll datamängd, versioner och cachetillstånd jämförbara. En förbättring av både slutförandet och det förutsagda mätvärdet klarar det kausala testet.
Köp inte maskinvara utifrån ett inaktivt genomsnitt eller en enda topp. En resurs är värd att uppgradera när den upprepade gånger styr den viktiga arbetsbelastningen efter att programvarufel, problem med ledigt utrymme och konkurrerande schemalagda jobb har uteslutits.
Återställ ändringar som flyttar felet till ett annat lager eller förlänger köerna bortom tjänstens mål. Eskalera med arbetsbelastningsdefinition, tidsstämplar, mätvärden per container, disklatens, nätverkstester, köförlopp och loggar om systemet stannar utan att någon resurs visar tryck; det mönstret kan bero på ett lås, ett beroende eller ett programfel.
Rekommenderade produkter
Support och tips
Mer att läsa
Så optimerar du Immich-databasanslutningar för samtidiga containrar
Höj inte max_connections först. Mät Immich-sessionerna, summera alla containers behov, behåll utrymme för administratörsåtkomst och justera bara den flaskhals som har bevisats.
Så förhindrar du duplicerade jobb eller importer i Immich
Separera upprepade jobb från duplicerade resurser. Använd en enda kanonisk inläsningsväg, kontrollera omförsök och sökvägsändringar och testa sedan återinmatning på en liten grupp.
Så reparerar du Immich när dess databasvolym blir full
Ta aldrig bort PostgreSQL-WAL för att frigöra utrymme. Stoppa skrivningar till Immich, bevara databastillståndet, lägg till säker lagringskapacitet, återställ PostgreSQL och förhindra sedan att...
