Immich ला किती RAM आणि disk space आवश्यक आहे?

Immich ला किती RAM आवश्यक आहे?

Immich ला documented minimum म्हणून 6 GB RAM (random access memory) आणि recommendation म्हणून 8 GB RAM आवश्यक आहे. यासाठी किमान 2 CPU cores आणि आरामदायी install साठी 4 CPU cores आवश्यक आहेत. हा आकडा संपूर्ण stack साठी आहे, कारण Immich हे एका application ऐवजी चार containers आहेत. आधीच import केलेली library browse करण्यासाठी कमी memory लागते. Memory मुख्यतः importing वेळी वापरली जाते आणि तिचा बहुतेक भाग तुम्ही बंद करू शकता अशा एका 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 वर सुरू होते. लहान server वर कोणती background jobs पूर्ण होतात आणि memory संपल्यावर import कसे वागते, यात बदल होतो.

एक वास्तविक hard limit आहे. Immich version 3 आणि त्यानंतरच्या आवृत्त्यांना amd64 hosts वर x86-64-v2 CPU आवश्यक आहे. यामध्ये साधारण 2012 पासून विकल्या गेलेल्या बहुतेक processors चा समावेश होतो. जुन्या hardware वर container हळू चालत नाही; तो सुरूच होत नाही.

जर install अजून केले नसेल, तर Docker Compose वापरून VPS वर संपूर्ण Immich install पासून सुरुवात करा आणि server ची क्षमता ठरवण्यासाठी येथे परत या.

मेमरी कुठे वापरली जाते: चार कंटेनर

अधिकृत Compose फाइलमध्ये चार सेवा सुरू होतात. प्रत्येक सेवेचा मेमरी वापर वेगळ्या प्रकारचा आहे. त्यामुळे एकूण संख्या पाहिल्यास महत्त्वाचा तपशील दिसत नाही.

immich-server वेब इंटरफेस आणि API पुरवते. तसेच ती background job workers देखील चालवते. त्या एकाच कंटेनरमध्ये दोन workers असतात. api browser आणि mobile app कडून आलेल्या विनंत्यांना प्रतिसाद देते. microservices thumbnail generation आणि video encoding यांसह queues चालवते. IMMICH_WORKERS_INCLUDE आणि IMMICH_WORKERS_EXCLUDE ही variables या दोन भागांना स्वतंत्र कंटेनरमध्ये विभाजित करतात. त्यामुळे photos पुरवणाऱ्या भागावर मर्यादा न घालता अधिक मेमरी वापरणाऱ्या भागासाठी स्वतंत्र memory limit देता येते.

database ही VectorChord extension समाविष्ट असलेली PostgreSQL 14 image आहे. ती सर्व metadata आणि प्रत्येक asset साठी एक search vector साठवते. या stack मध्ये स्पष्ट किमान आवश्यकता केवळ या सेवेसाठी दिली आहे: Docker resource limits लागू केल्यास database साठी किमान 2 GB आवश्यक आहे. त्याच पानावर database local SSD storage वर असावा आणि कोणत्याही प्रकारच्या network share वर ठेवू नये, असे सांगितले आहे. याचे कारण vector आणि index lookups हे लहान random reads असतात. त्यामुळे network volume मुळे प्रत्येक lookup साठी round trip आवश्यक होते. यावर plan ची निवड अवलंबून असल्यास, VPS वरील NVMe आणि SATA SSD storage यांमधील फरक या stack मधील इतर कोणत्याही भागापेक्षा येथे अधिक महत्त्वाचा ठरतो.

redis Valkey image चालवते आणि job queues साठवते. चारही सेवांमध्ये ही सेवा मोठ्या फरकाने सर्वात कमी मेमरी वापरते, कारण ती photo data ऐवजी job records साठवते.

immich-machine-learning ही सेवा तुमच्या plan चा आकार ठरवते. ती smart search, face detection आणि text recognition साठी models load करते. Load केलेला model मेमरीमध्येच राहतो. MACHINE_LEARNING_MODEL_TTL चे default मूल्य 300 आहे. त्यामुळे कोणतीही विनंती नसल्यास पाच मिनिटांनंतर model काढून टाकला जातो आणि पुढील विनंती आल्यावर /cache volume मधून पुन्हा वाचला जातो. Bulk import दरम्यान पाच मिनिटांचा खंड कधीच पडत नाही. त्यामुळे पहिल्या asset पासून शेवटच्या asset पर्यंत models load राहतात.

