Jak duży narzut na pamięć masową dodaje Jellyfin poza plikami multimedialnymi?

Eva Wong

IceWhale author

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.

How Much Storage Overhead Does Jellyfin Add Beyond the Media Files? - Zima Store Online

Jellyfin nie ma jednej niezawodnej wartości procentowej stałego narzutu, ponieważ metadane, grafiki, pamięć podręczna, indeksy i tymczasowe transkodowanie zwiększają się w różnym tempie w zależności od multimediów źródłowych.

Dwie biblioteki o takim samym rozmiarze multimediów mogą wymagać zupełnie różnej ilości miejsca na dane aplikacji, gdy różnią się liczbą elementów, zagęszczeniem grafik, podglądami, skanowaniem lub aktywnością użytkowników. Mierz osobno katalog danych i ścieżki tymczasowe. Celem jest budżet pojemności oparty na wzroście i zachowaniu szczytowym, a nie uniwersalnej regule 5%.

Dane aplikacji trwałych to osobna pula pojemności

Baza danych, metadane, grafiki, logi i generowane indeksy są używane podczas przeglądania, skanowania i aktualizowania stanu odtwarzania. Należy je mierzyć niezależnie od filmów i odcinków, których dotyczą.

Model narzutu pamięci masowej rozdziela pojemność na dane aplikacji od pojemności na multimedia i wyjaśnia, dlaczego oba rodzaje danych rosną według różnych krzywych.

Duże archiwum multimediów może mieć niewiele metadanych, podczas gdy mniejsza biblioteka z rozbudowanymi grafikami lub podglądami może zajmować więcej miejsca na dane aplikacji.

Ustawienia funkcji zmieniają zajętość miejsca

Zagęszczenie grafik, miniatury podglądu, dane analityczne, liczba elementów, wtyczki i sposób działania pamięci podręcznej mogą zwiększać ilość trwale zajmowanego miejsca. Tymczasowe transkodowanie działa inaczej: podczas aktywnych konwersji tworzy szczytowe zapotrzebowanie robocze.

Wykorzystaj opóźnienie i przepustowość pamięci masowej, aby przy doborze ścieżki przechowywania rozróżnić opóźnienie, przepustowość i tymczasową przestrzeń roboczą.

Trwały wzrost należy uwzględnić w budżecie danych aplikacji, a przejściowe wartości szczytowe — w budżecie przestrzeni roboczej.

Dlaczego reguły procentowe zawodzą

Stała proporcja nie sprawdza się, gdy biblioteka zawiera wiele małych elementów, gdy włączone są podglądy lub gdy równoczesne konwersje tworzą wyjątkowo duże segmenty tymczasowe. Może też zawyżać wymagania w przypadku prostej biblioteki z niewielką ilością generowanych zasobów.

Porównanie w ramach modelu narzutu pamięci masowej pokazuje, dlaczego zmierzony bieżący rozmiar i tempo wzrostu są bardziej przydatne niż pojedyncza wartość procentowa.

Granica zmienia się, gdy funkcja lub obciążenie zmienia krzywą wzrostu danych; po takich zmianach wykonaj ponowne obliczenia.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Utwórz budżet na podstawie pomiarów

Zapisz bieżący rozmiar danych aplikacji, miesięczny przyrost, największy szczyt tymczasowego transkodowania oraz rezerwę na kopie zapasowe. Trzymaj rezerwę na kopie zapasowe poza katalogiem aktywnych danych, aby miejsce potrzebne do odzyskiwania danych nie mogło zostać zużyte podczas normalnej pracy.

Skorzystaj ze schematu budżetu pamięci masowej opartego na modelu narzutu i aktualizuj go po skanowaniu, zmianach analizy lub znacznym powiększeniu biblioteki.

Przestań dodawać pojemność, gdy zmierzony trwały wzrost i tymczasowe wartości szczytowe mieszczą się w wybranym marginesie wolnego miejsca.