Immich को कितनी RAM और disk space चाहिए?

Immich को कितनी RAM चाहिए?

Immich की documented minimum आवश्यकता 6 GB RAM (random access memory) है और इसकी recommendation 8 GB है। इसके लिए कम-से-कम 2 CPU cores और आराम से चलाने के लिए 4 cores चाहिए। यह आंकड़ा पूरे stack के लिए है, क्योंकि Immich एक application के बजाय चार containers है। पहले से import की गई library को browse करने में बहुत कम memory लगती है। Memory import के दौरान खर्च होती है, और इसका अधिकांश हिस्सा एक ऐसे container में जाता है जिसे आप बंद कर सकते हैं।

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

ये Immich requirements page पर August 2026 तक प्रकाशित आंकड़े हैं। ये sizing recommendation हैं, यह जांच नहीं कि software startup के समय चलेगा या नहीं। Immich इससे कम memory पर भी start हो जाता है। छोटे server पर फर्क यह पड़ता है कि कौन-से background jobs पूरे होते हैं और memory खत्म होने पर import के साथ क्या होता है।

एक वास्तविक hard limit मौजूद है। Immich version 3 और उसके बाद के versions को amd64 hosts पर x86-64-v2 CPU चाहिए। इसमें लगभग 2012 के बाद बिकने वाले अधिकांश processors शामिल हैं। पुराने hardware पर container धीरे चलने के बजाय start होने में विफल हो जाता है।

यदि install अभी बाकी है, तो Docker Compose के साथ VPS पर पूरा Immich install शुरू करें और फिर यहाँ लौटकर server का आकार तय करें।

मेमोरी कहाँ जाती है: चार containers

आधिकारिक Compose file चार services शुरू करती है। हर service का memory pattern अलग है, इसलिए केवल कुल संख्या देखने से उपयोगी जानकारी छिप जाती है।

immich-server web interface और API उपलब्ध कराता है। यह background job workers भी चलाता है। इसी एक container के अंदर दो workers रहते हैं। api browser और mobile app से आने वाली requests का उत्तर देता है। microservices queues चलाता है, जिनमें thumbnail generation और video encoding शामिल हैं। Variables IMMICH_WORKERS_INCLUDE और IMMICH_WORKERS_EXCLUDE इन दोनों को अलग containers में बाँटते हैं। इससे noisy हिस्से के लिए अलग memory limit दी जा सकती है, बिना photos उपलब्ध कराने वाले हिस्से पर limit लगाए।

database PostgreSQL 14 image है, जिसमें VectorChord extension पहले से शामिल है। इसमें पूरा metadata और हर asset के लिए एक search vector रखा जाता है। Immich docs इस service के लिए stack में एकमात्र स्पष्ट न्यूनतम सीमा बताती हैं: यदि आप Docker resource limits लागू करते हैं, तो database को कम से कम 2 GB चाहिए। उसी page में कहा गया है कि database local SSD storage पर होना चाहिए और किसी भी प्रकार के network share पर नहीं, क्योंकि vector और index lookups छोटे random reads होते हैं। Network volume में हर lookup के लिए network round trip लगती है। यदि plan का चुनाव इसी पर निर्भर है, तो VPS पर NVMe और SATA SSD storage के बीच का अंतर इस stack के किसी भी अन्य हिस्से से अधिक महत्वपूर्ण है।

redis Valkey image चलाता है और job queues रखता है। चारों में इसका आकार काफी कम है, क्योंकि इसमें photo data के बजाय job records रखे जाते हैं।

immich-machine-learning वह service है जो आपके plan का आकार तय करती है। यह smart search, face detection और text recognition के लिए models load करती है। Load किया गया model memory में बना रहता है। MACHINE_LEARNING_MODEL_TTL का default मान 300 है। इसलिए requests न आने पर model पांच मिनट बाद हट जाता है और अगली request पर /cache volume से फिर पढ़ा जाता है। Bulk import के दौरान पांच मिनट का अंतर कभी नहीं आता। इसलिए models पहले asset से आखिरी asset तक memory में loaded रहते हैं।

