Immich کو کتنی RAM اور disk space درکار ہے؟

Immich کو کتنی RAM درکار ہوتی ہے؟

Immich اپنی دستاویزی کم از کم ضرورت کے طور پر 6 GB RAM (random access memory) اور تجویز کردہ مقدار کے طور پر 8 GB RAM مانگتا ہے۔ کم از کم تنصیب کے لیے 2 CPU cores اور آرام دہ استعمال کے لیے 4 CPU cores درکار ہیں۔ یہ مقدار پورے stack کے لیے ہے، کیونکہ Immich ایک ایپلیکیشن کے بجائے چار 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 کے ساتھ کیا ہوگا۔

ایک حقیقی سخت حد موجود ہے۔ Immich version 3 اور اس کے بعد کے versions کو amd64 hosts پر x86-64-v2 CPU درکار ہوتا ہے۔ اس میں تقریباً 2012 کے بعد فروخت ہونے والے زیادہ تر processors شامل ہیں۔ پرانے hardware پر container سست چلنے کے بجائے start ہونے میں ناکام ہو جاتا ہے۔

اگر installation ابھی باقی ہے تو پہلے Docker Compose کے ساتھ VPS پر مکمل Immich installation شروع کریں، پھر server کی capacity طے کرنے کے لیے یہاں واپس آئیں۔

میموری کہاں استعمال ہوتی ہے: چار containers

سرکاری Compose file چار services شروع کرتی ہے۔ ہر service کا memory profile مختلف ہے، اس لیے مجموعی memory ایک ایسا اہم فرق چھپا دیتی ہے جو جاننا ضروری ہے۔

immich-server web interface اور API فراہم کرتا ہے، اور background job workers بھی چلاتا ہے۔ دو workers اسی ایک container کے اندر رہتے ہیں۔ api browser اور mobile app سے آنے والی requests کا جواب دیتا ہے۔ microservices queues چلاتا ہے، جن میں thumbnail generation اور video encoding شامل ہیں۔ variables IMMICH_WORKERS_INCLUDE اور IMMICH_WORKERS_EXCLUDE ان دونوں کو الگ containers میں تقسیم کرتے ہیں۔ اس طرح زیادہ memory استعمال کرنے والے حصے کے لیے اپنی memory limit مقرر کی جا سکتی ہے، جبکہ آپ کی photos فراہم کرنے والے حصے پر حد عائد نہیں ہوتی۔

database ایک PostgreSQL 14 image ہے جس میں VectorChord extension شامل ہے۔ یہ تمام metadata اور ہر asset کے لیے ایک search vector محفوظ کرتا ہے۔ Immich docs stack میں اسی service کے لیے واحد واضح کم از کم حد مقرر کرتی ہیں: اگر آپ 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 محفوظ کرتا ہے۔ یہ چاروں میں واضح طور پر سب سے کم memory استعمال کرتا ہے، کیونکہ یہ photo data کے بجائے job records محفوظ کرتا ہے۔

immich-machine-learning وہ service ہے جو آپ کے plan size کا فیصلہ کرتی ہے۔ یہ smart search، face detection اور text recognition کے لیے models load کرتی ہے، اور load کیا ہوا model memory میں موجود رہتا ہے۔ MACHINE_LEARNING_MODEL_TTL کی default value 300 ہے، اس لیے requests نہ آنے کی صورت میں model پانچ منٹ بعد memory سے ہٹا دیا جاتا ہے اور اگلی request پر /cache volume سے دوبارہ پڑھا جاتا ہے۔ Bulk import کے دوران کبھی پانچ منٹ کا وقفہ نہیں آتا، اس لیے models پہلے asset سے آخری asset تک load رہتے ہیں۔

درآمد کے دوران کیا تبدیل ہوتا ہے

غیر فعال Immich خاموش رہتا ہے۔ مسئلہ درآمد کے دوران پیدا ہوتا ہے، کیونکہ ایک asset اپ لوڈ کرنے سے jobs کا ایک سلسلہ queue میں شامل ہو جاتا ہے اور کئی queues بیک وقت چلتی ہیں۔

Metadata extraction فائل کا header پڑھتی ہے اور اس پر کم وسائل خرچ ہوتے ہیں۔ Thumbnail generation زیادہ وسائل استعمال کرتی ہے۔ Immich ہر asset کے لیے تین thumbnail outputs بناتا ہے: ایک blurred thumbhash placeholder، ایک WebP preview، اور ایک JPEG thumbnail۔ اس کے علاوہ ہر detected face کے لیے ایک اور thumbnail بنتا ہے۔ ہر job کے دوران image decode ہوتی ہے، اور job concurrency طے کرتی ہے کہ ایک وقت میں کتنی images decode ہوں گی۔ Concurrency وہ multiplier ہے جو ہر job کی کم لاگت کو پورے server کی لاگت میں بدل دیتا ہے۔ اسی لیے محدود وسائل والی machine پر Immich FAQ اسے کم کرنے والی پہلی setting قرار دیتا ہے۔ Administration، Settings، Job Settings کے تحت بھاری queues کی concurrency کو 1 پر مقرر کریں۔

