Immich için ne kadar RAM ve disk gerekir?

Immich ne kadar RAM gerektirir?

Immich, belgelenmiş minimum değer olarak 6 GB RAM (rastgele erişimli bellek) ve önerilen değer olarak 8 GB RAM ister. Bu değerler, düşük seviyede 2 CPU çekirdeği ve rahat bir kurulum için 4 CPU çekirdeği içindir. Bu değer, Immich tek bir uygulama yerine dört container'dan oluştuğu için tüm yığını kapsar. Daha önce içe aktarılmış bir kitaplıkta gezinmek az kaynak tüketir. Bellek tüketimi içe aktarma sırasında oluşur ve bunun büyük bölümü kapatabileceğiniz tek bir container tarafından kullanılır.

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

Bunlar, Ağustos 2026 itibarıyla Immich gereksinimleri sayfasında yayımlanan değerlerdir. Bu değerler bir boyutlandırma önerisidir; yazılımın başlangıçta çalışıp çalışmayacağını denetleyen bir koşul değildir. Immich daha az kaynakla da başlar. Daha küçük bir sunucuda değişen şey, arka plan işlerinin hangilerinin tamamlanabildiği ve bellek tükendiğinde içe aktarma işleminin ne yaptığıdır.

Gerçek bir katı sınır vardır. Immich version 3 ve sonraki sürümler, amd64 host'larda x86-64-v2 CPU gerektirir. Bu gereksinim, yaklaşık 2012'den beri satılan işlemcilerin çoğunu kapsar. Daha eski donanımlarda container yavaş çalışmak yerine başlatılamaz.

Kurulum henüz yapılmadıysa Docker Compose ile VPS üzerinde tam Immich kurulumu bölümünden başlayıp sunucuyu boyutlandırmak için buraya dönülmelidir.

Bellek nereye gider: dört container

Resmi Compose dosyası dört servis başlatır. Her birinin bellek kullanım profili farklıdır. Bu nedenle toplam tek bir sayı, gerekli ayrıntıyı gizler.

immich-server web arayüzünü ve API'yi sunar. Ayrıca arka plan iş çalışanlarını da çalıştırır. Bu tek container içinde iki worker bulunur. api tarayıcıdan ve mobil uygulamadan gelen isteklere yanıt verir. microservices thumbnail oluşturma ve video kodlama dahil olmak üzere kuyrukları çalıştırır. IMMICH_WORKERS_INCLUDE ve IMMICH_WORKERS_EXCLUDE değişkenleri bu iki bileşeni ayrı container'lara böler. Böylece fotoğrafları sunan bileşene uygulanan bellek sınırını düşürmeden, daha fazla kaynak kullanan bileşene ayrı bir bellek sınırı verilebilir.

database, VectorChord extension yerleşik olarak gelen bir PostgreSQL 14 image'ıdır. Tüm metadata'yı ve her asset için bir search vector'ünü tutar. Immich belgeleri, stack içindeki tek açık alt sınırı bu servise uygular: Docker resource limit'leri kullanılıyorsa veritabanına en az 2 GB ayrılmalıdır. Aynı sayfada veritabanının local SSD storage üzerinde bulunması ve hiçbir tür network share üzerinde çalıştırılmaması gerektiği belirtilir. Bunun nedeni, vector ve index aramalarının küçük ve rastgele okumalardan oluşmasıdır. Network volume kullanıldığında bu okumaların her biri bir gidiş-dönüş işlemine dönüşür. Plan seçimi buna bağlıysa VPS üzerinde NVMe ve SATA SSD storage arasındaki fark, bu stack'in diğer bölümlerine kıyasla burada daha önemlidir.

redis Valkey image'ını çalıştırır ve job queue'larını tutar. Dört servis arasında açık ara en küçüğüdür. Bunun nedeni fotoğraf verileri yerine job kayıtlarını depolamasıdır.

immich-machine-learning plan boyutunu belirleyen servistir. Smart search, face detection ve text recognition için modelleri yükler. Yüklenen model bellekte tutulur. MACHINE_LEARNING_MODEL_TTL varsayılan olarak 300 değerini kullanır. Bu nedenle istek gelmeyen beş dakikanın ardından model bellekten kaldırılır ve sonraki istekte /cache volume'ünden yeniden okunur. Toplu import sırasında hiçbir zaman beş dakikalık boşluk oluşmaz. Bu nedenle modeller ilk asset'ten son asset'e kadar yüklü kalır.