आयात के दौरान क्या बदलता है

निष्क्रिय Immich शांत रहता है। छोटे servers import के दौरान fail होते हैं, क्योंकि एक asset upload करने पर jobs की पूरी श्रृंखला queue में लग जाती है और कई queues एक ही समय पर चलती हैं।

Metadata extraction file header को पढ़ता है और इसका भार कम होता है। Thumbnail generation का भार अधिक होता है। Immich प्रत्येक asset के लिए तीन thumbnail outputs बनाता है: एक धुंधला thumbhash placeholder, एक WebP preview और एक JPEG thumbnail। इसके अलावा, detected प्रत्येक face के लिए एक और thumbnail बनता है। इनमें से हर job image को decode करता है। Job concurrency यह तय करती है कि एक समय में कितनी images decode होंगी। Concurrency वह multiplier है जो प्रत्येक job की छोटी लागत को पूरे server की लागत में बदल देती है। इसी कारण सीमित संसाधनों वाली machine पर इसे सबसे पहले कम करने की सलाह Immich FAQ में दी गई है। Administration, Settings, Job Settings के अंतर्गत भारी queues की concurrency को 1 पर सेट करें।

Video assets transcoding जोड़ते हैं। प्रत्येक transcode job एक अलग FFmpeg process होता है, जिसकी अपनी memory होती है। यह आपके द्वारा अनुमत सभी CPU threads का उपयोग करेगा।

Smart search प्रत्येक नए asset को machine learning container में भेजता है, ताकि एक embedding vector की गणना की जा सके। Face detection उसी image पर दूसरा model चलाता है। मौजूदा photo library को पहली बार import करने पर, ये दोनों queues आपके सभी assets पर चलती हैं और इसमें कई घंटे लग सकते हैं। पूरे installation में memory पर सबसे अधिक दबाव इसी समय पड़ता है, और यह केवल एक बार होता है।

चेहरा और object recognition के लिए सबसे अधिक RAM की आवश्यकता क्यों होती है

Face handling दो काम करता है। Face detection, machine learning container में एक model चलाकर boxes खोजता है। इसके बाद facial recognition इन detections को लोगों के समूहों में व्यवस्थित करता है। इस चरण में Postgres के vector index से query की जाती है। इसलिए बड़ी library दोनों services पर क्रम से दबाव डालती है: पहले detection के दौरान model container पर, फिर grouping के दौरान database पर।

चार settings यह बदलती हैं कि machine learning container memory में क्या रखता है।

• Face model। Immich डिफ़ॉल्ट रूप से buffalo_l ship करता है, और FAQ छोटे server पर buffalo_s की सिफारिश करता है। यह छोटा model है, इसलिए कम memory लेता है और तेज़ चलता है। इसकी कीमत छोटे या side-on चेहरों की कम accuracy के रूप में चुकानी पड़ती है।
• Worker count। MACHINE_LEARNING_WORKERS का default 1 है। प्रत्येक worker एक अलग process होता है और models की अपनी copy load करता है। इसलिए इसे 2 करने पर resident model memory लगभग दोगुनी हो जाती है। जब तक आपके पास अतिरिक्त RAM न हो, इसे 1 पर रखें।
• Batch size। MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION एक बार में process किए जाने वाले faces की संख्या सीमित करता है। एक batch memory में एक साथ रखा जाता है। इसलिए forty faces वाली group photo में portrait की तुलना में अधिक memory लगती है।
• कौन-से model types वास्तव में चलें। Smart search, face detection और text recognition प्रत्येक अपने models load करते हैं। Administration, Settings, Machine Learning Settings के अंतर्गत जिनका उपयोग नहीं करते, उन्हें बंद करने पर उनकी memory imports के बीच ही नहीं, स्थायी रूप से मुक्त हो जाती है।

