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

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

Immich-এর নথিপত্র অনুযায়ী এর ন্যূনতম RAM চাহিদা হলো 6 GB এবং সুপারিশকৃত পরিমাণ হলো 8 GB। এর সাথে নিম্নতম 2 টি CPU কোর এবং আরামদায়ক ব্যবহারের জন্য 4 টি কোর প্রয়োজন। এই হিসাবটি পুরো স্ট্যাকের জন্য, কারণ Immich একটি একক অ্যাপ্লিকেশন নয় বরং চারটি কন্টেইনারের সমষ্টি। আগে থেকে ইমপোর্ট করা লাইব্রেরি ব্রাউজ করতে খুব কম মেমরি লাগে। মেমরির মূল ব্যবহার হয় ফাইল ইমপোর্ট করার সময়, যার সিংহভাগ খরচ হয় এমন একটি কন্টেইনারে যা আপনি চাইলে বন্ধ রাখতে পারেন।

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

আগস্ট 2026 পর্যন্ত Immich-এর রিকোয়ারমেন্ট পেজে এই তথ্যগুলো প্রকাশিত হয়েছে। এগুলো মূলত সাইজিং বা সক্ষমতার সুপারিশ, সফটওয়্যার চালু হওয়ার সময় কোনো হার্ড চেক নয়। Immich এর চেয়ে কম মেমরিতেও চালু হতে পারে। ছোট সার্ভারে যা ঘটে তা হলো, ব্যাকগ্রাউন্ড জবগুলো সম্পন্ন হতে সমস্যা হয় এবং মেমরি শেষ হয়ে গেলে ইমপোর্ট প্রক্রিয়ায় বিঘ্ন ঘটে।

একটি প্রকৃত হার্ড লিমিট রয়েছে। Immich ভার্সন 3 এবং পরবর্তী ভার্সনগুলোর জন্য amd64 হোস্ট মেশিনে একটি x86-64-v2 CPU প্রয়োজন, যা 2012 সালের পর থেকে বাজারে আসা অধিকাংশ প্রসেসরেই থাকে। পুরনো হার্ডওয়্যারে কন্টেইনারটি ধীরগতির হওয়ার পরিবর্তে সরাসরি চালু হতেই ব্যর্থ হয়।

আপনি যদি এখনো ইনস্টলেশন শুরু না করে থাকেন, তবে Docker Compose ব্যবহার করে VPS-এ সম্পূর্ণ Immich ইনস্টলেশন গাইডটি দেখুন এবং এরপর সার্ভারের আকার নির্ধারণ করতে এখানে ফিরে আসুন।

মেমোরি কোথায় ব্যবহৃত হয়: চারটি কন্টেইনার

অফিসিয়াল Compose ফাইলে চারটি সার্ভিস চালু হয়। প্রতিটির মেমোরি ব্যবহারের ধরন ভিন্ন, তাই একটি মোট সংখ্যা দিয়ে প্রকৃত অবস্থা বোঝা যায় না।

immich-server ওয়েব ইন্টারফেস এবং API পরিচালনা করে, পাশাপাশি এটি ব্যাকগ্রাউন্ড জব ওয়ার্কারদেরও চালায়। এই একটি কন্টেইনারের ভেতরেই দুটি ওয়ার্কার থাকে। api ব্রাউজার এবং মোবাইল অ্যাপ থেকে আসা অনুরোধের উত্তর দেয়। microservices কিউ (queues) পরিচালনা করে, যার মধ্যে থাম্বনেইল তৈরি এবং ভিডিও এনকোডিং অন্তর্ভুক্ত। IMMICH_WORKERS_INCLUDE এবং IMMICH_WORKERS_EXCLUDE ভেরিয়েবলগুলো এই দুটিকে আলাদা কন্টেইনারে বিভক্ত করে। এর মাধ্যমে আপনি ফটো সার্ভ করা অংশটিকে সীমাবদ্ধ না করেই বেশি লোড নেওয়া অংশটির জন্য আলাদা মেমোরি লিমিট নির্ধারণ করতে পারেন।

