Jak duży narzut na przestrzeń dyskową dodaje Immich ponad dane źródłowe?
Immich nie stosuje uniwersalnego procentowego przelicznika zajętości pamięci; narzut zależy głównie od liczby zasobów, proporcji zdjęć do filmów, ustawień plików pochodnych, rozrostu bazy danych oraz przechowywanych kopii zapasowych.
Rodzinna biblioteka o rozmiarze jednego terabajta, zdominowana przez zdjęcia, będzie wyglądać zupełnie inaczej niż biblioteka z przewagą długich filmów z telefonu. Planuj pojemność, mierząc rozmiar każdej wygenerowanej kategorii po reprezentatywnym imporcie, a następnie zarezerwuj osobne miejsce na rozwój biblioteki, pliki tymczasowe i kopie odzyskiwania.
Pliki pochodne zwykle stanowią największą widoczną część narzutu
Immich przygotowuje mniejsze obrazy do osi czasu i przeglądarki, a także może tworzyć zakodowane wersje filmów na potrzeby zgodnego odtwarzania. Rozmiar tych danych zależy od liczby zasobów, wybranej rozdzielczości, ustawień jakości oraz długości filmów i używanych kodeków. Są one dodatkiem do oryginalnych plików, nawet jeśli użytkownicy nigdy nie pobierają ich bezpośrednio.
Pomiar przeprowadzony przez społeczność dla zewnętrznej biblioteki o rozmiarze 772 GiB wykazał około 18 GiB miniatur i 65 GiB zakodowanych filmów. Ta obserwacja, wynosząca łącznie około 83 GiB, jest użytecznym przykładem obliczeniowym, a nie uniwersalnym wskaźnikiem planistycznym, ponieważ proporcje zdjęć do filmów i ustawienia innej biblioteki mogą znacząco zmienić oba składniki.
Po zaimportowaniu reprezentatywnej próbki zawierającej rzeczywiste zdjęcia domowników, pliki RAW, krótkie klipy i długie filmy zapisz rozmiary katalogów miniatur oraz zakodowanych filmów. Oblicz osobno stosunek każdej kategorii plików pochodnych do liczby zasobów i do rozmiaru źródłowych danych. Wskaźniki oparte na liczbie zasobów i na liczbie bajtów odpowiadają na różne pytania dotyczące wzrostu.
Baza danych i dane wyszukiwania skalują się wraz z liczbą powiązań
Narzut bazy danych obejmuje rekordy zasobów, użytkowników, albumów, metadane, dane twarzy, reprezentacje wyszukiwania, indeksy i stan zadań. Mały obraz i duży film mogą tworzyć podobną liczbę niektórych rekordów, mimo znacznie różniących się rozmiarów źródłowych. Z tego powodu rozrost bazy danych jest silniej związany z liczbą encji i włączonymi funkcjami niż z pierwotną liczbą terabajtów.
Artykuł ZimaSpace o kopiach zapasowych Immich rozdziela niezbędne oryginały i stan bazy danych od ścieżek plików pochodnych, które można odtworzyć. To rozróżnienie ma znaczenie podczas prognozowania, ponieważ usunięcie plików pochodnych może tymczasowo zwolnić miejsce, natomiast utrata bazy danych zmienia powiązania, których nie da się odtworzyć na podstawie samych miniatur.
Zmierz rozmiar bazy danych przed zaimportowaniem znanej grupy zasobów i po nim, a następnie odnotuj, które funkcje przetwarzania zostały ukończone. Powtórz pomiar po zakończeniu pracy funkcji rozpoznawania twarzy i wyszukiwania. Nie ekstrapoluj danych z kolejki, która nie została jeszcze przetworzona, ponieważ pozorny narzut na zasób wzrośnie po zapisaniu kolejnych reprezentacji i powiązań.
Kopie zapasowe i pliki tymczasowe zmieniają minimalną wymaganą pojemność
Bieżąca suma nie uwzględnia miejsca potrzebnego podczas tworzenia kopii zapasowych, zrzutów baz danych, przygotowywania importów ani wymiany plików pochodnych. Podczas aktualizacji lub ponownego generowania stare i nowe pliki mogą współistnieć. Dysk dobrany dokładnie do zużycia w stanie ustabilizowanym może więc zawieść podczas zwykłych prac konserwacyjnych, nawet gdy roczny przyrost multimediów jest niewielki.
Artykuł o planowaniu pamięci opisuje przypadek, w którym Immich zapełnił wcześniej wolny dysk SSD przez oryginały, miniatury, metadane i zadania uczenia maszynowego. Szerszy wniosek jest taki, że rozrost aplikacji i kopie odzyskiwania konkurują o zapas operacyjny, dlatego ilość wolnego miejsca musi wystarczyć na najbardziej obciążający scenariusz konserwacji, a nie tylko na dzisiejszy stan bezczynności.
Traktuj retencję kopii zapasowych jako osobną pozycję, ponieważ kopie przechowywane poza hostem chronią przed innym rodzajem awarii. Zarezerwuj także zmierzony zapas roboczy wynikający z największego importu, testu ponownego kodowania lub aktualizacji. Większa ilość wolnego miejsca nie zawsze jest automatycznie lepsza, ale brak zmierzonego marginesu szczytowego sprawia, że awaria z powodu braku pojemności staje się przewidywalna.
Przygotuj arkusz narzutu właściwy dla danej biblioteki
Utwórz wiersze dla oryginałów, miniatur i podglądów, zakodowanych filmów, bazy danych, artefaktów uczenia maszynowego, lokalnych zrzutów kopii zapasowych oraz tymczasowego miejsca na szczytowe zużycie. Zmierz stan początkowy bez danych, a następnie zaimportuj reprezentatywną grupę zasobów. Poczekaj na opróżnienie kolejek i ponownie zapisz wartości dla każdego wiersza, zanim obliczysz różnice.
Dyskusja praktyków na temat rozmieszczenia danych na dyskach SSD i HDD rozróżnia generowane dane wrażliwe na opóźnienia od dużych zbiorów oryginałów. W kontekście planowania pojemności takie rozróżnienie pozwala uwidocznić narzut szybkiej warstwy, nawet gdy oryginały znajdują się w innym miejscu; w przeciwnym razie duża suma na serwerze NAS może ukryć niemal pełny dysk SSD aplikacji.
Powtórz import grupy, aby uzyskać zakres zamiast pojedynczego wskaźnika. Prognozuj każdy wiersz według właściwego czynnika: liczby zasobów, liczby bajtów lub czasu trwania filmów, wzrostu liczby użytkowników i powiązań, liczby przechowywanych kopii albo szczytowego obciążenia podczas konserwacji. Planowany przyrost danych źródłowych dodaj dopiero po osobnym uwzględnieniu potrzeb plików pochodnych i odzyskiwania.
Polecane produkty
Centrum Technologii i Sztucznej Inteligencji
Więcej do przeczytania
Dlaczego Immich ponownie przetwarza istniejące dane po aktualizacji?
Immich może ponownie przetwarzać zasoby, gdy aktualizacja unieważni wcześniejsze wersje pochodne, metadane, modele lub stan zadań; powtarzająca się, niekończąca praca to osobna usterka.
Które zależności najczęściej wyznaczają rzeczywistą granicę wydajności Immich?
Immich jest ograniczony przez najwolniejszą zależność na każdej mierzonej ścieżce, dlatego przesyłanie, wyszukiwanie, przeglądanie i odtwarzanie mogą mieć różne limity.
Sieciowanie Immich: jak wykrywanie, DNS i routing zapewniają dostępność
Immich jest dostępny tylko wtedy, gdy wybór punktu końcowego, DNS, routing, NAT lub obsługa serwera proxy, TLS oraz odpowiedź aplikacji tworzą jedną prawidłową ścieżkę.