आयाताच्या वेळी काय बदलते

Idle Immich शांत असते. लहान सर्व्हरवर आयात करताना समस्या निर्माण होतात, कारण एक asset upload केल्यावर jobs ची साखळी queue मध्ये लागते आणि अनेक queues एकाच वेळी चालतात.

Metadata extraction फाइलचा header वाचते आणि त्यासाठी कमी संसाधने लागतात. Thumbnail generation साठी अधिक संसाधने लागतात. Immich प्रत्येक asset साठी तीन thumbnail outputs तयार करते: blurred thumbhash placeholder, WebP preview आणि JPEG thumbnail. तसेच आढळलेल्या प्रत्येक चेहऱ्यासाठी आणखी एक thumbnail तयार होतो. यापैकी प्रत्येक job image decode करतो. एकाच वेळी किती images decode करायच्या हे job concurrency ठरवते. Concurrency हा प्रत्येक job च्या कमी खर्चाला संपूर्ण सर्व्हरवरील खर्चात रूपांतरित करणारा multiplier आहे. त्यामुळे मर्यादित क्षमतेच्या मशीनवर सर्वप्रथम concurrency कमी करण्याची सूचना Immich FAQ मध्ये केली आहे. Administration, Settings, Job Settings अंतर्गत heavy 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 साठी हा सर्वात प्रतिकूल टप्पा असतो आणि तो एकदाच येतो.

चेहरा आणि ऑब्जेक्ट ओळखीसाठी सर्वाधिक RAM का आवश्यक असते

चेहऱ्यांशी संबंधित प्रक्रिया दोन कामांमध्ये विभागली जाते. Face detection मशीन लर्निंग कंटेनरमध्ये model चालवते आणि चेहऱ्यांच्या चौकटी शोधते. Facial recognition नंतर या detections चे लोकांनुसार गट तयार करते आणि त्यासाठी Postgres मधील vector index ला query करते. त्यामुळे मोठी library दोन्ही services वर अनुक्रमे भार टाकते: detection चालू असताना model container वर आणि grouping चालू असताना database वर.

चार settings मशीन लर्निंग कंटेनरमध्ये किती माहिती ठेवली जाते ते बदलतात.

• Face model. Immich मध्ये default म्हणून buffalo_l येते आणि लहान server साठी FAQ मध्ये buffalo_s ची शिफारस केली आहे. हे model लहान असल्यामुळे कमी memory वापरते आणि जलद चालते. मात्र लहान किंवा बाजूने दिसणाऱ्या चेहऱ्यांवरील 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 करता येणाऱ्या चेहऱ्यांची कमाल संख्या ठरवते. Batch एकत्र memory मध्ये ठेवला जातो. त्यामुळे चाळीस चेहऱ्यांचा group photo एका portrait पेक्षा अधिक memory वापरतो.
• कोणते model types प्रत्यक्षात चालतील. Smart search, face detection आणि text recognition यापैकी प्रत्येकासाठी स्वतंत्र models load होतात. Administration, Settings, Machine Learning Settings अंतर्गत न वापरणारे models बंद केल्यास imports दरम्यानच नव्हे तर कायमची त्यांची memory मोकळी होते.

MACHINE_LEARNING_MODEL_ARENA ही setting देखील आहे. तिचे documentation CPU memory चे pre-allocation करून fragmentation टाळते असे सांगते आणि ती default ने enabled असते. ही setting शेवटी बदला. तिचा परिणाम 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": "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 मध्ये टाकायच्या मर्यादा म्हणून समजा; Immich किती memory वापरते याचे मोजमाप म्हणून नाही. मर्यादा ही कमाल सीमा असते. ती कोणतीही memory राखून ठेवत नाही आणि सेवालाही लहान करत नाही. सर्व्हरची memory संपल्यावर kernel कोणती सेवा kill करेल हे ती ठरवते. हा निर्णय kernel च्या स्वतःच्या scoring पेक्षा तुम्ही घेणे अधिक योग्य आहे.

2 GB सर्व्हर: machine learning container काढा

