Immich চালানোর জন্য কতটুকু RAM ও স্টোরেজ প্রয়োজন?

Immich-এর কত RAM প্রয়োজন?

Immich-এর নথিভুক্ত ন্যূনতম প্রয়োজন 6 GB RAM (random access memory)। আর প্রস্তাবিত পরিমাণ হলো 8 GB। কমপক্ষে 2টি CPU core এবং স্বচ্ছন্দ ব্যবহারের জন্য 4টি core প্রয়োজন। এই হিসাব পুরো stack-এর জন্য, কারণ Immich একটি application নয়; এটি চারটি container নিয়ে গঠিত। আগে থেকেই import করা library ব্রাউজ করতে খুব কম memory লাগে। Memory মূলত import-এর সময় ব্যবহৃত হয়। এর বেশিরভাগ যায় এমন একটি container-এ, যেটি আপনি বন্ধ করে রাখতে পারেন।

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

এগুলো October 2026 অনুযায়ী Immich-এর requirements page-এ প্রকাশিত পরিসংখ্যান। এগুলো sizing recommendation, startup-এর সময় software চলবে কি না তা যাচাই করার পরীক্ষা নয়। একই page-এ machine learning feature বন্ধ রেখে 4 GB-এর একটি ছোট setup-এর কথাও বলা আছে। এর নিচে কোনো configuration উল্লেখ করা হয়নি। ছোট server-এ পরিবর্তন হয় কোন background job শেষ হবে এবং memory শেষ হয়ে গেলে import-এর কী ফল হবে।

একটি বাস্তব hard limit আছে। Version 3 থেকে amd64 host-এ machine learning container-এর জন্য একটি x86-64-v2 CPU প্রয়োজন। আনুমানিক 2012 সাল থেকে বিক্রি হওয়া অধিকাংশ processor-এ এটি থাকে। এই requirement ওই container-এর ক্ষেত্রে প্রযোজ্য, server-এর ক্ষেত্রে নয়। তাই পুরোনো hardware-এ machine learning বন্ধ করতে পারেন, নিচে বর্ণিত পদ্ধতিতে এটি অন্য machine-এ চালাতে পারেন, অথবা v2.7.5 ব্যবহার করতে পারেন। Immich docs অনুযায়ী এটিই সর্বশেষ compatible version।

Install এখনও শুরু না করে থাকলে, প্রথমে Docker Compose ব্যবহার করে VPS-এ সম্পূর্ণ Immich install নির্দেশিকা অনুসরণ করুন। এরপর এখানে ফিরে এসে server-এর capacity নির্ধারণ করুন।

মেমরি কোথায় যায়: চারটি container

অফিশিয়াল Compose file চারটি service চালু করে। প্রতিটির memory ব্যবহারের ধরন আলাদা, তাই মোট একটি সংখ্যা দেখলে গুরুত্বপূর্ণ তথ্য আড়ালে থাকে।

immich-server web interface ও API সরবরাহ করে এবং background job worker-ও চালায়। ওই একটি container-এর ভেতরে দুটি worker থাকে। api browser ও mobile app থেকে আসা অনুরোধের উত্তর দেয়। microservices thumbnail তৈরি ও video encoding-সহ queue চালায়। IMMICH_WORKERS_INCLUDE এবং IMMICH_WORKERS_EXCLUDE variable এই দুটি কাজকে আলাদা container-এ ভাগ করে। এভাবেই photo সরবরাহকারী অংশের memory সীমাবদ্ধ না করেই বেশি resource ব্যবহারকারী অংশের জন্য আলাদা memory limit নির্ধারণ করা যায়।

database হলো VectorChord extension-সহ PostgreSQL 14 image। এতে সব metadata এবং প্রতিটি asset-এর জন্য একটি করে search vector থাকে। Immich docs এই service-এর জন্য stack-এ একমাত্র নির্দিষ্ট minimum উল্লেখ করেছে: Docker resource limit প্রয়োগ করলে database-এর অন্তত 2 GB প্রয়োজন। একই পৃষ্ঠায় বলা হয়েছে, database আদর্শভাবে local SSD storage-এ থাকা উচিত এবং কোনো ধরনের network share-এ রাখা উচিত নয়। কারণ vector ও index lookup ছোট ছোট random read, তাই network volume প্রতিটি lookup-কে একটি round trip-এ পরিণত করে। পরিকল্পনার সিদ্ধান্তটি যদি এটির ওপর নির্ভর করে, তাহলে VPS-এ NVMe ও SATA SSD storage-এর পার্থক্য এই stack-এর অন্য যেকোনো অংশের তুলনায় এখানে বেশি গুরুত্বপূর্ণ।