database হলো একটি PostgreSQL 14 ইমেজ, যাতে VectorChord এক্সটেনশনটি বিল্ট-ইন থাকে। এটি প্রতিটি মেটাডেটা এবং প্রতি অ্যাসেটের জন্য একটি সার্চ ভেক্টর সংরক্ষণ করে। Immich-এর ডকুমেন্টেশনে এই সার্ভিসটির জন্য একটি নির্দিষ্ট সর্বনিম্ন মেমোরি সীমার কথা বলা হয়েছে: আপনি যদি Docker রিসোর্স লিমিট প্রয়োগ করেন, তবে ডাটাবেসের জন্য কমপক্ষে 2 GB মেমোরি প্রয়োজন। একই পৃষ্ঠায় উল্লেখ করা হয়েছে যে, ডাটাবেসটি অবশ্যই লোকাল SSD স্টোরেজে থাকতে হবে এবং কোনোভাবেই নেটওয়ার্ক শেয়ারে রাখা যাবে না। কারণ ভেক্টর এবং ইনডেক্স লুকআপগুলো ছোট র‍্যান্ডম রিড (random reads) অপারেশন, তাই নেটওয়ার্ক ভলিউম ব্যবহার করলে প্রতিটি অপারেশনের জন্য রাউন্ড ট্রিপের প্রয়োজন হয়। যদি আপনার পরিকল্পনার বিষয়টি এর ওপর নির্ভর করে, তবে এই স্ট্যাকের অন্য যেকোনো অংশের চেয়ে NVMe এবং SATA SSD স্টোরেজ-এর পার্থক্য এখানে সবচেয়ে বেশি গুরুত্বপূর্ণ।

redis Valkey ইমেজ চালায় এবং জব কিউগুলো সংরক্ষণ করে। এটি চারটি কন্টেইনারের মধ্যে সবচেয়ে ছোট, কারণ এটি ফটোর ডাটার পরিবর্তে জব রেকর্ড সংরক্ষণ করে।

immich-machine-learning হলো সেই সার্ভিস যা আপনার প্ল্যানের আকার নির্ধারণ করে। এটি স্মার্ট সার্চ, ফেস ডিটেকশন এবং টেক্সট রিকগনিশনের জন্য মডেল লোড করে এবং একটি লোড হওয়া মডেল মেমোরিতেই থেকে যায়। MACHINE_LEARNING_MODEL_TTL-এর ডিফল্ট মান 300, তাই কোনো অনুরোধ না থাকলে পাঁচ মিনিট পর মডেলটি ড্রপ করা হয় এবং পরবর্তী অনুরোধের সময় /cache ভলিউম থেকে পুনরায় পড়া হয়। বাল্ক ইম্পোর্টের সময় পাঁচ মিনিটের কোনো বিরতি থাকে না, তাই প্রথম অ্যাসেট থেকে শেষ অ্যাসেট পর্যন্ত মডেলগুলো লোড করা অবস্থাতেই থাকে।

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

একটি 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": "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 কী পরিমাণ ব্যবহার করে তার পরিমাপ হিসেবে নয়। একটি সীমা হলো সর্বোচ্চ পর্যায়। এটি কোনো কিছু রিজার্ভ করে না এবং কোনো সার্ভিসকে ছোটও করে না। সার্ভারে মেমোরি শেষ হয়ে গেলে কার্নেল কোন সার্ভিসটি বন্ধ করবে, তা এটি নির্ধারণ করে। কার্নেলের নিজস্ব স্কোরের ওপর নির্ভর না করে আপনার নিজের এই সিদ্ধান্ত নেওয়া ভালো।

2 GB বক্স: মেশিন লার্নিং কন্টেইনারটি সরিয়ে ফেলুন

2 GB মেমোরি 6 GB-এর নথিবদ্ধ ন্যূনতম চাহিদার নিচে, তাই এটি একটি আপস এবং এটি উল্লেখ করা প্রয়োজন। docker-compose.yml ফাইলে পুরো immich-machine-learning সার্ভিসটি কমেন্ট আউট করে দিন, অথবা এটি চালু রেখে Administration, Settings, Machine Learning Settings-এর অধীনে প্রতিটি মডেল নিষ্ক্রিয় করুন। কন্টেইনারটি সরিয়ে ফেলা বেশি কার্যকর, কারণ একটি নিষ্ক্রিয় মডেলও ব্যাকগ্রাউন্ডে পাইথন প্রসেস চালু রাখতে পারে।

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

চারটি লিমিট যোগ করলে প্রায় 1.7 GB হয়, যা হোস্টের জন্য প্রায় 300 MB খালি রাখে। লক্ষ্য করুন যে ডাটাবেসের জন্য 768 MB সীমাটি নথিবদ্ধ 2 GB ন্যূনতম চাহিদার নিচে। 2 GB-এর ক্ষেত্রে এই আপসটিই করতে হয় এবং এই কারণেই Postgres সার্ভিসটি এখানে বন্ধ হয়ে যাওয়ার সম্ভাবনা সবচেয়ে বেশি থাকে।