2 GB ही 6 GB या दस्तऐवजीकृत किमान आवश्यकतेपेक्षा कमी आहे. त्यामुळे हा तडजोडीचा पर्याय आहे, हे स्पष्टपणे लक्षात घ्या. docker-compose.yml मधील संपूर्ण immich-machine-learning service comment out करा. किंवा ती चालू ठेवा आणि Administration, Settings, Machine Learning Settings अंतर्गत प्रत्येक model disable करा. Container काढणे अधिक प्रभावी आहे, कारण disable केलेले model तरीही Python process memory मध्ये ठेवते.

तुमच्याकडे uploads, albums, sharing, mobile backup, thumbnails आणि date, place व filename नुसार search उपलब्ध राहतात. Description नुसार search, faces चे people मध्ये automatic grouping आणि images मधील text recognition उपलब्ध राहणार नाही.

चार मर्यादांची बेरीज सुमारे 1.7 GB होते. त्यामुळे host साठी अंदाजे 300 MB उरतात. Database साठी 768 MB ही documented 2 GB minimum पेक्षा कमी आहे, हे लक्षात घ्या. 2 GB मुळे हीच तडजोड करावी लागते. म्हणून येथे Postgres service kill होण्याची शक्यता सर्वाधिक असते.

सर्वप्रथम browsing नाही, तर import मध्ये अडचण येते. दहा हजारांच्या आसपासच्या कमी-अधिक photos असलेली library एकदा import झाल्यावर स्वीकारार्ह वेगाने browse करता येते. कारण page दाखवण्यासाठी metadata query आणि file read एवढेच आवश्यक असते. त्याच सर्व्हरवर video-heavy import केल्यास swap वापरला जातो. कारण transcode आणि thumbnail queue यांना एकाच वेळी memory हवी असते. प्रत्येक heavy queue ची concurrency 1 वर सेट करा आणि swap file जोडा.

4 GB सर्व्हर: machine learning सुरू, एका वेळी एक job

4 GB ही face आणि object recognition सुरू करण्यासाठी योग्य ठरणारी सर्वात लहान क्षमता आहे. Machine learning container ची मर्यादा 0 MB ठेवा, facial recognition buffalo_s वर switch करा आणि thumbnail generation, face detection व smart search साठी job concurrency 1 ठेवा.

विद्यमान library वरचा पहिला pass अनेक तास चालेल. मोठ्या library साठी तो एका दिवसापेक्षाही जास्त वेळ घेऊ शकतो. ही memory पेक्षा CPU ची मर्यादा आहे. त्यामुळे अधिक RAM मुळे हा कालावधी कमी होणार नाही.

पहिल्या bulk pass दरम्यान येथे machine learning container मध्ये सर्वप्रथम अडचण येते. मर्यादा नसेल, तर transcode job वाढत असतानाच तेही वाढते. त्यानंतर kernel या दोन्हींपैकी मोठे process kill करते. docker ps -a मध्ये Exited (137) दिसते आणि container पुन्हा सुरू होते. तुम्ही शेवटचे पाहिले होते त्यापेक्षा queue मागे गेलेली असते, पण ते शांतपणे घडते.

8 GB सर्व्हर: दस्तऐवजीकृत शिफारस

4 cores असलेली 8 GB क्षमता Immich च्या शिफारशीशी जुळते. त्यामुळे smart search, face detection, text recognition आणि transcoding हे सर्व default settings आणि default concurrency सह चालतात. एक लाखांपेक्षा जास्त assets असलेल्या libraries येथे सहज हाताळता येतात. या टप्प्यावर दबाव memory पेक्षा disk speed वर येतो, कारण vector index आणि metadata queries हे database दिवसभर हाताळत असते.

तरीही limits सेट करा. पुरेशी memory असलेल्या सर्व्हरवर एखादी runaway queue database ला देखील खाली आणू नये, यासाठी limits उपयोगी ठरतात. लहान पर्यायांच्या तुलनेत किंमत मोजत असाल, तर memory tier नुसार VPS ची प्रत्यक्ष किंमत पाहिल्यावर tuning थांबवण्याचा 8 GB plan सहसा सर्वात स्वस्त मार्ग ठरतो.

Compose limits वापरून प्रत्येक सेवेसाठी memory मर्यादा कशी ठरवावी