redis Valkey image চালায় এবং job queue ধরে রাখে। চারটির মধ্যে এটিই অনেক ব্যবধানে সবচেয়ে ছোট, কারণ এটি photo data নয়, job record সংরক্ষণ করে।

immich-machine-learning হলো আপনার plan-এর আকার নির্ধারণকারী service। এটি smart search, face detection এবং text recognition-এর জন্য model load করে, আর load করা model memory-তে স্থায়ীভাবে থাকে। MACHINE_LEARNING_MODEL_TTL-এর default মান 300। তাই কোনো request না থাকলে পাঁচ মিনিট পর model সরিয়ে ফেলা হয় এবং পরের request এলে /cache volume থেকে আবার পড়া হয়। Bulk import-এর সময় কখনোই পাঁচ মিনিটের বিরতি থাকে না, তাই প্রথম asset থেকে শেষ asset পর্যন্ত model load অবস্থায় থাকে।

ইমপোর্ট করার সময় যা পরিবর্তিত হয়

একটি idle Immich শান্ত থাকে। ইমপোর্টের সময় ছোট সার্ভারগুলো সমস্যার সম্মুখীন হয়, কারণ একটি অ্যাসেট আপলোড করলে তা একগুচ্ছ কাজের সারি (queue) তৈরি করে এবং একই সময়ে বেশ কয়েকটি সারি চলতে থাকে।

মেটাডেটা এক্সট্রাকশন ফাইলের হেডার পড়ে এবং এটি হালকা কাজ। থাম্বনেইল তৈরি করা তুলনামূলক ভারী কাজ। Immich প্রতিটি অ্যাসেটের জন্য তিনটি থাম্বনেইল আউটপুট তৈরি করে: একটি ঝাপসা thumbhash প্লেসহোল্ডার, একটি WebP প্রিভিউ এবং একটি JPEG থাম্বনেইল; এছাড়া প্রতিটি শনাক্ত করা মুখের জন্য আরও একটি করে থাম্বনেইল তৈরি হয়। এই প্রতিটি কাজ একটি ইমেজ ডিকোড করে এবং job concurrency নির্ধারণ করে যে একসাথে কয়টি ডিকোড হবে। Concurrency হলো সেই গুণক যা প্রতিটি কাজের ছোট খরচকে সার্ভার-ব্যাপী খরচে পরিণত করে, আর এই কারণেই Immich FAQ-তে সীমাবদ্ধ ক্ষমতার মেশিনে এটিকে সবার আগে কমানোর পরামর্শ দেওয়া হয়েছে। Administration, Settings, Job Settings-এ গিয়ে ভারী সারিগুলোর জন্য concurrency 1-এ সেট করুন।

ভিডিও অ্যাসেটগুলো ট্রান্সকোডিং যোগ করে। প্রতিটি ট্রান্সকোড জব একটি আলাদা FFmpeg প্রসেস, যার নিজস্ব মেমোরি থাকে এবং এটি আপনার অনুমতি দেওয়া প্রতিটি CPU থ্রেড ব্যবহার করবে।

স্মার্ট সার্চ প্রতিটি নতুন অ্যাসেটকে মেশিন লার্নিং কন্টেইনারে পাঠায় যাতে একটি এম্বেডিং ভেক্টর গণনা করা যায়। ফেস ডিটেকশন একই ইমেজের ওপর দ্বিতীয় একটি মডেল চালায়। বিদ্যমান ফটো লাইব্রেরির প্রথম ইমপোর্টের সময়, এই দুটি সারিই আপনার মালিকানাধীন প্রতিটি অ্যাসেটের ওপর ঘণ্টার পর ঘণ্টা ধরে চলতে থাকে। পুরো ইনস্টলেশনের মেমোরির জন্য এটিই সবচেয়ে কঠিন সময়, এবং এটি কেবল একবারই ঘটে।

