Jaki limit pamięci należy ustawić dla Jellyfin?
Nie ustawiaj uniwersalnego limitu pamięci dla Jellyfin — zacznij od zmierzonego obciążenia, zarezerwuj pamięć dla hosta i sąsiednich kontenerów, a twardy limit wprowadź dopiero po zaobserwowaniu rzeczywistych wartości szczytowych.
Czy Twój kontener rośnie, aż host zaczyna korzystać z pamięci wymiany, czy niski limit powoduje powtarzające się zabicia przez OOM? Zmierz zużycie w stanie bezczynności, skanowanie biblioteki, przetwarzanie metadanych, jednoczesne transkodowanie oraz pamięć dostępną dla Dockera lub maszyny wirtualnej, zanim zmienisz limit. Limit jest bezpieczny tylko wtedy, gdy pierwotne obciążenie nadal się kończy, a host zachowuje zapas umożliwiający odzyskanie stabilności.
Oddziel normalny wzrost pamięci podręcznej od presji na pamięć rezydentną
Najpierw porównaj pamięć RSS kontenera, pamięć podręczną, pamięć wymiany oraz ilość wolnej pamięci hosta w stanie bezczynności i podczas najbardziej obciążającego, powtarzalnego zadania. Pamięć podręczna systemu plików może wyglądać na dużą bez oznaczania wycieku, natomiast wzrost pamięci rezydentnej wraz ze zdarzeniami OOM wskazuje na rzeczywiste ograniczenie.
Podstawowe wdrożenie Jellyfin w Dockerze zwykle zaczyna się od kilku gigabajtów i wymaga więcej przy transkodowaniu, ale właściwa wartość zależy od obciążenia (wartość bazowa pamięci zależna od obciążenia).
Jeśli RSS pozostaje stabilne, pamięć podręczna rośnie, a host ma pamięć możliwą do odzyskania, monitoruj sytuację zamiast zaostrzać limit. Jeśli RSS rośnie wraz z użyciem pamięci wymiany lub komunikatami o zabiciu przez OOM, przejdź do testów transkodowania i biblioteki.
Przetestuj limit przy obciążeniu, które powoduje awarię
Uruchom jedno skanowanie biblioteki, jedno reprezentatywne transkodowanie oraz oczekiwaną liczbę jednoczesnych strumieni, rejestrując zużycie pamięci cgroup, zdarzenia pamięci, użycie pamięci wymiany i presję na hosta. Pomiędzy testami zmieniaj wyłącznie limit pamięci.
Limit, który sprawdza się przy odtwarzaniu w stanie bezczynności, ale zawodzi podczas obsługi napisów, konwersji HDR lub indeksowania, nie jest prawidłowym ustawieniem produkcyjnym. Zapisz, który czynnik wywołał awarię, aby nie zwiększać limitu z powodu niezwiązanego z nim wąskiego gardła.
Jeśli kontener zostanie zabity, zwiększ limit dopiero po ograniczeniu niepotrzebnej pamięci podręcznej transkodowania lub rozdzieleniu ciężkich zadań. Jeśli sam host korzysta z pamięci wymiany, zmniejsz współbieżność lub przenieś jedną z funkcji; przydzielenie Jellyfin całej pozostałej pamięci RAM jedynie przeniesie awarię na inną usługę.
Ustal granicę zatrzymania i zweryfikuj trwałość ustawienia
Ustaw miękki alarm poniżej twardego limitu i pozostaw wystarczająco dużo pamięci dla hosta, usług pamięci masowej oraz prawidłowego ponownego uruchomienia. Twardy limit powinien chronić hosta, a nie ukrywać nieograniczonego procesu lub zbyt słabego sprzętu.
Po zmianie limitu raz zatrzymaj i ponownie utwórz kontener, a następnie powtórz pierwotne skanowanie oraz test odtwarzania, który powodował problem. Sprawdź, czy skonfigurowany limit nadal jest aktywny po ponownym utworzeniu kontenera oraz czy baza danych pozostaje zapisywalna.
Przerwij dostrajanie i eskaluj problem, gdy zdarzenia OOM nadal występują przy limicie, który nie pozostawia hostowi żadnego zapasu, baza danych ulega uszkodzeniu lub proces rośnie bez powtarzalnego obciążenia. Zachowaj dzienniki i ostatnią poprawną konfigurację przed wprowadzeniem większej zmiany.
Ponownie sprawdź szczytowe obciążenie odtwarzania po zimnym restarcie
Uruchom ponownie hosta, zaczekaj na zamontowanie pamięci masowej i uruchomienie sąsiednich kontenerów, a następnie odtwórz tę samą kombinację strumieni dla wielu użytkowników, która pierwotnie ujawniła problem z limitem. Nie weryfikuj ustawienia wyłącznie za pomocą bezczynnego panelu ani pojedynczej sesji Direct Play.
Odzyskanie stabilności jest potwierdzone, gdy odtwarzanie pozostaje stabilne, nie pojawia się gwałtowne użycie pamięci wymiany, kontener pozostaje poniżej limitu, a wykonanie nowej kopii zapasowej lub ponowne uruchomienie kończy się bez błędów związanych z pamięcią. Porównaj wynik z wartością bazową zapisaną przed dostrajaniem.
Pozostaw ustawienie, jeśli szczytowe obciążenie przechodzi test z mierzalnym zapasem po stronie hosta. Jeśli problem pojawia się dopiero po uruchomieniu innego kontenera, podziel budżet zasobów lub przełóż konkurencyjne zadanie, zamiast ponownie zwiększać limit Jellyfin.
Polecane produkty
Wsparcie i wskazówki
Więcej do przeczytania
Jak zoptymalizować połączenia z bazą danych Jellyfin dla kontenerów działających równocześnie
Zacznij od jednego właściciela bazy danych i zmierz zachowanie blokad SQLite; dodaj inny backend dopiero wtedy, gdy współbieżność i odzyskiwanie danych uzasadnią tę złożoność.
Jak zapobiegać duplikowaniu zadań lub importów w Jellyfin
Duplikowanie pracy zwykle wynika z nakładających się harmonogramów lub więcej niż jednego procesu zapisującego; wyznacz jednego właściciela, jedną ścieżkę i jeden sposób sprawdzania ukończenia.
Jak naprawić Jellyfin po zapełnieniu woluminu bazy danych
Wstrzymaj zapisy, zachowaj bazę danych i pliki WAL, zwolnij miejsce bez bezmyślnego usuwania stanu, a następnie zweryfikuj integralność i pierwotne działanie.