यासाठी docker-compose.yml संपादित करू नका. wget वापरून upgrade केल्यावर ती file प्रत्येक वेळी बदलली जाते. तिच्या शेजारी docker-compose.override.yml मध्ये limits द्या; docker compose ती configuration आपोआप 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 मध्ये आता host ची एकूण memory न दाखवता MEM USAGE / LIMIT column मध्ये तुम्ही ठरवलेली कमाल मर्यादा दिसली पाहिजे. Limit column मध्ये अजूनही host ची पूर्ण memory दिसत असल्यास override file स्वीकारली गेलेली नाही. File चे नाव तपासा आणि merge झालेला result पाहण्यासाठी docker compose config चालवा.

खूप कमी limit ठेवल्यास slow service बंद पडू शकते. Container वारंवार restart होत असल्यास limit वाढवा. यामागील कार्यपद्धतीची अधिक माहिती Docker Compose मध्ये प्रत्येक सेवेसाठी memory limits ठरवणे येथे आहे. Compose v2 वापरताना deploy हे Swarm च्या बाहेर का कार्य करते, हेही तेथे स्पष्ट केले आहे.

मशीन लर्निंग कंटेनर कसा बंद करावा किंवा दुसरीकडे हलवावा

लहान सर्व्हरवर हा कंटेनर दुसरीकडे हलवणे हा तुम्ही करू शकणारा सर्वात मोठा बदल आहे. Immich हा कंटेनर दुसऱ्या मशीनवर चालवण्याचे समर्थन करते. दुसऱ्या host वर ही फाइल तयार करा. हा host फक्त संध्याकाळी सुरू असणारा 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 वर क्लिक करा आणि http://<host>:3003 प्रविष्ट करा. दोन्ही host वर एकच version ठेवा. दोन्हीमधील version mismatch मुळे bugs आणि instability निर्माण होतात, असा Immich docs मध्ये इशारा दिला आहे.

हा port तुमचे photos दुसऱ्या मशीनवर unencrypted स्वरूपात पाठवतो. त्यामुळे तो private network वरच ठेवा किंवा दोन्ही host मधील WireGuard tunnel वरून चालवा. 3003 इंटरनेटवर कधीही expose करू नका.

Resident model container हीच समस्या असेल, तर plan size ठरवण्यापूर्वी PhotoPrism आणि Immich मध्ये स्थिर स्थितीत कोणते components चालतात यांची तुलना कशी करावी हे पाहणेही योग्य ठरेल.

Immich लायब्ररीसाठी किती डिस्क जागा आवश्यक आहे?

एकच गुणक लागू होत नाही, कारण चार वेगवेगळ्या गोष्टी वेगवेगळ्या दराने वाढतात. येथे 50,000 फोटो आणि 500 लघु व्हिडिओ असलेल्या लायब्ररीसाठी गणना दिली आहे.

