Pourquoi Jellyfin conserve-t-il plus de données temporaires que prévu ?

Jellyfin peut conserver plus de données temporaires que prévu, car les transcodages, les caches, les artefacts multimédias générés et les tâches de nettoyage suivent tous des cycles de vie différents.

Un cache ou un répertoire temporaire qui grossit n’est pas automatiquement le signe d’une fuite. Certains fichiers appartiennent à des sessions actives, certains sont des états dérivés réutilisables, certains attendent qu’un seuil d’ancienneté ou de planification soit atteint, et d’autres persistent parce qu’une tâche s’est terminée avant le nettoyage. Commencez par diagnostiquer le producteur et le cycle de vie ; supprimer un répertoire inexpliqué peut masquer les indices ou forcer une régénération coûteuse sans résoudre la cause.

La cause première est un décalage de cycle de vie, pas simplement un cache volumineux

Les données temporaires deviennent suspectes lorsque leur durée de vie observée ne correspond plus à l’événement qui les a créées. L’ensemble de travail d’un transcodage devrait suivre l’activité de lecture, les vignettes réutilisables ou les données de trickplay peuvent volontairement survivre à une session, et les fichiers gérés par le nettoyage peuvent rester présents jusqu’à l’expiration d’un délai ou d’un seuil. Il s’agit de contrats différents, même si tous les chemins semblent « temporaires ».

Les recommandations de dépannage de Jellyfin concernant l’utilisation intensive des ressources distinguent le transcodage actif des autres tâches en arrière-plan ; c’est pourquoi le transcodage actif doit être vérifié avant de supposer que les fichiers restants sont orphelins. Un fichier qui possède encore un propriétaire et un consommateur actif n’est pas obsolète simplement parce qu’il est volumineux.

La condition de défaillance est une croissance inexpliquée : aucun producteur actif n’a besoin des données, aucune règle de réutilisation ne justifie leur conservation et aucune règle de nettoyage ne permet de prévoir leur disparition. Lorsque ces trois explications échouent, les données temporaires conservées deviennent un défaut opérationnel plutôt qu’un coût normal du traitement des médias dérivés.

Les quatre causes des données temporaires conservées

Classez les fichiers conservés par producteur avant de les supprimer. Les catégories utiles sont les données de session active, les artefacts dérivés réutilisables, les fichiers en attente d’un nettoyage piloté par une règle et les intermédiaires orphelins laissés par une tâche interrompue. Chaque catégorie possède un moment de suppression sûr différent.

Les systèmes de nettoyage fondés sur l’ancienneté montrent pourquoi « inutilisé actuellement » ne signifie pas « éligible à la suppression » : la conservation peut dépendre d’horodatages, de règles et de balayages planifiés. Les règles de nettoyage fondées sur l’ancienneté constituent donc un modèle utile pour séparer la politique de cycle de vie de l’état immédiat d’une session.

Utilisez les quatre signatures ci-dessous pour déterminer si la croissance est attendue, retardée ou due à des fichiers orphelins. N’appliquez pas de seuil de taille global avant de savoir si le répertoire contient des fichiers de travail jetables ou des artefacts réutilisables dont la régénération recréerait simplement la même empreinte.

Cause 1 : des transcodages actifs possèdent encore un ensemble de travail

• Mécanisme : une session de lecture active ou venant de se terminer écrit des segments temporaires qui restent utiles jusqu’à la libération du pipeline de transcodage.
• Signature observable : la date de modification des fichiers et la croissance du répertoire suivent les sessions de transcodage actives ou les recherches récentes.
• SI–ALORS : si l’ensemble de travail cesse d’évoluer et est libéré après la fin de tous les transcodages, considérez-le comme lié à la session plutôt que comme orphelin.

Cause 2 : les artefacts dérivés réutilisables sont conservés intentionnellement

• Mécanisme : les vignettes, images de trickplay, métadonnées ou autres représentations générées sont conservées, car de futurs clients peuvent les réutiliser.
• Signature observable : les fichiers restent stables d’une session à l’autre et sont relus lors de la navigation ou des recherches ; les fichiers de trickplay et de métadonnées peuvent donc se comporter davantage comme un état dérivé pouvant être mis en cache que comme des données de travail propres à une seule session.
• SI–ALORS : si la suppression des fichiers ne fait que déclencher une régénération prévisible sans réduire l’empreinte à long terme, gérez leur génération et leur conservation au lieu de les purger à répétition.