İçe aktarma sırasında neler değişir

Boşta olan bir Immich sessizdir. Küçük sunucular genellikle içe aktarma sırasında zorlanır. Bunun nedeni, tek bir varlığın yüklenmesinin bir dizi işi kuyruğa eklemesi ve birden fazla kuyruğun aynı anda çalışmasıdır.

Metadata extraction, dosya başlığını okur ve hafif bir işlemdir. Thumbnail generation daha fazla kaynak tüketir. Immich her varlık için üç thumbnail çıktısı üretir: bulanık bir thumbhash yer tutucusu, bir WebP önizlemesi ve bir JPEG thumbnail. Ayrıca algılanan her yüz için bir thumbnail daha üretir. Bu işlerin her biri bir görüntünün kodunu çözer. Job concurrency değeri, aynı anda kaç görüntünün kodunun çözüleceğini belirler. Concurrency, iş başına düşük kaynak tüketimini sunucu genelinde yüksek tüketime dönüştüren çarpandır. Bu nedenle Immich FAQ, kısıtlı kaynaklara sahip bir makinede ilk olarak bu değerin düşürülmesini önerir. Administration, Settings, Job Settings altında ağır kuyrukların concurrency değerini 1 olarak ayarlayın.

Video varlıkları transcoding işlemi ekler. Her transcode işi, kendine ait memory alanı bulunan ayrı bir FFmpeg sürecidir. İzin verilen her CPU thread'ini kullanır.

Smart search, her yeni varlığı bir embedding vector hesaplamak üzere machine learning container'ına gönderir. Face detection aynı görüntü üzerinde ikinci bir model çalıştırır. Mevcut bir fotoğraf kitaplığının ilk içe aktarımında bu iki kuyruk, sahip olduğunuz tüm varlıklar üzerinde saatler boyunca çalışır. Bu, kurulumun tamamında memory kullanımının en yüksek olduğu andır ve yalnızca bir kez gerçekleşir.

Yüz ve nesne tanımanın neden en fazla RAM'e ihtiyaç duyduğu

Yüz işleme iki aşamadan oluşur. Yüz algılama, machine learning container içinde bir model çalıştırır ve yüzleri kutularla belirler. Yüz tanıma ise bu algılamaları kişilerle eşleştirir ve bu aşamada Postgres içindeki vector index sorgulanır. Bu nedenle büyük bir kitaplık her iki servisi de sırayla zorlar: algılama sırasında model container, gruplama sırasında ise veritabanı.

Dört ayar, machine learning container içinde tutulan verileri değiştirir.

• Yüz modeli. Immich varsayılan olarak buffalo_l ile birlikte gelir ve FAQ küçük bir sunucuda buffalo_s kullanılmasını önerir. Bu model daha küçüktür; dolayısıyla daha az bellek kullanır ve daha hızlı çalışır. Bunun karşılığında küçük veya yandan görünen yüzlerde doğruluk azalır.
• Worker sayısı. MACHINE_LEARNING_WORKERS varsayılan olarak 1 değerindedir. Her worker, modellerin kendi kopyasını yükleyen ayrı bir süreçtir. Bu nedenle değerin 2 yapılması, kullanılan model belleğini yaklaşık iki katına çıkarır. Kullanılabilir RAM yeterli değilse değer 1 olarak bırakılmalıdır.
• Batch size. MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION aynı anda işlenebilecek yüz sayısını sınırlar. Bir batch bellekte birlikte tutulur. Bu nedenle kırk kişinin bulunduğu bir grup fotoğrafı, portre fotoğrafından daha fazla bellek kullanır.
• Hangi model türlerinin çalıştırılacağı. Smart search, face detection ve text recognition kendi modellerini yükler. Administration, Settings, Machine Learning Settings altında kullanılmayan özelliklerin kapatılması, bu modellerin bellekte tuttuğu alanı yalnızca import işlemleri arasında değil, kalıcı olarak kaldırır.

Ayrıca bellek parçalanmasını önlemek için CPU belleğini önceden ayırdığı belgelenen ve varsayılan olarak açık olan MACHINE_LEARNING_MODEL_ARENA bulunur. Bu ayar en son değiştirilmelidir. Etkisi altta kullanılan memory allocator'a bağlıdır. Bu nedenle etkisini değerlendirmenin güvenilir tek yolu, değişiklikten önce ve sonra docker stats değerini izlemektir.