ব্রাউজিংয়ের চেয়ে ইমপোর্ট করার সময় সমস্যা বেশি হয়। কয়েক হাজার ছবির লাইব্রেরি একবার ইমপোর্ট হয়ে গেলে ব্রাউজিং মোটামুটি ঠিকঠাক চলে, কারণ পেজ সার্ভ করার জন্য মেটাডেটা কোয়েরি এবং ফাইল রিড প্রয়োজন হয়। একই বক্সে ভিডিও ইমপোর্ট করলে মেমোরি সোয়াপ হতে পারে, কারণ ট্রান্সকোড এবং থাম্বনেইল কিউ একই সময়ে মেমোরি দাবি করে। প্রতিটি ভারী কিউ-এর কনকারেন্সি (concurrency) 1-এ সেট করুন এবং একটি সোয়াপ ফাইল যোগ করুন।

4 GB বক্স: মেশিন লার্নিং চালু, তবে একবারে একটি কাজ

4 GB হলো সর্বনিম্ন সাইজ যেখানে ফেস এবং অবজেক্ট রিকগনিশন চালু রাখা অর্থবহ। মেশিন লার্নিং কন্টেইনারকে 0 MB-তে সীমাবদ্ধ করুন, ফেসিয়াল রিকগনিশনকে buffalo_s-এ পরিবর্তন করুন এবং থাম্বনেইল জেনারেশন, ফেস ডিটেকশন ও স্মার্ট সার্চের জন্য জব কনকারেন্সি 1-এ সেট করুন।

বিদ্যমান লাইব্রেরির ওপর প্রথমবার কাজ করতে অনেক ঘণ্টা সময় লাগবে, আর বড় লাইব্রেরির ক্ষেত্রে তা একদিনের বেশি সময় নিতে পারে। এটি মেমোরির চেয়ে CPU-এর সীমাবদ্ধতা, তাই বেশি RAM থাকলেও সময় কমবে না।

এখানে প্রথম বাল্ক পাসের সময় মেশিন লার্নিং কন্টেইনারটি আগে বন্ধ হয়ে যায়। কোনো সীমা না থাকলে, ট্রান্সকোড জব বাড়ার সাথে সাথে এটিও বাড়তে থাকে এবং কার্নেল দুটির মধ্যে বড়টিকে বন্ধ করে দেয়। আপনি docker ps -a-এ Exited (137) দেখতে পাবেন এবং কন্টেইনারটি রিস্টার্ট হবে, যার ফলে কিউ আগের চেয়ে আরও পিছিয়ে যাবে।

8 GB বক্স: নথিবদ্ধ সুপারিশ

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

তবুও সীমাগুলো সেট করে রাখুন। পর্যাপ্ত মেমোরি থাকলেও, এই সীমাগুলো কোনো একটি অনিয়ন্ত্রিত কিউ-কে ডাটাবেস ডাউন করা থেকে বিরত রাখে। আপনি যদি ছোট অপশনগুলোর সাথে এর খরচের তুলনা করেন, তবে মেমোরি টিয়ার অনুযায়ী একটি VPS-এর প্রকৃত খরচ সাধারণত 8 GB প্ল্যানকেই টিউনিং করার ঝামেলা এড়ানোর সবচেয়ে সাশ্রয়ী উপায় করে তোলে।

Compose limits ব্যবহার করে প্রতি সার্ভিসের মেমোরি সীমাবদ্ধ করার উপায়

এর জন্য docker-compose.yml এডিট করবেন না। আপনি যখনই wget দিয়ে আপগ্রেড করবেন, তখনই এই ফাইলটি প্রতিস্থাপিত হবে। এর পরিবর্তে পাশে থাকা docker-compose.override.yml ফাইলে লিমিটগুলো লিখুন, যা docker compose স্বয়ংক্রিয়ভাবে মার্জ করে নেয়।

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 কলামে আপনার নির্ধারিত সীমা দেখাবে। যদি লিমিট কলামে এখনও হোস্টের পূর্ণ মেমোরি সাইজ দেখায়, তবে বুঝতে হবে ওভাররাইড ফাইলটি কার্যকর হয়নি: ফাইলের নাম চেক করুন এবং মার্জ করা ফলাফল দেখতে docker compose config কমান্ডটি চালান।

