Les analyses nocturnes de la bibliothèque ne cessent de réveiller les disques durs : comment les réduire
Réduisez les réveils nocturnes des disques en identifiant la tâche planifiée exacte qui accède aux médias, puis en limitant sa fréquence, sa portée ou son travail au niveau des fichiers.
Un serveur multimédia peut réveiller des disques durs en veille même lorsque sa base de données et son cache résident sur un SSD, car une analyse planifiée de la bibliothèque peut parcourir les répertoires, sonder les fichiers, actualiser les illustrations, générer des aperçus, vérifier les chemins ou traiter des éléments qui n’atteignent jamais un état stable. Commencez par corréler le premier accès au disque avec une tâche et une entrée de journal précises. Modifier les minuteries de mise en veille avant d’avoir identifié le déclencheur masque généralement le schéma sans réduire les lectures sous-jacentes.
Déterminez quelle tâche planifiée réveille les disques
Notez l’heure exacte du réveil à partir de la télémétrie des disques, des journaux système ou de la surveillance de la consommation, puis comparez-la à l’historique des tâches planifiées du serveur multimédia. Désactivez une seule tâche suspecte pendant une nuit afin que le résultat reste attribuable.
Un rapport concernant Jellyfin a révélé que l’analyse planifiée de la bibliothèque traitait à plusieurs reprises l’intégralité de la bibliothèque deux fois par jour et passait des heures à sonder les médias. L’indice utile était que la même analyse complète se répétait, plutôt qu’une demande de lecture isolée.
Si les disques se réveillent avant le début de l’analyse de la bibliothèque, examinez une autre tâche telle que l’extraction d’images de chapitres, la génération de trickplay, l’analyse des intros, l’actualisation des métadonnées, la sauvegarde, les tests SMART, la vérification du système de fichiers ou l’organisateur de téléchargements. N’accusez pas le serveur multimédia tant que son processus ou son conteneur n’apparaît pas dans les éléments de preuve du premier accès.
Distingu ez les analyses complètes de la bibliothèque de la surveillance en temps réel
Vérifiez si la bibliothèque utilise à la fois des analyses complètes périodiques et la surveillance du système de fichiers. La surveillance en temps réel peut importer rapidement les ajouts ordinaires sur les systèmes de fichiers locaux compatibles, tandis qu’une analyse complète planifiée reste utile comme filet de sécurité à faible fréquence.
Jellyfin considère depuis longtemps l’analyse planifiée et la surveillance en temps réel comme deux mécanismes distincts. Un ticket du projet indique que la surveillance en temps réel peut détecter les nouveaux médias, tandis qu’une tâche planifiée assure leur découverte à intervalles réguliers.
Sur un stockage local fiable, testez la surveillance en temps réel avec un fichier nouvellement ajouté et réduisez la fréquence de l’analyse complète uniquement après avoir vérifié que ce fichier apparaît correctement. Avec NFS, SMB, rclone, les systèmes de fichiers fusionnés et certains chemins montés dans des conteneurs, la transmission des événements peut être incomplète ; conservez donc une analyse périodique à une heure adaptée à la politique de stockage.
Identifiez les tâches qui lisent le contenu des médias plutôt que les seuls noms de répertoires
Examinez le journal de l’analyseur pour repérer le sondage des médias, les lectures de sommes de contrôle, l’extraction des chapitres, l’analyse des sous-titres, la génération de trickplay, l’analyse du niveau sonore et les actualisations répétées des métadonnées. L’énumération des répertoires peut provoquer un réveil bref, tandis que la lecture de portions de chaque fichier peut maintenir toute une grappe active pendant des heures.
Le cas d’analyses répétées mentionné plus haut signalait des lectures importantes dans chaque fichier multimédia pendant le sondage, ce qui explique que la tâche faisait davantage que vérifier les noms de fichiers. Un autre ticket montre que les mêmes entrées étaient retraitées à chaque analyse au lieu d’atteindre un état stable.
Corrigez le premier élément qui change à chaque exécution : chemin inaccessible, échec d’autorisation, fichier compagnon mal formé, horodatage instable, racine de bibliothèque en double ou enregistrement de métadonnées supprimé puis recréé à répétition. Raccourcir l’intervalle ne sera d’aucune utilité si chaque analyse continue de traiter le même contenu comme nouveau.
Conservez les métadonnées sur le SSD sans supposer que cela empêchera tous les réveils
Placez la base de données de l’application, le cache, les affiches et les métadonnées actives sur un SSD lorsque la plateforme le permet. Cela réduit les petites lectures aléatoires pendant la navigation et maintient la maintenance courante de la base de données à l’écart des disques de capacité.
La séparation du stockage ne constitue pas une garantie complète. Un rapport de régression Jellyfin a documenté des réveils de disques durs pendant la consultation des détails de la bibliothèque, même lorsque le cache et les métadonnées étaient stockés sur NVMe, montrant que le serveur peut tout de même accéder aux médias sources pour certaines opérations.
Après avoir déplacé les données de l’application, observez quels chemins sources sont ouverts pendant la navigation et les analyses. Gardez autant que possible les affiches, les aperçus et les bases de données à l’écart des disques contenant les médias, mais considérez tout accès restant aux fichiers sources comme un comportement distinct à diagnostiquer, et non comme la preuve que le déplacement vers le SSD a échoué.
Réduisez la fréquence, la portée et les tâches qui se chevauchent
Exécutez les analyses complètes aussi souvent que nécessaire pour la bibliothèque et évitez de les planifier en même temps que les sauvegardes, les vérifications, la génération d’aperçus ou les importations de médias. Analysez des bibliothèques ou des dossiers individuels lorsque la plateforme permet des actualisations ciblées.
Désactivez le remplacement étendu des métadonnées pendant les analyses courantes, sauf si les métadonnées doivent réellement être reconstruites. Une analyse incrémentielle normale ne devrait pas régénérer à répétition les images de chapitres, les fichiers trickplay, les affiches et l’identification des épisodes pour des médias inchangés.
Utilisez un calendrier décalé : importations d’abord, actualisation ciblée de la bibliothèque après la période d’importation, puis tâches lourdes de génération de fichiers dérivés un autre jour ou uniquement à la demande. Vous obtiendrez ainsi une période de réveil prévisible au lieu de plusieurs réveils brefs répartis pendant la nuit.
Vérifiez la disponibilité des points de montage avant le démarrage du service multimédia
Un point de montage réseau ou mutualisé absent peut exposer un répertoire local vide à l’emplacement attendu. Le serveur multimédia peut analyser ce répertoire de secours, supprimer les éléments, puis tout analyser à nouveau lorsque le partage réel revient.
Les interruptions de disque ou de point de montage peuvent faire disparaître une bibliothèque multimédia et forcer une reconstruction coûteuse. Un ticket Jellyfin décrit la perte d’une bibliothèque après la déconnexion d’un point de montage, un scénario qu’une dépendance au démarrage devrait empêcher.
Configurez le conteneur ou le service pour qu’il démarre après l’activation et le peuplement des points de montage requis. Ajoutez une vérification de présence du point de montage qui recherche un marqueur connu ou un type de système de fichiers attendu, puis interrompez l’analyse lorsque le chemin de stockage est indisponible au lieu de considérer un répertoire vide comme une bibliothèque valide.
Vérifiez la stabilité du fonctionnement au repos sur plusieurs nuits
Après chaque modification, consignez les heures de début et de fin des tâches, l’état d’alimentation des disques, le volume de lectures, les entrées de journal les plus importantes et l’apparition éventuelle des nouveaux médias. Une seule nuit calme ne suffit pas si l’analyse réduite ne s’exécute que tous les quelques jours.
Le guide ZimaSpace consacré au choix des rôles des disques durs et des SSD dans un NAS fournit le contexte d’organisation du stockage nécessaire pour garder les données actives des applications à l’écart des disques multimédias en veille.
L’ajustement est réussi lorsque la maintenance planifiée se déroule dans une seule fenêtre connue, que les bibliothèques inchangées ne font plus l’objet d’un travail répété au niveau des fichiers, que les importations sont toujours détectées et que les disques durs restent inactifs en dehors de la lecture, des analyses vérifiées, des sauvegardes ou des tâches de contrôle de l’état du stockage.
Produits recommandés
Assistance et conseils
Plus à lire
Pourquoi la restauration d’un volume Docker recrée-t-elle le contenu des fichiers, mais supprime-t-elle les attributs étendus ?
Un diagnostic de restauration de volume couvrant l’inventaire des xattr, les options de tar et de Rsync, les espaces de noms, la prise en...
Pourquoi un conteneur en cours d’exécution conserve-t-il son ancienne limite de mémoire après la modification du fichier Compose ?
Un diagnostic des limites mémoire couvrant les cgroups actifs, le redémarrage par rapport à la recréation, les champs Compose, les limites strictes et souples,...
Pourquoi le redémarrage d’un proxy inverse invalide-t-il toutes les sessions d’une application auto-hébergée ?
Un diagnostic de perte de session couvrant la portée des redémarrages, la propriété des cookies, la rotation des secrets, les sessions adossées au cache,...