Üç örnek profil: 2 GB, 4 GB ve 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"
  }
]

Bunları Immich'in ne kadar kaynak kullandığını gösteren ölçümler olarak değil, Compose içine yazılacak limitler olarak değerlendirin. Limit bir üst sınırdır. Herhangi bir kaynağı rezerve etmez ve servisi küçültmez. Sunucunun belleği tükendiğinde kernel'in hangi servisi sonlandıracağını belirler. Bu kararı kernel'in kendi puanlamasına bırakmak yerine sizin vermeniz daha uygundur.

2 GB sunucu: machine learning container kaldırılmalı

2 GB, belgelenen 6 GB minimum değerinin altındadır. Bu nedenle bunun bir taviz olduğu açıkça belirtilmelidir. docker-compose.yml içindeki immich-machine-learning servisinin tamamını yorum satırı haline getirin veya servisi çalışır durumda bırakıp Administration, Settings, Machine Learning Settings altındaki tüm modelleri devre dışı bırakın. Container'ı kaldırmak daha güçlü bir seçenektir. Çünkü devre dışı bırakılmış bir model yine de bellekte bir Python süreci bırakır.

Uploads, albümler, paylaşım, mobil yedekleme, thumbnails ve tarihe, konuma ve dosya adına göre arama kullanılmaya devam eder. Açıklamaya göre arama, yüzlerin kişiler altında otomatik gruplanması ve görüntülerin içindeki metinlerin tanınması kullanılamaz.

Dört limit toplamda yaklaşık 1.7 GB eder ve host için yaklaşık 300 MB bırakır. Veritabanı için ayrılan 768 MB değerinin belgelenen 2 GB alt sınırının altında olduğuna dikkat edilmelidir. 2 GB'ın zorunlu kıldığı taviz tam olarak budur. Bu nedenle burada sonlandırılma olasılığı en yüksek servis Postgres'tir.

İlk bozulan işlem browsing değil, import işlemidir. Düşük on binler seviyesindeki bir fotoğraf kütüphanesi içe aktarıldıktan sonra kabul edilebilir hızda taranır. Bunun nedeni bir sayfanın sunulmasının metadata sorgusu ile dosya okuma işleminden oluşmasıdır. Aynı sunucuda video ağırlıklı bir import işlemi swap kullanmaya başlar. Çünkü transcode işlemi ile thumbnail kuyruğu aynı anda belleğe ihtiyaç duyar. Tüm ağır kuyruklar için concurrency değerini 1 olarak ayarlayın ve bir swap file ekleyin.

4 GB sunucu: machine learning açık, aynı anda tek iş

4 GB, yüz ve nesne tanımayı etkinleştirmenin anlamlı olduğu en küçük boyuttur. Machine learning container için 0 MB limiti belirleyin, facial recognition ayarını buffalo_s olarak değiştirin ve thumbnail generation, face detection ve smart search için job concurrency değerini 1 olarak ayarlayın.

Mevcut bir kütüphane üzerindeki ilk tarama birçok saat sürer. Büyük bir kütüphanede bu süre bir günden uzun olabilir. Bu durum bellekten çok CPU limitidir. Bu nedenle daha fazla RAM süreyi kısaltmaz.

Burada ilk bozulan bileşen, ilk toplu tarama sırasında machine learning container'dır. Limit belirlenmezse container büyürken bir transcode job da büyür ve kernel bu ikisinden daha büyük olanı sonlandırır. docker ps -a içinde Exited (137) görürsünüz ve yeniden başlatılmış bir container ile karşılaşırsınız. Kuyruk da son kontrolünüze göre sessizce daha geride kalır.

8 GB sunucu: belgelenen öneri

4 çekirdekli 8 GB yapılandırma, Immich'in önerdiği değerlerle eşleşir. Her şey varsayılan ayarlarda çalışır: smart search, face detection, text recognition ve varsayılan concurrency değerindeki transcoding. Yüz bin asset'i aşan kütüphaneler burada rahatça çalışır. Kaynak baskısı bellekten disk hızına kayar. Çünkü veritabanı gün boyunca vector index ve metadata sorgularını işler.

