Immich: wymagania RAM i miejsca na dysku

Ile pamięci RAM wymaga Immich?

Immich wymaga 6 GB pamięci RAM (pamięci o dostępie swobodnym) jako udokumentowanego minimum oraz 8 GB jako wartości zalecanej, przy 2 rdzeniach procesora w konfiguracji podstawowej oraz 4 dla komfortowej instalacji. Wartość ta obejmuje cały stos, ponieważ Immich składa się z czterech kontenerów, a nie z jednej aplikacji. Przeglądanie zaimportowanej już biblioteki nie jest zasobożerne. Pamięć jest zużywana głównie podczas importu, a jej największa część przypada na jeden kontener, który można wyłączyć.

[
  {
    "label": "Documented minimum",
    "ram_gb": 6,
    "cpu_cores": 2
  },
  {
    "label": "Documented recommended",
    "ram_gb": 8,
    "cpu_cores": 4
  }
]

Są to opublikowane wartości ze strony wymagań Immich według stanu na październik 2026. Stanowią one zalecenie dotyczące doboru rozmiaru, a nie mechanizm sprawdzający poprawność działania oprogramowania przy starcie. Immich uruchomi się przy mniejszej ilości pamięci. Na mniejszym serwerze zmienia się to, które zadania w tle zostaną ukończone oraz jak import zachowa się w przypadku wyczerpania pamięci.

Istnieje jedno rzeczywiste, twarde ograniczenie. Od wersji 3 kontener uczenia maszynowego na hostach amd64 wymaga procesora z instrukcjami x86-64-v2, co obejmuje większość jednostek sprzedawanych mniej więcej od 2012 roku. Wymaganie to dotyczy wspomnianego kontenera, a nie całego serwera, więc na starszym sprzęcie można wyłączyć uczenie maszynowe, uruchomić je na innej maszynie zgodnie z poniższym opisem lub pozostać przy wersji v2.7.5, którą dokumentacja Immich wskazuje jako ostatnią kompatybilną.

Jeśli instalacja jest dopiero przed Tobą, zacznij od pełnej instalacji Immich na VPS z użyciem Docker Compose, a następnie wróć tutaj, aby dobrać odpowiednie parametry serwera.

Gdzie trafia pamięć: cztery kontenery

Oficjalny plik Compose uruchamia cztery usługi. Każda z nich ma inną charakterystykę zużycia pamięci, więc jedna łączna wartość nie oddaje rzeczywistego stanu.

immich-server obsługuje interfejs WWW oraz API, a także uruchamia procesy robocze w tle. Wewnątrz tego pojedynczego kontenera działają dwa procesy robocze. api odpowiada na żądania z przeglądarki oraz aplikacji mobilnej. microservices obsługuje kolejki, w tym generowanie miniatur i kodowanie wideo. Zmienne IMMICH_WORKERS_INCLUDE oraz IMMICH_WORKERS_EXCLUDE rozdzielają te dwa zadania na osobne kontenery, co pozwala na nałożenie limitu pamięci na bardziej obciążoną część bez ograniczania modułu serwującego zdjęcia.

database to obraz PostgreSQL 14 z wbudowanym rozszerzeniem VectorChord. Przechowuje on wszystkie metadane oraz jeden wektor wyszukiwania dla każdego zasobu. Dokumentacja Immich narzuca dla tej usługi jedyny sztywny wymóg w całym stosie: w przypadku stosowania limitów zasobów Docker, baza danych wymaga co najmniej 2 GB. Ta sama strona wskazuje, że baza danych powinna znajdować się na lokalnym nośniku SSD i nigdy na udziale sieciowym dowolnego typu. Wynika to z faktu, że wyszukiwanie wektorów i indeksów to operacje małych, losowych odczytów, a wolumen sieciowy zamienia każdą z nich w pełny cykl komunikacji. Jeśli wybór planu zależy od tego aspektu, różnica między pamięcią masową NVMe a SATA SSD na VPS ma tutaj większe znaczenie niż w jakimkolwiek innym elemencie tego stosu.

redis uruchamia obraz Valkey i przechowuje kolejki zadań. Jest to zdecydowanie najmniejszy z czterech kontenerów, ponieważ przechowuje rekordy zadań, a nie dane zdjęć.