কেন ফেস এবং অবজেক্ট রিকগনিশনের জন্য সবচেয়ে বেশি RAM প্রয়োজন

ফেস হ্যান্ডলিং বা মুখমণ্ডল শনাক্তকরণ মূলত দুটি কাজের সমষ্টি। ফেস ডিটেকশন বা মুখ শনাক্তকরণ মেশিন লার্নিং কন্টেইনারে একটি মডেল চালায় এবং ছবি থেকে মুখমণ্ডলগুলো খুঁজে বের করে। এরপর ফেস রিকগনিশন বা মুখমণ্ডল শনাক্তকরণ সেই ডিটেকশনগুলোকে নির্দিষ্ট ব্যক্তিদের সাথে গ্রুপ করে, এবং এই ধাপটি Postgres-এ থাকা ভেক্টর ইনডেক্সকে কোয়েরি করে। তাই একটি বড় লাইব্রেরি এই দুটি সার্ভিসকেই পর্যায়ক্রমে চাপের মুখে ফেলে: ডিটেকশন চলার সময় মডেল কন্টেইনার এবং গ্রুপিং চলার সময় ডাটাবেস।

চারটি সেটিংস মেশিন লার্নিং কন্টেইনারের মেমোরি ব্যবহারের ওপর প্রভাব ফেলে।

• ফেস মডেল। Immich ডিফল্টভাবে buffalo_l ব্যবহার করে, এবং FAQ ছোট সার্ভারের জন্য buffalo_s ব্যবহারের পরামর্শ দেয়। এটি একটি ছোট মডেল, তাই এটি কম মেমোরি দখল করে এবং দ্রুত চলে, তবে ছোট বা পাশ থেকে তোলা ছবির ক্ষেত্রে এর নির্ভুলতা কিছুটা কম হতে পারে।
• ওয়ার্কার সংখ্যা। MACHINE_LEARNING_WORKERS ডিফল্টভাবে 1 থাকে। প্রতিটি ওয়ার্কার একটি আলাদা প্রসেস হিসেবে কাজ করে যা মডেলের নিজস্ব কপি লোড করে, তাই এটি 2-এ উন্নীত করলে মডেলের জন্য প্রয়োজনীয় মেমোরি প্রায় দ্বিগুণ হয়ে যায়। আপনার কাছে অতিরিক্ত RAM না থাকলে এটি 1-এই রাখুন।
• ব্যাচ সাইজ। MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION একসাথে কতগুলো মুখমণ্ডল প্রসেস করা হবে তার সীমা নির্ধারণ করে। একটি ব্যাচ একসাথে মেমোরিতে থাকে, তাই চল্লিশটি মুখমণ্ডলসহ একটি গ্রুপ ফটোর জন্য একটি পোর্ট্রেট ছবির চেয়ে বেশি মেমোরি প্রয়োজন হয়।
• কোন মডেলগুলো চালু থাকবে। স্মার্ট সার্চ, ফেস ডিটেকশন এবং টেক্সট রিকগনিশন—প্রতিটিই তাদের নিজস্ব মডেল লোড করে। Administration, Settings, Machine Learning Settings-এ গিয়ে যে মডেলগুলো আপনার প্রয়োজন নেই সেগুলো বন্ধ করে দিলে তা ইমপোর্টের মধ্যবর্তী সময় নয়, বরং স্থায়ীভাবে মেমোরি খালি করে দেয়।

এছাড়া MACHINE_LEARNING_MODEL_ARENA নামে একটি সেটিংস আছে, যা মেমোরি ফ্র্যাগমেন্টেশন এড়াতে CPU মেমোরি প্রি-অ্যালোকেট করে এবং এটি ডিফল্টভাবে চালু থাকে। এটি সবার শেষে পরিবর্তন করুন। এর প্রভাব নির্ভর করে নিচের মেমোরি অ্যালোকেটরের ওপর, তাই এটি যাচাই করার একমাত্র সঠিক উপায় হলো পরিবর্তনের আগে ও পরে docker stats পর্যবেক্ষণ করা।

