Immich: wymagania RAM i miejsca na dysku

Ile pamięci RAM wymaga Immich?

Immich wymaga 6 GB pamięci RAM jako udokumentowanego minimum oraz 8 GB jako zalecanej wartości, przy 2 rdzeniach procesora w konfiguracji podstawowej i 4 dla komfortowego działania. Wartość ta obejmuje cały stos, ponieważ Immich składa się z czterech kontenerów, a nie z jednej aplikacji. Przeglądanie już zaimportowanej 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 z dokumentacji wymagań Immich na sierpień 2026 roku. Stanowią one zalecenie dotyczące doboru sprzętu, a nie weryfikację uruchomieniową oprogramowania. Immich uruchomi się przy mniejszej ilości pamięci. Na słabszym serwerze zmianie ulega to, które zadania w tle zostaną ukończone oraz jak import zachowa się w przypadku wyczerpania pamięci.

Istnieje jedno twarde ograniczenie. Immich w wersji 3 i nowszych wymaga procesora z instrukcjami x86-64-v2 na hostach amd64, co obejmuje większość jednostek sprzedawanych od około 2012 roku. Na starszym sprzęcie kontener nie uruchomi się, zamiast działać wolniej.

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 jednego kontenera działają dwa procesy robocze. api odpowiada na żądania z przeglądarki oraz aplikacji mobilnej. microservices zarządza kolejkami, w tym generowaniem miniatur i kodowaniem 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 obsługują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 pamięci. Ta sama strona wskazuje, że baza danych musi znajdować się na lokalnym nośniku SSD i nigdy na żadnym udziale sieciowym, ponieważ wyszukiwanie wektorów i indeksów to operacje małego, losowego odczytu, 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ą 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 najmniejsza z czterech usług, ponieważ przechowuje rekordy zadań, a nie dane zdjęć.

immich-machine-learning to usługa, która determinuje wymagania dotyczące rozmiaru planu. Ładuje ona modele do inteligentnego wyszukiwania, rozpoznawania 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 przerwa pięciominutowa, 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 gotowe 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 Compose, a nie jako pomiar zużycia zasobów przez Immich. Limit to górna granica. Nie rezerwuje on pamięci ani 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 udokumentowanego minimum wynoszącego 6 GB, więc 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, albumy, udostępnianie, kopie zapasowe z urządzeń mobilnych, miniatury oraz wyszukiwanie według daty, miejsca i nazwy pliku. Utracone zostaje wyszukiwanie według opisu, automatyczne grupowanie twarzy oraz rozpoznawanie tekstu na zdjęciach.

Suma czterech limitów wynosi około 1.7 GB, co pozostawia systemowi gospodarzowi około 300 MB. Warto zauważyć, że 768 MB dla bazy danych jest wartością poniżej udokumentowanego minimum 2 GB. Jest to kompromis wymuszony przez 2 GB RAM i dlatego Postgres jest usługą najbardziej narażoną na zakończenie przez system.

W pierwszej kolejności zawodzi import, a nie przeglądanie. Biblioteka zawierająca kilkadziesiąt tysięcy zdjęć przegląda się poprawnie po zakończeniu indeksowania, ponieważ wyświetlenie strony to zapytanie o metadane i 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) każdej ciężkiej kolejki na 1 i dodać plik swap.

Serwer 4 GB: włączone uczenie maszynowe, jedno zadanie jednocześnie

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 nawet ponad dobę. Jest to ograniczenie procesora, a nie pamięci, więc zwiększenie ilości RAM nie przyspieszy tego procesu.

W tym przypadku najpierw zawodzi kontener uczenia maszynowego podczas pierwszego masowego skanowania. Bez limitu jego zużycie rośnie w tym samym czasie co zadanie transkodowania, a jądro systemu kończy proces, który zajmuje więcej pamięci. W docker ps -a widoczny jest błąd Exited (137) oraz restart kontenera, a kolejka zadań pozostaje w tyle bardziej niż podczas ostatniego sprawdzenia.

Serwer 8 GB: udokumentowane zalecenie

8 GB RAM 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 zasobów działają 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.