इसके अलावा MACHINE_LEARNING_MODEL_ARENA भी है। Documentation के अनुसार यह fragmentation से बचने के लिए CPU memory पहले से allocate करता है और default रूप से चालू रहता है। इसे सबसे अंत में बदलें। इसका प्रभाव underlying memory allocator पर निर्भर करता है। इसलिए इसका आकलन करने का विश्वसनीय तरीका केवल यह है कि बदलाव से पहले और बाद में docker stats को monitor करें।

तीन तैयार profiles: 2 GB, 4 GB और 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"
  }
]

इन्हें Compose में दर्ज की जाने वाली limits समझें, न कि Immich के वास्तविक memory usage के माप के रूप में। Limit एक ceiling होती है। यह memory reserve नहीं करती और service को छोटा नहीं बनाती। यह तय करती है कि host की memory समाप्त होने पर kernel किस service को kill करेगा। यह निर्णय kernel की अपनी scoring पर छोड़ने के बजाय आप स्वयं करें, तो बेहतर है।

2 GB box: machine learning container हटाएँ

2 GB, 6 GB की documented minimum आवश्यकता से कम है। इसलिए यह एक compromise है और इसे स्पष्ट रूप से समझना चाहिए। docker-compose.yml में पूरी immich-machine-learning service को comment out करें। वैकल्पिक रूप से, इसे चलने दें और Administration, Settings, Machine Learning Settings के अंतर्गत हर model को disable करें। Container हटाना बेहतर विकल्प है, क्योंकि disabled model होने पर भी Python process memory में resident रहता है।

आप uploads, albums, sharing, mobile backup और date, place तथा filename के आधार पर search बनाए रखते हैं। आप description के आधार पर search, faces को लोगों के रूप में automatic grouping और images के भीतर text recognition खो देते हैं।

चारों limits का योग लगभग 1.7 GB है। इससे host के लिए लगभग 300 MB बचता है। ध्यान दें कि database के लिए 768 MB, documented 2 GB floor से कम है। यही वह compromise है जो 2 GB मजबूर करता है। इसी कारण यहाँ Postgres के kill होने की सबसे अधिक संभावना रहती है।

सबसे पहले import प्रभावित होता है, browsing नहीं। कम दसियों हज़ार photos वाली library, import पूरा होने के बाद, ठीक से browse होती है। इसका कारण है कि page serve करने में metadata query और file read शामिल होते हैं। उसी box पर video-heavy import swap का उपयोग करेगा, क्योंकि transcode और thumbnail queue को एक ही समय पर memory चाहिए। हर heavy queue की concurrency को 1 पर सेट करें और swap file जोड़ें।

4 GB box: machine learning चालू रखें, एक समय में एक job

4 GB वह सबसे छोटा आकार है जहाँ face और object recognition चालू करना उपयोगी है। Machine learning container की limit 0 MB करें, facial recognition को buffalo_s पर switch करें और thumbnail generation, face detection तथा smart search के लिए job concurrency को 1 पर सेट करें।

मौजूदा library पर पहला pass कई घंटे चलेगा। बड़ी library पर इसमें एक दिन से अधिक समय लग सकता है। यह memory की बजाय CPU limit है। इसलिए अधिक RAM इसे जल्दी पूरा नहीं कराएगी।

यहाँ पहले bulk pass के दौरान machine learning container सबसे पहले प्रभावित होता है। Limit न होने पर यह बढ़ता रहता है और उसी समय transcode job भी memory बढ़ाती है। फिर kernel दोनों में से बड़ी process को kill कर देता है। docker ps -a में Exited (137) दिखाई देता है और container restart हो जाता है। जब आप अगली बार देखते हैं, तो queue बिना किसी स्पष्ट संकेत के पहले से और पीछे होती है।

8 GB box: documented recommendation

4 cores वाला 8 GB setup, Immich की recommendation से मेल खाता है। इसमें सब कुछ default settings पर चलता है: smart search, face detection, text recognition और default concurrency पर transcoding। एक लाख से अधिक assets वाली libraries यहाँ आराम से चलती हैं। इसके बाद pressure memory की बजाय disk speed पर स्थानांतरित हो जाता है, क्योंकि database पूरे दिन vector index और metadata queries पर काम कर रहा होता है।

