Pourquoi Immich renvoie-t-il des erreurs intermittentes lors de l’importation de grandes bibliothèques mobiles ?
Les erreurs intermittentes d’Immich lors d’un import mobile volumineux signifient généralement qu’une couche échoue sous l’effet de la concurrence, et non que toute la bibliothèque ou chaque fichier importé est corrompu.
Les imports volumineux combinent le fonctionnement en arrière-plan du mobile, les requêtes longues, les limites du proxy inverse ou du tunnel, les écritures en base de données, les entrées-sorties du stockage, le traitement des miniatures et des vidéos, ainsi que les files d’attente d’apprentissage automatique. Commencez par relever un petit groupe de fichiers en échec et leurs horodatages. Déterminez ensuite si l’échec commence sur le téléphone, sur le chemin réseau, sur le serveur d’application ou au niveau d’une dépendance saturée.
Classez le groupe d’erreurs avant de tout relancer
Regroupez les échecs par type de média, taille de fichier, appareil source, chemin réseau et heure. Si seules les grandes vidéos échouent, examinez la durée des requêtes et les limites d’importation avant le processeur. Si des photos et des vidéos aléatoires échouent aux mêmes périodes de forte activité, les ressources partagées du serveur ou l’instabilité du réseau deviennent des causes plus probables.
Un témoignage d’utilisateur d’Immich datant de 2026 décrivant de nombreuses erreurs d’importation mobile est utile, car il montre comment un important retard d’importation sur un téléphone peut faire apparaître des échecs répétés nécessitant un diagnostic fichier par fichier et chemin par chemin. Il ne permet pas d’établir l’existence d’un bug universel du client mobile.
Ne sélectionnez pas « tout relancer » comme première action de diagnostic. Enregistrez les noms ou identifiants de dix fichiers en échec, un fichier témoin importé avec succès, ainsi que la fenêtre correspondante des journaux client et serveur. Un petit groupe connu vous permet de tester des modifications sans générer une nouvelle avalanche qui masquerait les éléments d’origine.
Comparez les importations locales avec le chemin distant habituel
Importez les mêmes fichiers de test, petits et volumineux, via un Wi-Fi local stable, directement vers le point de terminaison local de confiance, puis répétez l’opération via le nom d’hôte distant habituel, le VPN, le tunnel ou le proxy inverse. Conservez le même compte et les mêmes fichiers afin que le chemin soit la principale variable.
Un témoignage concernant des échecs de sauvegarde de fichiers volumineux montre pourquoi les limites de requête du proxy ou du tunnel doivent être examinées dans cette branche. Le service et les seuils rapportés dépendent du déploiement ; le test général consiste à vérifier si le transfert local direct réussit tandis que le chemin distant échoue systématiquement.
Si les deux chemins échouent avec les mêmes fichiers, examinez les éléments liés au serveur et au stockage. Si seul le chemin distant échoue, vérifiez la taille maximale du corps de requête, la mise en mémoire tampon des requêtes, les délais d’inactivité et de lecture, la terminaison TLS, les changements de réseau mobile et les retransmissions. Modifier la concurrence des miniatures ne réparera pas une requête qui n’atteint jamais complètement Immich.
Corrélez les erreurs avec la croissance des files d’attente et la pression sur les ressources
Les imports volumineux peuvent continuer à accepter des fichiers tandis que les tâches en arrière-plan s’accumulent. Surveillez le processeur, la pression mémoire, la latence des entrées-sorties de blocs, la réactivité de la base de données, les redémarrages de conteneurs et l’achèvement des tâches pendant la période d’échec. Une utilisation élevée ne constitue pas une preuve en soi ; la métrique doit évoluer au même moment que les erreurs.
L’article Docker consacré aux métriques du processeur, de la mémoire, du réseau et du disque des conteneurs montre l’intérêt de comparer les conteneurs plutôt que de consulter une seule moyenne globale de l’hôte. Sous Linux, combinez les métriques des conteneurs avec les éléments concernant le stockage de l’hôte et la pression mémoire aux mêmes horodatages.
Si la pression mémoire provoque l’arrêt de conteneurs, si la latence du stockage augmente avec les erreurs d’importation ou si le temps de réponse de la base de données augmente tandis que la file d’attente n’avance plus, réduisez uniquement la charge ou la concurrence responsables, puis répétez le test avec le même groupe de fichiers. Si les graphiques de ressources restent stables, poursuivez avec les journaux de l’application et le diagnostic du chemin réseau.
Considérez le taux d’erreur et la latence de queue comme des indicateurs de charge
Un système peut sembler sain selon le temps de réponse moyen alors qu’un faible pourcentage de requêtes expire pendant les pics d’activité. Relevez le nombre d’importations tentées, les échecs, le temps de réponse médian et les requêtes les plus lentes sur une période contrôlée. Les erreurs « intermittentes » deviennent ainsi mesurables plutôt qu’anecdotiques.
Le cadre de test de charge consacré à l’analyse des erreurs et de la latence recommande d’examiner les catégories de statuts, les problèmes de connexion, les distributions et les corrélations temporelles. Il n’est pas nécessaire de solliciter fortement la bibliothèque familiale ; appliquez la même structure d’analyse au débit d’importation réel.
Si la réduction nette du débit d’arrivée diminue les échecs alors que chaque fichier réussit individuellement, la pile actuelle ne dispose pas d’une marge suffisante pour cette intensité d’importation. Si les mêmes fichiers échouent même un par un, le problème concerne les fichiers, le chemin utilisé ou une erreur logicielle déterministe, plutôt qu’une saturation générale.
Réduisez une seule source de pression et retestez le même schéma d’importation
Choisissez la modification la plus sûre au vu des éléments observés : réduisez une seule concurrence en arrière-plan, mettez en pause un autre conteneur lourd, utilisez le chemin local, effectuez l’importation en dehors d’une fenêtre de sauvegarde ou corrigez le délai d’expiration du proxy. Ne modifiez pas simultanément les limites du processeur, le stockage, les règles du proxy et les versions de l’application.
Le guide ZimaSpace consacré aux interruptions de sauvegarde des photos du téléphone fournit la branche côté mobile : la planification en arrière-plan, les originaux uniquement dans le cloud et les changements de conditions réseau peuvent interrompre les importations même lorsque le serveur fonctionne correctement.
Considérez le test comme réussi lorsque le groupe de fichiers fixe est importé correctement et que le même import volumineux s’exécute avec un taux d’erreur stable, des files d’attente qui progressent et des performances interactives acceptables. Escaladez le problème si les échecs persistent à faible charge ou se reproduisent avec des fichiers identiques ; incluez les journaux client, les journaux serveur, l’état du proxy, les graphiques de ressources, le type et la taille des fichiers, ainsi que la première requête en échec.
Produits recommandés
Assistance et conseils
Plus à lire
Comment optimiser les connexions à la base de données d’Immich pour des conteneurs simultanés
N’augmentez pas d’abord max_connections. Mesurez les sessions Immich, totalisez la demande de chaque conteneur, préservez une marge pour l’administration et n’optimisez que le goulot...
Comment empêcher les tâches ou importations en double dans Immich
Séparez les tâches répétées des ressources en double. Utilisez un chemin d’ingestion canonique, contrôlez les nouvelles tentatives et les changements de chemin, puis testez...
Comment réparer Immich après le remplissage de son volume de base de données
Ne supprimez jamais les journaux WAL de PostgreSQL pour libérer de l’espace. Arrêtez les écritures d’Immich, préservez l’état de la base de données, ajoutez...