তিনটি ব্যবহারিক প্রোফাইল: 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-এ নির্ধারণ করার সীমা হিসেবে দেখুন, Immich কত মেমরি ব্যবহার করে তার পরিমাপ হিসেবে নয়। একটি limit হলো সর্বোচ্চ সীমা। এটি কোনো resource reserve করে না এবং কোনো service-কে ছোটও করে না। host-এর memory শেষ হয়ে গেলে kernel কোন service বন্ধ করবে, এটি তা নির্ধারণ করে। এই সিদ্ধান্ত kernel-এর নিজস্ব scoring-এর ওপর ছেড়ে দেওয়ার চেয়ে আপনি নিজে নেওয়াই ভালো।

2 GB মেশিন: machine learning container সরিয়ে দিন

2 GB, 6 GB-এর নথিভুক্ত minimum-এর চেয়ে কম। এটি Immich-এর নথিভুক্ত একমাত্র reduced setup—machine learning disabled অবস্থায় 4 GB—এর চেয়েও কম। Immich 2 GB-এর কোনো configuration প্রকাশ করে না। তাই এই profile একটি unsupported compromise, ব্যবহারযোগ্য recipe নয়। তবু চেষ্টা করলে docker-compose.yml-এ পুরো immich-machine-learning service-টি comment out করুন। অথবা service-টি চালু রেখে Administration, Settings, Machine Learning Settings থেকে প্রতিটি model disable করুন। Container সরিয়ে ফেলাই বেশি কার্যকর, কারণ model disabled থাকলেও Python process memory-তে থেকে যায়।

আপনি uploads, albums, sharing, mobile backup, thumbnails এবং date, place ও filename অনুযায়ী search ব্যবহার করতে পারবেন। Description অনুযায়ী search, face-গুলোকে people হিসেবে স্বয়ংক্রিয় group করা এবং image-এর ভেতরের text recognition ব্যবহার করতে পারবেন না।

চারটি limit মিলিয়ে প্রায় 1.7 GB হয়। ফলে host-এর জন্য প্রায় 300 MB থাকে। Immich-এর documentation অনুযায়ী Docker resource limits ব্যবহারের পরে শুধু database-এর জন্যই অন্তত 2 GB প্রয়োজন, যা পুরো box-এর সমান। তাই database-এর জন্য 768 MB এই minimum-এর অনেক নিচে। এ কারণেই এখানে Postgres service-টি বন্ধ হয়ে যাওয়ার সম্ভাবনা সবচেয়ে বেশি।

প্রথমে import ব্যর্থ হয়। একটি page পরিবেশন করতে metadata query এবং file read লাগে। তাই আগে থেকেই থাকা library browse করলে box-এর ওপর কম চাপ পড়ে। কিন্তু video-heavy import-এ swap ব্যবহার শুরু হবে, কারণ একই সময়ে transcode এবং thumbnail queue—দুটিই memory চায়। আপনার কাছে যদি 2 GB-ই থাকে, প্রতিটি heavy queue-এর concurrency 1 নির্ধারণ করুন এবং একটি swap file যোগ করুন। কোনো plan বেছে নিলে 4 GB-কে প্রকৃত minimum হিসেবে ধরুন।

4 GB মেশিন: machine learning চালু, একবারে একটি job

Immich-এর documentation অনুযায়ী machine learning feature disabled থাকলে 4 GB ব্যবহারযোগ্য। Requirements page-এ এটিই একমাত্র reduced configuration। Database-কে নথিভুক্ত 2 GB minimum-এ রাখলে chart-এর তিনটি limit মিলিয়ে প্রায় 3.2 GB হয়। ফলে host-এর জন্য প্রায় 800 MB থাকে। Thumbnail generation-এর job concurrency 1 নির্ধারণ করুন এবং transcoding thread-এর সংখ্যা কম রাখুন।

Face ও object recognition চালু রাখতে নথিভুক্ত পদ্ধতি হলো নিচে বর্ণিতভাবে machine learning container অন্য একটি মেশিনে চালানো এবং এই server-কে সেটির দিকে নির্দেশ করা। একই 4 GB box-এ এটি চালালে Immich-এর নথিভুক্ত সীমা অতিক্রম হবে। কারণ database-এর minimum বাদ দিলে server, Redis, model এবং host—সবকিছুর জন্য প্রায় 2 GB থাকে। তবু চেষ্টা করলে Compose limit দিয়ে machine learning container-এর সীমা নির্ধারণ করুন, facial recognition-কে buffalo_s-এ পরিবর্তন করুন এবং thumbnail generation, face detection ও smart search-এর job concurrency 1 নির্ধারণ করুন।