খুব কম লিমিট সেট করলে একটি ধীরগতির সার্ভিস পুরোপুরি বন্ধ হয়ে যেতে পারে, তাই কোনো কন্টেইনার বারবার রিস্টার্ট (cycling) হলে লিমিট বাড়িয়ে দিন। এর কার্যপদ্ধতি সম্পর্কে আরও জানতে Docker Compose-এ প্রতি সার্ভিসের জন্য মেমোরি লিমিট সেট করা দেখুন, যেখানে Docker Compose v2-এর সাথে Swarm-এর বাইরে কেন deploy কাজ করে তা ব্যাখ্যা করা হয়েছে।

কিভাবে মেশিন লার্নিং কন্টেইনার বন্ধ বা স্থানান্তর করবেন

একটি ছোট সার্ভারে, এই কন্টেইনারটিকে অন্য কোথাও সরিয়ে নেওয়া সবচেয়ে কার্যকর পরিবর্তন হতে পারে। Immich এটিকে অন্য একটি মেশিনে চালানো সমর্থন করে। দ্বিতীয় হোস্টটিতে এই ফাইলটি তৈরি করুন, যা এমন একটি ডেস্কটপ হতে পারে যেটি শুধুমাত্র সন্ধ্যায় চালু থাকে:

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

এরপর ওয়েব ইন্টারফেসে Administration, Settings, Machine Learning Settings-এ যান, Add URL-এ ক্লিক করুন এবং http://<host>:3003 লিখুন। উভয় হোস্টে একই ভার্সন ব্যবহার করুন, কারণ Immich-এর ডকুমেন্টেশনে সতর্ক করা হয়েছে যে ভার্সনের অমিল থাকলে বাগ এবং অস্থিরতা দেখা দিতে পারে।

এই পোর্টটি আপনার ছবিগুলোকে এনক্রিপশন ছাড়াই অন্য মেশিনে পাঠায়, তাই এটিকে একটি প্রাইভেট নেটওয়ার্কে রাখুন অথবা দুই হোস্টের মধ্যে একটি WireGuard tunnel ব্যবহার করে চালান। 3003 পোর্টটিকে কখনোই ইন্টারনেটে উন্মুক্ত করবেন না।

যদি একটি রেসিডেন্ট মডেল কন্টেইনার রাখাটাই মূল সমস্যা হয়, তবে কোনো পরিকল্পনা চূড়ান্ত করার আগে 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 ব্যবহার করা হয়।

Transcoding-এর জন্য RAM নয়, CPU ব্যবহৃত হয়

RAM বাড়ালে transcoding দ্রুত হয় না। Immich FFmpeg ব্যবহার করে transcoding করে এবং সাধারণ VPS-এ প্রতিটি ফ্রেম CPU দ্বারা decode ও encode করা হয়। এমনকি যেখানে hardware acceleration উপলব্ধ, সেখানেও Immich-এর ডকুমেন্টেশন অনুযায়ী শুধুমাত্র encoding ত্বরান্বিত হয়, তাই CPU-কে এখনও software decoding এবং tone mapping করতে হয়।

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

এর ব্যবহারিক সেটিং হলো thread count। Administration-এর অধীনে, Settings, Video Transcoding Settings-এ thread-এর মান 0 থাকার অর্থ হলো সব কোর ব্যবহৃত হওয়া, যা 2 কোরের প্ল্যানে একটি ভিডিওর কারণে পুরো web interface-কে ফ্রিজ করে দিতে পারে। Immich FAQ-এর পরামর্শ অনুযায়ী এখানে মান 1 বা 2 সেট করুন, এতে transcode ধীরগতির হবে কিন্তু সিস্টেমের স্বাভাবিক কাজে ব্যাঘাত ঘটবে না।

কেন swap thrashing-এর কারণে সিস্টেম হ্যাং হয়েছে বলে মনে হয়

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

swap না থাকলে, কার্নেল একটি প্রসেসকে বন্ধ (kill) করে দেয়। কন্টেইনারটি কয়েক সেকেন্ডের মধ্যেই পুনরায় চালু হয়, তাই ব্রাউজার থেকে দেখলে মনে হয় জব কিউ (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)-এর অর্থ হলো প্রসেসটিকে সিগন্যাল 9 দিয়ে বন্ধ করা হয়েছে। 137 হলো 128 যোগ 9। OOMKilled-এর মান true নিশ্চিত করে যে এটি ক্র্যাশ হওয়ার পরিবর্তে মেমরির অভাবে বন্ধ হয়েছে।

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