Yine de limitleri belirleyin. Kaynak bulunan bir sunucuda limitler, kontrolden çıkan tek bir kuyruğun veritabanını da kullanılamaz hale getirmesini önler. Bu seçeneği daha küçük seçeneklerle fiyatlandırıyorsanız bir VPS'in bellek katmanına göre gerçek maliyeti, genellikle ayarlarla uğraşmayı bırakmanın en ucuz yolunun 8 GB planı olduğunu gösterir.

Compose limitleriyle servis başına bellek sınırı belirleme

Bunun için docker-compose.yml dosyasını düzenlemeyin. Bu dosya, her yükseltme yaptığınızda wget tarafından yeniden oluşturulur. Sınırları, otomatik olarak birleştirilen docker-compose.override.yml dosyasına, docker compose dosyasının yanına ekleyin.

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 artık ana makinenin toplam belleği yerine MEM USAGE / LIMIT sütununda belirlediğiniz üst sınırı göstermelidir. Limit sütununda hâlâ ana makinenin toplam belleği görünüyorsa override dosyası yüklenmemiştir. Dosya adını kontrol edin ve birleştirilmiş sonucu görmek için docker compose config komutunu çalıştırın.

Çok düşük bir sınır, yavaş çalışan bir servisi tamamen durdurabilir. Bu nedenle container yeniden başlatma döngüsüne girerse sınırı artırın. Mekanizmanın ayrıntıları için Docker Compose'ta servis başına bellek sınırı belirleme bölümüne bakın. Bu bölümde ayrıca deploy seçeneğinin Swarm dışında Compose v2 ile neden çalıştığı açıklanır.

Machine learning container'ını kapatma veya taşıma

Küçük bir sunucuda bu container'ı başka bir yere taşımak, yapabileceğiniz en büyük değişikliktir. Immich, bu container'ın başka bir makinede çalıştırılmasını destekler. Akşamları açık tutulan bir masaüstü bilgisayar olabilecek ikinci host üzerinde aşağıdaki dosyayı oluşturun:

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

Ardından web arayüzünde Administration, Settings, Machine Learning Settings bölümüne gidin, Add URL seçeneğine tıklayın ve http://<host>:3003 değerini girin. Her iki host'ta da aynı sürümü kullanın. Immich belgeleri, iki host arasındaki sürüm uyuşmazlıklarının hatalara ve kararsızlığa neden olabileceği konusunda uyarır.

Bu port, fotoğraflarınızı diğer makineye şifrelenmemiş olarak taşır. Bu nedenle portu özel bir ağda tutun veya iki host arasında WireGuard tüneli üzerinden çalıştırın. 3003 portunu hiçbir zaman internete açmayın.

Sorun, sürekli çalışan bir model container'ının kendisiyse, bir plan boyutuna karar vermeden önce PhotoPrism ve Immich'in çalışır durumda tuttukları bileşenler bakımından nasıl farklılaştığını karşılaştırmak da geçerli bir yaklaşımdır.

Immich library'si ne kadar disk alanı gerektirir?

Tek bir çarpan yoktur, çünkü dört farklı bileşen dört farklı hızda büyür. Aşağıda 50,000 fotoğraf ve 500 kısa videodan oluşan bir library için hesaplama yer alır.

[
  {
    "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
  }
]

200 GB fotoğraf ve 60 GB video varsayımdır. Herhangi bir satın alma yapmadan önce bunları kendi ortalamalarınızla değiştirin, çünkü bu sayıyı video belirler: telefondaki bir dakikalık video, yüz fotoğraftan daha büyük olabilir.

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}'

39 GB satırı, Immich'in yayımladığı tek orandır: oluşturulan thumbnail'lar ve transcoded video, library boyutuna ortalama olarak 10 ila 20 yüzde ekler. Bu bir aralıktır, çünkü browser uyumluluğu için yeniden encode edilmesi gereken asset'lerinizin ne kadarının video olduğuna bağlıdır. JPEG'lerden oluşan bir library bu aralığın alt sınırına yakın olur.

Database 3 GB yer kaplar ve bu değer sabit maliyete yakındır. Immich, database dosyalarının genellikle 1 ila 3 GB olduğunu belirtir, çünkü bu dosyalar piksel yerine metadata ve search vector'ları içerir. Model cache'i 2 GB yer kaplar ve birkaç model etkinleştirir veya farklı modelleri test ederseniz büyür. FAQ, bu volume'ü tam olarak bu nedenle alan tüketen bir bileşen olarak belirtir.