আগে থেকে থাকা library-র প্রথম pass-এ অনেক ঘণ্টা লাগবে। বড় library হলে এক দিনেরও বেশি লাগতে পারে। এটি memory নয়, CPU limit-এর বিষয়। তাই বেশি RAM এই সময় কমাবে না।

এই box-এ machine learning চললে প্রথম bulk pass-এর সময় সেই container-টিই আগে ব্যর্থ হবে। কোনো limit না থাকলে transcode job বাড়ার সঙ্গে container-টির memory ব্যবহারও বাড়বে। এরপর kernel দুটির মধ্যে যেটি বড়, সেটি বন্ধ করবে। Container-টি কয়েক সেকেন্ডের মধ্যে restart হওয়ায় docker ps -a-এ Up-এর uptime তার পাশের service-গুলোর তুলনায় অনেক কম দেখা যাবে, Exited (137) নয়। আপনি শেষবার দেখার পর queue আরও পিছিয়ে থাকবে, কিন্তু তা নীরবে ঘটবে।

8 GB মেশিন: নথিভুক্ত সুপারিশ

4 cores-সহ 8 GB Immich-এর সুপারিশের সঙ্গে মেলে। সবকিছু default settings-এ চলবে: smart search, face detection, text recognition এবং default concurrency-এ transcoding। এক লাখের বেশি asset থাকা library-ও এখানে স্বাচ্ছন্দ্যে চলবে। তখন চাপ memory থেকে disk speed-এর দিকে সরে যায়, কারণ database সারাদিন vector index এবং metadata query নিয়ে কাজ করে।

তবুও limit নির্ধারণ করুন। পর্যাপ্ত memory থাকা box-এও limit একটি runaway queue-কে database-কে সঙ্গে নিয়ে বন্ধ হয়ে যাওয়া থেকে আটকায়। ছোট option-গুলোর সঙ্গে খরচ তুলনা করলে, memory tier অনুযায়ী একটি VPS-এর প্রকৃত খরচ সাধারণত 8 GB plan-কে tuning বন্ধ করার সবচেয়ে সস্তা উপায় করে তোলে।

Compose limits ব্যবহার করে প্রতি service-এর memory সীমা নির্ধারণ

এটির জন্য docker-compose.yml সম্পাদনা করবেন না। wget দিয়ে upgrade করার সময় ওই file-টি প্রতিবার প্রতিস্থাপিত হয়। তার পাশে থাকা docker-compose.override.yml-এ limits রাখুন; 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-এর MEM USAGE / LIMIT column-এ এখন host-এর মোট memory-এর বদলে আপনার নির্ধারিত ceiling দেখা উচিত। limit column-এ যদি এখনও host-এর সম্পূর্ণ size দেখা যায়, তাহলে override file নেওয়া হয়নি। file-এর নাম পরীক্ষা করুন এবং merge করা ফলাফল দেখতে docker compose config চালান।

Database-এর memory 2048M বা তার বেশি রাখুন। Docker resource limits ব্যবহার করলে Immich database-এর minimum হিসেবে 2 GB উল্লেখ করে। Limit খুব কম হলে ধীর service সম্পূর্ণ বন্ধ হয়ে যেতে পারে। তাই container বারবার restart হলে limit বাড়ান। Docker Compose-এ প্রতি service-এর memory limit নির্ধারণ-এ এই প্রক্রিয়ার বিস্তারিত ব্যাখ্যা আছে। সেখানে Compose v2-এ deploy কেন Swarm ছাড়াও কাজ করে, তাও ব্যাখ্যা করা হয়েছে।

Machine learning 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 লিখুন। উভয় host-এ একই version ব্যবহার করুন। Immich-এর documentation সতর্ক করে যে দুই host-এর version ভিন্ন হলে bug এবং instability দেখা দিতে পারে।