free -m
vmstat 1 5

vmstat-এর si এবং so কলামে দীর্ঘ সময় ধরে শূন্য ছাড়া অন্য মান থাকা মানে হলো মেশিনটি ক্রমাগত swap রিড এবং রাইট করছে, যা thrashing-এর সংজ্ঞা। একই সময়ে Swap ব্যবহারের জন্য free -m সারিটি বাড়তে থাকবে।

2 GB বা 4 GB র‍্যামের বক্সে অবশ্যই swap যোগ করুন, কারণ একটি ধীরগতির ইমপোর্ট যা আপনি নির্ণয় করতে পারেন, তা এমন একটি বন্ধ হয়ে যাওয়া কন্টেইনারের চেয়ে ভালো যা আপনি নির্ণয় করতে পারবেন না:

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 করুন, মেশিন লার্নিং কন্টেইনারের রিসোর্স সীমাবদ্ধ করুন অথবা সেটিকে অন্য কোনো হোস্টে সরিয়ে নিন। swap আপনাকে এটি করার জন্য সময় দেয়। এটি নিজে কোনো সমাধান নয়।

FAQ

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

হ্যাঁ, যদি immich-machine-learning সার্ভিসটিকে docker-compose.yml ফাইল থেকে কমেন্ট আউট করে দেন এবং job concurrency 1-এ সেট করেন। এটি নথিপত্র অনুযায়ী নির্ধারিত সর্বনিম্ন 6 GB RAM-এর চেয়ে কম, তাই এটিকে একটি আপস হিসেবে গণ্য করুন। আপনি আপলোড, অ্যালবাম, শেয়ারিং, মোবাইল ব্যাকআপ এবং তারিখ, স্থান ও ফাইলের নাম অনুযায়ী সার্চ সুবিধা পাবেন। তবে আপনি ডেসক্রিপশন অনুযায়ী সার্চ, স্বয়ংক্রিয়ভাবে মুখমণ্ডল গ্রুপ করা এবং ছবির ভেতরের টেক্সট শনাক্ত করার সুবিধা পাবেন না। একটি 2 GB swap file তৈরি করে রাখুন, যাতে ইমপোর্টের সময় সার্ভার ধীর হয়ে গেলেও কন্টেইনারটি বন্ধ না হয়ে যায়।

আমার Immich ইমপোর্ট কোনো error message ছাড়াই কেন বন্ধ হয়ে যায়?

ব্রাউজার থেকে দুটি ভিন্ন কারণ একই রকম মনে হতে পারে। হয় মেমোরির কারণে কোনো কন্টেইনার বন্ধ (kill) হয়ে গেছে, সেক্ষেত্রে docker ps -a কমান্ডটি Exited (137) দেখাবে এবং কন্টেইনারটি ইতিমধ্যে রিস্টার্ট হয়েছে; অথবা হোস্ট সার্ভার swap ব্যবহার করছে, সেক্ষেত্রে সব কন্টেইনার সচল থাকলেও সবকিছু অত্যন্ত ধীরগতির হয়ে যায়। vmstat 1 5 কমান্ডটি এই দুটিকে আলাদা করতে সাহায্য করে: si এবং so কলামে ক্রমাগত শূন্য ছাড়া অন্য কোনো সংখ্যা থাকা মানেই হলো swap ব্যবহৃত হচ্ছে। উভয় ক্ষেত্রেই থাম্বনেইল জেনারেশন, ফেস ডিটেকশন এবং স্মার্ট সার্চের জন্য job concurrency কমিয়ে দিন।

Immich লগে exit code 137-এর অর্থ কী?

137 মানে হলো 128 যোগ সিগন্যাল 9, অর্থাৎ প্রসেসটিকে SIGKILL সিগন্যালের মাধ্যমে বন্ধ করা হয়েছে। বাস্তবে এর অর্থ হলো মেমোরির সীমা অতিক্রম করা হয়েছে, যা কন্টেইনারের নিজস্ব সীমা হতে পারে অথবা পুরো হোস্ট সার্ভারের মেমোরি শেষ হয়ে যাওয়া হতে পারে। 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 ফেস মডেল ব্যবহার করুন এবং প্রথমবার বড় আকারের ইমপোর্ট রাতের বেলা চলতে দিন।