Dlaczego uruchamianie Plexa trwa dłużej w miarę rozrastania się biblioteki

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.

Uruchamianie Plexa może trwać coraz dłużej wraz ze wzrostem stanu zindeksowanej biblioteki, szczególnie gdy serwer musi sprawdzić, przeprowadzić migrację lub wczytać do pamięci podręcznej większą ilość danych bazy i metadanych.

Sama pojemność multimediów jest słabym wskaźnikiem, ponieważ dwie biblioteki o tej samej liczbie terabajtów mogą znacznie różnić się liczbą elementów, dodatków, grafik i rekordów bazy danych. Monitoruj rozmiar i responsywność katalogu danych Plexa wraz z czasem uruchamiania. Istotne jest to, czy wzrost ilości zindeksowanych danych wiąże się z dłuższym osiąganiem gotowości lub wolniejszym działaniem zapytań.

Zindeksowane rekordy mają większe znaczenie niż sama pojemność multimediów

Biblioteka zawierająca wiele krótkich utworów muzycznych, zdjęć, dodatków lub odcinków może generować znacznie więcej operacji na bazie danych niż biblioteka z mniejszą liczbą elementów, ale dużymi plikami filmowymi. Koszt uruchamiania i wykonywania zapytań zależy od stanu zindeksowanych danych, a nie tylko od liczby bajtów źródłowych.

Duże biblioteki Plexa mogą gromadzić miliony zindeksowanych plików i rekordów, nawet gdy sama liczba terabajtów multimediów wydaje się możliwa do opanowania. Dlatego wzrost liczby elementów i rekordów należy śledzić osobno od surowej pojemności.

Monitoruj jednocześnie liczbę elementów biblioteki, rozmiar bazy danych, rozmiar danych binarnych i metadanych oraz czas uruchamiania. Korzystaj z trendów na własnym serwerze, zamiast traktować liczbę elementów innego użytkownika jako uniwersalny limit.

Zmiany wersji mogą zwielokrotnić pracę podczas uruchamiania

Podczas zwykłego ponownego uruchomienia serwer może jedynie ponownie otworzyć zapisany stan, natomiast aktualizacja może dodać jednorazowe operacje obejmujące wiele istniejących wierszy. W przypadku rosnącej biblioteki jest to szczególnie widoczne podczas migracji schematu lub danych.

Podczas migracji bazy danych czas migracji może rosnąć wraz z liczbą zindeksowanych elementów i szybkością procesora, dlatego czas pierwszego uruchomienia należy analizować osobno od czasu zwykłego restartu.

Ustal bazowy czas restartu sprzed aktualizacji i porównaj go z pierwszym oraz drugim uruchomieniem po aktualizacji. Jeśli podczas drugiego uruchomienia czas wróci do wartości bazowej, biblioteka nie stała się nagle trwale zbyt duża.

Opóźnienia pamięci masowej nadal determinują koszt dostępu do małego stanu

Większa baza danych i drzewo metadanych stwarzają więcej okazji do losowych odczytów, operacji fsync i chybień pamięci podręcznej. Szybki transfer sekwencyjny multimediów nie eliminuje kosztów związanych z małymi operacjami dostępu.

Gdy uruchamianie wielokrotnie odwołuje się do niewielkich ilości danych stanu, opóźnienie uruchamiania na SSD w porównaniu z HDD może zmieniać czas osiągnięcia gotowości, nawet gdy środowisko uruchomieniowe kontenera pozostaje identyczne.

Umieść stan Plexa w miejscu, w którym opóźnienia są przewidywalne, a następnie wykonaj pomiary przed zmianą i po niej. Trwała ścieżka danych aplikacji powinna być zoptymalizowana pod kątem stanu serwera, podczas gdy multimedia zbiorcze mogą pozostać na pamięci masowej nastawionej na dużą pojemność.

-15% OFF

Trend wolniejszych zapytań jest lepszym sygnałem do aktualizacji

Praktyczny limit pojawia się wtedy, gdy typowe otwieranie, wyszukiwanie, uruchamianie lub czynności konserwacyjne regularnie nie mieszczą się w założonym czasie, mimo że baza danych działa prawidłowo. Rozbudowa sprzętu pomoże tylko wtedy, gdy obciążenie rzeczywiście jest ograniczone przez ten sprzęt.

Długi czas operacji na bazie danych jest lepszym sygnałem, by odizolować ścieżkę stanu, niż traktowanie każdego wolnego uruchomienia jako ogólnej powolności hosta.

Zapisuj niewielki zestaw powtarzalnych zadań — restart do momentu gotowości, otwieranie biblioteki, wyszukiwanie i konserwację bazy danych — i obserwuj je w czasie. Wykonaj aktualizację, gdy mierzona ścieżka stale się pogarsza, a nie wtedy, gdy biblioteka przekroczy arbitralny rozmiar.

Centrum Technologii i Sztucznej Inteligencji

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.