immich-machine-learning to usługa decydująca o rozmiarze planu. Ładuje ona modele do inteligentnego wyszukiwania, wykrywania twarzy oraz rozpoznawania tekstu, a załadowany model pozostaje w pamięci. MACHINE_LEARNING_MODEL_TTL ma domyślną wartość 300, więc model jest usuwany z pamięci po pięciu minutach braku żądań i wczytywany ponownie z wolumenu /cache przy kolejnym wywołaniu. Podczas importu masowego nie występuje pięciominutowa przerwa, więc modele pozostają załadowane od pierwszego do ostatniego zasobu.

Co zmienia się podczas importu

Bezczynny Immich nie generuje obciążenia. Importy to moment, w którym małe serwery ulegają awarii, ponieważ przesłanie jednego zasobu uruchamia łańcuch zadań, a kilka kolejek działa jednocześnie.

Ekstrakcja metadanych odczytuje nagłówek pliku i jest procesem lekkim. Generowanie miniatur jest bardziej wymagające. Immich tworzy trzy miniatury dla każdego zasobu: rozmyty symbol zastępczy thumbhash, podgląd WebP oraz miniaturę JPEG, a dodatkowo po jednej miniaturze dla każdej wykrytej twarzy. Każde z tych zadań dekoduje obraz, a współbieżność zadań decyduje o tym, ile z nich jest dekodowanych jednocześnie. Współbieżność jest mnożnikiem, który zamienia niewielki koszt pojedynczego zadania w obciążenie całego serwera, dlatego FAQ Immich wskazuje ją jako pierwszy parametr do obniżenia na maszynach o ograniczonej wydajności. Ustaw współbieżność dla ciężkich kolejek na 1 w sekcji Administration, Settings, Job Settings.

Zasoby wideo wymagają transkodowania. Każde zadanie transkodowania to osobny proces FFmpeg z własnym przydziałem pamięci, który wykorzysta każdy dostępny wątek procesora, na który zezwolisz.

Inteligentne wyszukiwanie przesyła każdy nowy zasób do kontenera uczenia maszynowego w celu obliczenia jednego wektora osadzenia (embedding vector). Wykrywanie twarzy uruchamia drugi model na tym samym obrazie. Podczas pierwszego importu istniejącej biblioteki zdjęć obie te kolejki przetwarzają każdy posiadany zasób przez wiele godzin. Jest to najbardziej krytyczny moment dla zużycia pamięci w całej instalacji, który występuje tylko raz.

Dlaczego rozpoznawanie twarzy i obiektów wymaga najwięcej pamięci RAM

Obsługa twarzy składa się z dwóch zadań. Wykrywanie twarzy uruchamia model w kontenerze uczenia maszynowego i wyznacza ramki. Rozpoznawanie twarzy grupuje następnie te wykrycia w osoby, a ten krok odpytuje indeks wektorowy w Postgres. Duża biblioteka obciąża zatem naprzemiennie obie usługi: kontener modelu podczas wykrywania oraz bazę danych podczas grupowania.

Cztery ustawienia zmieniają zawartość pamięci kontenera uczenia maszynowego.

• Model twarzy. Immich domyślnie dostarcza buffalo_l, a FAQ zaleca buffalo_s na małym serwerze. Jest to mniejszy model, więc zajmuje mniej pamięci i działa szybciej, kosztem dokładności w przypadku małych lub ustawionych bokiem twarzy.
• Liczba procesów roboczych (worker count). MACHINE_LEARNING_WORKERS domyślnie wynosi 1. Każdy proces roboczy jest osobnym procesem, który ładuje własną kopię modeli, więc zwiększenie tej wartości do 2 mniej więcej podwaja pamięć rezydentną modeli. Pozostaw wartość 1, chyba że dysponujesz nadmiarem pamięci RAM.
• Rozmiar partii (batch size). MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION ogranicza liczbę twarzy przetwarzanych jednocześnie. Partia jest przechowywana w pamięci w całości, więc zdjęcie grupowe z czterdziestoma twarzami kosztuje więcej niż portret.
• Typy modeli, które są uruchamiane. Inteligentne wyszukiwanie, wykrywanie twarzy i rozpoznawanie tekstu ładują własne modele. Wyłączenie nieużywanych funkcji w sekcji Administration, Settings, Machine Learning Settings trwale zwalnia zajmowaną przez nie pamięć, a nie tylko pomiędzy importami.