Video assets میں transcoding بھی شامل ہوتی ہے۔ ہر transcode job ایک الگ FFmpeg process چلاتی ہے، جس کے لیے اپنی memory درکار ہوتی ہے۔ یہ process آپ کی اجازت کے مطابق CPU کے تمام threads استعمال کرے گا۔

Smart search ہر نئے asset کو machine learning container میں بھیجتا ہے، جہاں ایک embedding vector تیار کیا جاتا ہے۔ Face detection اسی image پر دوسرا model چلاتی ہے۔ موجودہ photo library کی پہلی import کے دوران یہ دونوں queues آپ کے ہر asset پر کئی گھنٹوں تک چلتی ہیں۔ پوری installation میں memory پر سب سے زیادہ دباؤ اسی وقت پڑتا ہے، اور یہ عمل صرف ایک بار ہوتا ہے۔

چہرے اور اشیا کی شناخت کے لیے سب سے زیادہ RAM کیوں درکار ہوتی ہے

چہرے سے متعلق کارروائی دو کاموں پر مشتمل ہوتی ہے۔ 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 میں کیا موجود رہتا ہے۔

• Face model۔ Immich بطور default buffalo_l فراہم کرتا ہے، جبکہ FAQ چھوٹے server پر buffalo_s استعمال کرنے کی تجویز دیتی ہے۔ یہ چھوٹا model ہے، اس لیے کم memory استعمال کرتا ہے اور زیادہ تیزی سے چلتا ہے، لیکن چھوٹے یا ایک طرف رخ کیے ہوئے چہروں کی شناخت میں accuracy کم ہو سکتی ہے۔
• Worker count۔ MACHINE_LEARNING_WORKERS کی default value 1 ہے۔ ہر worker ایک الگ process ہوتا ہے جو models کی اپنی copy load کرتا ہے، اس لیے اسے 2 کرنے سے resident model memory تقریباً دوگنی ہو جاتی ہے۔ اسے 1 ہی رہنے دیں، الاّ یہ کہ اضافی RAM دستیاب ہو۔
• 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 کے تحت جن features کو آپ استعمال نہیں کرتے انہیں بند کرنے سے ان کی memory ہمیشہ کے لیے آزاد ہو جاتی ہے، صرف imports کے درمیان نہیں۔

ایک اور setting MACHINE_LEARNING_MODEL_ARENA بھی ہے، جسے fragmentation سے بچنے کے لیے CPU memory پہلے سے allocate کرنے کے طور پر document کیا گیا ہے، اور یہ بطور default enabled ہوتی ہے۔ اسے آخر میں تبدیل کریں۔ اس کا اثر بنیادی 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 میں درج کی جانے والی limits سمجھیں، نہ کہ اس بات کی پیمائش کہ Immich کتنا memory استعمال کرتا ہے۔ Limit ایک بالائی حد ہوتی ہے۔ یہ کوئی memory reserve نہیں کرتی اور نہ ہی service کو چھوٹا بناتی ہے۔ جب box کی memory ختم ہو جائے تو یہ طے کرتی ہے کہ kernel کس service کو ختم کرے گا۔ یہ فیصلہ kernel کے اپنے scoring نظام کے بجائے آپ کا کیا ہوا بہتر ہوتا ہے۔

2 GB کا box: machine learning container ہٹا دیں

2 GB، 6 GB کی documented minimum requirement سے کم ہے۔ اس لیے یہ ایک سمجھوتا ہے، اور اسے اسی نام سے بیان کرنا چاہیے۔ docker-compose.yml میں پوری immich-machine-learning service کو comment out کر دیں، یا اسے چلتا رہنے دیں اور Administration، Settings، Machine Learning Settings کے تحت ہر model کو disable کر دیں۔ Container ہٹانا زیادہ مؤثر طریقہ ہے، کیونکہ disabled model کے باوجود Python process memory میں موجود رہتا ہے۔

آپ uploads، albums، sharing، mobile backup، thumbnails، اور date، place اور filename کے مطابق search برقرار رکھتے ہیں۔ آپ description کے مطابق search، چہروں کو لوگوں کے گروپس میں خودکار طور پر تقسیم کرنا، اور images کے اندر text recognition سے محروم ہو جاتے ہیں۔