এই port আপনার ছবির image preview অন্য machine-এ encryption ছাড়াই পাঠায়। Immich-এর documentation আরও সতর্ক করে যে machine learning container-এর নিজস্ব কোনো security ব্যবস্থা নেই। তাই এটিকে private network-এ রাখুন অথবা দুই host-এর মধ্যে একটি WireGuard tunnel-এর মাধ্যমে চালান। কখনোই 3003 Internet-এ উন্মুক্ত করবেন না।

যদি resident model container রাখার ধারণাটিই সমস্যা হয়, তাহলে plan size নির্ধারণের আগে PhotoPrism এবং Immich স্থায়ীভাবে কোন কোন উপাদান চালায়, তার পার্থক্য তুলনা করাও যুক্তিসঙ্গত।

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-এর দেওয়া একমাত্র প্রকাশিত অনুপাত: জেনারেট করা থাম্বনেইল এবং ট্রান্সকোড করা ভিডিও গড়ে লাইব্রেরির আকারের সাথে 10 থেকে 20 শতাংশ যোগ করে। এটি একটি পরিসীমা, কারণ এটি নির্ভর করে আপনার কতগুলো অ্যাসেট ব্রাউজার কম্প্যাটিবিলিটির জন্য পুনরায় এনকোড করার প্রয়োজন তার ওপর। শুধুমাত্র JPEG-এর লাইব্রেরি এই পরিসীমার নিচের দিকে থাকে।

ডেটাবেসটি 3 GB, যা অনেকটা নির্দিষ্ট খরচের মতো। Immich-এর ডকুমেন্টেশন অনুযায়ী ডেটাবেস ফাইলগুলো সাধারণত 1 থেকে 3 GB হয়, কারণ এতে পিক্সেলের পরিবর্তে মেটাডেটা এবং সার্চ ভেক্টর থাকে। মডেল ক্যাশে 2 GB এবং আপনি যদি একাধিক মডেল সক্রিয় করেন বা বিভিন্ন মডেল পরীক্ষা করেন তবে এটি বৃদ্ধি পায়। FAQ-তে এই ভলিউমটিকে জায়গা দখলকারী হিসেবে চিহ্নিত করা হয়েছে ঠিক এই কারণেই।

পাঁচটি সারির যোগফল 300 GB-এর কিছুটা বেশি, তাই 500 GB-এর ভলিউমে বৃদ্ধির জন্য জায়গা থাকে কিন্তু 250 GB-এর ভলিউমে তা থাকে না। ডিস্কের বিভাজন পরীক্ষা করুন এভাবে:

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

UPLOAD_LOCATION-এর অধীনে ছয়টি ফোল্ডার থাকে। upload এবং library অরিজিনাল ফাইলগুলো ধারণ করে, thumbs প্রিভিউ এবং ফেস থাম্বনেইল রাখে, encoded-video পুনরায় এনকোড করা কপি রাখে, profile অবতার রাখে এবং backups স্বয়ংক্রিয় ডেটাবেস ডাম্প রাখে। শুধুমাত্র upload, library এবং profile অপরিবর্তনীয়, কারণ বাকি সবকিছু এগুলো থেকে পুনরায় তৈরি করা সম্ভব।

দুটি বিষয় ব্যবহারকারীদের অবাক করে। ডিলিট করা অ্যাসেটগুলো প্রথমে ট্র্যাশে যায় এবং ট্র্যাশ খালি না করা পর্যন্ত জায়গা দখল করে রাখে, তাই বড় কোনো ক্লিনআপের দিন তাৎক্ষণিকভাবে কোনো জায়গা খালি হয় না। এছাড়া ডেটাবেস ডাম্প শুধুমাত্র মেটাডেটা, তাই অরিজিনাল ফাইল ছাড়া এর কোনো মূল্য নেই:

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

এর সাথে অরিজিনাল ফাইলগুলোর একটি ফাইল-লেভেল কপি সার্ভারের বাইরে কোথাও রাখুন, যার জন্য restic backups from a VPS to off-server storage ব্যবহার করা হয়।

ট্রান্সকোডিং RAM নয়, CPU দ্বারা সীমাবদ্ধ