Limity należy ustawić mimo wszystko. Na serwerze z zapasem zasobów limity zapobiegają sytuacji, w której jedna niekontrolowana kolejka powoduje awarię bazy danych. Jeśli porównujesz koszty z mniejszymi opcjami, rzeczywisty koszt 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 jest najskuteczniejszą zmianą, jaką można wprowadzić. 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 sekcji Administration, Settings, Machine Learning Settings w interfejsie WWW, kliknij Add URL i wprowadź http://<host>:3003. Utrzymuj tę samą wersję na obu hostach, ponieważ dokumentacja Immich ostrzega, że niezgodność wersji między nimi powoduje błędy i niestabilność.

Ten port przesyła zdjęcia do drugiej maszyny w sposób niezaszyfrowany, 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 idea rezydentnego kontenera z modelem, jest to również uzasadniony powód, aby porównać różnice między PhotoPrism a Immich w zakresie procesów działających w spoczynku przed podjęciem ostatecznej decyzji o rozmiarze planu.

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 wykorzystuje procesor, a nie pamięć RAM

Dodanie pamięci RAM nie przyspieszy transkodowania. Immich wykonuje transkodowanie przy użyciu FFmpeg, a na standardowym serwerze VPS każda klatka jest dekodowana i kodowana przez procesor. Nawet w przypadku dostępności akceleracji sprzętowej, dokumentacja Immich wskazuje, że przyspieszone jest tylko kodowanie, więc procesor nadal odpowiada za programowe dekodowanie i mapowanie tonów.

Akceleracja sprzętowa wymaga dodatkowego pliku hwaccel.transcoding.yml Compose oraz urządzenia przekazanego do kontenera, wykorzystującego NVENC, Quick Sync, RKMPP lub VAAPI. Większość planów VPS nie oferuje takich zasobów, dlatego należy polegać na procesorze.

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 zakłóci pracy systemu.

Dlaczego thrashing swapu wygląda jak zawieszenie systemu

Jest to błąd najczęściej błędnie interpretowany 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 zatrzymuje się, 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ł zakończony sygnałem 9. Wartość 137 to suma 128 i 9. Wartość OOMKilled równa true potwierdza, że przyczyną było wyczerpanie pamięci, a nie awaria aplikacji.

Z aktywnym swapem nic nie jest zabijane i nie pojawiają się błędy. Jądro zaczyna przenosić strony pamięci na dysk, import zwalnia o rząd wielkości, a interfejs webowy przestaje odpowiadać w przewidzianym czasie. Każdy kontener działa. Każda kontrola stanu (health check) może nadal przechodzić pomyślnie. Wygląda to jak zawieszenie systemu, więc użytkownicy restartują maszynę, co powoduje utratę postępu kolejki i nie rozwiązuje problemu.

free -m
vmstat 1 5

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

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

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ę. Zmniejsz współbieżność zadań do 1, ogranicz 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 pamięci RAM?

Tak, pod warunkiem zakomentowania 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. Zachowasz funkcje przesyłania, albumów, udostępniania, kopii zapasowych z urządzeń mobilnych oraz wyszukiwania według daty, miejsca i nazwy pliku. Utracisz wyszukiwanie według opisu, automatyczne grupowanie twarzy oraz rozpoznawanie tekstu na zdjęciach. Dodaj 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 objawiają się w przeglądarce w ten sam sposób. Albo kontener został ubity z powodu braku pamięci (w takim przypadku docker ps -a pokazuje Exited (137), a kontener został już zrestartowany), albo host korzysta z pamięci swap (wtedy wszystkie kontenery działają, ale całość pracuje 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 suma 128 oraz sygnału 9, co oznacza, że proces został zakończony sygnałem SIGKILL. W praktyce oznacza to przekroczenie limitu pamięci – albo limitu samego kontenera, albo wyczerpanie pamięci na hoście. Sprawdź 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żą, czy przyczyną był limit kontenera, czy całego hosta. Kontener uczenia maszynowego jest zazwyczaj pierwszą ofiarą, ponieważ jest to zazwyczaj najbardziej zasobożerny proces.

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

Zaplanuj miejsce na oryginalny plik oraz dodatkowe 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 zmierz średni rozmiar swoich plików, zamiast stosować mnożnik do liczby zdjęć.

Czy do Immich potrzebuję karty graficznej (GPU)?

Nie. Każdy element Immich działa na procesorze (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 w oparciu o CPU ustaw liczbę wątków transkodowania na 1 lub 2, użyj modelu twarzy buffalo_s i pozwól, aby pierwszy masowy import trwał przez noc.