Varför ger Immich intermittenta fel under stora importer från mobilbibliotek?

Intermittenta Immich-fel under en stor mobilimport innebär vanligtvis att ett lager fallerar vid överlappning, inte att hela biblioteket eller alla uppladdade filer är korrupta.

Stora importer kombinerar mobilens bakgrundsbeteende, långa förfrågningar, begränsningar i omvänd proxy eller tunnel, databasskrivningar, lagrings-I/O, arbete med miniatyrbilder och videor samt köer för maskininlärning. Samla först in en liten grupp misslyckade filer och tidsstämplar. Ta sedan reda på om felet börjar i telefonen, på nätverksvägen, på applikationsservern eller i ett överbelastat beroende.

Klassificera felgruppen innan du försöker igen med allt

Gruppera felen efter medietyp, filstorlek, källenhet, nätverksväg och tidpunkt. Om bara stora videor misslyckas bör du undersöka förfrågningarnas varaktighet och uppladdningsgränser före CPU-belastning. Om slumpmässiga foton och videor misslyckas under samma belastade tidsintervall blir delade serverresurser eller nätverksinstabilitet starkare kandidater.

En användarrapport från 2026 om många fel vid mobiluppladdningar är användbar eftersom den visar hur en stor kö från en telefon kan ge upprepade fel som kräver diagnos per fil och nätverksväg. Den fastställer inte att det finns ett enda universellt fel i mobilklienten.

Välj inte ”försök igen med alla” som första diagnostiska åtgärd. Spara namnen eller ID:na för tio misslyckade filer, ett lyckat kontrollobjekt samt motsvarande loggfönster från klient och server. En liten känd grupp låter dig testa ändringar utan att skapa en ny storm som döljer de ursprungliga bevisen.

Jämför lokala uppladdningar med den vanliga fjärrvägen

Ladda upp samma små och stora testfiler via stabilt lokalt Wi‑Fi direkt till den betrodda lokala slutpunkten och upprepa sedan via det vanliga fjärrvärdnamnet, VPN:et, tunneln eller den omvända proxyn. Behåll konto och fil oförändrade så att nätverksvägen är den huvudsakliga variabeln.

En rapport om fel vid säkerhetskopiering av stora filer visar varför begränsningar för förfrågningar i proxyer eller tunnlar hör hemma i denna gren av felsökningen. Den rapporterade tjänsten och tröskelvärdena är specifika för distributionen; det allmänna testet är om direkt lokal överföring lyckas medan fjärrvägen konsekvent misslyckas.

Om båda vägarna misslyckas med samma filer följer du bevisen från server och lagring. Om bara fjärrvägen misslyckas bör du kontrollera maximal meddelandestorlek, buffring av förfrågningar, tidsgränser för inaktivitet och läsning, TLS-terminering, övergångar mellan mobilnät samt omsändningar. Att ändra samtidigheten för miniatyrbilder reparerar inte en förfrågan som aldrig når Immich fullständigt.

Samordna fel med köökning och resursbelastning

Stora importer kan fortsätta att ta emot uppladdningar medan bakgrundsjobb samlas på hög. Observera CPU, minnestryck, I/O-latens för blockenheter, databasens svarstid, omstarter av containrar och slutförda jobb under felperioden. Hög användning i sig är inte ett bevis; mätvärdet måste förändras samtidigt som felen.

Docker-artikeln om resursövervakning av CPU-, minnes-, nätverks- och diskmätvärden för containrar visar värdet av att jämföra containrar i stället för att läsa av ett enda genomsnitt för hela värden. I Linux kombinerar du containermätvärden med bevis på lagrings- och minnestryck på värden vid samma tidsstämplar.

Om minnestryck orsakar att containrar avslutas, lagringslatensen ökar tillsammans med uppladdningsfelen eller databasens svarstid ökar samtidigt som kön slutar gå framåt, bör du minska endast den ansvariga arbetsbelastningen eller samtidigheten och upprepa testet med den fasta gruppen. Om resursgraferna förblir lugna fortsätter du med applikationsloggar och diagnos av nätverksvägen.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Behandla felfrekvens och svanslatens som belastningssignaler

Ett system kan verka friskt enligt den genomsnittliga svarstiden samtidigt som en liten andel förfrågningar får tidsgränsöverskridanden under toppar. Registrera antalet försöka uppladdningar, fel, median­svarstid och långsammare svansförfrågningar under ett kontrollerat tidsfönster. Då blir ”intermittent” mätbart i stället för anekdotiskt.

Ramverket för belastningstestning i fel- och latensanalys rekommenderar analys av statusklasser, anslutningsproblem, fördelningar och korrelationer över tid. Du behöver inte belasta familjebiblioteket aggressivt; använd samma analytiska struktur på den faktiska importtakten.

Om en kraftig minskning av ankomsttakten sänker felfrekvensen medan varje enskild fil lyckas saknar den aktuella stacken kapacitet för den importintensiteten. Om samma filer misslyckas även en i taget är problemet filspecifikt, väg­specifikt eller ett deterministiskt programvarufel snarare än generell överbelastning.

Minska en belastningskälla och testa samma importmönster igen

Välj den säkraste ändringen som stöds av bevisen: minska en bakgrundssamtidighet, pausa en annan tung container, använd den lokala vägen, flytta importen utanför ett säkerhetskopieringsfönster eller korrigera en tidsgräns i proxyn. Ändra inte CPU-gränser, lagring, proxyregler och appversioner samtidigt.

ZimaSpace-arbetsflödet för avbrott i säkerhetskopieringen av telefonfoton beskriver grenen på mobilsidan: bakgrundsschemaläggning, originalfiler som endast finns i molnet och förändrade nätverksförhållanden kan avbryta uppladdningar även när servern fungerar korrekt.

Godkänt resultat är att den fasta gruppen lyckas och att samma större import körs med stabil felfrekvens, köer som går framåt och godtagbar interaktiv prestanda. Eskalera när felen kvarstår vid låg belastning eller återkommer för identiska filer; inkludera klientloggar, serverloggar, proxystatus, resursgrafer, filtyp och storlek samt den första misslyckade förfrågan.