Tymczasowe pliki transkodowania wciąż zapełniają dysk systemowy: jak to zatrzymać

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Zatrzymaj aktywne zadanie transkodowania, sprawdź, gdzie zapisywane są segmenty tymczasowe, a następnie wymuś ich usuwanie i przenieś tę lokalizację poza dysk systemowy.

Serwer multimediów może przechowywać segmenty HLS, strumienie po remuksowaniu, dane wyjściowe z wypalonymi napisami oraz nieukończone pliki sesji w domyślnym katalogu pamięci podręcznej lub aplikacji, nawet gdy biblioteka źródłowa znajduje się na dużej puli pamięci masowej. Dysk systemowy zapełnia się, gdy te pliki nie są usuwane wystarczająco szybko, katalog transkodowania jest nieprawidłowo zmapowany lub porzucone sesje pozostają po zakończeniu odtwarzania. Zdiagnozuj rzeczywisty katalog i sesję, zanim usuniesz pliki lub przeniesiesz pamięć podręczną.

Zlokalizuj aktywny katalog transkodowania i jego największe sesje

Rozpocznij jedno kontrolowane transkodowanie i obserwuj, który katalog się powiększa. Zapisz ustawienie aplikacji, ścieżkę kontenera, montowanie wiązane hosta, system plików, dostępną przestrzeń, liczbę plików oraz największe podkatalogi sesji.

Jellyfin udostępnia osobną lokalizację z prawem zapisu na potrzeby tymczasowych plików transkodowania, co potwierdza, że ścieżka transkodowania różni się od ścieżki stałej biblioteki multimediów i metadanych. Odpowiednim ustawieniem jest tymczasowa ścieżka transkodowania.

Jeśli aplikacja pokazuje jedną ścieżkę, ale zapełnia się inny dysk hosta, sprawdź rzeczywiste montowania Dockera i warstwę zapisywalną. Brakującego montowania wiązanego może spowodować zapisywanie plików tymczasowych przez kontener w systemie plików kontenera opartym na dysku systemowym zamiast w przeznaczonym do tego woluminie pamięci podręcznej.

Zatrzymaj proces tworzący pliki przed awaryjnym czyszczeniem

Zidentyfikuj aktywne sesje odtwarzania i zatrzymaj tylko transkodowania powiązane z szybko rosnącymi plikami. Przed odzyskaniem miejsca zapisz najnowszy dziennik FFmpeg, tytuł źródłowy, klienta, przepływność wyjściową, napisy oraz czas rozpoczęcia.

W przeszłości stare pliki transkodowania pozostawały po zakończeniu odtwarzania i powodowały zapełnienie dysku, aż serwer nie mógł się uruchomić. Zgłoszenie dotyczące Jellyfin dokumentuje film nadal zajmujący tymczasowy folder transkodowania wiele godzin po zakończeniu oglądania przez użytkownika.

Nie usuwaj plików należących do aktywnej sesji, gdy FFmpeg nadal je zapisuje. Zatrzymaj sesję lub serwer w kontrolowany sposób, potwierdź, że pliki nie są już otwarte, a następnie usuń wyłącznie potwierdzone dane wyjściowe tymczasowe, zamiast kasować całą pamięć podręczną lub bazę danych aplikacji.

Włącz usuwanie segmentów podczas długich sesji strumieniowania

Sprawdź, czy serwer usuwa pobrane segmenty HLS podczas odtwarzania. Bez usuwania segmentów długi film lub transmisja na żywo może wymagać wystarczającej ilości miejsca, aby przechować całe wygenerowane dane wyjściowe.

Jellyfin opisuje usuwanie segmentów jako kasowanie starych segmentów po ich pobraniu przez klienta, dzięki czemu serwer nie musi przechowywać całego transkodowanego pliku. Ta opcja służy konkretnie do zapobiegania przechowywaniu całego strumienia.

Włącz ją dla klienta testowego i monitoruj odtwarzanie, przewijanie oraz wznawianie. Pozostaw ją wyłączoną tylko wtedy, gdy odtworzony problem klienta wymaga zachowania segmentów, a następnie zrekompensuj to większym dedykowanym woluminem transkodowania i bardziej rygorystycznym czyszczeniem sesji.

Przenieś ścieżkę transkodowania na dedykowany szybki wolumin