Cause 3 : le nettoyage n’a pas encore atteint son déclencheur d’ancienneté ou de planification

• Mécanisme : le producteur termine son travail, mais un processus de nettoyage distinct est responsable de la suppression et s’exécute ultérieurement.
• Signature observable : les anciens fichiers disparaissent par lots à une heure ou après une durée d’ancienneté constante, plutôt qu’immédiatement après la lecture ou l’analyse.
• SI–ALORS : si la durée de conservation correspond à la fenêtre de nettoyage documentée ou observée, ne modifiez la règle que lorsque l’espace disque disponible impose une fenêtre plus courte.

Cause 4 : une tâche interrompue laisse des intermédiaires orphelins

• Mécanisme : un processus crée des fichiers temporaires, mais se termine brutalement, est arrêté ou suit un chemin d’exécution qui ne lance jamais le nettoyage.
• Signature observable : les fichiers obsolètes n’ont aucun propriétaire actif ni schéma de réutilisation, et leurs horodatages se concentrent autour de tâches interrompues ; les défaillances réelles de l’automatisation montrent comment un nettoyage ignoré après une interruption peut remplir de grands répertoires de travail.
• SI–ALORS : si la même tâche laisse régulièrement des fichiers après une annulation ou un échec, corrigez son nettoyage à la sortie, puis supprimez uniquement l’ensemble d’orphelins confirmé.

Limite de défaillance : distinguer la conservation attendue de la croissance anormale

Ne vous fiez pas uniquement à la taille du répertoire. Notez la répartition des âges des fichiers, l’activité récente des modifications, les sessions Jellyfin actives, les tâches planifiées et le processus qui garde encore chaque fichier suspect ouvert. Une conservation attendue possède un propriétaire ou une règle ; une croissance anormale n’a ni l’un ni l’autre, ou dépasse régulièrement la règle.

La comptabilité du système de fichiers peut également fausser le diagnostic. Sous Linux, un fichier supprimé peut continuer à consommer des blocs tant qu’un processus le garde ouvert ; les fichiers supprimés peuvent donc toujours occuper de l’espace disque même après la disparition du chemin visible. Si `df` et les totaux des répertoires divergent, inspectez les descripteurs de fichiers ouverts avant de supprimer davantage de données.

La limite est franchie lorsque le producteur a disparu, que la fenêtre de nettoyage attendue est dépassée, que les fichiers ne constituent pas un état dérivé réutilisable et que l’empreinte continue de croître ou réapparaît après une suppression manuelle. À ce stade, modifier uniquement la taille du cache revient à traiter le symptôme. Réparez le cycle de vie qui crée, ferme, invalide ou supprime les données.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Créez un registre des données temporaires avant tout nettoyage

Créez un registre succinct pour chaque chemin temporaire volumineux : producteur, rôle des données, propriétaire actif, dates de modification la plus ancienne et la plus récente, indice de réutilisation, déclencheur de nettoyage attendu, taille actuelle et condition de suppression sûre. Vous transformerez ainsi « le cache est énorme » en affirmations vérifiables et pourrez comparer la croissance ultérieure à une référence connue.

L’explication de ZimaSpace sur la répartition de la charge entre lectures et écritures aide à distinguer les données produites activement de celles qui sont simplement réutilisées. Lorsque la propriété d’un fichier est incertaine, l’inspection des processus Linux peut identifier le processus qui garde encore un fichier ouvert avant que le nettoyage ne modifie les indices.

Ne validez la décision de nettoyage que lorsque le registre identifie un ensemble jetable et que le producteur ne l’utilise plus. Supprimez un petit échantillon confirmé, vérifiez le comportement de Jellyfin, puis appliquez la règle de nettoyage. Si le répertoire retrouve immédiatement la même taille stable, ajustez le producteur ou la politique de conservation au lieu de planifier une purge permanente.