RAM বাড়ালে ট্রান্সকোডিং দ্রুত হবে না। Immich FFmpeg ব্যবহার করে। সাধারণ VPS-এ প্রতিটি frame CPU দ্বারা decode ও encode করা হয়। প্রতিটি FFmpeg process decoded frame-এর buffer memory-তে ধরে রাখে। এ কারণেই import section-এ প্রতিটি transcode-কে আলাদা memory cost হিসেবে গণনা করা হয়। তবে এর গতি নির্ধারিত হয় CPU দ্বারা। Hardware acceleration থাকলেও Immich-এর documentation অনুযায়ী default অবস্থায় শুধু encoding accelerated হয়। তাই hardware decoding-ও enable না করলে decoding ও tone mapping CPU-তেই সম্পন্ন হয়।

Hardware acceleration-এর জন্য অতিরিক্ত hwaccel.transcoding.yml Compose file এবং pass-through করার মতো একটি device প্রয়োজন। এখানে NVENC, Quick Sync, RKMPP বা VAAPI ব্যবহার করা হয়। অধিকাংশ VPS plan-এ এগুলোর কোনোটিই থাকে না। তাই CPU-ভিত্তিক কাজের জন্য পরিকল্পনা করুন।

বাস্তবে গুরুত্বপূর্ণ setting হলো thread count। Administration, Settings, Video Transcoding Settings-এর অধীনে thread value 0 দিলে সব core ব্যবহার করা হয়। 2 core plan-এ এর ফলে একটি video web interface আটকে দিতে পারে। Immich FAQ-এর পরামর্শ অনুযায়ী সেখানে 1 বা 2 সেট করুন। এতে transcode ধীর হবে, কিন্তু অন্য কাজ ব্যাহত করবে না।

swap thrashing-এর কারণে import কেন hang-এর মতো দেখায়

এটি এমন একটি ব্যর্থতা, যা মানুষ সবচেয়ে বেশি ভুলভাবে ব্যাখ্যা করে। Immich-এর memory শেষ হয়ে গেলে দুটি ফল হতে পারে, এবং তার মধ্যে শুধু একটিই ব্যর্থতার মতো দেখায়।

swap না থাকলে kernel একটি process বন্ধ করে দেয়। 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 দিয়ে বন্ধ করা হয়েছে। 137 হলো 128 plus 9। Container বন্ধ থাকা অবস্থাতেই শুধু এই status দেখা যায়। Restart policy container-টিকে ফিরিয়ে আনার পরে docker ps -a আবার Up দেখায়। অন্য Immich container-গুলোর তুলনায় অনেক কম uptime-ই এখানে গুরুত্বপূর্ণ ইঙ্গিত। তবে signal 9 একাই memory সমস্যার প্রমাণ নয়, কারণ স্বাভাবিক stop timeout পেরিয়ে গেলেও Docker এটি পাঠায়। OOMKilled-এর true value নিশ্চিত করে যে memory-এর কারণে process-টি বন্ধ হয়েছে। Container restart হওয়ার পরে dmesg থেকে পাওয়া oom-kill line-গুলোই নির্ভরযোগ্য রেকর্ড।

swap থাকলে কিছু বন্ধ হয় না এবং কোনো error-ও হয় না। Kernel page-গুলো disk-এ সরাতে শুরু করে। Import-এর গতি এক order of magnitude কমে যায়। Web interface স্বাভাবিক timeout-এর মধ্যে আর response দেয় না। প্রতিটি container running থাকে। প্রতিটি health check তখনও pass করতে পারে। এটি hang-এর মতো দেখায়। এই অবস্থায় অনেকে box reboot করেন। এতে queue-এর অগ্রগতি হারিয়ে যায়, কিন্তু সমস্যার কোনো পরিবর্তন হয় না।

free -m
vmstat 1 5

vmstat-এর si এবং so column-এ ধারাবাহিক non-zero value থাকার অর্থ machine ক্রমাগত swap পড়ছে এবং লিখছে। এটিই thrashing-এর সংজ্ঞা। একই সময়ে ব্যবহৃত Swap-এর free -m row-এর মানও বাড়তে থাকবে।

2 GB বা 4 GB box-এ যেকোনো অবস্থায় swap যোগ করুন। কারণ যে import ধীর হলেও diagnose করা যায়, সেটি এমন 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-এর resource limit নির্ধারণ করুন, অথবা এটিকে এই host থেকে সরিয়ে নিন। Swap আপনাকে এই কাজ করার সময় দেয়। তবে swap নিজে সমাধান নয়।

