Så minskar du Immichs uppstartstid efter omstart

Om Immich blir långsamt användbart först efter att hemmaservern startats om bör du mäta vilken beroendekomponent som blir redo sist innan du försöker ”snabba upp” själva programmet.

En omstart kan göra att lagringsmonteringar, PostgreSQL, nätverkssökvägar, DNS eller andra tjänster startar i en annan ordning än vid en vanlig omstart av Immich. Det användbara måttet är inte när Docker säger att en container har startat, utan tiden från att värdenheten startar tills databasen accepterar riktiga förfrågningar, nödvändig lagring är monterad, Immich slutar försöka ansluta till beroenden och en klient kan läsa in tidslinjen. Dokumentera den sekvensen en gång och ta sedan bort den faktiska väntetiden eller omförsöksloopen.

Mät startförloppet innan du ändrar något

Starta om under ett underhållsfönster och tidsstämpla fyra tidpunkter: när värdenheten kan nås, när Immich-relaterad lagring är monterad, när databasen är frisk och när Immich kan användas från en klient. Dokumentera också starttider för containrar, hälsotillstånd, antal omstarter och den första användbara loggraderna från varje tjänst. Då omvandlas ”starten känns långsam” till en avgränsad fördröjning.

Jämför resultatet med en vanlig omstart av stacken efter att värdenheten redan har startat helt. Om Immich startar snabbt senare men endast är långsamt vid uppstart, beror flaskhalsen sannolikt på en ordnings- eller beredskapsberoende utanför programmet. Om båda förloppen är lika långsamma bör du i stället undersöka databasarbeten, lagringsfördröjning, migreringar eller CPU-belastning.

Optimera inte alla lager samtidigt. När detta steg är klart ska du veta vilken komponent som blir redo sist i förhållande till när dess container startar, eller vilken komponent som upprepade gånger tvingar Immich att försöka igen.

Kontrollera att lagringen är redo innan Immich startar

Kontrollera att alla bindmonteringar och nätverksbaserade sökvägar finns och innehåller förväntade data innan Immich-tjänsterna startar. En monteringspunkt kan finnas som en tom lokal katalog medan den riktiga disken eller NAS-resursen fortfarande är otillgänglig, vilket kan få programmet att starta mot fel filsystemsvy.

Om databasen eller mediefilerna finns på lagring som blir tillgänglig sent under uppstarten bör du låta tjänsten vara beroende av den monteringen på värdnivå eller fördröja stacken tills monteringen faktiskt kan verifieras. Testet bör kontrollera det verkligt monterade filsystemet eller en känd markör, inte bara att katalognamnet finns.

Starta om igen efter att du har justerat lagringens beredskap och jämför samma tidsstämplar. En lyckad ändring tar bort omförsök eller beteende med tomma sökvägar utan att ändra Immichs konfiguration i normalt driftläge. Om lagringen redan var redo långt före databasen bör du gå vidare till beroendesekvensen i stället för att lägga till godtyckliga sovtimers.

Vänta tills databasen är frisk, inte bara igång

PostgreSQL kan ha en körande container innan den är redo att ta emot programmets arbetsbelastning, särskilt efter en oren avstängning, lagringsfördröjning, initiering eller återställning. Jämför när databasen blir frisk med de första anslutningsfelen från Immich i uppstartsloggarna.

En enkel startordning kan starta en beroende container innan tjänsten den behöver faktiskt är redo. Där din Compose-version och dina tjänstedefinitioner stöder det kan hälsobaserade beroendekontroller skilja mellan ”containern har startat” och ”beroendet är redo”. Använd dem för att ta bort onödiga återanslutningscykler i stället för att dölja ett långsamt eller sjukt beroende.

Håll beredskapskontrollen snäv och meningsfull. En databaskontroll bör bevisa att den kan acceptera den anslutning Immich behöver; den bör inte köra en dyr fråga som själv skapar fördröjning. När databasen konsekvent blir redo före Immichs uppstart bör du upprepa testet med omstart av värdenheten innan du ändrar något annat.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Skilj omförsöksloopar från legitimt uppstartsarbete

Om lagringen och PostgreSQL är redo men Immich fortfarande tar mycket längre tid efter en omstart bör du granska program- och arbetarkloggarna efter upprepade anslutningsfel, misslyckade hälsokontroller, migreringar, initiering av jobb eller resursbrist. Upprepade fel med fasta intervall tyder ofta på väntan; ihållande CPU- eller diskarbete med framsteg tyder på verkligt uppstartsarbete.

Beroendeordning fungerar bäst tillsammans med meningsfulla hälsokontroller i stället för korta fasta fördröjningar. Ett Compose-mönster med hälsokontroller kan hjälpa till att hindra ett program från att tävla mot en databas eller cache som fortfarande initieras. Håll kontrollerna realistiska; att korta intervallen tills en sjuk tjänst ser frisk ut förbättrar inte uppstarten.

Om antalet omstarter ökar under uppstarten bör du stoppa stormen och identifiera det första otillgängliga beroendet innan du finjusterar CPU-, minnes- eller parametrar för bildstart. En kontroll av containerberoenden vid omstartsloopar hjälper dig att skilja ett långsamt förkrav från ett problem i själva Immich.

Starta om igen och verifiera tiden till verklig användbarhet

Efter en riktad ändring ska du starta om hela värdenheten och registrera samma tidsstämplar. En verklig förbättring bör förkorta avståndet mellan att beroendena blir redo och att en Immich-klient kan användas, utan att skapa nya omstartsloopar, saknade monteringar eller bakgrundsfel.

Testa mer än webbinloggningssidan. Öppna flera äldre foton, kör en sökning, läs in en representativ video, bekräfta att en mobilklient ansluter och ladda upp en testfil som kan tas bort, så att både läs- och skrivvägarna testas. För hushållets del är servern inte ”startad” förrän dessa normala operationer fungerar.

Genomför en andra omstart efter det första lyckade testet för att säkerställa att resultatet inte berodde på cache eller en tillfällig nätverkshändelse. Om uppstarten fortfarande är inkonsekvent bör du spara uppstartsspåren och fokusera på den komponent vars beredskap varierar mellan körningarna. Dölj inte variationen med en längre fast fördröjning om du har en bättre signal för beredskap.