Beş satır toplamda 300 GB'ın biraz üzerinde yer kaplar. Bu nedenle 500 GB'lık bir volume büyüme için alan bırakır, 250 GB'lık bir volume ise bırakmaz. Dağılımı şu komutla izleyin:

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

UPLOAD_LOCATION altında altı klasör bulunur. upload ve library original dosyaları, thumbs preview'ları ve face thumbnail'larını, encoded-video yeniden encode edilmiş kopyaları, profile avatar'ları ve backups otomatik database dump'larını içerir. Yalnızca upload, library ve profile yerine konamaz, çünkü diğer her şey bunlardan yeniden oluşturulabilir.

İki nokta kullanıcıları şaşırtır. Silinen asset'ler önce trash'e taşınır ve trash boşaltılana kadar alanı kullanmaya devam eder. Bu nedenle büyük bir cleanup işlemi yaptığınız gün boş alan oluşmaz. Ayrıca database dump yalnızca metadata içerir. Dosyalar olmadan hiçbir işe yaramaz:

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

Bunu original dosyaların server dışında bir konuma file-level kopyasıyla birlikte kullanın. VPS'ten server dışındaki depolama alanına restic yedekleri bu amaçla kullanılır.

Transcoding işlemi RAM değil CPU kullanır

RAM miktarını artırmak transcoding işlemini hızlandırmaz. Immich, FFmpeg ile transcoding yapar. Standart bir VPS üzerinde her kare CPU tarafından decode ve encode edilir. Donanım hızlandırma kullanılabilir olsa bile Immich belgelerine göre yalnızca encoding hızlandırılır. CPU yine yazılımsal decoding ve tone mapping işlemlerini yapar.

Donanım hızlandırma için ek hwaccel.transcoding.yml Compose dosyası ve passthrough yapılacak bir cihaz gerekir. Bunun için NVENC, Quick Sync, RKMPP veya VAAPI kullanılır. Çoğu VPS planında bunların hiçbiri bulunmaz. Bu nedenle CPU kullanımını esas alacak şekilde planlama yapılmalıdır.

Pratikte ayarlanması gereken değer thread sayısıdır. Administration, Settings, Video Transcoding Settings bölümünde thread değerinin 0 olması tüm çekirdeklerin kullanılacağı anlamına gelir. Bu ayar, 2 çekirdekli bir planda tek bir videonun web arayüzünü kilitlemesine neden olabilir. Immich FAQ'da önerildiği gibi bu değeri 1 veya 2 olarak ayarlayın. Böylece transcoding işlemi sistemi aksatmak yerine yavaşlar.

Swap thrashing nedeniyle içe aktarma işleminin kilitlenmiş gibi görünmesi

Bu, en sık yanlış yorumlanan arızadır. Immich bellek yetersizliği yaşadığında iki sonuç ortaya çıkar ve bunlardan yalnızca biri arıza gibi görünür.

Swap olmadan kernel bir süreci sonlandırır. Container birkaç saniye içinde yeniden başlatılır. Bu nedenle tarayıcıda iş kuyruğu yalnızca duraklar ve ardından devam eder. Kanıt docker ps -a içindedir:

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), sürecin signal 9 ile sonlandırıldığı anlamına gelir. 137, 128 artı 9 değeridir. Bir OOMKilled değerinin true olması, sürecin crash nedeniyle değil bellek yetersizliği nedeniyle sonlandırıldığını doğrular.

Swap varken hiçbir süreç sonlandırılmaz ve hiçbir hata oluşmaz. Kernel sayfaları diske taşımaya başlar, içe aktarma işlemi bir büyüklük mertebesi yavaşlar ve web arayüzü normal timeout süresi içinde yanıt vermeyi durdurur. Tüm container'lar çalışır durumdadır. Tüm health check işlemleri hâlâ başarılı olabilir. Sistem kilitlenmiş gibi görünür. Bu noktada sistem yeniden başlatılırsa kuyruktaki ilerleme kaybedilir ve hiçbir şey düzelmez.

free -m
vmstat 1 5

vmstat içindeki si ve so sütunlarında sürekli sıfır olmayan değerler görülmesi, makinenin sürekli swap okuduğu ve swap'a yazdığı anlamına gelir. Bu durum thrashing'in tanımıdır. Aynı anda Swap için free -m satırındaki kullanım değeri de yükselir.