چاروں limits کا مجموعہ تقریباً 1.7 GB ہے، جس سے host کے لیے تقریباً 300 MB بچتی ہے۔ نوٹ کریں کہ database کے لیے 768 MB، documented 2 GB floor سے کم ہے۔ یہی وہ سمجھوتا ہے جو 2 GB لازمی بناتا ہے، اور اسی وجہ سے یہاں Postgres کے ختم کیے جانے کا امکان سب سے زیادہ ہے۔

سب سے پہلے import متاثر ہوتا ہے، browsing نہیں۔ دسیوں ہزار photos پر مشتمل library، شامل ہو جانے کے بعد قابل قبول رفتار سے browse ہوتی ہے، کیونکہ page پیش کرنا metadata query اور file read کا مجموعہ ہے۔ اسی box پر video-heavy import ہونے کی صورت میں swap استعمال ہوگا، کیونکہ transcode اور thumbnail queue کو ایک ہی وقت میں memory درکار ہوتی ہے۔ ہر heavy queue کی concurrency کو 1 پر set کریں اور swap file شامل کریں۔

4 GB کا box: machine learning فعال، ایک وقت میں ایک job

4 GB وہ سب سے چھوٹا size ہے جہاں face اور object recognition فعال کرنا مفید رہتا ہے۔ Machine learning container کو 0 MB تک محدود کریں، facial recognition کو buffalo_s پر switch کریں، اور thumbnail generation، face detection اور smart search کے لیے job concurrency کو 1 پر set کریں۔

موجودہ library پر پہلی processing کئی گھنٹے چل سکتی ہے، اور بڑی library پر ایک دن سے زیادہ بھی لگ سکتا ہے۔ یہ memory کے بجائے CPU limit ہے، اس لیے زیادہ RAM اس عمل کو مختصر نہیں کرے گی۔

یہاں پہلی bulk processing کے دوران machine learning container سب سے پہلے متاثر ہوتا ہے۔ اگر اسے محدود نہ کیا جائے تو یہ بڑھتا رہتا ہے، جبکہ transcode job بھی memory استعمال کرتی رہتی ہے، اور kernel دونوں میں سے بڑی service کو ختم کر دیتا ہے۔ آپ docker ps -a میں Exited (137) دیکھتے ہیں اور container دوبارہ شروع ہو جاتا ہے، جبکہ queue آپ کے آخری جائزے کے مقابلے میں خاموشی سے مزید پیچھے رہ جاتی ہے۔

8 GB کا box: documented recommendation

8 GB اور 4 cores، Immich کی recommended configuration سے مطابقت رکھتے ہیں، اور default settings پر سب کچھ چلتا ہے: smart search، face detection، text recognition اور transcoding، default concurrency کے ساتھ۔ ایک لاکھ سے زیادہ assets والی libraries یہاں اطمینان سے چلتی ہیں، اور دباؤ memory کے بجائے disk speed پر منتقل ہو جاتا ہے، کیونکہ vector index اور metadata queries ہی وہ کام ہیں جو database سارا دن انجام دیتا ہے۔

اس کے باوجود limits set کریں۔ اضافی گنجائش والے box میں limits ایک runaway queue کو database کو بھی متاثر کرنے سے روکتی ہیں۔ اگر آپ اس configuration کا موازنہ چھوٹے options سے لاگت کی بنیاد پر کر رہے ہیں تو memory tier کے لحاظ سے VPS کی اصل لاگت عموماً 8 GB plan کو tuning روکنے کا سب سے سستا طریقہ بناتی ہے۔

Compose limits کے ساتھ ہر service کے لیے memory حد مقرر کرنے کا طریقہ

اس مقصد کے لیے docker-compose.yml میں ترمیم نہ کریں۔ 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 کا مکمل size دکھائی دے تو override file load نہیں ہوئی۔ File name کی جانچ کریں اور merged نتیجہ دیکھنے کے لیے docker compose config چلائیں۔

بہت کم limit کسی سست service کو بند کر سکتی ہے۔ اگر container بار بار restart ہو تو limit بڑھا دیں۔ اس طریقۂ کار کی مزید وضاحت Docker Compose میں ہر service کے لیے memory limits مقرر کرنا میں موجود ہے، جس میں یہ بھی بتایا گیا ہے کہ deploy، Compose v2 کے ساتھ Swarm کے بغیر کیوں کام کرتا ہے۔

مشین لرننگ container کو بند یا منتقل کرنے کا طریقہ

