Comment optimiser les connexions à la base de données d’Immich pour des conteneurs simultanés

Optimisez les connexions à la base de données d’Immich en mesurant la demande totale de sessions de chaque processus Immich et des autres clients PostgreSQL, plutôt qu’en augmentant d’abord max_connections. La base de données doit disposer d’un nombre de sessions suffisant pour la charge réelle, avec une marge administrative, mais une concurrence excessive peut accroître l’utilisation de la mémoire et les conflits sans accélérer les requêtes.

Sur un serveur domestique composé de plusieurs conteneurs, consignez les connexions actives, inactives et en attente, ainsi que la latence des requêtes, l’utilisation du processeur et de la mémoire et la latence du stockage, pendant l’utilisation normale et lors d’un démarrage simultané. Une erreur « trop de clients » peut provenir de la configuration cumulée, d’un autre service ou d’une tempête de redémarrages, même lorsqu’un seul conteneur Immich semble peu sollicité.

Répertoriez chaque client PostgreSQL avant de modifier les limites

Répertoriez chaque processus ou réplica du serveur Immich, chaque tâche de migration ou de maintenance, chaque tâche de sauvegarde, chaque outil de surveillance et chaque application indépendante qui se connecte à la même instance PostgreSQL. Attribuez-leur, lorsque c’est possible, des utilisateurs de base de données distincts afin que pg_stat_activity puisse indiquer qui détient les sessions. Notez la valeur actuelle de max_connections et conservez une voie d’administration pour la réponse aux incidents.

Une discussion sur l’erreur « trop de clients » d’Immich contient un commentaire du projet indiquant qu’Immich utilisait un pool par défaut de 10 dans cette version. Une discussion distincte de 2026 indique que plusieurs workers Immich peuvent chacun maintenir un pool. Considérez ces chiffres comme des éléments d’implémentation propres à une version donnée, et non comme une valeur à multiplier aveuglément pour les versions futures. Si la base de données est déjà proche de sa limite de connexions alors qu’Immich est inactif, identifiez le propriétaire de ces sessions avant de régler Immich. Si les sessions actives sont peu nombreuses mais que les requêtes sont lentes, le nombre de connexions peut être le symptôme d’une latence du stockage ou des requêtes plutôt que le principal goulot d’étranglement.

Établissez un budget de connexions à partir de la concurrence mesurée

Réservez des sessions pour l’administration de la base de données, les outils de sauvegarde et de restauration, les migrations et la surveillance.

Répartissez ensuite les connexions applicatives restantes entre le nombre de processus Immich exécutés simultanément et les autres applications. L’objectif est d’avoir un pool suffisamment grand pour que le travail normal n’attende pas inutilement, mais pas plus grand que ce que la base de données peut exécuter efficacement.

Une analyse du dimensionnement des pools de connexions PostgreSQL décrit le pool idéal comme suffisamment grand pour répondre à la demande normale tout en restant aussi petit que possible, car un nombre réduit de sessions backend diminue les conflits. Appliquez ce principe à la demande observée d’Immich au lieu de copier la taille d’un pool de serveur web provenant d’une autre charge de travail.

Si la version d’Immich ne propose pas de contrôle pris en charge de la taille du pool, ne modifiez pas les composants internes simplement pour atteindre un nombre cible. Contrôlez ce qui peut l’être : le nombre de réplicas applicatifs, les clients indépendants, le calendrier des redémarrages, le chevauchement des sauvegardes et la capacité de la base de données. Réévaluez la configuration prise en charge lors des changements de version.

Réduisez les renouvellements de connexions et les attentes de la base de données avant d’ajouter des sessions

Échelonnez le démarrage des conteneurs afin qu’Immich, les outils d’analyse, les tâches de sauvegarde et les autres applications ne se reconnectent pas ou n’effectuent pas tous leurs migrations simultanément. Utilisez des vérifications d’état et de disponibilité qui attendent que PostgreSQL soit utilisable, mais évitez les boucles de nouvelle tentative trop rapprochées, qui créent une tempête de connexions pendant que la base de données se rétablit.

Le guide de ZimaSpace consacré à la sécurité d’une base de données Immich externe définit une limite importante : une fois PostgreSQL séparé de la pile par défaut, les responsabilités liées à la version, aux extensions, aux privilèges, aux sauvegardes et aux restaurations deviennent explicites. N’introduisez pas de proxy de connexions ni d’hôte de base de données supplémentaire uniquement pour masquer des requêtes lentes ou un stockage saturé.

Si de nombreuses sessions sont inactives et que le nombre élevé d’applications est légitime, un pooler de connexions peut réduire les sessions backend dans certaines architectures PostgreSQL, mais uniquement après avoir testé la version exacte d’Immich, les migrations, la sémantique des transactions et le comportement des instructions préparées. La mise en pool ne remplace pas la correction d’un client défaillant ni celle d’une base de données surchargée.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Validez avec des téléversements, des recherches, des tâches et un redémarrage simultanés

Créez une période de pointe reproductible : effectuez des téléversements mobiles représentatifs, une recherche ou une navigation sur des éléments anciens et le fonctionnement habituel des tâches en arrière-plan, tandis que les autres conteneurs prévus sont actifs. Consignez le nombre de connexions par utilisateur et par état, les erreurs d’acquisition ou de requête, la latence des requêtes, l’utilisation du processeur et de la mémoire de la base de données ainsi que la latence du disque. Recommencez après chaque modification.

Une configuration valide maintient les sessions sous le seuil d’échec avec une marge administrative, évite les erreurs « trop de clients », maintient la latence des requêtes dans l’objectif défini pour le foyer et permet aux files d’attente de se vider après le pic. L’ajout de connexions n’est justifié que lorsque les requêtes attendent réellement une session alors que la base de données dispose encore de capacité processeur, mémoire et entrées-sorties.

Redémarrez une fois la pile applicative, puis l’hôte, afin de tester le pic de connexions maximal. Si l’échec survient uniquement au démarrage, corrigez l’ordre de démarrage ou le comportement des nouvelles tentatives plutôt que d’augmenter la limite permanente. Si les sessions s’accumulent avec le temps, identifiez les utilisateurs et les requêtes propriétaires, puis transmettez ce schéma de fuite avec les versions et les éléments attestant l’état des connexions.