Istnieje również MACHINE_LEARNING_MODEL_ARENA, udokumentowane jako wstępna alokacja pamięci CPU w celu uniknięcia fragmentacji, włączone domyślnie. Zmieniaj je jako ostatnie. Jego wpływ zależy od zastosowanego alokatora pamięci, więc jedynym rzetelnym sposobem oceny jest monitorowanie docker stats przed i po zmianie.

Trzy sprawdzone profile: 2 GB, 4 GB i 8 GB

[
  {
    "label": "2 GB VPS",
    "server_limit_mb": 768,
    "db_limit_mb": 768,
    "ml_limit_mb": 0,
    "redis_limit_mb": 128,
    "notes": "machine learning container removed"
  },
  {
    "label": "4 GB VPS",
    "server_limit_mb": 1024,
    "db_limit_mb": 1280,
    "ml_limit_mb": 1024,
    "redis_limit_mb": 192,
    "notes": "machine learning on, job concurrency 1, buffalo_s"
  },
  {
    "label": "8 GB VPS",
    "server_limit_mb": 2048,
    "db_limit_mb": 2048,
    "ml_limit_mb": 2560,
    "redis_limit_mb": 256,
    "notes": "everything on at default settings"
  }
]

Należy traktować te wartości jako limity do wpisania w pliku Compose, a nie jako pomiar zużycia zasobów przez Immich. Limit to górna granica. Nie rezerwuje on pamięci i nie zmniejsza rozmiaru usługi. Określa on, którą usługę jądro systemu zakończy w przypadku wyczerpania pamięci RAM – jest to decyzja, którą lepiej podjąć samodzielnie, niż pozostawiać ją algorytmom jądra.

Serwer 2 GB: usunięcie kontenera uczenia maszynowego

2 GB to wartość poniżej dokumentowanego minimum wynoszącego 6 GB, dlatego jest to rozwiązanie kompromisowe. Należy zakomentować całą usługę immich-machine-learning w pliku docker-compose.yml lub pozostawić ją uruchomioną i wyłączyć wszystkie modele w sekcji Administration, Settings, Machine Learning Settings. Usunięcie kontenera jest skuteczniejszym rozwiązaniem, ponieważ wyłączony model nadal utrzymuje proces Python w pamięci.

Zachowane zostają funkcje przesyłania, albumów, udostępniania, kopii zapasowych z urządzeń mobilnych, miniatur oraz wyszukiwania według daty, miejsca i nazwy pliku. Utracone zostają funkcje wyszukiwania według opisu, automatycznego grupowania twarzy oraz rozpoznawania tekstu na zdjęciach.

Cztery limity sumują się do około 1.7 GB, co pozostawia systemowi operacyjnemu około 300 MB. Należy zauważyć, że 768 MB dla bazy danych jest wartością poniżej dokumentowanego minimum 2 GB. Jest to dokładnie ten kompromis, który wymusza konfiguracja 2 GB i dlatego Postgres jest usługą najbardziej narażoną na zakończenie przez system.

Jako pierwszy zawodzi proces importu, a nie przeglądanie. Biblioteka licząca kilkadziesiąt tysięcy zdjęć przegląda się poprawnie, ponieważ wyświetlenie strony to zapytanie o metadane oraz odczyt pliku. Import dużej liczby plików wideo na tym samym serwerze spowoduje użycie swapu, ponieważ transkodowanie i kolejka miniatur wymagają pamięci w tym samym momencie. Należy ustawić współbieżność (concurrency) wszystkich ciężkich zadań na 1 i dodać plik wymiany (swap file).

Serwer 4 GB: uczenie maszynowe włączone, jedno zadanie naraz

4 GB to najmniejszy rozmiar, przy którym warto włączyć rozpoznawanie twarzy i obiektów. Należy ograniczyć kontener uczenia maszynowego do 0 MB, przełączyć rozpoznawanie twarzy na buffalo_s oraz ustawić współbieżność zadań na 1 dla generowania miniatur, wykrywania twarzy i inteligentnego wyszukiwania.

