Comment réduire le temps de démarrage d’Immich après un redémarrage

Si Immich met du temps à devenir utilisable uniquement après le redémarrage du serveur domestique, mesurez quelle dépendance devient prête en dernier avant d’essayer d’« accélérer » l’application elle-même.

Un redémarrage peut modifier l’ordre d’apparition des montages de stockage, de PostgreSQL, des chemins réseau, du DNS ou d’autres services par rapport à un redémarrage normal d’Immich. La mesure utile n’est pas le moment où Docker indique qu’un conteneur a démarré, mais le délai entre le démarrage de l’hôte et le moment où la base de données accepte de vraies requêtes, le stockage requis est monté, Immich cesse de réessayer les dépendances et un client peut charger la chronologie. Capturez cette séquence une fois, puis supprimez l’attente ou la boucle de nouvelles tentatives réellement en cause.

Mesurez la chronologie du démarrage avant toute modification

Redémarrez pendant une fenêtre de maintenance et horodatez quatre points : l’hôte est joignable, le stockage lié à Immich est monté, la base de données est saine et Immich est utilisable depuis un client. Capturez également les heures de démarrage des conteneurs, leurs états de santé, le nombre de redémarrages et la première ligne de journal utile de chaque service. Vous transformerez ainsi la sensation d’un « démarrage lent » en un délai mesurable.

Comparez le résultat à celui d’un redémarrage normal de la pile, effectué une fois que l’hôte est complètement opérationnel. Si Immich redémarre rapidement plus tard, mais reste lent uniquement au démarrage, le goulot d’étranglement est probablement un problème d’ordre ou de disponibilité d’une dépendance externe à l’application. Si les deux démarrages sont aussi lents l’un que l’autre, examinez plutôt les opérations de la base de données, la latence du stockage, les migrations ou la pression exercée sur le processeur.

N’optimisez pas toutes les couches en même temps. À l’issue de cette étape, vous devez avoir identifié le premier composant dont la disponibilité accuse un retard par rapport au démarrage de son conteneur ou qui force régulièrement Immich à réessayer.

Vérifiez que le stockage est prêt avant le démarrage d’Immich

Vérifiez que chaque montage lié et chaque chemin reposant sur le réseau existe et contient les données attendues avant le démarrage des services Immich. Un point de montage peut exister sous la forme d’un répertoire local vide alors que le véritable disque ou partage NAS est encore indisponible, ce qui peut amener l’application à utiliser une vue du mauvais système de fichiers.

Si votre base de données ou vos médias résident sur un stockage qui apparaît tardivement au démarrage, faites dépendre le service de ce montage au niveau de l’hôte ou retardez le lancement de la pile jusqu’à ce que la présence du montage soit vérifiée. Le test doit vérifier le système de fichiers réellement monté ou un marqueur connu, et pas seulement l’existence du nom du répertoire.

Après avoir ajusté la disponibilité du stockage, redémarrez et comparez à nouveau les mêmes horodatages. Une modification réussie élimine les nouvelles tentatives ou le comportement lié à un chemin vide, sans changer la configuration d’Immich en fonctionnement normal. Si le stockage était déjà prêt bien avant la base de données, passez à l’ordre des dépendances au lieu d’ajouter des temporisations arbitraires.

Attendez que la base de données soit saine, pas seulement en cours d’exécution

PostgreSQL peut avoir un conteneur en cours d’exécution avant d’être prêt à accepter la charge de travail de l’application, notamment après un arrêt brutal, un retard du stockage, une initialisation ou une récupération. Comparez la transition vers l’état sain de la base de données aux premières erreurs de connexion d’Immich dans les journaux du démarrage.

Un simple ordre de démarrage peut lancer un conteneur dépendant avant que le service dont il a besoin soit réellement prêt. Lorsque votre version de Compose et vos définitions de services le permettent, les vérifications des dépendances fondées sur l’état de santé peuvent distinguer « conteneur démarré » de « dépendance prête ». Utilisez-les pour supprimer les cycles de reconnexion évitables plutôt que pour masquer une dépendance lente ou défaillante.

Gardez la vérification de disponibilité ciblée et pertinente. Une vérification de la base de données doit prouver qu’elle peut accepter la connexion dont Immich a besoin ; elle ne doit pas exécuter une requête coûteuse qui ajouterait son propre délai. Une fois que la disponibilité de la base de données précède systématiquement le démarrage d’Immich, répétez le test après redémarrage de l’hôte avant de modifier quoi que ce soit d’autre.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Distinguez les boucles de nouvelles tentatives du travail de démarrage légitime

Si le stockage et PostgreSQL sont prêts, mais qu’Immich met toujours beaucoup plus de temps à démarrer après un redémarrage, examinez les journaux de l’application et des travailleurs à la recherche d’échecs de connexion répétés, de vérifications de santé échouées, de migrations, d’initialisations de tâches ou de problèmes de ressources. Des erreurs répétées à intervalles fixes indiquent souvent une attente ; une activité soutenue du processeur ou du disque avec une progression visible indique un véritable travail de démarrage.

L’ordre des dépendances est plus efficace lorsqu’il est associé à des vérifications de santé pertinentes plutôt qu’à de courtes temporisations fixes. Un modèle de vérification de santé avec Compose peut empêcher une application de démarrer en concurrence avec une base de données ou un cache encore en cours d’initialisation. Gardez ces vérifications réalistes ; réduire les intervalles jusqu’à ce qu’un service défaillant paraisse sain n’améliore pas le démarrage.

Si le nombre de redémarrages augmente au démarrage, interrompez la succession de redémarrages et identifiez la première dépendance indisponible avant d’ajuster le processeur, la mémoire ou les paramètres de démarrage de l’image. Une vérification des dépendances à l’origine d’une boucle de redémarrage de conteneur aide à distinguer un prérequis lent d’un problème interne à Immich.

Redémarrez à nouveau et vérifiez le délai avant une véritable disponibilité

Après une modification ciblée, effectuez un redémarrage complet de l’hôte et consignez les mêmes horodatages. Une amélioration réelle doit réduire l’écart entre la disponibilité des dépendances et l’utilisation d’un client Immich opérationnel, sans introduire de nouvelles boucles de redémarrage, de montages manquants ou d’erreurs en arrière-plan.

Ne testez pas uniquement la page de connexion web. Ouvrez plusieurs anciennes photos, effectuez une recherche, chargez une vidéo représentative, vérifiez qu’un client mobile se connecte et téléversez un fichier sans importance afin d’exercer les chemins de lecture et d’écriture. Pour un usage domestique, le serveur n’est pas réellement « démarré » tant que ces opérations courantes ne fonctionnent pas.

Effectuez un deuxième redémarrage après le premier test réussi afin de vous assurer que le résultat ne tient pas à un effet de cache ou à un événement ponctuel de synchronisation réseau. Si le démarrage reste irrégulier, conservez les traces du démarrage et concentrez-vous sur le composant dont la disponibilité varie d’une exécution à l’autre. Ne masquez pas cette variabilité avec un délai fixe plus long tant que vous disposez d’un meilleur signal de disponibilité.