2 GB veya 4 GB belleğe sahip bir makineye yine de swap eklenmelidir. Tanılayabileceğiniz yavaş bir içe aktarma işlemi, tanılayamayacağınız sonlandırılmış bir container'dan daha iyidir:

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

Ardından nedeni giderin. İş eşzamanlılığını 1'e düşürün, machine learning container'ı için bellek sınırı belirleyin veya bu container'ı başka bir host'a taşıyın. Swap, bunu yapmanız için zaman kazandırır. Tek başına çözüm değildir.

FAQ

Immich'i 2 GB RAM'e sahip bir VPS üzerinde çalıştırabilir miyim?

Evet, immich-machine-learning servisini docker-compose.yml içinde yorum satırı haline getirerek ve iş eşzamanlılığını 1 olarak ayarlayarak çalıştırabilirsiniz. Bu değer, belgelenen 6 GB minimum gereksinimin altındadır. Bu nedenle yapılandırma bilinen bir ödün olarak değerlendirilmelidir. Yükleme, albüm, paylaşım, mobil yedekleme ve tarihe, konuma ve dosya adına göre arama kullanılabilir. Açıklamaya göre arama, yüzleri otomatik olarak kişiler altında gruplama ve görüntülerde metin tanıma kullanılamaz. İçe aktarma sırasında oluşan ani yükte container'ın sonlandırılması yerine sunucunun yavaşlaması için 2 GB swap dosyası eklenmelidir.

Immich içe aktarma işlemi neden hata mesajı göstermeden duruyor?

Tarayıcı açısından iki farklı neden aynı görünür. Ya bir container bellek nedeniyle sonlandırılmıştır; bu durumda docker ps -a çıktısında Exited (137) görülür ve container zaten yeniden başlatılmıştır. Ya da host swap kullanıyordur; bu durumda tüm container'lar çalışmaya devam eder ve sistem yalnızca çok yavaştır. vmstat 1 5 bu iki durumu ayırır: si ve so sütunlarında sürekli olarak sıfır olmayan değerler görülmesi swap kullanıldığını gösterir. Her iki durumda da küçük resim oluşturma, yüz algılama ve akıllı arama için iş eşzamanlılığı düşürülmelidir.

Immich günlüklerinde exit code 137 ne anlama gelir?

137, 128 ile signal 9'un toplamıdır. Bu nedenle süreç SIGKILL ile sonlandırılmıştır. Uygulamada bu, container'ın kendi bellek limitine ulaşılması veya host üzerinde belleğin tükenmesi anlamına gelir. docker inspect immich_machine_learning | grep -i oomkilled ile kontrol edilmelidir. true değeri, kernel tarafından bellek nedeniyle sonlandırıldığını doğrular. Ardından free -m ile sudo dmesg -T | grep -i oom-kill, sorunun container limitiyle mi yoksa tüm host ile mi ilgili olduğunu gösterir. Machine learning container'ı genellikle en büyük süreç olduğu için çoğunlukla etkilenen container'dır.

Immich her fotoğraf için ne kadar disk alanına ihtiyaç duyar?

Orijinal dosyaya ek olarak %10 ila %20 pay ayrılmalıdır. Immich belgelerine göre oluşturulan küçük resimler ve dönüştürülen videolar, kitaplık boyutunu ortalama %10 ila %20 artırır. Veritabanının kendisi de büyük bir kitaplıkta bile genellikle 1 ila 3 GB yer kaplar. Toplam alanı asıl belirleyen video dosyalarıdır. Bu nedenle bir plan seçmeden önce fotoğraf sayısına bir çarpan uygulamak yerine kendi ortalama dosya boyutunuz ölçülmelidir.

Immich için GPU gerekli mi?

Hayır. Immich'in tüm bileşenleri CPU üzerinde çalışır. GPU, machine learning container'ındaki model çıkarımını ve video kodlamayı hızlandırır. Ancak bunların hiçbiri gerekli değildir. Çoğu VPS planında GPU bulunmaz. Yalnızca CPU bulunan donanımda transcoding thread sayısı 1 veya 2 olarak ayarlanmalı, buffalo_s face model kullanılmalı ve ilk toplu içe aktarma işlemi gece boyunca çalıştırılmalıdır.