Hoe je de opstarttijd van Immich na een herstart verkort

Als Immich pas na een herstart van de homeserver langzaam bruikbaar wordt, meet dan welke afhankelijkheid als laatste gereed is voordat je de applicatie zelf probeert te ‘versnellen’.

Een herstart kan ervoor zorgen dat opslagkoppelingen, PostgreSQL, netwerkpaden, DNS of andere services in een andere volgorde beschikbaar komen dan tijdens een normale herstart van Immich. De nuttige maatstaf is niet wanneer Docker zegt dat een container is gestart, maar de tijd vanaf het opstarten van de host totdat de database echte verzoeken accepteert, de vereiste opslag is gekoppeld, Immich stopt met het opnieuw proberen van afhankelijkheden en een client de tijdlijn kan laden. Leg die volgorde één keer vast en verwijder vervolgens de daadwerkelijke wachttijd of herhaallus.

Meet de opstarttijdlijn voordat je iets wijzigt

Herstart tijdens een onderhoudsvenster en noteer de tijdstippen waarop de host bereikbaar is, Immich-gerelateerde opslag is gekoppeld, de database gezond is en Immich vanaf een client bruikbaar is. Leg ook de starttijden van containers, gezondheidsstatussen, het aantal herstarts en de eerste nuttige logregel van elke service vast. Zo wordt ‘het opstarten voelt traag’ een begrensde vertraging.

Vergelijk het resultaat met een normale herstart van de stack nadat de host al volledig is opgestart. Als Immich later snel herstart maar alleen tijdens het opstarten traag is, ligt de bottleneck waarschijnlijk bij een volgorde- of gereedheidsafhankelijkheid buiten de applicatie. Als beide situaties even traag zijn, onderzoek dan databasewerk, opslaglatentie, migraties of CPU-belasting.

Optimaliseer niet alle lagen tegelijk. Aan het einde van deze fase moet duidelijk zijn welk eerste onderdeel later gereed is dan zijn containertstarttijd of Immich herhaaldelijk dwingt om opnieuw te proberen.

Controleer of de opslag gereed is voordat Immich start

Controleer of elke bindkoppeling en elk netwerkpad naar opslag bestaat en de verwachte gegevens bevat voordat de Immich-services starten. Een koppelpunt kan als lege lokale map bestaan terwijl de echte schijf of NAS-share nog niet beschikbaar is. Daardoor kan de applicatie starten met een onjuiste weergave van het bestandssysteem.

Als je database of media zich bevindt op opslag die tijdens het opstarten laat beschikbaar komt, laat de service dan op hostniveau afhankelijk zijn van die koppeling of stel de stack uit totdat de koppeling aantoonbaar aanwezig is. De test moet het daadwerkelijk gekoppelde bestandssysteem of een bekende marker controleren, niet alleen of de mapnaam bestaat.

Herstart na het aanpassen van de opslaggereedheid opnieuw en vergelijk dezelfde tijdstippen. Een geslaagde wijziging verwijdert herhaalde pogingen of gedrag met lege paden zonder de Immich-configuratie in stabiele toestand te wijzigen. Als de opslag al ruim vóór de database gereed was, ga dan verder met de afhankelijkheidsvolgorde in plaats van willekeurige slaaptimers toe te voegen.

Wacht tot de database gezond is, niet alleen tot deze draait

PostgreSQL kan een draaiende container hebben voordat deze klaar is om de werklast van de applicatie te accepteren, vooral na een onjuiste stop, opslagvertraging, initialisatie of herstel. Vergelijk de overgang naar een gezonde databasestatus met de eerste Immich-verbindingsfouten in de opstartlogboeken.

Een eenvoudige opstartvolgorde kan een afhankelijke container starten voordat de benodigde service daadwerkelijk gereed is. Waar je Compose-versie en servicedefinities dit ondersteunen, kunnen afhankelijkheidscontroles op basis van gezondheidsstatus onderscheid maken tussen ‘container gestart’ en ‘afhankelijkheid gereed’. Gebruik ze om vermijdbare verbindingscycli te verwijderen in plaats van een trage of ongezonde afhankelijkheid te verbergen.

Houd de gereedheidscontrole beperkt en betekenisvol. Een databasecontrole moet aantonen dat de database de verbinding kan accepteren die Immich nodig heeft; er moet geen dure query worden uitgevoerd die zelf vertraging veroorzaakt. Zodra de database consequent vóór de start van Immich gereed is, herhaal je de host-herstarttest voordat je iets anders wijzigt.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Scheid herhaallussen van legitiem opstartwerk

Als de opslag en PostgreSQL gereed zijn maar Immich na een herstart nog steeds veel langer nodig heeft, controleer dan de logboeken van de applicatie en workers op herhaalde verbindingsfouten, mislukte gezondheidscontroles, migraties, initialisatie van taken of capaciteitsproblemen. Herhaalde fouten met vaste intervallen wijzen vaak op wachten; aanhoudend CPU- of schijfwerk met voortgang wijst op echt opstartwerk.

Een afhankelijkheidsvolgorde werkt het best in combinatie met betekenisvolle gezondheidscontroles in plaats van korte vaste vertragingen. Een Compose-patroon voor gezondheidscontroles kan helpen voorkomen dat een applicatie verbinding probeert te maken met een database of cache die nog wordt geïnitialiseerd. Houd de controles realistisch; door intervallen steeds korter te maken lijkt een zieke service niet opeens gezond en wordt het opstarten niet beter.

Als het aantal herstarts tijdens het opstarten toeneemt, stop dan de storm en bepaal eerst welke afhankelijkheid niet beschikbaar is voordat je CPU-, geheugen- of parameters voor het opstarten van images aanpast. Een controle op afhankelijkheden in container-herstartlussen helpt onderscheid te maken tussen een trage voorwaarde en een probleem in Immich zelf.

Herstart opnieuw en controleer de tijd tot echte bruikbaarheid

Voer na één gerichte wijziging een volledige herstart van de host uit en noteer dezelfde tijdstippen. Een echte verbetering moet het verschil tussen het gereedkomen van de afhankelijkheid en een bruikbare Immich-client verkleinen zonder nieuwe herstartlussen, ontbrekende koppelingen of achtergrondfouten te veroorzaken.

Test meer dan alleen de webaanmeldingspagina. Open meerdere oude foto’s, voer een zoekopdracht uit, laad een representatieve video, controleer of een mobiele client verbinding maakt en upload één wegwerpbestand zodat zowel lees- als schrijfprocessen worden getest. Voor huishoudelijk gebruik is de server pas ‘gestart’ wanneer deze normale handelingen werken.

Voer na de eerste geslaagde test nog een tweede herstart uit om er zeker van te zijn dat het resultaat niet te danken was aan een cache of een eenmalige netwerktiming. Als het opstarten inconsistent blijft, bewaar dan de opstarttraces en richt je op het onderdeel waarvan de gereedheid tussen runs varieert. Verberg variatie niet met een langere vaste vertraging tenzij je geen beter gereedheidssignaal hebt.