Wybierz dedykowany dysk SSD, pamięć podręczną NVMe lub odpowiednio duży tymczasowy system plików, oddzielony od głównego systemu operacyjnego. Miejsce docelowe musi obsługiwać równoczesne zapisy i mieć wystarczającą pojemność dla najgorszego przewidywanego obciążenia sesjami transkodowania.

Użytkownicy umieszczający transkodowanie na małych dyskach RAM zgłaszali potrzebę limitu pamięci podręcznej, ponieważ katalog może nadal rosnąć aż do wyczerpania tymczasowego urządzenia. Granicą awarii jest nieograniczona pamięć podręczna transkodowania, niezależnie od tego, czy urządzeniem bazowym jest pamięć RAM, czy SSD.

Zatrzymaj serwer, utwórz nowy katalog z prawidłowym właścicielem usługi, jawnie zamontuj go w kontenerze i zaktualizuj ustawienie aplikacji, wskazując ścieżkę widoczną w kontenerze. Uruchom jedno transkodowanie i sprawdź, czy dysk systemowy hosta przestał się zapełniać.

Znajdź nieaktualne sesje i błędy czyszczenia

Porównaj tymczasowe katalogi sesji z identyfikatorami aktywnych sesji odtwarzania i procesami FFmpeg. Pliki bez odpowiadającej sesji, bez otwartego procesu i ze starymi znacznikami modyfikacji są kandydatami do czyszczenia obsługiwanego przez aplikację.

Nie zakładaj, że ogólne zadanie czyszczenia pamięci podręcznej usunie każdy artefakt transkodowania. Wcześniejszy raport dotyczący Jellyfin wykazał, że standardowe zadanie czyszczenia nie usunęło nieaktualnego pliku transkodowania, dlatego właściwym sprawdzeniem jest ustalenie, czy czyszczenie konkretnej sesji zostało ukończone.

Przejrzyj dziennik serwera pod kątem rozłączeń klienta, ponownych uruchomień kontenera, awarii, utraty sieci i wymuszonego zakończenia procesu. Napraw przyczynę uniemożliwiającą serwerowi otrzymanie prawidłowego zdarzenia zatrzymania, zamiast polegać wyłącznie na codziennym skrypcie usuwającym pliki.

Zmierz najgorszy przypadek równoczesnego obciążenia transkodowaniem

Uruchom jedno reprezentatywne zdalne transkodowanie i zmierz liczbę tymczasowych bajtów na minutę. Powtórz test z wypalaniem napisów, mapowaniem tonów HDR oraz najwyższą obsługiwaną przepływnością wyjściową, a następnie pomnóż wynik przez planowaną liczbę równoczesnych sesji i czas przechowywania danych.

Całkowicie zapełniony dysk systemowy może wpływać na serwer multimediów nie tylko podczas odtwarzania. W zgłoszeniu pomocy technicznej Jellyfin zauważono, że transkodowanie zapełniające dysk mogło mieć związek z brakiem połączenia z interfejsem internetowym, co pokazuje, że wyczerpanie woluminu systemowego wpływa na dostępność aplikacji.

Na dysku systemowym zachowaj wolne miejsce na system operacyjny, dzienniki, bazy danych, aktualizacje pakietów i metadane Dockera. Wolumin transkodowania powinien ulec zapełnieniu niezależnie, bez uniemożliwiania uruchomienia serwera ani otwarcia aplikacji multimedialnej.

Zweryfikuj czyszczenie i dodaj alerty pojemności

Przetestuj rozpoczęcie odtwarzania, przewijanie, wstrzymywanie, rozłączenie klienta, ponowne uruchomienie serwera oraz równoczesne sesje. Potwierdź, że aktywne pliki rosną wyłącznie w dedykowanej ścieżce transkodowania i zmniejszają się po zakończeniu sesji.

Przewodnik ZimaSpace dotyczący budowy domowego serwera multimediów przedstawia szerszą ścieżkę weryfikacji, która obejmuje oddzielenie pamięci źródłowej od obciążeń aplikacji i danych tymczasowych.

Naprawa jest zakończona, gdy nieaktualne sesje przestają pozostawać na dysku, usuwanie segmentów działa dla obsługiwanych klientów, na dysku systemowym pozostaje bezpieczny zapas miejsca, a alerty są uruchamiane, zanim dedykowany wolumin transkodowania lub główny system plików osiągnie próg pojemności.

Wsparcie i wskazówki

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.