چھوٹے سرور پر اس 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 کو unencrypted حالت میں دوسری machine تک پہنچاتا ہے۔ اس لیے اسے private network پر رکھیں یا دونوں hosts کے درمیان WireGuard tunnel کے ذریعے چلائیں۔ 3003 کو کبھی internet پر expose نہ کریں۔

اگر resident model container کا پورا تصور ہی مسئلہ ہے تو یہ بھی ایک معقول وجہ ہے کہ plan size طے کرنے سے پہلے PhotoPrism اور Immich کے idle حالت میں چلنے والے اجزا کا فرق کا جائزہ لیا جائے۔

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 محض مفروضے ہیں۔ کچھ خریدنے سے پہلے انہیں اپنی اوسط کے مطابق تبدیل کریں، کیونکہ یہ مقدار ویڈیو طے کرتی ہے: فون کی ایک منٹ کی ویڈیو 100 تصاویر سے زیادہ بڑی ہوتی ہے۔

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 فیصد اضافہ کرتے ہیں۔ یہ ایک حد ہے، کیونکہ اس کا انحصار اس بات پر ہے کہ آپ کے کتنے assets کو browser compatibility کے لیے دوبارہ encode کرنا پڑتا ہے۔ JPEGs پر مشتمل لائبریری اس حد کے نچلے حصے کے قریب رہتی ہے۔

Database 3 GB کا ہے، اور یہ تقریباً مستقل لاگت ہے۔ Immich کے مطابق database files عموماً 1 سے 3 GB کی ہوتی ہیں، کیونکہ ان میں pixels کے بجائے metadata اور search vectors محفوظ ہوتے ہیں۔ Model cache 2 GB کا ہے اور اگر آپ کئی models فعال کریں یا مختلف models آزمائیں تو یہ بڑھتا ہے۔ FAQ اسی وجہ سے اس volume کو space consumer قرار دیتا ہے۔

پانچوں قطاروں کا مجموعہ 300 GB سے کچھ زیادہ بنتا ہے، اس لیے 500 GB کا volume اضافے کے لیے گنجائش چھوڑتا ہے، جبکہ 250 GB کا volume کافی نہیں ہوتا۔ یہ تقسیم دیکھنے کے لیے چلائیں:

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

UPLOAD_LOCATION کے تحت چھ folders موجود ہیں۔ upload اور library originals رکھتے ہیں، thumbs previews اور face thumbnails رکھتا ہے، encoded-video دوبارہ encode کی گئی copies رکھتا ہے، profile avatars رکھتا ہے، اور backups خودکار 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 سے server سے باہر storage پر restic backups استعمال ہوتے ہیں۔

Transcoding میں RAM نہیں بلکہ CPU استعمال ہوتی ہے

RAM بڑھانے سے transcoding تیز نہیں ہوگی۔ Immich، FFmpeg کے ذریعے transcoding کرتا ہے، اور عام VPS پر ہر frame کو CPU کے ذریعے decode اور encode کیا جاتا ہے۔ Hardware acceleration دستیاب ہونے کی صورت میں بھی Immich کی documentation کے مطابق صرف encoding تیز ہوتی ہے، اس لیے CPU software decoding اور tone mapping پھر بھی کرتا ہے۔

Hardware acceleration کے لیے اضافی hwaccel.transcoding.yml Compose file اور passthrough کے لیے ایک 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 کو منجمد کر سکتی ہے۔ Immich FAQ کی تجویز کے مطابق وہاں value 1 یا 2 مقرر کریں۔ اس طرح transcode سست ہوگا، لیکن دیگر خدمات متاثر نہیں ہوں گی۔

swap thrashing کی وجہ سے import کا معطل دکھائی دینا

یہ وہ failure ہے جسے لوگ سب سے زیادہ غلط سمجھتے ہیں۔ جب Immich کی memory ختم ہو جاتی ہے تو دو نتائج ممکن ہوتے ہیں، اور ان میں سے صرف ایک failure جیسا دکھائی دیتا ہے۔

Swap کے بغیر kernel کسی process کو ختم کر دیتا ہے۔ 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 کے ذریعے ختم کیا گیا۔ 137، 128 جمع 9 کے برابر ہے۔ OOMKilled کی true قدر اس بات کی تصدیق کرتی ہے کہ process memory کی کمی کی وجہ سے ختم ہوا، crash کی وجہ سے نہیں۔

