Jak zoptymalizować połączenia z bazą danych Jellyfin dla kontenerów działających równocześnie

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 to Optimize Jellyfin Database Connections for Concurrent Containers - Zima Store Online

Zoptymalizuj dostęp do bazy danych Jellyfin dla współbieżnych kontenerów, najpierw upewniając się, że istnieje jeden właściciel bazy, a następnie mierząc czas oczekiwania na blokady, serie operacji zapisu, opóźnienia pamięci masowej i nakładanie się obciążeń.

Czy kilka kontenerów otwiera tę samą bazę danych Jellyfin albo jeden kontener Jellyfin działa wolno podczas skanowania i aktywności użytkowników? Nie zwiększaj liczby połączeń na ślepo. Ustal typ bazy danych, aktywnych zapisujących, lokalizację punktu montowania, metodę tworzenia kopii zapasowych oraz dokładną operację, która oczekuje, zanim zmienisz backend lub pulę połączeń.

Sprawdź, czy ograniczeniem są blokady, czy pamięć masowa

Rejestruj komunikaty o zajętej lub zablokowanej bazie, czas trwania transakcji, opóźnienia operacji wejścia/wyjścia, czas oczekiwania procesora oraz zadania wykonywane jednocześnie. SQLite umożliwia równoczesne odczyty, ale szereguje zapisy, więc wielu zapisujących może zamienić krótką aktualizację metadanych w kolejkę (sposób działania blokad SQLite).

Przenieś bazę danych na szybką lokalną pamięć masową wyłącznie jako kontrolowany test. Jeśli czas oczekiwania na blokady pozostanie bez zmian, a opóźnienia pamięci masowej spadną, problemem jest nakładanie się operacji zapisu lub konstrukcja bazy danych, a nie sam dysk.

Porównaj czas oczekiwania na blokady z opóźnieniami pamięci masowej podczas tego samego skanowania. Jeśli baza działa szybko, ale operacje zapisu oczekują, kolejnym elementem do kontrolowania jest harmonogram i własność, a nie kolejne połączenie.

Przypisz własność bazy i zaplanuj operacje zapisu

Tylko jedna instancja Jellyfin powinna być właścicielem danej bazy aplikacji, chyba że obsługiwany backend i wdrożenie wyraźnie zapewniają koordynację wielu instancji. Nie dopuszczaj do jednoczesnego uruchamiania skanowania, odświeżania metadanych, importowania, tworzenia kopii zapasowych i konserwacji. Używaj jednej tożsamości kontenera i jednej trwałej ścieżki, aby ponowne uruchomienie nie utworzyło drugiej bazy danych.

Zweryfikuj konfigurację, uruchamiając najpierw jedno skanowanie, następnie jedno obciążenie użytkownika, a na końcu zwykłą mieszankę operacji współbieżnych. Po dodaniu każdego kolejnego zapisującego porównaj czas oczekiwania na blokady i czas ukończenia zadania.

Przeprowadź test z jednym zapisującym, a następnie dodaj zwykłe współbieżne obciążenie kontenerów. Pozwoli to ustalić, czy każdy kolejny zapisujący wydłuża czas oczekiwania w kolejce, czy tylko dodaje nieszkodliwe odczyty.

Dowiedz się, kiedy uzasadniona jest zmiana backendu

Warto rozważyć większy backend, taki jak PostgreSQL, gdy obciążenie rzeczywiście wymaga wielu zapisujących aplikacji, większej aktywności współbieżnej lub narzędzi operacyjnych, których SQLite nie zapewnia. Taka zmiana oznacza jednak także migracje, dane uwierzytelniające, kopie zapasowe, awarie sieci i kolejną usługę wymagającą odtworzenia. W dyskusji projektowej zauważono, że współbieżność na skalę komercyjną wykracza poza typowy cel Jellyfin, jakim jest domowy serwer, dlatego nie przenoś założeń dotyczących liczby połączeń z systemów firmowych do domowego wdrożenia (dyskusja dotycząca zakresu współbieżności).

Jeśli testujesz zmianę backendu, zachowaj dostępną oryginalną bazę danych i definicję wdrożenia, aby można było wycofać zmianę bez modyfikowania stanu aplikacji.

-15% OFF

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

Single board computer zimaboard2

Zweryfikuj wybraną konfigurację

Uruchom ponownie każdy kontener, wykonaj pierwotne obciążenie współbieżne i potwierdź, że czas oczekiwania na blokady, opóźnienia, działania użytkowników oraz kopie zapasowe nadal mieszczą się w zaakceptowanych granicach. Zakończ dostrajanie, gdy baza danych obsługuje obciążenie z jednym jasno określonym właścicielem i przetestowaną ścieżką odtwarzania. Eskaluj problem, jeśli po odwracalnych testach harmonogramu i pamięci masowej nadal występują uszkodzenia, powtarzające się błędy blokad lub nieobsługiwane zapisy z wielu instancji.

Jeśli testujesz zmianę backendu, zachowaj dostępną oryginalną bazę danych i definicję wdrożenia, aby można było wycofać zmianę bez modyfikowania stanu aplikacji.