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

Immich को कितनी RAM की आवश्यकता है?

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

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

ये आंकड़े अक्टूबर 2026 तक Immich की आवश्यकताओं वाले पेज से प्रकाशित किए गए हैं। ये केवल आकार निर्धारण (sizing) के सुझाव हैं, न कि कोई ऐसी जांच जो सॉफ्टवेयर के स्टार्टअप पर चलती है। उसी पेज पर एक छोटे सेटअप का भी उल्लेख है, जिसमें machine learning फीचर्स को बंद करके 4 GB RAM का उपयोग किया जा सकता है, इससे कम पर नहीं। छोटे सर्वर पर अंतर यह आता है कि कौन से बैकग्राउंड जॉब्स पूरे होते हैं, और मेमोरी खत्म होने पर import प्रक्रिया कैसे व्यवहार करती है।

एक वास्तविक हार्ड लिमिट मौजूद है। वर्जन 3 के बाद से, amd64 hosts पर machine learning container के लिए x86-64-v2 CPU की आवश्यकता होती है, जो लगभग 2012 के बाद बेचे गए अधिकांश प्रोसेसरों में उपलब्ध है। यह आवश्यकता केवल उस container पर लागू होती है, पूरे सर्वर पर नहीं। इसलिए, पुराने हार्डवेयर पर आप machine learning को बंद कर सकते हैं, इसे नीचे बताए अनुसार किसी अन्य मशीन पर चला सकते हैं, या v2.7.5 पर बने रह सकते हैं, जिसे Immich के दस्तावेज़ अंतिम संगत वर्जन के रूप में बताते हैं।

यदि आपने अभी तक इंस्टॉलेशन शुरू नहीं किया है, तो Docker Compose के साथ पूर्ण Immich इंस्टॉलेशन से शुरुआत करें और फिर सर्वर का आकार निर्धारित करने के लिए यहाँ वापस आएं।

मेमोरी कहाँ जाती है: चार कंटेनर

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

immich-server वेब इंटरफ़ेस और API को सर्व करता है, और यह बैकग्राउंड जॉब वर्कर्स को भी चलाता है। उस एक कंटेनर के भीतर दो वर्कर्स रहते हैं। api ब्राउज़र और मोबाइल ऐप से आने वाले अनुरोधों का उत्तर देता है। microservices कतारों (queues) को चलाता है, जिसमें थंबनेल जनरेशन और वीडियो एन्कोडिंग शामिल हैं। IMMICH_WORKERS_INCLUDE और IMMICH_WORKERS_EXCLUDE वेरिएबल उन दोनों को अलग-अलग कंटेनरों में विभाजित करते हैं, जिससे आप उस आधे हिस्से को उसकी अपनी मेमोरी सीमा दे सकते हैं जो अधिक संसाधन लेता है, बिना उस हिस्से को सीमित किए जो आपकी फ़ोटो सर्व करता है।

database एक PostgreSQL 14 इमेज है जिसमें VectorChord एक्सटेंशन इन-बिल्ट है। यह हर मेटाडेटा और प्रति एसेट एक सर्च वेक्टर को होल्ड करता है। Immich दस्तावेज़ इस सेवा को स्टैक में एकमात्र स्पष्ट न्यूनतम सीमा (floor) देते हैं: यदि आप Docker संसाधन सीमाएं लागू करते हैं, तो डेटाबेस को कम से कम 2 GB की आवश्यकता होती है। उसी पेज पर कहा गया है कि डेटाबेस को आदर्श रूप से लोकल SSD स्टोरेज पर होना चाहिए और किसी भी प्रकार के नेटवर्क शेयर पर नहीं, क्योंकि वेक्टर और इंडेक्स लुकअप छोटे रैंडम रीड होते हैं, इसलिए नेटवर्क वॉल्यूम हर एक को राउंड ट्रिप में बदल देता है। यदि कोई प्लान विकल्प इस पर निर्भर करता है, तो VPS पर NVMe और SATA SSD स्टोरेज के बीच का अंतर यहाँ इस स्टैक में कहीं और की तुलना में अधिक मायने रखता है।

redis Valkey इमेज को चलाता है और जॉब क्यूज़ को होल्ड करता है। यह चारों में सबसे छोटा है, क्योंकि यह फ़ोटो डेटा के बजाय जॉब रिकॉर्ड स्टोर करता है।