FAQ

আমি কি 2 GB VPS-এ Immich চালাতে পারি?

Immich যে কোনো নথিভুক্ত configuration-এ এটি সমর্থন করে না। Requirements page-এ 6 GB-কে সর্বনিম্ন বলা হয়েছে। সেখানে machine learning feature নিষ্ক্রিয় রেখে 4 GB-কে একমাত্র ছোট setup হিসেবে উল্লেখ করা হয়েছে। এছাড়া Docker resource limit ব্যবহার করলে শুধু database-এর জন্যই অন্তত 2 GB প্রয়োজন। immich-machine-learning service-টি comment out করে job concurrency 1 নির্ধারণ করলে এটি চালু হতে পারে। তবে এটি unsupported compromise। Import চলাকালে Postgres service-টিই সবচেয়ে বেশি বন্ধ হয়ে যাওয়ার ঝুঁকিতে থাকে। আপনার কাছে যদি শুধু 2 GB থাকে, তাহলে 2 GB swap file যোগ করুন। এতে import spike-এর সময় container বন্ধ হওয়ার বদলে server ধীর হয়ে যাবে। কোনো plan বেছে নিলে 4 GB দিয়ে শুরু করুন।

কেন আমার Immich import কোনো error message ছাড়াই থেমে যায়?

Browser থেকে দুটি ভিন্ন কারণ একই রকম দেখায়। হয় memory-এর কারণে কোনো container বন্ধ হয়ে গেছে এবং ইতিমধ্যে restart হয়েছে। সে ক্ষেত্রে docker ps -a-এ সেটিকে Up দেখা যাবে, এবং uptime অস্বাভাবিকভাবে কম থাকবে। (Container বন্ধ থাকা অবস্থায় ধরতে পারলেই শুধু Exited (137) দেখা যাবে।) অথবা host swapping করছে। সে ক্ষেত্রে সব container চালু থাকে, কিন্তু সবকিছু খুব ধীর হয়ে যায়। vmstat 1 5 এই দুটি কারণ আলাদা করে: si এবং so column-এ ধারাবাহিক non zero সংখ্যা থাকলে swapping হচ্ছে। উভয় ক্ষেত্রেই thumbnail generation, face detection এবং smart search-এর job concurrency কমান।

Immich log-এ exit code 137-এর অর্থ কী?

137 হলো 128-এর সঙ্গে signal 9 যোগ করলে পাওয়া মান। তাই process-টি SIGKILL দিয়ে বন্ধ করা হয়েছে। Immich server-এ এর সাধারণ কারণ হলো memory ceiling। এটি container-এর নিজস্ব limit হতে পারে, অথবা host-এর memory শেষ হয়ে যেতে পারে। তবে code একাই কারণ নিশ্চিত করে না। Timeout-এর মধ্যে container বন্ধ না হলেও Docker SIGKILL পাঠায়। Linux-এ default timeout 10 seconds। docker inspect immich_machine_learning | grep -i oomkilled দিয়ে পরীক্ষা করুন। true-এর মান নিশ্চিত করে যে kernel memory-এর কারণে process-টি বন্ধ করেছে। এরপর 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 percent অতিরিক্ত space ধরুন। Immich-এর documentation অনুযায়ী generated thumbnail এবং transcoded video library-এর আকার গড়ে 10 থেকে 20 percent বাড়ায়। বড় library হলেও database সাধারণত 1 থেকে 3 GB হয়। মোট space মূলত video-র আকারের ওপর নির্ভর করে। তাই photo count-এর ওপর multiplier প্রয়োগ না করে plan বেছে নেওয়ার আগে নিজের গড় file size মাপুন।

Immich চালাতে কি GPU দরকার?

না। Immich-এর প্রতিটি অংশ CPU-তে চলে। Graphics card machine learning container-এ model inference এবং video encoding দ্রুত করে, তবে কোনোটিই বাধ্যতামূলক নয়। অধিকাংশ VPS plan-এ GPU থাকে না। শুধু CPU-ভিত্তিক hardware হলে transcoding thread 1 বা 2 নির্ধারণ করুন, buffalo_s face model ব্যবহার করুন, এবং প্রথম bulk import রাতভর চলতে দিন।