फिर भी limits सेट करें। पर्याप्त memory वाले box पर भी limits किसी एक runaway queue को database को अपने साथ down करने से रोकती हैं। यदि आप इसकी कीमत छोटी options के साथ तुलना कर रहे हैं, तो memory tier के अनुसार VPS की वास्तविक लागत आम तौर पर 8 GB plan को tuning रोकने का सबसे सस्ता तरीका बनाती है।

Compose limits के साथ प्रत्येक service की memory सीमा कैसे तय करें

इसके लिए docker-compose.yml को edit न करें। wget के upgrade होने पर वह file हर बार replace हो जाती है। Limits को उसके पास docker-compose.override.yml में रखें; docker compose उसे अपने-आप merge करता है।

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 के MEM USAGE / LIMIT column में host की कुल memory के बजाय आपकी तय की गई सीमा दिखनी चाहिए। यदि limit column में अभी भी host का पूरा आकार दिख रहा है, तो override file load नहीं हुई है। File name जाँचें और merged result देखने के लिए docker compose config चलाएँ।

बहुत कम limit किसी धीमी service को पूरी तरह बंद कर सकती है। इसलिए यदि कोई container बार-बार restart हो, तो limit बढ़ाएँ। इसके कार्य करने के तरीके की अधिक जानकारी Docker Compose में प्रत्येक service के लिए memory limits तय करना में है। इसमें यह भी बताया गया है कि Compose v2 के साथ deploy Swarm के बाहर कैसे काम करता है।

Machine learning container को बंद या स्थानांतरित कैसे करें

छोटे server पर इस container को किसी दूसरी जगह स्थानांतरित करना सबसे बड़ा बदलाव हो सकता है। Immich इसे किसी दूसरी machine पर चलाने की सुविधा देता है। दूसरे host पर यह file बनाएँ। यह ऐसा desktop भी हो सकता है, जो केवल शाम के समय चालू रहता हो:

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

इसके बाद web interface में Administration, Settings, Machine Learning Settings पर जाएँ, Add URL पर click करें और http://<host>:3003 दर्ज करें। दोनों hosts पर version समान रखें, क्योंकि Immich documentation के अनुसार दोनों के version अलग होने पर bugs और instability हो सकती है।

यह port आपकी photos को दूसरी machine तक unencrypted भेजता है। इसलिए इसे private network पर रखें या दोनों hosts के बीच WireGuard tunnel चलाएँ। 3003 को internet पर कभी expose न करें।

यदि समस्या resident model container के विचार से है, तो plan size तय करने से पहले यह तुलना करना भी उचित है कि PhotoPrism और Immich में उनके लगातार चलने वाले components कैसे अलग हैं।

Immich library को कितनी disk space चाहिए?

कोई एक निश्चित multiplier नहीं है, क्योंकि चार अलग चीजें चार अलग दरों से बढ़ती हैं। 50,000 photos और 500 short videos वाली library का हिसाब इस प्रकार है।