immich-machine-learning वह सेवा है जो आपके प्लान के आकार को निर्धारित करती है। यह स्मार्ट सर्च, फेस डिटेक्शन और टेक्स्ट रिकग्निशन के लिए मॉडल लोड करती है, और एक लोड किया गया मॉडल मेमोरी में ही रहता है। MACHINE_LEARNING_MODEL_TTL डिफ़ॉल्ट रूप से 300 पर सेट होता है, इसलिए 5 मिनट तक कोई अनुरोध न आने पर मॉडल को हटा दिया जाता है और अगले अनुरोध पर उसे /cache वॉल्यूम से वापस पढ़ा जाता है। बल्क इम्पोर्ट के दौरान कभी भी 5 मिनट का अंतराल नहीं होता है, इसलिए मॉडल पहले एसेट से लेकर आखिरी तक लोड रहते हैं।

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

निष्क्रिय 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 करें।

तीन कार्यशील प्रोफाइल: 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": "below every documented configuration, machine learning container removed"
  },
  {
    "label": "4 GB VPS",
    "server_limit_mb": 1024,
    "db_limit_mb": 2048,
    "ml_limit_mb": 0,
    "redis_limit_mb": 192,
    "notes": "documented 4 GB setup: machine learning disabled or moved to another host, job concurrency 1"
  },
  {
    "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 कितना उपयोग करता है। एक सीमा (limit) एक अधिकतम स्तर (ceiling) है। यह कुछ भी आरक्षित (reserve) नहीं करती है, और यह किसी सर्विस को छोटा नहीं बनाती है। यह तय करती है कि जब सिस्टम की मेमोरी खत्म हो जाए तो कर्नेल किस सर्विस को बंद (kill) करे, और यह निर्णय कर्नेल की अपनी स्कोरिंग के बजाय आपके द्वारा लिया जाना बेहतर है।

2 GB वाला बॉक्स: machine learning कंटेनर को हटाना

2 GB की क्षमता 6 GB की आधिकारिक न्यूनतम आवश्यकता से कम है, और Immich द्वारा बताए गए एकमात्र कम सेटअप (जो machine learning अक्षम होने पर 4 GB है) से भी नीचे है। Immich कोई 2 GB कॉन्फ़िगरेशन प्रकाशित नहीं करता है, इसलिए यह प्रोफाइल एक असमर्थित समझौता है, न कि कोई मानक तरीका। यदि आप फिर भी इसे आज़माना चाहते हैं, तो docker-compose.yml में पूरे immich-machine-learning सर्विस को कमेंट आउट कर दें, या इसे चलते रहने दें और Administration, Settings, Machine Learning Settings के अंतर्गत सभी मॉडलों को अक्षम कर दें। कंटेनर को हटाना अधिक प्रभावी विकल्प है, क्योंकि एक अक्षम मॉडल भी Python प्रक्रिया को मेमोरी में बनाए रखता है।

आप अपलोड, एल्बम, शेयरिंग, मोबाइल बैकअप, थंबनेल और तारीख, स्थान व फ़ाइल नाम के आधार पर खोज का उपयोग कर सकते हैं। आप विवरण के आधार पर खोज, चेहरों की स्वचालित ग्रुपिंग और छवियों के भीतर टेक्स्ट पहचान की सुविधा खो देंगे।

चारों सीमाएं कुल मिलाकर लगभग 1.7 GB होती हैं, जिससे होस्ट के पास लगभग 300 MB बचते हैं। Immich के दस्तावेज़ों के अनुसार, Docker संसाधन सीमाओं का उपयोग होने पर केवल डेटाबेस को ही कम से कम 2 GB की आवश्यकता होती है, जो कि पूरे बॉक्स की क्षमता है। इसलिए डेटाबेस के लिए 768 MB उस न्यूनतम सीमा से काफी कम है, और यही कारण है कि यहाँ Postgres के बंद होने की संभावना सबसे अधिक है।

सबसे पहले इम्पोर्ट की प्रक्रिया विफल होती है। पेज सर्व करना एक मेटाडेटा क्वेरी और फ़ाइल रीड का काम है, इसलिए पहले से मौजूद लाइब्रेरी को ब्राउज़ करना बॉक्स पर सबसे कम दबाव डालता है, लेकिन वीडियो-आधारित इम्पोर्ट के दौरान स्वैपिंग (swap) होगी, क्योंकि ट्रांसकोड और थंबनेल कतार को एक ही समय में मेमोरी की आवश्यकता होती है। यदि आपके पास केवल 2 GB है, तो प्रत्येक भारी कतार (heavy queue) को concurrency 1 पर सेट करें और एक स्वैप फ़ाइल जोड़ें। यदि आप कोई प्लान चुन रहे हैं, तो 4 GB को ही वास्तविक न्यूनतम सीमा मानें।

4 GB वाला बॉक्स: machine learning चालू, एक बार में एक कार्य

Immich 4 GB को machine learning सुविधाओं के अक्षम होने पर कार्यशील बताता है, और इसकी आवश्यकताओं वाले पेज पर यही एकमात्र कम कॉन्फ़िगरेशन है। डेटाबेस को उसके दस्तावेजी 2 GB के न्यूनतम स्तर पर रखने पर, चार्ट में दी गई तीन सीमाएं कुल मिलाकर लगभग 3.2 GB होती हैं, जिससे होस्ट के पास लगभग 800 MB बचते हैं। थंबनेल जनरेशन के लिए जॉब कॉन्करेंसी (job concurrency) को 1 पर सेट करें और ट्रांसकोडिंग थ्रेड्स को कम रखें।

चेहरा और ऑब्जेक्ट पहचान बनाए रखने के लिए, दस्तावेजी तरीका यह है कि machine learning कंटेनर को किसी अन्य मशीन पर चलाएं (जैसा कि नीचे वर्णित है) और इस सर्वर को उसकी ओर निर्देशित करें। इसे उसी 4 GB बॉक्स पर चलाना Immich के दस्तावेज़ों से बाहर है, क्योंकि डेटाबेस की न्यूनतम आवश्यकता सर्वर, Redis, मॉडलों और होस्ट के लिए कुल मिलाकर लगभग 2 GB ही छोड़ती है। यदि आप फिर भी इसे आज़माना चाहते हैं, तो machine learning कंटेनर को Compose सीमा के साथ सीमित करें, चेहरे की पहचान को buffalo_s पर स्विच करें, और थंबनेल जनरेशन, चेहरा पहचान और स्मार्ट सर्च के लिए जॉब कॉन्करेंसी को 1 पर सेट करें।

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

यदि machine learning इस बॉक्स पर चलता है, तो पहले बल्क पास के दौरान सबसे पहले वही कंटेनर विफल होता है। बिना सीमा के, यह तब बढ़ता है जब ट्रांसकोड जॉब भी बढ़ रही होती है, और कर्नेल दोनों में से बड़े को बंद कर देता है। चूंकि यह सेकंडों में रीस्टार्ट हो जाता है, इसलिए docker ps -a इसे Up के रूप में दिखाता है, जिसका अपटाइम उसके पड़ोसियों की तुलना में बहुत कम होता है, न कि Exited (137), और कतार चुपचाप आपके द्वारा पिछली बार देखे जाने की तुलना में और अधिक पीछे हो जाती है।

8 GB वाला बॉक्स: दस्तावेजी अनुशंसा

8 GB के साथ 4 कोर वही है जो Immich अनुशंसा करता है, और सब कुछ डिफ़ॉल्ट सेटिंग्स पर चलता है: स्मार्ट सर्च, चेहरा पहचान, टेक्स्ट पहचान और ट्रांसकोडिंग, डिफ़ॉल्ट कॉन्करेंसी पर। एक लाख से अधिक एसेट्स वाली लाइब्रेरी यहाँ आसानी से चलती हैं, और दबाव मेमोरी से डिस्क की गति पर स्थानांतरित हो जाता है, क्योंकि वेक्टर इंडेक्स और मेटाडेटा क्वेरी ही वह काम है जो डेटाबेस दिन भर करता है।

सीमाएं फिर भी सेट करें। जिस बॉक्स में जगह है, वहां सीमाएं किसी एक अनियंत्रित कतार को डेटाबेस को बंद करने से रोकती हैं। यदि आप इसकी तुलना छोटे विकल्पों से कर रहे हैं, तो मेमोरी टियर के आधार पर VPS की वास्तविक लागत आमतौर पर 8 GB प्लान को ट्यूनिंग रोकने का सबसे सस्ता तरीका बनाती है।

Compose limits का उपयोग करके प्रति service memory को कैसे सीमित करें

इसके लिए docker-compose.yml को edit न करें। जब भी आप upgrade करते हैं, तो वह file wget द्वारा बदल दी जाती है। 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: 2048M
  redis:
    deploy:
      resources:
        limits:
          memory: 192M

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

docker stats में अब host की कुल memory के बजाय MEM USAGE / LIMIT column में आपकी निर्धारित सीमा (ceiling) दिखनी चाहिए। यदि limit column में अभी भी host का कुल size दिखाई दे रहा है, तो इसका मतलब है कि override file को pick नहीं किया गया है: file का नाम जाँचें और merged result देखने के लिए docker compose config चलाएँ।

database को 2048M या उससे अधिक पर रखें। Immich के documentation के अनुसार, जब भी Docker resource limits का उपयोग किया जाता है, तो database के लिए 2 GB की न्यूनतम सीमा आवश्यक है। बहुत कम limit रखने से एक धीमी service पूरी तरह बंद हो सकती है, इसलिए यदि container बार-बार restart (cycling) हो रहा है, तो limit बढ़ा दें। इसकी कार्यप्रणाली के बारे में अधिक जानकारी Docker Compose में प्रति service memory limits सेट करना में दी गई है, जिसमें यह भी शामिल है कि deploy, Swarm के बाहर Compose v2 के साथ कैसे काम करता है।

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

एक छोटे सर्वर पर, इस container को कहीं और ले जाना सबसे बड़ा बदलाव है जो आप कर सकते हैं। Immich इसे किसी अन्य मशीन पर चलाने का समर्थन करता है। दूसरे 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 docs चेतावनी देते हैं कि दोनों के बीच version का मेल न होने से bugs और अस्थिरता आ सकती है।

वह port आपकी photos के image previews को दूसरी मशीन पर बिना encryption के भेजता है, और Immich docs चेतावनी देते हैं कि machine learning container में अपनी कोई सुरक्षा व्यवस्था नहीं है, इसलिए इसे private network पर रखें या दो hosts के बीच WireGuard tunnel के माध्यम से चलाएँ। 3003 port को कभी भी internet पर expose न करें।

यदि resident model container का पूरा विचार ही समस्या है, तो योजना के आकार को अंतिम रूप देने से पहले PhotoPrism और Immich के बीच अंतर की तुलना करना भी एक उचित कदम है।

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 CPU द्वारा सीमित है, RAM द्वारा नहीं

RAM बढ़ाने से transcoding की गति नहीं बढ़ेगी। Immich, FFmpeg का उपयोग करके transcoding करता है, और एक सामान्य VPS पर प्रत्येक frame को CPU द्वारा decode और encode किया जाता है। प्रत्येक FFmpeg process decoded frames के buffers को memory में रखती है, इसीलिए import section में transcode को memory cost के रूप में गिना जाता है, लेकिन इसकी गति CPU द्वारा निर्धारित होती है। यहाँ तक कि जहाँ hardware acceleration उपलब्ध है, Immich के documentation के अनुसार default रूप से केवल encoding ही accelerate होती है, इसलिए जब तक आप hardware decoding को enable नहीं करते, CPU ही decoding और tone mapping का कार्य करता है।

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

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

Swap thrashing का प्रभाव hang जैसा क्यों दिखता है

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

Swap के बिना, kernel एक process को kill कर देता है। container कुछ ही सेकंड में 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 है। आप वह status केवल तभी देखते हैं जब container बंद होता है। एक बार जब restart policy उसे वापस ले आती है, तो docker ps -a उसे फिर से Up दिखाता है, और अन्य Immich containers की तुलना में बहुत कम uptime इसका संकेत है। केवल signal 9 मेमोरी समस्या को साबित नहीं करता है, क्योंकि Docker इसे तब भी भेजता है जब एक सामान्य stop अपने timeout से अधिक समय लेता है। OOMKilled का true मान पुष्टि करता है कि इसे मेमोरी के लिए kill किया गया था, और एक बार जब container restart हो जाता है, तो dmesg की oom-kill लाइनें ही वह रिकॉर्ड हैं जिस पर भरोसा किया जा सकता है।

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

free -m
vmstat 1 5

vmstat के si और so columns में लगातार गैर-शून्य मान का मतलब है कि machine लगातार swap को read और write कर रही है, जिसे thrashing कहा जाता है। उसी समय Swap के लिए free -m row का मान बढ़ रहा होगा।

2 GB या 4 GB वाली machine पर swap जरूर जोड़ें, क्योंकि एक धीमा import जिसे आप diagnose कर सकते हैं, उस killed container से बेहतर है जिसे आप नहीं कर सकते:

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 को सीमित करें, या उसे इस host से हटा दें। Swap आपको ऐसा करने के लिए समय देता है। यह अपने आप में समाधान नहीं है।

FAQ

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

Immich के किसी भी आधिकारिक कॉन्फ़िगरेशन में ऐसा संभव नहीं है। आवश्यकता पृष्ठ 6 GB को न्यूनतम मानता है, मशीन लर्निंग फीचर्स बंद होने पर 4 GB को एकमात्र छोटा सेटअप बताता है, और कहता है कि Docker रिसोर्स लिमिट का उपयोग होने पर केवल डेटाबेस को ही कम से कम 2 GB की आवश्यकता होती है। immich-machine-learning सर्विस को कमेंट आउट करने और जॉब कॉनकरेंसी को 1 पर सेट करने से यह चल सकता है, लेकिन यह एक असमर्थित समझौता है, और इम्पोर्ट के दौरान Postgres के बंद होने की संभावना सबसे अधिक होती है। यदि आपके पास केवल 2 GB है, तो 2 GB की स्वैप फाइल जोड़ें ताकि इम्पोर्ट के दौरान सर्वर धीमा हो जाए, न कि कंटेनर बंद हो जाए। यदि आप प्लान चुन रहे हैं, तो 4 GB से शुरुआत करें।

मेरा Immich इम्पोर्ट बिना किसी एरर मैसेज के क्यों रुक जाता है?

ब्राउज़र से दो अलग-अलग कारण एक जैसे दिखते हैं। या तो मेमोरी के कारण कंटेनर बंद होकर रीस्टार्ट हो गया है, ऐसी स्थिति में docker ps -a इसे Up दिखाएगा और अपटाइम बहुत कम होगा (Exited (137) केवल तब दिखता है जब आप इसे बंद होने के दौरान पकड़ते हैं), या होस्ट स्वैपिंग कर रहा है, ऐसी स्थिति में हर कंटेनर चल रहा होता है और सब कुछ बहुत धीमा होता है। vmstat 1 5 इन दोनों में अंतर करता है: si और so कॉलम में लगातार गैर-शून्य संख्या का मतलब स्वैपिंग है। किसी भी स्थिति में थंबनेल जनरेशन, फेस डिटेक्शन और स्मार्ट सर्च के लिए जॉब कॉनकरेंसी को कम करें।

Immich लॉग्स में एग्जिट कोड 137 का क्या मतलब है?

137 का मतलब 128 प्लस सिग्नल 9 है, इसलिए प्रोसेस को SIGKILL के साथ बंद कर दिया गया था। Immich बॉक्स पर यह आमतौर पर मेमोरी की सीमा होती है, या तो कंटेनर की अपनी सीमा या होस्ट की मेमोरी खत्म होना, लेकिन केवल कोड से यह साबित नहीं होता: Docker तब भी SIGKILL भेजता है जब कोई कंटेनर अपने टाइमआउट (Linux पर डिफ़ॉल्ट रूप से 10 सेकंड) के भीतर बंद नहीं होता है। docker inspect immich_machine_learning | grep -i oomkilled के साथ जाँच करें। true का मान पुष्टि करता है कि कर्नेल ने इसे मेमोरी के कारण बंद किया है, और free -m प्लस sudo dmesg -T | grep -i oom-kill फिर आपको बताता है कि यह कंटेनर की सीमा थी या पूरे होस्ट की। मशीन लर्निंग कंटेनर आमतौर पर इसका शिकार होता है क्योंकि यह सबसे बड़ी प्रोसेस होती है।

Immich को प्रति फोटो कितनी डिस्क स्पेस की आवश्यकता होती है?

मूल फ़ाइल के साथ 10 से 20 प्रतिशत अतिरिक्त जगह का बजट रखें। Immich के दस्तावेज़ बताते हैं कि जनरेट किए गए थंबनेल और ट्रांसकोडेड वीडियो लाइब्रेरी के आकार को औसतन 10 से 20 प्रतिशत तक बढ़ा देते हैं, और डेटाबेस स्वयं एक बड़ी लाइब्रेरी के लिए भी आमतौर पर 1 से 3 GB का होता है। वीडियो ही वास्तव में आपके कुल आकार को निर्धारित करता है, इसलिए फोटो की संख्या पर मल्टीप्लायर लगाने के बजाय प्लान चुनने से पहले अपनी औसत फ़ाइल साइज़ को मापें।

क्या मुझे Immich के लिए GPU की आवश्यकता है?

नहीं। Immich का हर हिस्सा CPU पर चलता है। ग्राफिक्स कार्ड मशीन लर्निंग कंटेनर में मॉडल इन्फरेंस और वीडियो एन्कोडिंग को गति देता है, लेकिन इनमें से किसी की भी आवश्यकता नहीं है। अधिकांश VPS प्लान GPU प्रदान नहीं करते हैं। केवल CPU वाले हार्डवेयर पर, ट्रांसकोडिंग थ्रेड्स को 1 या 2 पर सेट करें, buffalo_s फेस मॉडल का उपयोग करें, और पहले बल्क इम्पोर्ट को रात भर चलने दें।