Pierwsze skanowanie istniejącej biblioteki będzie trwało wiele godzin, a w przypadku dużej biblioteki – ponad dobę. Jest to ograniczenie wynikające z wydajności CPU, a nie pamięci, więc zwiększenie ilości RAM nie przyspieszy tego procesu.

W tym przypadku najczęściej zawodzi kontener uczenia maszynowego podczas pierwszego masowego skanowania. Bez limitu jego zużycie pamięci rośnie w tym samym czasie co zadanie transkodowania, a jądro systemu kończy proces, który zajmuje więcej pamięci. Ponieważ kontener restartuje się w ciągu kilku sekund, docker ps -a pokazuje go jako Up z czasem pracy znacznie krótszym niż pozostałe kontenery, zamiast Exited (137), a kolejka zadań pozostaje w tyle bardziej, niż wynikałoby to z ostatniej kontroli.

Serwer 8 GB: dokumentowana rekomendacja

8 GB z 4 rdzeniami odpowiada zaleceniom Immich, a wszystkie funkcje działają przy ustawieniach domyślnych: inteligentne wyszukiwanie, wykrywanie twarzy, rozpoznawanie tekstu i transkodowanie przy domyślnej współbieżności. Biblioteki przekraczające sto tysięcy elementów działają tutaj płynnie, a obciążenie przesuwa się z pamięci na szybkość dysku, ponieważ indeks wektorowy i zapytania o metadane są głównymi operacjami bazy danych.

Mimo to należy ustawić limity. Na serwerze z zapasem zasobów limity zapobiegają sytuacji, w której jedna przeciążona kolejka powoduje awarię bazy danych. Jeśli porównujesz to rozwiązanie z mniejszymi opcjami, ile faktycznie kosztuje VPS w zależności od ilości pamięci zazwyczaj sprawia, że plan 8 GB jest najtańszym sposobem na uniknięcie konieczności optymalizacji.

Ograniczanie pamięci dla usługi za pomocą limitów w Compose

Nie edytuj docker-compose.yml w tym celu. Ten plik jest zastępowany przy każdej aktualizacji przez wget. Limity należy umieścić w docker-compose.override.yml obok niego, który docker compose scala automatycznie.

services:
  immich-server:
    deploy:
      resources:
        limits:
          memory: 1024M
  immich-machine-learning:
    deploy:
      resources:
        limits:
          memory: 1024M
          cpus: '1.5'
  database:
    deploy:
      resources:
        limits:
          memory: 1280M
  redis:
    deploy:
      resources:
        limits:
          memory: 192M

docker compose up -d
docker stats --no-stream

docker stats powinien teraz wyświetlać limit w kolumnie MEM USAGE / LIMIT zamiast całkowitej pamięci hosta. Jeśli kolumna limitu nadal wskazuje pełną wielkość pamięci hosta, plik nadpisujący nie został wczytany: sprawdź nazwę pliku i uruchom docker compose config, aby zobaczyć scalony wynik.

Zbyt niski limit zmienia wolną usługę w niedziałającą, więc należy go zwiększyć, jeśli kontener wpada w pętlę restartów. Więcej informacji na temat mechaniki działania znajduje się w ustawianiu limitów pamięci dla usług w Docker Compose, w tym wyjaśnienie, dlaczego deploy działa poza Swarm w Compose v2.

Jak wyłączyć lub przenieść kontener uczenia maszynowego

Na małym serwerze przeniesienie tego kontenera w inne miejsce stanowi największą możliwą optymalizację. Immich wspiera uruchamianie go na innej maszynie. Utwórz poniższy plik na drugim hoście, którym może być komputer stacjonarny włączany tylko wieczorami:

name: immich_remote_ml
services:
  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    volumes:
      - model-cache:/cache
    restart: always
    ports:
      - 3003:3003
volumes:
  model-cache:

docker compose up -d
curl -s http://localhost:3003/ping

Następnie przejdź do Administration, Settings, Machine Learning Settings w interfejsie webowym, kliknij Add URL i wprowadź http://<host>:3003. Utrzymuj tę samą wersję na obu hostach, ponieważ dokumentacja Immich ostrzega, że rozbieżności wersji mogą powodować błędy i niestabilność.