[
  {
    "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 फोटो आणि 60 GB व्हिडिओ ही गृहीते आहेत. काहीही खरेदी करण्यापूर्वी ती तुमच्या सरासरी आकारांनी बदला, कारण हा आकडा व्हिडिओवर ठरतो: फोनवरील एक मिनिटाचा व्हिडिओ शंभर फोटोंपेक्षा मोठा असतो.

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 ची ओळ हा Immich कडून दिलेला एकमेव प्रकाशित अनुपात आहे: तयार केलेली thumbnails आणि transcoded व्हिडिओ लायब्ररीच्या आकारात सरासरी 10 ते 20 टक्के भर घालतात. ही श्रेणी आहे, कारण browser compatibility साठी पुन्हा encoding आवश्यक असलेल्या assets पैकी किती व्हिडिओ आहेत यावर तो आकार अवलंबून असतो. JPEG लायब्ररी साधारणपणे या श्रेणीच्या खालच्या टोकाला येते.

Database 3 GB आहे आणि हा आकार जवळजवळ निश्चित असतो. Immich च्या दस्तऐवजानुसार database files साधारणपणे 1 ते 3 GB असतात, कारण त्यात pixels ऐवजी metadata आणि search vectors साठवलेले असतात. Model cache 2 GB आहे. तुम्ही अनेक models enable केले किंवा वेगवेगळी models तपासली, तर तो वाढतो. याच कारणामुळे FAQ मध्ये हा volume space consumer म्हणून नमूद केला आहे.

या पाच ओळींची बेरीज 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 पुनर्निर्माण करता येत नाहीत; बाकी सर्व त्यांच्यापासून पुन्हा तयार करता येते.

दोन गोष्टींमुळे अनेकांना आश्चर्य वाटते. Deleted assets प्रथम trash मध्ये जातात आणि trash रिकामा करेपर्यंत त्यांची जागा वापरत राहतात. त्यामुळे मोठी cleanup केल्यानंतर त्याच दिवशी जागा मोकळी होत नाही. तसेच 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 वापरले जाते आणि साध्या VPS वर प्रत्येक frame चे decoding आणि encoding CPU कडून केले जाते. Hardware acceleration उपलब्ध असली तरी Immich च्या दस्तऐवजानुसार ती फक्त encoding साठी असते. त्यामुळे 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 मध्ये सुचवल्याप्रमाणे तेथे ही value 1 किंवा 2 सेट करा. त्यामुळे transcode disruptive न होता फक्त slow होईल.

swap thrashing मुळे import अडकलेला का दिसतो

लोक सर्वाधिक चुकीचा अर्थ लावतात ते failure हेच आहे. Immich ची memory संपल्यावर दोन परिणाम होतात. त्यापैकी फक्त एकच failure सारखा दिसतो.

swap नसल्यास kernel एखादी process बंद करते. Container काही सेकंदांत पुन्हा सुरू होतो. त्यामुळे 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 ने बंद केली गेली. 137 म्हणजे 128 अधिक 9. OOMKilled ची true value असल्यास process crash मुळे नव्हे, तर memory अभावी बंद केली गेली हे निश्चित होते.

swap असल्यास काहीही बंद केले जात नाही आणि कोणतीही error येत नाही. Kernel pages disk वर हलवू लागतो. Import चा वेग अनेक पटींनी कमी होतो आणि web interface सामान्य timeout मध्ये प्रतिसाद देणे थांबवते. प्रत्येक container चालू असतो. प्रत्येक health check अजूनही यशस्वी होऊ शकतो. हे hang सारखे दिसते. त्या वेळी लोक box reboot करतात. त्यामुळे queue ची प्रगती गमावली जाते आणि समस्या बदलत नाही.

free -m
vmstat 1 5

vmstat च्या si आणि so columns मध्ये सतत non zero values दिसत असल्यास machine सतत swap वाचत आणि लिहित आहे. यालाच thrashing म्हणतात. त्याच वेळी Swap साठी free -m row मधील वापरलेली value वाढत जाते.

2 GB किंवा 4 GB box वर swap तरी जोडा. कारण निदान करता येणारा धीमा import, निदान करता न येणाऱ्या बंद झालेल्या 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 यासाठी वेळ मिळवून देते. Swap स्वतःहून उपाय नाही.

FAQ

मी Immich 2 GB VPS वर चालवू शकतो का?

होय. docker-compose.yml मधील immich-machine-learning सेवा comment out करून आणि job concurrency 1 वर सेट करून ते चालवता येते. हे दस्तऐवजीकरणातील 6 GB या किमान आवश्यकतेपेक्षा कमी आहे. त्यामुळे ही ज्ञात तडजोड मानावी. Uploads, albums, sharing, mobile backup आणि date, place व filename नुसार search सुविधा उपलब्ध राहतात. Description नुसार search, faces चे people मध्ये automatic grouping आणि images मधील text recognition उपलब्ध राहणार नाही. 2 GB ची swap file जोडा. त्यामुळे import दरम्यान server धीमा होईल, पण container kill होण्याची शक्यता कमी होईल.

माझा Immich import कोणताही error message न दाखवता का थांबतो?

Browser मध्ये दोन वेगवेगळी कारणे सारखीच दिसतात. एकतर memory अभावी container kill झालेला असतो. अशा वेळी docker ps -a मध्ये Exited (137) दिसते आणि container पुन्हा सुरू झालेला असतो. किंवा 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 ची स्वतःची असू शकते किंवा 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 असतो.

प्रत्येक photo साठी Immich ला किती disk space आवश्यक आहे?

Original file इतकी जागा आणि त्यावर 10 ते 20 टक्के अतिरिक्त जागा राखून ठेवा. Immich च्या दस्तऐवजीकरणानुसार generated thumbnails आणि transcoded video मुळे library size सरासरी 10 ते 20 टक्क्यांनी वाढते. मोठी library असली तरी database ला साधारणपणे 1 ते 3 GB जागा लागते. तुमच्या एकूण वापराचा मुख्य निर्धारक video असतो. त्यामुळे photo count वर multiplier लागू करण्याऐवजी plan निवडण्यापूर्वी तुमच्या files ची सरासरी size मोजा.

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 चालू द्या.