[
  {
    "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 photos और 60 GB video अनुमानित मान हैं। कुछ खरीदने से पहले इन्हें अपने औसत आकार से बदलें, क्योंकि यह संख्या video तय करता है: phone video का एक मिनट 100 photos से भी बड़ा हो सकता है।

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 वाली row ही Immich द्वारा दिया गया एकमात्र published ratio है: generated thumbnails और transcoded video library के आकार में औसतन 10 से 20 percent जोड़ते हैं। यह range इसलिए है, क्योंकि यह इस बात पर निर्भर करती है कि browser compatibility के लिए re-encoding की जरूरत वाले आपके assets में video कितने हैं। JPEGs वाली library इस range के निचले स्तर के करीब रहती है।

Database 3 GB का है, और यह लगभग fixed cost है। Immich के documentation के अनुसार database files आम तौर पर 1 से 3 GB की होती हैं, क्योंकि इनमें pixels के बजाय metadata और search vectors होते हैं। Model cache 2 GB का है और कई models enable करने या अलग-अलग models test करने पर बढ़ता है। FAQ इस volume को ठीक इसी कारण space consumer बताता है।

पाँचों rows मिलकर 300 GB से थोड़ी अधिक होती हैं, इसलिए 500 GB का volume बढ़ने के लिए जगह छोड़ता है, जबकि 250 GB का volume पर्याप्त नहीं है। यह विभाजन इस command से देखें:

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

UPLOAD_LOCATION के अंतर्गत छह folders होते हैं। upload और library originals रखते हैं, thumbs previews और face thumbnails रखता है, encoded-video re-encoded copies रखता है, profile avatars रखता है और backups automatic database dumps रखता है। केवल upload, library और profile को दोबारा बनाया नहीं जा सकता, क्योंकि बाकी सभी उनसे regenerate हो जाते हैं।

दो बातें लोगों को अक्सर चौंकाती हैं। Deleted assets पहले trash में जाते हैं और trash empty होने तक अपनी space रखते हैं। इसलिए बड़े cleanup के दिन कोई space free नहीं होती। दूसरा, database dump में केवल metadata होता है, इसलिए files के बिना उसका कोई उपयोग नहीं है:

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

इसके साथ originals की file level copy server से बाहर किसी स्थान पर रखें। इसी काम के लिए VPS से off-server storage तक restic backups उपयोगी हैं।

Transcoding में RAM नहीं, CPU का उपयोग होता है

RAM बढ़ाने से transcoding तेज नहीं होगा। Immich, FFmpeg के साथ transcoding करता है और सामान्य VPS पर हर frame को CPU decode और encode करता है। Hardware acceleration उपलब्ध होने पर भी Immich के documentation के अनुसार केवल encoding accelerated होती है। इसलिए CPU software decoding और tone mapping करता रहता है।

Hardware acceleration के लिए अतिरिक्त hwaccel.transcoding.yml Compose file और pass through करने के लिए किसी device की जरूरत होती है। इसके लिए NVENC, Quick Sync, RKMPP या VAAPI का उपयोग किया जाता है। अधिकांश VPS plans में इनमें से कोई सुविधा नहीं होती। इसलिए CPU उपयोग के अनुसार योजना बनाएँ।

व्यावहारिक setting thread count है। Administration, Settings, Video Transcoding Settings के अंतर्गत thread value 0 का अर्थ सभी cores होता है। इससे 2 core plan पर एक video web interface को freeze कर सकता है। Immich FAQ के सुझाव के अनुसार वहाँ इसे 1 या 2 पर set करें। इससे transcode धीमा होगा, लेकिन अन्य services बाधित नहीं होंगी।

Swap thrashing के कारण import hang जैसा क्यों दिखता है

यह वह failure है जिसे लोग सबसे अधिक गलत समझते हैं। जब Immich की memory समाप्त हो जाती है, तो दो परिणाम हो सकते हैं। इनमें से केवल एक failure जैसा दिखता है।

Swap के बिना kernel किसी process को kill कर देता है। Container कुछ ही seconds में restart हो जाता है। इसलिए browser में job queue रुकती हुई दिखती है और फिर चलने लगती है। इसका प्रमाण 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) का अर्थ है कि process को signal 9 से kill किया गया। 137, 128 और 9 का योग है। OOMKilled का true मान यह पुष्टि करता है कि process को memory के कारण kill किया गया था, crash के कारण नहीं।

Swap के साथ कुछ भी kill नहीं होता और कोई error भी नहीं आता। Kernel pages को disk पर भेजना शुरू कर देता है। Import की गति एक order of magnitude तक घट जाती है और web interface सामान्य timeout के भीतर जवाब देना बंद कर देता है। हर container चल रहा होता है। हर health check अभी भी pass हो सकता है। यह hang जैसा दिखता है। इसी समय लोग box को reboot कर देते हैं, जिससे queue की progress खो जाती है और समस्या में कोई बदलाव नहीं होता।

free -m
vmstat 1 5

vmstat के si और so columns में लगातार non zero values होने का अर्थ है कि machine लगातार swap को read और write कर रही है। यही thrashing की परिभाषा है। उसी समय Swap के लिए free -m row में used value भी बढ़ती जाएगी।

2 GB या 4 GB box पर भी swap जोड़ें, क्योंकि ऐसा slow import जिसे आप diagnose कर सकते हैं, उस killed container से बेहतर है जिसे आप diagnose नहीं कर सकते:

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

इसके बाद मूल कारण ठीक करें। Job concurrency को 1 तक घटाएँ, machine learning container पर limit लगाएँ, या उसे इस host से हटा दें। Swap आपको ऐसा करने के लिए समय देता है। यह अपने आप में समाधान नहीं है।

FAQ

क्या मैं 2 GB VPS पर Immich चला सकता हूँ?

हाँ, यदि docker-compose.yml में immich-machine-learning service को comment out किया गया हो और job concurrency को 1 पर सेट किया गया हो। यह documented minimum 6 GB से कम है, इसलिए इसे ज्ञात compromise मानें। Uploads, albums, sharing, mobile backup और date, place तथा filename से search उपलब्ध रहेंगे। Description से search, faces को people में automatic grouping और images के अंदर text recognition उपलब्ध नहीं होंगे। 2 GB की swap file जोड़ें, ताकि import spike के दौरान server धीमा हो, container kill न हो।

मेरा Immich import बिना error message के क्यों रुक जाता है?

Browser में दो अलग कारण एक जैसे दिखाई दे सकते हैं। पहला, memory के कारण कोई container kill हुआ हो। ऐसी स्थिति में docker ps -a में Exited (137) दिखाई देता है और container पहले ही restart हो चुका होता है। दूसरा, host swapping कर रहा हो। ऐसी स्थिति में सभी containers चलते रहते हैं, लेकिन सब कुछ बहुत धीमा हो जाता है। vmstat 1 5 इन दोनों स्थितियों में अंतर बताता है। si और so columns में लगातार non zero numbers swapping का संकेत हैं। दोनों ही मामलों में thumbnail generation, face detection और smart search के लिए job concurrency कम करें।

Immich logs में exit code 137 का क्या अर्थ है?

137, 128 और signal 9 का योग है। इसलिए process को SIGKILL से kill किया गया। व्यवहार में इसका अर्थ है कि memory ceiling तक पहुँच गई थी। यह container की अपनी limit हो सकती है या host की memory समाप्त हो सकती है। docker inspect immich_machine_learning | grep -i oomkilled से जाँच करें। true की value यह पुष्टि करती है कि kernel ने memory के कारण process को kill किया। इसके बाद free -m और sudo dmesg -T | grep -i oom-kill बताते हैं कि कारण container limit थी या पूरा host memory से बाहर हो गया था। Machine learning container आम तौर पर प्रभावित होता है, क्योंकि वह प्रायः सबसे बड़ा process होता है।

Immich को प्रत्येक photo के लिए कितनी disk space चाहिए?

Original file के साथ 10 से 20 प्रतिशत अतिरिक्त space का budget रखें। Immich के documentation के अनुसार generated thumbnails और transcoded video library का size औसतन 10 से 20 प्रतिशत बढ़ाते हैं। Large library में भी database आम तौर पर 1 से 3 GB का होता है। आपके total size का वास्तविक निर्धारण video करता है। इसलिए plan चुनने से पहले अपने average file size को मापें, photo count पर कोई multiplier लागू न करें।

क्या Immich के लिए GPU आवश्यक है?

नहीं। Immich का प्रत्येक भाग CPU पर चलता है। Graphics card machine learning container में model inference और video encoding को तेज करता है, लेकिन दोनों के लिए यह आवश्यक नहीं है। अधिकांश VPS plans में GPU उपलब्ध नहीं होता। केवल CPU वाले hardware पर transcoding threads को 1 या 2 पर सेट करें, buffalo_s face model का उपयोग करें और पहला bulk import overnight चलने दें।