Ten port przesyła zdjęcia do drugiej maszyny w formie niezaszyfrowanej, dlatego należy korzystać z sieci prywatnej lub uruchomić go przez tunel WireGuard między oboma hostami. Nigdy nie wystawiaj portu 3003 do Internetu.

Jeśli problemem jest sama obecność kontenera z modelem, warto porównać różnice w wymaganiach zasobów w spoczynku między PhotoPrism a Immich przed podjęciem ostatecznej decyzji o rozmiarze instalacji.

Ile miejsca na dysku wymaga biblioteka Immich?

Nie istnieje jeden uniwersalny mnożnik, ponieważ cztery różne elementy rosną w różnym tempie. Oto wyliczenia dla biblioteki zawierającej 50 000 zdjęć i 500 krótkich filmów.

[
  {
    "label": "Originals: 50,000 photos at 4 MB",
    "gb": 200
  },
  {
    "label": "Originals: 500 videos at 120 MB",
    "gb": 60
  },
  {
    "label": "Thumbnails and encoded video at 15%",
    "gb": 39
  },
  {
    "label": "Postgres database",
    "gb": 3
  },
  {
    "label": "Machine learning model cache",
    "gb": 2
  }
]

Wartości 200 GB dla zdjęć oraz 60 GB dla wideo są założeniami. Przed zakupem sprzętu należy podstawić własne średnie wartości, ponieważ to wideo determinuje ostateczny wynik: minuta nagrania z telefonu zajmuje więcej miejsca niż sto zdjęć.

find /srv/immich/upload -type f -printf '%s\n' \
  | awk '{n++; s+=$1} END {printf "%d files, %.1f MB average\n", n, s/n/1048576}'

Wiersz 39 GB to jedyny oficjalny wskaźnik podawany przez Immich: wygenerowane miniatury oraz transkodowane wideo zwiększają rozmiar biblioteki średnio o 10 do 20 procent. Jest to zakres, ponieważ zależy on od liczby plików wideo wymagających przekodowania w celu zapewnienia kompatybilności z przeglądarkami. Biblioteka składająca się z plików JPEG mieści się w dolnej granicy tego zakresu.

Baza danych zajmuje 3 GB i jest to koszt zbliżony do stałego. Dokumentacja Immich wskazuje, że pliki bazy danych zajmują zazwyczaj od 1 do 3 GB, ponieważ przechowują one metadane i wektory wyszukiwania, a nie dane obrazu. Pamięć podręczna modeli zajmuje 2 GB i rośnie w przypadku aktywacji kilku modeli lub testowania różnych wariantów. FAQ wskazuje na ten wolumen jako na istotny czynnik zużycia miejsca właśnie z tego powodu.

Pięć wierszy sumuje się do nieco ponad 300 GB, więc wolumen 500 GB zapewnia przestrzeń na rozwój, podczas gdy 250 GB jest niewystarczające. Podział miejsca można monitorować za pomocą:

grep UPLOAD_LOCATION .env
du -sh /srv/immich/*

Sześć folderów znajduje się w UPLOAD_LOCATION. upload oraz library przechowują oryginały, thumbs zawiera podglądy i miniatury twarzy, encoded-video przechowuje przekodowane kopie, profile zawiera awatary, a backups przechowuje automatyczne zrzuty bazy danych. Tylko upload, library oraz profile są niezastąpione, ponieważ cała reszta może zostać z nich odtworzona.

Dwie kwestie są często zaskakujące. Usunięte zasoby trafiają najpierw do kosza i zajmują miejsce do momentu jego opróżnienia, więc duże porządki nie zwalniają przestrzeni w dniu ich wykonania. Zrzut bazy danych zawiera wyłącznie metadane, więc jest bezużyteczny bez plików źródłowych:

docker exec -t immich_postgres pg_dump --clean --if-exists \
  --dbname=immich --username=postgres | gzip > /srv/backups/immich-dump.sql.gz

Należy to połączyć z kopią plików źródłowych na poziomie systemu plików w lokalizacji poza serwerem, do czego służą kopie zapasowe restic z VPS do pamięci zewnętrznej.

Transkodowanie jest ograniczone przez CPU, a nie RAM

Dodanie pamięci RAM nie przyspieszy transkodowania. Immich wykonuje transkodowanie przy użyciu FFmpeg, a na standardowym VPS każda klatka jest dekodowana i kodowana przez procesor. Każdy proces FFmpeg przechowuje bufory zdekodowanych klatek w pamięci, dlatego sekcja importu uwzględnia transkodowanie jako koszt pamięci, jednak jego szybkość zależy od CPU. Nawet jeśli dostępna jest akceleracja sprzętowa, dokumentacja Immich wskazuje, że domyślnie przyspieszane jest tylko kodowanie, więc CPU nadal odpowiada za dekodowanie i mapowanie tonów, chyba że włączone zostanie również dekodowanie sprzętowe.

Akceleracja sprzętowa wymaga dodatkowego pliku hwaccel.transcoding.yml Compose oraz urządzenia przekazanego do kontenera przy użyciu NVENC, Quick Sync, RKMPP lub VAAPI. Większość planów VPS nie zapewnia takich zasobów, dlatego należy planować wydajność w oparciu o CPU.

Praktycznym ustawieniem jest liczba wątków. W sekcji Administration, Settings, Video Transcoding Settings wartość 0 oznacza wykorzystanie wszystkich rdzeni, co sprawia, że jeden film może zawiesić interfejs webowy na planie z 2 rdzeniami. Należy ustawić tam wartość 1 lub 2, zgodnie z zaleceniami FAQ Immich, dzięki czemu transkodowanie stanie się wolniejsze, ale nie będzie zakłócać pracy systemu.

Dlaczego thrashing swapu wygląda jak zawieszenie systemu

Jest to awaria najczęściej błędnie interpretowana przez użytkowników. Gdy Immich wyczerpuje pamięć RAM, występują dwa scenariusze, z których tylko jeden wygląda na awarię.

Bez partycji swap jądro systemu zabija proces. Kontener restartuje się w ciągu kilku sekund, więc z perspektywy przeglądarki kolejka zadań po prostu się zatrzymuje, a następnie wznawia. Dowód znajduje się w docker ps -a:

docker ps -a --filter name=immich
docker inspect immich_machine_learning | grep -i oomkilled
sudo dmesg -T | grep -i -E 'out of memory|oom-kill'

Exited (137) oznacza, że proces został zabity sygnałem 9. Wartość 137 to suma 128 i 9. Ten status widoczny jest tylko wtedy, gdy kontener jest zatrzymany. Gdy polityka restartu przywróci go do działania, docker ps -a pokaże status Up, a wskazówką będzie czas pracy (uptime) znacznie krótszy niż w przypadku innych kontenerów Immich. Sam sygnał 9 nie dowodzi problemów z pamięcią, ponieważ Docker wysyła go również, gdy standardowe zatrzymanie przekroczy limit czasu. Wartość OOMKilled równa true potwierdza, że proces został zabity z powodu braku pamięci, a po restarcie kontenera wiarygodnym źródłem informacji są linie oom-kill z polecenia dmesg.

Z włączonym swapem żaden proces nie jest zabijany i nie występują błędy. Jądro zaczyna przenosić strony pamięci na dysk, import zwalnia o rząd wielkości, a interfejs webowy przestaje odpowiadać w standardowym czasie oczekiwania. Każdy kontener działa. Każdy test stanu (health check) może nadal przechodzić pomyślnie. Wygląda to jak zawieszenie systemu, więc użytkownicy w tym momencie restartują maszynę, co powoduje utratę postępu kolejki i niczego nie zmienia.

free -m
vmstat 1 5

Utrzymujące się niezerowe wartości w kolumnach si oraz so narzędzia vmstat oznaczają, że maszyna nieustannie odczytuje i zapisuje dane w swapie, co jest definicją zjawiska thrashing. W tym samym czasie wiersz free -m dla użycia Swap będzie stale rosnąć.

Na maszynach z 2 GB lub 4 GB pamięci RAM należy dodać swap, ponieważ wolny import, który można zdiagnozować, jest lepszy niż zabity kontener, którego nie można zbadać:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Następnie należy usunąć przyczynę problemu. Należy zmniejszyć współbieżność zadań do 1, ograniczyć zasoby dla kontenera uczenia maszynowego lub przenieść go na inny host. Swap daje czas na wykonanie tych czynności. Sam w sobie nie jest rozwiązaniem problemu.

FAQ

Czy mogę uruchomić Immich na VPS z 2 GB RAM?

Tak, pod warunkiem wykomentowania usługi immich-machine-learning w pliku docker-compose.yml oraz ustawienia współbieżności zadań na 1. Jest to wartość poniżej udokumentowanego minimum 6 GB, więc należy traktować to jako świadomy kompromis. Zachowane zostają funkcje przesyłania, albumów, udostępniania, kopii zapasowych z urządzeń mobilnych oraz wyszukiwania według daty, miejsca i nazwy pliku. Utracone zostają: wyszukiwanie według opisu, automatyczne grupowanie twarzy oraz rozpoznawanie tekstu na zdjęciach. Należy dodać plik wymiany (swap) o rozmiarze 2 GB, aby nagły wzrost obciążenia podczas importu spowolnił serwer, zamiast powodować ubicie kontenera przez system.

Dlaczego import w Immich zatrzymuje się bez komunikatu o błędzie?

Dwie różne przyczyny dają identyczne objawy w przeglądarce. Albo kontener został ubity z powodu braku pamięci i zdążył się zrestartować – w takim przypadku docker ps -a pokaże go jako Up z podejrzanie krótkim czasem działania (Exited (137) pojawi się tylko, jeśli sprawdzisz stan w momencie, gdy kontener jest zatrzymany) – albo host korzysta ze swapu, przez co wszystkie kontenery działają, ale bardzo wolno. Polecenie vmstat 1 5 pozwala je rozróżnić: utrzymujące się niezerowe wartości w kolumnach si oraz so oznaczają korzystanie ze swapu. W obu przypadkach należy zmniejszyć współbieżność zadań dla generowania miniatur, wykrywania twarzy oraz inteligentnego wyszukiwania.

Co oznacza kod wyjścia 137 w logach Immich?

Kod 137 to 128 plus sygnał 9, co oznacza, że proces został zakończony sygnałem SIGKILL. W przypadku Immich zazwyczaj wynika to z przekroczenia limitu pamięci – albo limitu samego kontenera, albo wyczerpania zasobów hosta – jednak sam kod nie jest na to bezpośrednim dowodem. Docker wysyła SIGKILL również wtedy, gdy kontener nie zatrzyma się w wyznaczonym czasie (domyślnie 10 sekund w systemach Linux). Należy sprawdzić to za pomocą docker inspect immich_machine_learning | grep -i oomkilled. Wartość true potwierdza, że jądro systemu zabiło proces z powodu braku pamięci, a free -m wraz z sudo dmesg -T | grep -i oom-kill wskaże, czy przyczyną był limit kontenera, czy całego hosta. Kontener z modelem uczenia maszynowego jest najczęstszą ofiarą, ponieważ zazwyczaj jest to największy proces.

Ile miejsca na dysku potrzebuje Immich na jedno zdjęcie?

Należy zaplanować miejsce na oryginalny plik plus 10 do 20 procent. Dokumentacja Immich wskazuje, że wygenerowane miniatury i transkodowane wideo zwiększają rozmiar biblioteki średnio o 10 do 20 procent, a sama baza danych zajmuje zazwyczaj od 1 do 3 GB nawet przy dużej bibliotece. To wideo decyduje o całkowitym zapotrzebowaniu, dlatego przed wyborem planu należy zmierzyć średni rozmiar własnych plików, zamiast stosować mnożnik do liczby zdjęć.

Czy do Immich potrzebuję GPU?

Nie. Każdy komponent Immich działa na CPU. Karta graficzna przyspiesza wnioskowanie modeli w kontenerze uczenia maszynowego oraz kodowanie wideo, ale żadna z tych funkcji nie jest wymagana. Większość planów VPS nie oferuje GPU. Na sprzęcie działającym wyłącznie na CPU należy ustawić liczbę wątków transkodowania na 1 lub 2, użyć modelu twarzy buffalo_s i pozwolić, aby pierwszy masowy import przebiegł w nocy.