Dlaczego podczas dużych importów z urządzeń mobilnych rośnie ilość miejsca zajmowanego przez miniatury i dane ML w Immich?

Duże importy zwykle zwiększają zajętość miejsca w Immich, ponieważ każdy zasób generuje pliki pochodne i rekordy w bazie danych, podczas gdy pobrane modele zajmują osobną pamięć podręczną.

Rodzina przenosi wieloletnie zdjęcia z telefonów na domowy serwer NAS, a następnie obserwuje, jak ilość wolnego miejsca nadal się zmniejsza po zakończeniu licznika przesyłania. Może to oznaczać prawidłowe przetwarzanie w tle, a nie kolejną kopię każdego oryginału. Istotne jest rozróżnienie między plikami generowanymi dla poszczególnych zasobów, współdzielonymi plikami modeli a wzrostem, który trwa bez odpowiadającego mu zwiększenia liczby ukończonych zadań.

Jedno przesłanie tworzy kilka rodzajów danych

Przesłany oryginał to tylko jedna część wynikowej biblioteki. Immich przygotowuje także mniejsze reprezentacje do przeglądania oraz przechowuje informacje łączące zasób z właścicielem, datami, albumami i funkcjami wyszukiwania. Dane te obsługują różne żądania, dlatego zakończenie transferu sieciowego nie oznacza, że wszystkie kolejne operacje zapisu zostały już ukończone.

Rozdzielenie plików multimedialnych i rekordów bazy danych ma tutaj znaczenie: metadane aplikacji oraz wektory wyszukiwania znajdują się w PostgreSQL, a nie jako dodatkowe zdjęcia w pełnej rozdzielczości. Usługa uczenia maszynowego oblicza wyniki wykorzystywane przez aplikację. Traktowanie wszystkich dodatkowych bajtów jako zduplikowanych oryginałów prowadzi więc do błędnego wyjaśnienia zwykłego wzrostu po imporcie.

Wyobraźmy sobie telefon, który kończy transfer, podczas gdy serwer nadal przetwarza zaakceptowaną partię. Oryginały mogą już być stabilnie zapisane na dysku, ale podglądy i rekordy możliwe do przeszukiwania mogą nadal się pojawiać. Porównuj pomiary zajętości miejsca na tym samym etapie przetwarzania; partia właśnie przesłana i partia w pełni przetworzona nie są równoważnymi próbkami.

Liczba zasobów wyjaśnia więcej niż gigabajty oryginałów

Przy planowaniu miejsca na miniatury liczba i typ zasobów często wyjaśniają więcej niż łączna liczba gigabajtów oryginałów. Tysiąc małych zdjęć i kilka długich nagrań wideo może zajmować podobną ilość miejsca źródłowego, ale wymagać zupełnie różnej liczby pochodnych obrazów. Wymiary podglądów, ustawienia kompresji i zawartość obrazu dodatkowo wpływają na liczbę wygenerowanych bajtów.

Opublikowane pomiary miniatur pokazują tę zmienność: jeden użytkownik zgłosił 6,3 GB dla biblioteki o rozmiarze 70 GB, a inny około 370 GB dla 2 TB zdjęć i nagrań wideo. Są to indywidualne konfiguracje, a nie porównywalne, kontrolowane testy porównawcze. Pokazują, dlaczego przyjęcie jednej wartości procentowej z forum może błędnie opisywać inną gospodarstwo domowe.

Przykładowe obliczenie: 100 000 zasobów, dla których zmierzone pochodne obrazy mają średnio 250 KB, wymaga około 25 GB w jednostkach dziesiętnych. Przy 500 KB na zasób ta sama liczba wymaga około 50 GB. Żadna z tych wartości nie obejmuje oryginałów, zakodowanych nagrań wideo, wzrostu bazy danych ani kopii zapasowych; przykład pokazuje zależność od liczby zasobów, a nie zaleca uniwersalnego zapasu miejsca.

Pliki modeli i rekordy wyszukiwania rosną w różny sposób

Pamięć podręczna modeli zawiera wielokrotnie używane pliki modeli, natomiast wektory wyszukiwania reprezentują poszczególne zasoby. Przy stałym zestawie pobranych modeli dodanie większej liczby zdjęć nie wymaga pobierania od nowa pełnego modelu dla każdego obrazu. Dodanie lub zmiana modeli może natomiast zwiększać zajętość pamięci podręcznej skokowo, niezależnie od liczby przesłanych zdjęć.

