Warum behält Jellyfin mehr temporäre Daten als erwartet?

Jellyfin kann mehr temporäre Daten als erwartet behalten, da Transkodierungen, Caches, generierte Medienartefakte und Bereinigungsaufgaben jeweils eigenen Lebenszyklen folgen.

Ein wachsender Cache oder ein wachsendes temporäres Verzeichnis ist nicht automatisch ein Leck. Einige Dateien gehören zu aktiven Sitzungen, manche sind wiederverwendbare abgeleitete Daten, andere warten auf das Erreichen einer Alters- oder Zeitplan-Schwelle, und einige bleiben bestehen, weil eine Aufgabe vor der Bereinigung beendet wurde. Ermitteln Sie zuerst den Erzeuger und den Lebenszyklus. Das Löschen eines unerklärten Verzeichnisses kann Beweise verwischen oder eine teure Neugenerierung erzwingen, ohne die Ursache zu beheben.

Die eigentliche Ursache ist ein nicht übereinstimmender Lebenszyklus, nicht einfach ein großer Cache

Temporäre Daten werden verdächtig, wenn ihre beobachtete Lebensdauer nicht mehr zu dem Ereignis passt, durch das sie erstellt wurden. Ein Transkodierungs-Arbeitssatz sollte der Wiedergabeaktivität folgen, wiederverwendbare Vorschaubilder oder Trickplay-Daten dürfen absichtlich über eine einzelne Sitzung hinaus bestehen, und von der Bereinigung verwaltete Dateien können bleiben, bis ein Timer oder Schwellenwert abläuft. Das sind unterschiedliche Vereinbarungen, auch wenn jeder Pfad „temporär“ aussieht.

Die Jellyfin-Anleitung zur Fehlerbehebung bei hoher Ressourcennutzung unterscheidet zwischen aktiver Transkodierung und anderer Hintergrundarbeit. Deshalb sollte aktive Transkodierung überprüft werden, bevor übrig gebliebene Dateien als verwaist betrachtet werden. Eine Datei, die noch einen Besitzer und einen aktiven Verbraucher hat, ist nicht veraltet, nur weil sie groß ist.

Die Fehlerbedingung ist ein ungeklärtes Wachstum: Kein aktiver Erzeuger benötigt die Daten, keine Wiederverwendungsrichtlinie rechtfertigt ihre Aufbewahrung, und keine Bereinigungsregel sagt voraus, wann sie verschwinden sollten. Wenn alle drei Erklärungen ausscheiden, werden zurückgehaltene temporäre Daten zu einem betrieblichen Fehler statt zu normalen Kosten der Verarbeitung abgeleiteter Medien.

Die vier Ursachen zurückgehaltener temporärer Daten

Ordnen Sie zurückgehaltene Dateien nach ihrem Erzeuger, bevor Sie sie löschen. Die nützlichen Kategorien sind aktive Sitzungsdaten, wiederverwendbare abgeleitete Artefakte, Dateien, die auf eine richtliniengesteuerte Bereinigung warten, sowie verwaiste Zwischenprodukte aus unterbrochenen Aufgaben. Jede Kategorie hat einen anderen sicheren Löschzeitpunkt.

Altersbasierte Bereinigungssysteme zeigen, warum „gerade nicht verwendet“ nicht dasselbe ist wie „zum Löschen geeignet“: Die Aufbewahrung kann an Zeitstempel, Regeln und geplante Bereinigungsläufe gebunden sein. Daher sind altersbasierte Bereinigungsregeln ein nützliches Modell, um Lebenszyklus-Richtlinien vom unmittelbaren Sitzungsstatus zu trennen.

Verwenden Sie die folgenden vier Merkmale, um zu entscheiden, ob das Wachstum erwartet, verzögert oder verwaist ist. Wenden Sie keinen globalen Größenschwellwert an, bevor Sie wissen, ob das Verzeichnis löschbare Arbeitsdateien oder wiederverwendbare Artefakte enthält, deren Neugenerierung denselben Speicherbedarf lediglich erneut erzeugen würde.

Ursache 1: Aktive Transkodierungen besitzen weiterhin einen Arbeitssatz

• Mechanismus: Eine laufende oder gerade beendete Wiedergabesitzung schreibt temporäre Segmente, die nützlich bleiben, bis die Transkodierungspipeline sie freigibt.
• Typisches Symptom: Änderungszeitpunkt der Dateien und Verzeichniswachstum folgen aktiven Transkodierungssitzungen oder kürzlich ausgeführten Sprüngen in der Wiedergabe.
• WENN–DANN: Wenn sich der Arbeitssatz nicht mehr verändert und nach dem Ende aller Transkodierungen freigegeben wird, behandeln Sie ihn als sitzungsgebunden und nicht als verwaist.

Ursache 2: Wiederverwendbare abgeleitete Artefakte bleiben absichtlich bestehen

• Mechanismus: Vorschaubilder, Trickplay-Bilder, Metadaten oder andere generierte Darstellungen werden behalten, weil zukünftige Clients sie wiederverwenden können.
• Typisches Symptom: Die Dateien bleiben über mehrere Sitzungen hinweg stabil und werden beim Durchsuchen oder Springen erneut gelesen. Trickplay- und Metadatendateien können sich daher eher wie cachebare abgeleitete Daten als wie sitzungsbezogene temporäre Dateien verhalten.
• WENN–DANN: Wenn das Löschen der Dateien lediglich eine vorhersehbare Neugenerierung auslöst, ohne den langfristigen Speicherbedarf zu verringern, verwalten Sie Erzeugung und Aufbewahrung, statt sie wiederholt zu löschen.