Swap کے ساتھ کچھ بھی ختم نہیں ہوتا اور کوئی error بھی نہیں آتا۔ Kernel pages کو disk پر منتقل کرنا شروع کر دیتا ہے، import کی رفتار ایک order of magnitude تک کم ہو جاتی ہے، اور web interface معمول کے timeout کے اندر جواب دینا بند کر دیتا ہے۔ ہر container چل رہا ہوتا ہے۔ ہر health check اب بھی pass ہو سکتا ہے۔ یہ hang جیسا دکھائی دیتا ہے، اور لوگ اس مرحلے پر machine reboot کر دیتے ہیں، جس سے queue کی progress ضائع ہو جاتی ہے اور مسئلہ بھی حل نہیں ہوتا۔

free -m
vmstat 1 5

vmstat کے si اور so columns میں مسلسل non-zero values کا مطلب ہے کہ machine swap کو مسلسل read اور write کر رہی ہے۔ یہی thrashing کی تعریف ہے۔ اسی وقت Swap کے لیے free -m row بھی بڑھ رہی ہو گی۔

2 GB یا 4 GB کی machine پر swap ضرور شامل کریں، کیونکہ ایسا slow import جس کی تشخیص کی جا سکے، اس 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 کی memory محدود کریں، یا اسے اس host سے ہٹا دیں۔ Swap آپ کو یہ کام کرنے کے لیے وقت دیتا ہے۔ Swap بذاتِ خود حل نہیں ہے۔

FAQ

کیا میں Immich کو 2 GB VPS پر چلا سکتا ہوں؟

ہاں، بشرطیکہ immich-machine-learning سروس کو docker-compose.yml میں تبصرہ کر کے غیر فعال کیا جائے اور job concurrency کو 1 پر مقرر کیا جائے۔ یہ دستاویزی کم از کم ضرورت 6 GB سے کم ہے، اس لیے اسے ایک معلوم سمجھوتا سمجھیں۔ آپ uploads، albums، sharing، mobile backup، اور تاریخ، مقام اور filename کے ذریعے search برقرار رکھتے ہیں۔ آپ description کے ذریعے search، چہروں کو لوگوں کے گروپس میں خودکار طور پر تقسیم کرنا، اور images کے اندر text recognition کھو دیتے ہیں۔ 2 GB کی swap file شامل کریں تاکہ import کے دوران اچانک memory استعمال server کو سست کرے، container بند نہ ہو۔

میرا Immich import بغیر کسی error message کے کیوں رک جاتا ہے؟

Browser میں دو مختلف وجوہات ایک جیسی دکھائی دیتی ہیں۔ یا تو memory کی کمی کے باعث کوئی container بند کیا گیا ہے، جس صورت میں docker ps -a، Exited (137) دکھاتا ہے اور container پہلے ہی دوبارہ شروع ہو چکا ہوتا ہے؛ یا host swapping کر رہا ہے، جس صورت میں ہر container اب بھی چل رہا ہوتا ہے اور سب کچھ صرف بہت سست ہوتا ہے۔ vmstat 1 5 دونوں صورتوں میں فرق واضح کرتا ہے: si اور so columns میں مسلسل non zero اعداد swapping کی نشاندہی کرتے ہیں۔ دونوں صورتوں میں thumbnail generation، face detection اور smart search کے لیے job concurrency کم کریں۔

Immich logs میں exit code 137 کا کیا مطلب ہے؟

137، 128 جمع signal 9 کے برابر ہے، اس لیے process کو SIGKILL کے ذریعے بند کیا گیا۔ عملی طور پر اس کا مطلب ہے کہ memory کی حد پوری ہو گئی، خواہ وہ container کی اپنی limit ہو یا host کی memory ختم ہو گئی ہو۔ docker inspect immich_machine_learning | grep -i oomkilled سے جانچ کریں۔ true کی قدر اس بات کی تصدیق کرتی ہے کہ kernel نے memory کی وجہ سے اسے بند کیا، جبکہ free -m اور sudo dmesg -T | grep -i oom-kill پھر یہ بتاتے ہیں کہ وجہ container limit تھی یا پورا host۔ عموماً machine learning container متاثر ہوتا ہے، کیونکہ یہ عام طور پر سب سے بڑا process ہوتا ہے۔

Immich کو فی photo کتنی disk space درکار ہوتی ہے؟

اصل file کے علاوہ 10 سے 20 فیصد اضافی جگہ مختص کریں۔ Immich کی دستاویزات کے مطابق generated thumbnails اور transcoded video library کا حجم اوسطاً 10 سے 20 فیصد بڑھاتے ہیں، جبکہ database خود بھی بڑی library کے لیے عموماً 1 سے 3 GB ہوتا ہے۔ آپ کے کل storage کا اصل تعین video کرتا ہے، اس لیے plan منتخب کرنے سے پہلے اپنے اوسط 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 کو رات بھر چلنے دیں۔