Przenośne wdrożenie opisane przez autora przechowuje bibliotekę, pamięć podręczną modeli i dane PostgreSQL w oddzielnych trwałych katalogach. Taki podział pozwala obserwować każdą funkcję zajmowanego miejsca bez zakładania, że jeden łączny rozmiar Dockera reprezentuje dane wynikowe uczenia maszynowego. Jest to przykład układu ze starszej wersji, a nie aktualna instrukcja instalacji ani zalecany zestaw tagów kontenerów.

Rozróżniaj także zajętość dysku od załadowanej pamięci. Model może pozostać na dysku, gdy jego kopia w pamięci zostanie zwolniona, a buforowanie systemu plików może zwiększyć raportowane zużycie pamięci bez tworzenia większej liczby trwałych plików. Aby wyjaśnić skok, najpierw ustal katalog odpowiedzialny za wzrost i zmienione ustawienie, zanim wyciągniesz wnioski na podstawie nazwy kontenera.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Kiedy zwykły wzrost przestaje być wystarczającym wyjaśnieniem

Normalny wzrost liczby plików pochodnych ma ograniczone wejście: stałą partię oryginałów przetwarzaną przy niezmienionych ustawieniach. Nie powinien tworzyć bez końca rosnącej populacji nowych zasobów źródłowych. Jeśli liczba zasobów nadal rośnie po zakończeniu wszystkich zamierzonych importów, wyjaśnienie musi obejmować ścieżki wykrywania, wielokrotne importowanie lub inne źródło nowych zadań.

Potwierdzony przypadek rekurencyjnego skanowania obejmował lokalizację przesyłania Immich dodaną do biblioteki zewnętrznej. Wygenerowane miniatury były następnie traktowane jako nowe obrazy, co tworzyło kolejne pochodne pochodnych. Jest to inny mechanizm przyczynowy niż duży import z telefonu i nie należy używać go jako dowodu, że każda duża biblioteka naturalnie rozmnaża się bez ograniczeń.

Nietypowy wzrost w zapisywalnej warstwie kontenera to kolejna odrębna kategoria. Raport z 2026 roku opisywał gromadzenie się setek gigabajtów w tej warstwie, ale dyskusja nie ustaliła uniwersalnej przyczyny. Nie usuwaj plików bazy danych, multimediów ani wewnętrznych danych Dockera tylko po to, aby wykres wyglądał normalnie. Najpierw ustal, która funkcja rośnie i czy ukończone zadania to wyjaśniają.

Mierz import według funkcji zajmowanego miejsca

Przed reprezentatywnym importem zapisz liczbę i rozmiar oryginalnych zasobów, rozmiar miniatur i podglądów, rozmiar zakodowanych nagrań wideo, rozmiar bazy danych, rozmiar pamięci podręcznej modeli oraz ewentualny wzrost danych tymczasowych lub dzienników. Powtórz pomiar po zakończeniu przez tę samą partię wszystkich włączonych zadań przetwarzania. Nie zmieniaj ustawień multimediów, aby różnice można było przypisać importowi, a nie jednoczesnej zmianie konfiguracji.

Rozliczenie zajętości miejsca nie zastępuje rodzinnego planu tworzenia kopii zapasowych. Użyteczna usługa zdjęciowa wymaga zabezpieczonych oryginałów oraz stanu aplikacji potrzebnego do odtworzenia biblioteki; sam katalog miniatur nie może zachować rodzinnej kolekcji. Chroń te dane niezależnie od pomiaru danych, które można ponownie wygenerować, aby eksperyment oszczędzający miejsce nie stał się jedyną kopią wspomnienia.

Uznaj wynik za wyjaśniony, gdy zmierzone sumy według funkcji odpowiadają dodatkowym bajtom i nie pojawiają się nadal żadne nieoczekiwane zasoby źródłowe. Zbadaj inny mechanizm, gdy stan modeli pozostaje niezmieniony, ale pamięć podręczna lub zapisywalna warstwa nadal rośnie, albo gdy pliki pochodne ponownie trafiają do wykrywania. Ten test wyjaśnia przyczynę wzrostu zajętości miejsca, nie zamieniając wyjaśnienia w destrukcyjną procedurę czyszczenia.