Ursache 3: Die Bereinigung hat ihren Alters- oder Zeitplan-Auslöser noch nicht erreicht

• Mechanismus: Der Erzeuger wird beendet, aber ein separater Bereinigungsprozess ist für das Löschen zuständig und läuft später.
• Typisches Symptom: Alte Dateien verschwinden zu einer bestimmten Zeit oder ab einem einheitlichen Altersgrenzwert in Gruppen statt unmittelbar nach der Wiedergabe oder Analyse.
• WENN–DANN: Wenn die Aufbewahrung dem dokumentierten oder beobachteten Bereinigungsfenster entspricht, passen Sie die Richtlinie nur an, wenn der verfügbare Speicher eine kürzere Aufbewahrung erfordert.

Ursache 4: Unterbrochene Aufgaben hinterlassen verwaiste Zwischenprodukte

• Mechanismus: Ein Prozess erstellt temporäre Dateien, stürzt jedoch ab, wird beendet oder verlässt den Prozess über einen Pfad, auf dem keine Bereinigung ausgeführt wird.
• Typisches Symptom: Veraltete Dateien haben keinen aktiven Besitzer, kein Wiederverwendungsmuster und Zeitstempel, die sich um unterbrochene Aufgaben gruppieren. Reale Fehler in der Automatisierung zeigen, wie eine nach einer Unterbrechung übersprungene Bereinigung große Arbeitsverzeichnisse anwachsen lassen kann.
• WENN–DANN: Wenn dieselbe Aufgabe nach einer Abmeldung oder einem Fehler wiederholt Dateien hinterlässt, beheben Sie ihre Bereinigung beim Beenden und entfernen Sie anschließend nur die bestätigte Gruppe verwaister Dateien.

Fehlergrenze: Erwartete Aufbewahrung von abnormalem Wachstum unterscheiden

Beurteilen Sie die Situation nicht allein anhand der Verzeichnisgröße. Erfassen Sie die Altersverteilung der Dateien, die aktuelle Änderungsaktivität, aktive Jellyfin-Sitzungen, geplante Aufgaben und den Prozess, der jede verdächtige Datei noch geöffnet hat. Erwartete Aufbewahrung hat einen Besitzer oder eine Regel; abnormales Wachstum hat beides nicht oder überschreitet die Regel wiederholt.

Auch die Dateisystemabrechnung kann die Diagnose erschweren. Unter Linux kann eine gelöschte Datei weiterhin Speicherblöcke belegen, solange ein Prozess sie geöffnet hält. Daher können gelöschte Dateien weiterhin Speicherplatz belegen, selbst wenn der sichtbare Pfad verschwunden ist. Wenn `df` und die Verzeichnissummen voneinander abweichen, prüfen Sie offene Dateideskriptoren, bevor Sie weitere Daten löschen.

Die Grenze ist überschritten, wenn der Erzeuger beendet ist, das erwartete Bereinigungsfenster verstrichen ist, die Dateien keinen wiederverwendbaren abgeleiteten Daten entsprechen und der Speicherbedarf nach dem manuellen Löschen weiter wächst oder erneut auftritt. An diesem Punkt behandelt eine bloße Änderung der Cache-Größe nur das Symptom. Reparieren Sie den Lebenszyklus, der die Daten erstellt, schließt, ungültig macht oder löscht.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Erstellen Sie vor jeder Bereinigung ein Verzeichnis für temporäre Daten

Erstellen Sie für jeden großen temporären Pfad ein kurzes Verzeichnis: Erzeuger, Datenrolle, aktiver Besitzer, ältester und neuester Änderungszeitpunkt, Wiederverwendungssignal, erwarteter Bereinigungsauslöser, aktuelle Größe und sichere Löschbedingung. So wird aus „Der Cache ist riesig“ eine Reihe überprüfbarer Aussagen, und späteres Wachstum lässt sich mit einer bekannten Ausgangsbasis vergleichen.

Die Erklärung von ZimaSpace zur Aufteilung der Lese- und Schreiblast hilft dabei, aktiv erzeugte Daten von lediglich wiederverwendeten Daten zu unterscheiden. Wenn unklar ist, wem eine Datei gehört, kann die Linux-Prozessinspektion ermitteln, welcher Prozess eine Datei noch geöffnet hat, bevor die Bereinigung die Beweislage verändert.

Führen Sie die Bereinigungsentscheidung erst aus, wenn das Verzeichnis eine löschbare Gruppe identifiziert und der Erzeuger sie nicht mehr verwendet. Löschen Sie zunächst eine kleine, bestätigte Stichprobe, prüfen Sie das Jellyfin-Verhalten und wenden Sie anschließend die Bereinigungsregel an. Wenn das Verzeichnis sofort wieder auf dieselbe stabile Größe anwächst, passen Sie den Erzeuger oder die Aufbewahrungsrichtlinie an, statt eine endlose Löschung zu planen.