Ogranicz nocne wybudzenia dysków, identyfikując dokładne zaplanowane zadanie, które uzyskuje dostęp do multimediów, a następnie ograniczając jego częstotliwość, zakres lub operacje na poziomie plików.
Serwer multimediów może wybudzać uśpione dyski HDD, nawet gdy jego baza danych i pamięć podręczna znajdują się na dysku SSD, ponieważ zaplanowane skanowanie biblioteki może przeglądać katalogi, analizować pliki, odświeżać grafiki, generować podglądy, sprawdzać ścieżki lub przetwarzać elementy, które nigdy nie osiągają stabilnego stanu. Zacznij od skorelowania pierwszego dostępu do dysku z jednym zadaniem i jednym wpisem w dzienniku. Zmiana timerów usypiania przed potwierdzeniem przyczyny zwykle tylko ukrywa wzorzec, nie ograniczając źródłowych odczytów.
Sprawdź, które zaplanowane zadanie wybudza dyski
Zapisz dokładną godzinę wybudzenia na podstawie telemetrii dysków, dzienników systemowych lub monitoringu zużycia energii, a następnie porównaj ją z historią zaplanowanych zadań serwera multimediów. Wyłącz tylko jedno podejrzane zadanie na jedną noc, aby wynik można było jednoznacznie przypisać.
W jednym ze zgłoszeń dotyczących Jellyfin stwierdzono, że zaplanowane skanowanie biblioteki dwukrotnie dziennie przetwarzało całą bibliotekę i przez wiele godzin analizowało multimedia. Kluczową wskazówką było to, że to samo pełne skanowanie ciągle się powtarzało, a nie pojedyncze żądanie odtwarzania.
Jeśli dyski wybudzają się przed rozpoczęciem skanowania biblioteki, sprawdź inne zadanie, takie jak wyodrębnianie obrazów rozdziałów, generowanie podglądów trickplay, analiza wstępów, odświeżanie metadanych, tworzenie kopii zapasowych, testy SMART, sprawdzanie systemu plików lub organizowanie pobranych plików. Nie obwiniaj serwera multimediów, dopóki jego proces lub kontener nie pojawi się w dowodach pierwszego dostępu.
Oddziel pełne skanowanie biblioteki od monitorowania w czasie rzeczywistym
Sprawdź, czy biblioteka korzysta zarówno z okresowych pełnych skanów, jak i monitorowania systemu plików. Monitorowanie w czasie rzeczywistym może szybko importować zwykłe nowe pliki na obsługiwanych lokalnych systemach plików, podczas gdy zaplanowane pełne skanowanie nadal może służyć jako wykonywana rzadziej siatka bezpieczeństwa.
Jellyfin od dawna traktuje skanowanie zaplanowane i monitorowanie w czasie rzeczywistym jako odrębne mechanizmy. W jednym ze zgłoszeń projektu zauważono, że monitorowanie w czasie rzeczywistym może wykrywać nowe multimedia, podczas gdy zaplanowane zadanie zapewnia wykrywanie w określonych odstępach.
Na niezawodnym lokalnym magazynie przetestuj monitorowanie w czasie rzeczywistym, dodając jeden nowy plik, i ogranicz częstotliwość pełnego skanowania dopiero po prawidłowym pojawieniu się tego pliku. W przypadku NFS, SMB, rclone, systemów plików łączących wiele źródeł oraz niektórych ścieżek montowanych w kontenerach dostarczanie zdarzeń może być niepełne, dlatego zachowaj okresowe skanowanie o porze dopasowanej do zasad przechowywania danych.
Znajdź zadania odczytujące zawartość multimediów, a nie tylko nazwy katalogów
Przejrzyj dziennik skanera pod kątem analizowania multimediów, odczytów sum kontrolnych, wyodrębniania rozdziałów, analizy napisów, generowania podglądów trickplay, analizy głośności i powtarzającego się odświeżania metadanych. Wyliczenie katalogów może spowodować krótkie wybudzenie, ale odczytywanie fragmentów każdego pliku może utrzymywać aktywność całej macierzy przez wiele godzin.
W opisanym wyżej przypadku powtarzających się skanów odnotowano znaczne odczyty z każdego pliku multimedialnego podczas analizy, co wyjaśnia, dlaczego zadanie robiło więcej niż tylko sprawdzało nazwy plików. Inne zgłoszenie pokazuje, że te same wpisy były przetwarzane ponownie przy każdym skanowaniu, zamiast osiągnąć stabilny stan.
Napraw pierwszy element, który zmienia się przy każdym uruchomieniu: niedostępną ścieżkę, błąd uprawnień, nieprawidłowy plik dodatkowy, niestabilny znacznik czasu, zduplikowany główny katalog biblioteki lub rekord metadanych, który jest wielokrotnie usuwany i tworzony ponownie. Skrócenie odstępów między skanami nie pomoże, jeśli każde skanowanie nadal traktuje tę samą zawartość jako nową.
Trzymaj metadane na SSD, ale nie zakładaj, że powstrzyma to każde wybudzenie
Jeśli platforma na to pozwala, umieść bazę danych aplikacji, pamięć podręczną, plakaty i aktywne metadane na dysku SSD. Ograniczy to małe losowe odczyty podczas przeglądania i przeniesie rutynową konserwację bazy danych z dysków przeznaczonych na pojemność.
Rozdzielenie danych nie daje pełnej gwarancji. W raporcie dotyczącym regresji w Jellyfin opisano wybudzenia dysków HDD podczas przeglądania szczegółów biblioteki, mimo że pamięć podręczna i metadane znajdowały się na NVMe, co pokazuje, że serwer może nadal uzyskiwać dostęp do źródłowych multimediów podczas niektórych operacji.
Po przeniesieniu danych aplikacji sprawdź, które ścieżki źródłowe są otwierane podczas przeglądania i skanowania. W miarę możliwości trzymaj plakaty, podglądy i bazy danych poza dyskami z multimediami, ale traktuj każdy pozostały dostęp do plików źródłowych jako osobne zachowanie wymagające diagnozy, a nie jako dowód, że przeniesienie danych na SSD się nie powiodło.
Ogranicz częstotliwość, zakres i nakładanie się zadań
Uruchamiaj pełne skanowanie tylko tak często, jak wymaga tego biblioteka, i unikaj planowania go w tym samym czasie co kopie zapasowe, sprawdzanie systemu plików, generowanie podglądów lub import multimediów. Jeśli platforma na to pozwala, skanuj pojedyncze biblioteki lub katalogi podczas odświeżania wybranych elementów.
Wyłącz szeroką podmianę metadanych podczas rutynowych skanów, chyba że metadane rzeczywiście wymagają odbudowy. Zwykłe skanowanie przyrostowe nie powinno wielokrotnie generować obrazów rozdziałów, plików trickplay, plakatów ani identyfikować odcinków dla niezmienionych multimediów.
Zastosuj rozłożony harmonogram: najpierw importy, następnie ukierunkowane odświeżenie biblioteki po zakończeniu okna importu, a ciężkie zadania generujące pliki pochodne w innym dniu lub tylko na żądanie. Zapewni to przewidywalny okres wybudzenia zamiast kilku krótkich wybudzeń w ciągu nocy.
Sprawdź dostępność montowań przed uruchomieniem usługi multimediów
Brakujące montowanie sieciowe lub montowanie puli może udostępnić pusty lokalny katalog pod oczekiwaną ścieżką. Serwer multimediów może przeskanować ten katalog zastępczy, usunąć elementy, a następnie ponownie przeskanować wszystko po powrocie właściwego udziału.
Przerwy w działaniu dysku lub montowania mogą sprawić, że biblioteka multimediów zniknie, i wymusić kosztowną odbudowę. W jednym ze zgłoszeń Jellyfin opisano utratę biblioteki po rozłączeniu montowania — właśnie temu scenariuszowi awaryjnemu powinno zapobiegać zależne uruchamianie usługi.
Skonfiguruj kontener lub usługę tak, aby uruchamiały się dopiero po aktywowaniu i udostępnieniu wymaganych montowań. Dodaj kontrolę obecności montowania, która sprawdza znacznik kontrolny lub oczekiwany typ systemu plików, a następnie zatrzymuje skanowanie, gdy ścieżka magazynu jest niedostępna, zamiast traktować pusty katalog jako prawidłową bibliotekę.
Zweryfikuj stabilne działanie w trybie bezczynności przez kilka nocy
Po każdej zmianie zapisuj godziny rozpoczęcia i zakończenia zadań, stan zasilania dysków, ilość odczytanych danych, najobszerniejsze wpisy w dzienniku oraz informację, czy nowo dodane multimedia nadal się pojawiają. Jedna spokojna noc nie wystarczy, jeśli ograniczone skanowanie uruchamia się tylko co kilka dni.
Przewodnik ZimaSpace dotyczący wyboru ról dysków HDD i SSD w serwerze NAS przedstawia kontekst układu pamięci masowej, który pomaga trzymać aktywne dane aplikacji z dala od uśpionych dysków z multimediami.
Zmiana jest skuteczna, gdy zaplanowana konserwacja odbywa się w jednym znanym oknie, niezmienione biblioteki nie są już wielokrotnie przetwarzane na poziomie plików, importy nadal są wykrywane, a dyski HDD pozostają bezczynne poza odtwarzaniem, zweryfikowanymi skanami, kopiami zapasowymi lub zadaniami związanymi ze stanem magazynu.
Wsparcie i wskazówki
Więcej do przeczytania

Dlaczego przywracanie woluminu Dockera odtwarza zawartość plików, ale usuwa atrybuty rozszerzone?
Diagnoza przywracania woluminu obejmująca inwentaryzację atrybutów xattr, opcje tar i Rsync, przestrzenie nazw, obsługę miejsca docelowego, uprawnienia, etykiety, metadane aplikacji i testy.

Dlaczego uruchomiony kontener zachowuje stary limit pamięci po zmianie pliku Compose?
Diagnoza limitu pamięci obejmująca aktywne grupy cgroup, ponowne uruchamianie w porównaniu z odtwarzaniem, pola Compose, limity twarde i miękkie, zakresy nadrzędne, pamięć wymiany oraz...

Dlaczego ponowne uruchomienie odwrotnego proxy unieważnia każdą sesję w jednej samodzielnie hostowanej aplikacji?
Diagnoza utraty sesji obejmująca zakres restartu, własność plików cookie, rotację sekretów, sesje oparte na pamięci podręcznej, przekierowanie do serwera przyklejonego, bramy uwierzytelniania oraz przywracanie...

