حداقل رم و فضای دیسک مورد نیاز برای نصب Immich

Immich به چه مقدار رم نیاز دارد؟

Immich حداقل 6 GB رم (حافظه دسترسی تصادفی) را به عنوان حداقلِ مستندشده و 8 GB را به عنوان مقدار پیشنهادی درخواست می‌کند. این مقادیر برای 2 هسته CPU در سطح پایین و 4 هسته برای یک نصب راحت در نظر گرفته شده است. این رقم کل پشته (stack) را پوشش می‌دهد، زیرا Immich به جای یک برنامه واحد، از چهار کانتینر تشکیل شده است. مرور کتابخانه‌ای که قبلاً وارد (import) شده، هزینه کمی دارد. مصرف حافظه مربوط به عملیات وارد کردن است و بخش عمده آن توسط کانتینری مصرف می‌شود که می‌توانید آن را خاموش کنید.

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

این‌ها ارقام منتشرشده از صفحه نیازمندی‌های Immich تا اوت 2026 هستند. این مقادیر یک توصیه برای تعیین اندازه (sizing) هستند، نه یک بررسی سیستمی که نرم‌افزار هنگام شروع اجرا می‌کند. Immich با مقدار کمتر هم اجرا می‌شود. آنچه در یک سرور کوچک‌تر تغییر می‌کند، این است که کدام کارهای پس‌زمینه (background jobs) به پایان می‌رسند و هنگام تمام شدن حافظه، عملیات وارد کردن چه واکنشی نشان می‌دهد.

یک محدودیت سخت‌افزاری واقعی وجود دارد. نسخه 3 و بالاتر Immich به یک CPU با قابلیت x86-64-v2 در میزبان‌های amd64 نیاز دارد که اکثر پردازنده‌های فروخته‌شده از حدود سال 2012 را پوشش می‌دهد. روی سخت‌افزارهای قدیمی‌تر، کانتینر به جای اجرای کند، اصلاً اجرا نمی‌شود.

اگر هنوز نصب را انجام نداده‌اید، با نصب کامل Immich روی یک VPS با Docker Compose شروع کنید و سپس برای تعیین اندازه سرور به اینجا بازگردید.

حافظه کجا مصرف می‌شود: چهار کانتینر

فایل Compose رسمی، چهار سرویس را راه‌اندازی می‌کند. هر کدام الگوی مصرف حافظه متفاوتی دارند، بنابراین یک عدد کلی، بخش‌های مهم را پنهان می‌کند.

immich-server رابط وب و API را ارائه می‌دهد و همچنین workerهای پردازش پس‌زمینه را اجرا می‌کند. دو worker درون همین یک کانتینر قرار دارند. api به درخواست‌های مرورگر و اپلیکیشن موبایل پاسخ می‌دهد. microservices صف‌ها را مدیریت می‌کند، که شامل تولید بندانگشتی (thumbnail) و انکود ویدیو است. متغیرهای IMMICH_WORKERS_INCLUDE و IMMICH_WORKERS_EXCLUDE این دو را به کانتینرهای جداگانه تقسیم می‌کنند؛ این روشی است که به شما اجازه می‌دهد برای بخش پرمصرف، محدودیت حافظه اختصاصی تعیین کنید بدون آنکه بخشی که تصاویر شما را سرو می‌کند، محدود شود.

database یک ایمیج PostgreSQL 14 است که افزونه VectorChord در آن تعبیه شده است. این سرویس تمام متادیتاها و یک بردار جستجو برای هر دارایی (asset) را نگهداری می‌کند. مستندات Immich تنها کفِ حافظه صریح را برای این سرویس در کل پشته تعیین کرده‌اند: اگر محدودیت منابع Docker اعمال می‌کنید، دیتابیس حداقل به 2 GB حافظه نیاز دارد. همان صفحه تأکید می‌کند که دیتابیس باید روی حافظه SSD محلی قرار گیرد و هرگز نباید روی هیچ نوع شبکه اشتراکی (network share) باشد، زیرا جستجوهای بردار و ایندکس شامل خواندن‌های تصادفی کوچک هستند و یک volume شبکه، هر کدام از این عملیات را به یک رفت‌وبرگشت (round trip) تبدیل می‌کند. اگر انتخاب پلن شما به این موضوع وابسته است، تفاوت بین حافظه NVMe و SATA SSD در یک VPS در اینجا بیش از هر جای دیگری در این پشته اهمیت دارد.

redis ایمیج Valkey را اجرا می‌کند و صف‌های کاری را نگه می‌دارد. این سرویس با اختلاف زیاد، کوچک‌ترینِ این چهار مورد است، زیرا به جای داده‌های عکس، رکوردهای کاری را ذخیره می‌کند.

immich-machine-learning سرویسی است که اندازه پلن شما را تعیین می‌کند. این سرویس مدل‌هایی را برای جستجوی هوشمند، تشخیص چهره و تشخیص متن بارگذاری می‌کند و یک مدل بارگذاری‌شده در حافظه باقی می‌ماند. مقدار پیش‌فرض MACHINE_LEARNING_MODEL_TTL برابر با 300 است، بنابراین اگر به مدت پنج دقیقه درخواستی نباشد، مدل از حافظه خارج شده و در درخواست بعدی دوباره از volume /cache خوانده می‌شود. در طول یک import انبوه، هرگز وقفه پنج دقیقه‌ای ایجاد نمی‌شود، بنابراین مدل‌ها از اولین دارایی تا آخرین دارایی در حافظه باقی می‌مانند.

تغییرات هنگام Import

یک Immich در حالت بیکار، ساکت است. فرآیند Import جایی است که سرورهای کوچک دچار مشکل می‌شوند، زیرا آپلود یک دارایی (asset)، زنجیره‌ای از وظایف (jobs) را در صف قرار می‌دهد و چندین صف به‌طور هم‌زمان اجرا می‌شوند.

استخراج متادیتا (Metadata extraction) هدر فایل را می‌خواند و سبک است. تولید بندانگشتی (Thumbnail generation) سنگین‌تر است. Immich برای هر دارایی سه خروجی بندانگشتی تولید می‌کند: یک placeholder از نوع thumbhash تار، یک پیش‌نمایش WebP و یک بندانگشتی JPEG؛ به‌علاوه یک بندانگشتی دیگر برای هر چهره شناسایی‌شده. هر یک از این وظایف یک تصویر را دیکد می‌کنند و میزان هم‌زمانی وظایف (job concurrency) تعیین می‌کند که چه تعداد در یک لحظه دیکد شوند. این هم‌زمانی، ضریبی است که هزینه اندک هر وظیفه را به یک بارِ سنگین برای کل سرور تبدیل می‌کند؛ به همین دلیل است که در FAQ مربوط به Immich، کاهش آن اولین توصیه برای ماشین‌های با منابع محدود است. در بخش Administration، Settings، Job Settings، مقدار هم‌زمانی را برای صف‌های سنگین روی 1 تنظیم کنید.

دارایی‌های ویدیویی، فرآیند Transcoding را اضافه می‌کنند. هر وظیفه Transcode یک فرآیند FFmpeg مجزا با حافظه اختصاصی خود است و از تمام رشته‌های (thread) CPU که به آن اجازه دهید، استفاده خواهد کرد.

جستجوی هوشمند (Smart search)، هر دارایی جدید را برای محاسبه یک بردار embedding به کانتینر یادگیری ماشین می‌فرستد. تشخیص چهره (Face detection) نیز مدل دومی را روی همان تصویر اجرا می‌کند. در اولین Import از یک کتابخانه عکس موجود، هر دوی این صف‌ها ساعت‌ها روی تمام دارایی‌های شما اجرا می‌شوند. این بدترین لحظه برای مصرف حافظه در کل نصب است و فقط یک‌بار اتفاق می‌افتد.

چرا تشخیص چهره و اشیاء به بیشترین میزان RAM نیاز دارند

پردازش چهره شامل دو وظیفه است. تشخیص چهره (Face detection)، یک مدل را در کانتینر یادگیری ماشین اجرا کرده و کادرهای مربوطه را پیدا می‌کند. سپس تشخیص هویت چهره (Facial recognition)، این موارد شناسایی‌شده را در دسته‌های مربوط به افراد گروه‌بندی می‌کند؛ این مرحله، ایندکس برداری (vector index) را در Postgres پرس‌وجو می‌کند. بنابراین، یک کتابخانه بزرگ به‌نوبت به هر دو سرویس فشار می‌آورد: ابتدا کانتینر مدل در حین اجرای تشخیص، و سپس دیتابیس در حین اجرای گروه‌بندی.

چهار تنظیمات وجود دارد که میزان بارگذاری کانتینر یادگیری ماشین را تغییر می‌دهد:

• مدل چهره. Immich به‌صورت پیش‌فرض از buffalo_l استفاده می‌کند و در FAQ توصیه شده است که در سرورهای کوچک از buffalo_s استفاده شود. این مدل کوچک‌تر است، بنابراین حافظه کمتری اشغال کرده و سریع‌تر اجرا می‌شود، اما دقت آن در چهره‌های کوچک یا نیم‌رخ کمتر است.
• تعداد Workerها. مقدار MACHINE_LEARNING_WORKERS به‌صورت پیش‌فرض روی 1 تنظیم شده است. هر Worker یک پردازش مجزا است که کپی مخصوص به خود از مدل‌ها را بارگذاری می‌کند، بنابراین افزایش آن به 2، حافظه مقیم (resident memory) مدل‌ها را تقریباً دو برابر می‌کند. تا زمانی که RAM اضافه ندارید، آن را روی 1 نگه دارید.
• اندازه دسته (Batch size). مقدار MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION محدودیت تعداد چهره‌هایی که هم‌زمان پردازش می‌شوند را تعیین می‌کند. یک دسته به‌طور کامل در حافظه نگه داشته می‌شود، بنابراین یک عکس دسته‌جمعی با چهل چهره، حافظه بیشتری نسبت به یک پرتره اشغال می‌کند.
• اینکه کدام نوع مدل‌ها اصلاً اجرا شوند. جستجوی هوشمند، تشخیص چهره و تشخیص متن، هر کدام مدل‌های خاص خود را بارگذاری می‌کنند. غیرفعال کردن مواردی که از آن‌ها استفاده نمی‌کنید، از طریق مسیر Administration, Settings, Machine Learning Settings، باعث می‌شود حافظه مصرفی آن‌ها به‌طور دائم آزاد شود (نه فقط در فواصل بین وارد کردن فایل‌ها).

همچنین تنظیم MACHINE_LEARNING_MODEL_ARENA وجود دارد که مستندات آن را به‌عنوان پیش‌تخصیص حافظه CPU برای جلوگیری از تکه‌تکه شدن (fragmentation) معرفی کرده‌اند و به‌صورت پیش‌فرض فعال است. این مورد را به‌عنوان آخرین گزینه تغییر دهید. تأثیر آن به تخصیص‌دهنده حافظه (memory allocator) زیرساختی بستگی دارد، بنابراین تنها راه صادقانه برای قضاوت در مورد آن، مشاهده docker stats قبل و بعد از تغییر است.

سه پروفایل عملیاتی: 2 گیگابایت، 4 گیگابایت و 8 گیگابایت

[
  {
    "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 گیگابایتی: حذف کانتینر یادگیری ماشین

2 گیگابایت پایین‌تر از حداقل مقدار مستندشده یعنی 6 گیگابایت است، بنابراین این یک مصالحه است و باید به عنوان یک محدودیت شناخته شود. کل سرویس immich-machine-learning را در docker-compose.yml کامنت کنید، یا آن را فعال بگذارید و تمام مدل‌ها را در بخش Administration، Settings، Machine Learning Settings غیرفعال کنید. حذف کانتینر گزینه مطمئن‌تری است، زیرا یک مدل غیرفعال همچنان یک پردازش Python را در حافظه باقی می‌گذارد.

شما قابلیت‌های آپلود، آلبوم‌ها، اشتراک‌گذاری، پشتیبان‌گیری موبایل، تصاویر بندانگشتی (thumbnails) و جستجو بر اساس تاریخ، مکان و نام فایل را حفظ می‌کنید. شما قابلیت جستجو بر اساس توضیحات، گروه‌بندی خودکار چهره‌ها در بخش افراد و تشخیص متن داخل تصاویر را از دست می‌دهید.

مجموع چهار محدودیت حدود 1.7 گیگابایت است که تقریباً 300 مگابایت برای میزبان باقی می‌گذارد. توجه داشته باشید که 768 مگابایت برای پایگاه داده، کمتر از کف 2 گیگابایتی مستندشده است. این دقیقاً همان مصالحه‌ای است که 2 گیگابایت تحمیل می‌کند و به همین دلیل Postgres سرویسی است که در اینجا بیشترین احتمال توقف توسط سیستم را دارد.

آنچه ابتدا دچار مشکل می‌شود، فرآیند import است، نه مرور کردن. یک کتابخانه با ده‌ها هزار عکس، پس از import شدن به خوبی مرور می‌شود، زیرا نمایش یک صفحه شامل یک کوئری متادیتا و خواندن یک فایل است. یک import سنگین ویدیو در همان سرور باعث استفاده از swap می‌شود، زیرا فرآیند transcode و صف تولید تصاویر بندانگشتی همزمان به حافظه نیاز دارند. تمام صف‌های سنگین را روی concurrency 1 تنظیم کنید و یک فایل swap اضافه کنید.

سرور 4 گیگابایتی: یادگیری ماشین فعال، یک کار در هر زمان

4 گیگابایت کوچک‌ترین اندازه‌ای است که در آن تشخیص چهره و اشیاء ارزش فعال‌سازی را دارد. کانتینر یادگیری ماشین را روی 0 مگابایت محدود کنید، تشخیص چهره را روی buffalo_s قرار دهید و concurrency کارها را برای تولید تصاویر بندانگشتی، تشخیص چهره و جستجوی هوشمند روی 1 تنظیم کنید.

اولین پردازش روی یک کتابخانه موجود، چندین ساعت و در کتابخانه‌های بزرگ بیش از یک روز طول می‌کشد. این یک محدودیت CPU است نه حافظه، بنابراین رم بیشتر آن را کوتاه نمی‌کند.

آنچه در اینجا ابتدا دچار مشکل می‌شود، کانتینر یادگیری ماشین در طول آن اولین پردازش انبوه است. اگر محدود نشود، همزمان با رشد کار transcode بزرگ می‌شود و هسته سیستم‌عامل بزرگ‌تر از این دو را متوقف می‌کند. شما Exited (137) را در docker ps -a مشاهده می‌کنید و کانتینر ری‌استارت می‌شود، در حالی که صف پردازش‌ها عقب‌تر از زمانی است که آخرین بار بررسی کردید.

سرور 8 گیگابایتی: توصیه مستندشده

8 گیگابایت رم با 4 هسته CPU، مطابق با توصیه Immich است و همه چیز با تنظیمات پیش‌فرض اجرا می‌شود: جستجوی هوشمند، تشخیص چهره، تشخیص متن و transcoding با concurrency پیش‌فرض. کتابخانه‌های با بیش از صد هزار آیتم در اینجا به راحتی اجرا می‌شوند و فشار از حافظه به سرعت دیسک منتقل می‌شود، زیرا ایندکس برداری و کوئری‌های متادیتا همان چیزی هستند که پایگاه داده در تمام طول روز انجام می‌دهد.

با این حال محدودیت‌ها را اعمال کنید. در سروری که فضای کافی دارد، این محدودیت‌ها مانع از آن می‌شوند که یک صفِ خارج از کنترل، پایگاه داده را با خود از کار بیندازد. اگر در حال مقایسه قیمت این گزینه با گزینه‌های کوچک‌تر هستید، هزینه واقعی یک VPS بر اساس سطح حافظه معمولاً باعث می‌شود طرح 8 گیگابایتی ارزان‌ترین راه برای خلاص شدن از تنظیمات دستی باشد.

نحوه محدود کردن حافظه برای هر سرویس با استفاده از 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 به‌جای کل حافظه میزبان نشان دهد. اگر ستون محدودیت همچنان اندازه کامل میزبان را نشان می‌دهد، فایل override شناسایی نشده است: نام فایل را بررسی کنید و docker compose config را اجرا کنید تا نتیجه ادغام‌شده را ببینید.

محدودیتی که بیش از حد پایین باشد، یک سرویس کند را به یک سرویس ازکارافتاده تبدیل می‌کند، بنابراین اگر container شروع به چرخه راه‌اندازی مجدد کرد، آن را افزایش دهید. جزئیات بیشتر درباره مکانیسم این کار در تنظیم محدودیت‌های حافظه برای هر سرویس در Docker Compose آمده است، از جمله اینکه چرا deploy خارج از Swarm با Compose v2 کار می‌کند.

نحوه غیرفعال‌سازی یا انتقال کانتینر یادگیری ماشین

در یک سرور کوچک، انتقال این کانتینر به جای دیگر، بزرگ‌ترین تغییری است که می‌توانید اعمال کنید. 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 بین دو میزبان اجرا کنید. هرگز پورت 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 گیگابایت برای عکس‌ها و 60 گیگابایت برای ویدیوها، فرض هستند. پیش از خرید هرگونه سخت‌افزار، این مقادیر را با میانگین‌های خود جایگزین کنید، زیرا ویدیو تعیین‌کننده اصلی این عدد است: یک دقیقه ویدیوی موبایل از صدها عکس حجم بیشتری اشغال می‌کند.

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 گیگابایت تنها نسبت منتشرشده‌ای است که Immich ارائه می‌دهد: بندانگشتی‌های (thumbnails) تولیدشده و ویدیوهای تبدیل‌شده (transcoded)، به‌طور میانگین 10 تا 20 درصد به حجم کتابخانه اضافه می‌کنند. این یک بازه است، زیرا به تعداد فایل‌های ویدیویی شما که نیاز به انکود مجدد برای سازگاری با مرورگر دارند، بستگی دارد. کتابخانه‌ای متشکل از فایل‌های JPEG در پایین این بازه قرار می‌گیرد.

پایگاه داده 3 گیگابایت است و این مقدار تقریباً یک هزینه ثابت محسوب می‌شود. Immich فایل‌های پایگاه داده را معمولاً 1 تا 3 گیگابایت ذکر می‌کند، زیرا این فایل‌ها به جای پیکسل، متادیتا و بردارهای جستجو را ذخیره می‌کنند. کش مدل‌ها 2 گیگابایت است و اگر چندین مدل را فعال کنید یا مدل‌های مختلف را آزمایش کنید، رشد می‌کند. بخش FAQ دقیقاً به همین دلیل، این حجم را به عنوان یک مصرف‌کننده فضا علامت‌گذاری کرده است.

مجموع این پنج ردیف کمی بیش از 300 گیگابایت است، بنابراین یک درایو 500 گیگابایتی فضای کافی برای رشد باقی می‌گذارد، اما یک درایو 250 گیگابایتی خیر. تفکیک فضا را با دستور زیر بررسی کنید:

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 از یک VPS به فضای ذخیره‌سازی خارج از سرور برای آن طراحی شده است.

ترنسکدینگ از CPU استفاده می‌کند، نه RAM

افزایش RAM باعث سریع‌تر شدن ترنسکدینگ نمی‌شود. Immich عملیات ترنسکدینگ را با استفاده از FFmpeg انجام می‌دهد و در یک VPS معمولی، هر فریم توسط CPU دیکد و انکد می‌شود. حتی در مواردی که شتاب‌دهنده سخت‌افزاری در دسترس باشد، مستندات Immich تأکید می‌کنند که فقط انکدینگ شتاب‌دهی می‌شود و بنابراین CPU همچنان وظیفه دیکدینگ نرم‌افزاری و tone mapping را بر عهده دارد.

شتاب‌دهنده سخت‌افزاری به فایل hwaccel.transcoding.yml Compose اضافی و یک دستگاه برای pass-through نیاز دارد که از NVENC، Quick Sync، RKMPP یا VAAPI استفاده کند. اکثر پلن‌های VPS هیچ‌کدام از این موارد را ارائه نمی‌دهند، بنابراین برای استفاده از CPU برنامه‌ریزی کنید.

تنظیم کاربردی در اینجا، تعداد threadها است. در بخش Administration، تنظیمات Video Transcoding Settings، مقدار 0 برای thread به معنای استفاده از تمام هسته‌ها است که باعث می‌شود یک ویدیو در پلن‌های 2 هسته‌ای، رابط کاربری وب را فریز کند. همان‌طور که در FAQ مربوط به Immich پیشنهاد شده است، این مقدار را روی 1 یا 2 تنظیم کنید تا ترنسکدینگ به‌جای ایجاد اختلال، صرفاً با سرعت کمتری انجام شود.

چرا thrashing در swap شبیه به هنگ کردن به نظر می‌رسد

این خطایی است که کاربران اغلب به اشتباه تفسیر می‌کنند. وقتی Immich با کمبود حافظه مواجه می‌شود، دو نتیجه ممکن است رخ دهد که تنها یکی از آن‌ها به عنوان خطا شناسایی می‌شود.

بدون وجود swap، هسته سیستم‌عامل (kernel) یک پردازش را متوقف (kill) می‌کند. کانتینر در عرض چند ثانیه دوباره راه‌اندازی می‌شود، بنابراین از دید مرورگر، صف پردازش‌ها صرفاً متوقف شده و سپس از سر گرفته می‌شود. شواهد این اتفاق در 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، هیچ پردازشی متوقف نمی‌شود و هیچ خطایی رخ نمی‌دهد. هسته شروع به انتقال صفحات حافظه به دیسک می‌کند، سرعت وارد کردن داده‌ها (import) به شدت کاهش می‌یابد و رابط کاربری وب در بازه زمانی معمول پاسخگو نخواهد بود. تمام کانتینرها در حال اجرا هستند. تمام بررسی‌های سلامت (health check) ممکن است همچنان موفقیت‌آمیز باشند. این وضعیت شبیه به هنگ کردن است و کاربران در این مرحله سرور را reboot می‌کنند، که باعث از دست رفتن پیشرفت صف پردازش شده و هیچ مشکلی را حل نمی‌کند.

free -m
vmstat 1 5

مقادیر غیر صفر پایدار در ستون‌های si و so در دستور vmstat به این معنی است که سیستم به‌طور مداوم در حال خواندن و نوشتن در swap است؛ این همان تعریف thrashing است. در همان زمان، مقدار سطر free -m برای Swap مورد استفاده، رو به افزایش خواهد بود.

در هر صورت، روی سرورهای 2 گیگابایتی یا 4 گیگابایتی swap اضافه کنید، زیرا یک import کند که می‌توانید آن را عیب‌یابی کنید، بهتر از کانتینری است که متوقف شده و قابل بررسی نیست:

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) تعیین کنید یا آن را به میزبان دیگری منتقل کنید. swap به شما زمان می‌خرد تا این کارها را انجام دهید. swap به تنهایی راه‌حل نهایی نیست.

FAQ

آیا می‌توانم Immich را روی یک VPS با 2 GB رم اجرا کنم؟

بله، به شرطی که سرویس immich-machine-learning را در فایل docker-compose.yml کامنت کنید و concurrency کارها را روی 1 تنظیم نمایید. این مقدار کمتر از حداقل رم توصیه شده یعنی 6 GB است، بنابراین آن را به عنوان یک محدودیت شناخته‌شده در نظر بگیرید. شما همچنان قابلیت‌های آپلود، آلبوم‌ها، اشتراک‌گذاری، پشتیبان‌گیری موبایل و جستجو بر اساس تاریخ، مکان و نام فایل را خواهید داشت. در مقابل، جستجو بر اساس توضیحات، گروه‌بندی خودکار چهره‌ها و تشخیص متن داخل تصاویر را از دست می‌دهید. یک فایل swap با حجم 2 GB اضافه کنید تا در زمان پیک پردازش، سرور به جای متوقف کردن (kill) کانتینر، دچار کندی شود.

چرا فرآیند import در Immich بدون نمایش پیام خطا متوقف می‌شود؟

دو دلیل متفاوت وجود دارد که در مرورگر مشابه به نظر می‌رسند. یا یک کانتینر به دلیل کمبود حافظه متوقف شده است که در این صورت docker ps -a مقدار Exited (137) را نشان می‌دهد و کانتینر قبلاً ری‌استارت شده است، یا میزبان (host) در حال استفاده از swap است که در این حالت همه کانتینرها در حال اجرا هستند اما سیستم بسیار کند عمل می‌کند. دستور vmstat 1 5 این دو وضعیت را تفکیک می‌کند: اعداد غیر صفر پایدار در ستون‌های si و so به معنای استفاده از swap است. در هر دو حالت، concurrency کارها را برای تولید بندانگشتی (thumbnail)، تشخیص چهره و جستجوی هوشمند کاهش دهید.

کد خروج 137 در لاگ‌های Immich به چه معناست؟

عدد 137 حاصل جمع 128 و سیگنال 9 است، یعنی فرآیند با SIGKILL متوقف شده است. در عمل، این یعنی سقف حافظه پر شده است؛ یا محدودیت خود کانتینر یا کمبود حافظه در کل میزبان. با استفاده از docker inspect immich_machine_learning | grep -i oomkilled وضعیت را بررسی کنید. مقدار true تأیید می‌کند که هسته سیستم‌عامل (kernel) فرآیند را به دلیل کمبود حافظه کشته است و free -m به همراه sudo dmesg -T | grep -i oom-kill به شما می‌گوید که آیا محدودیت مربوط به کانتینر بوده یا کل میزبان. کانتینر یادگیری ماشین معمولاً قربانی اصلی است، زیرا اغلب بزرگترین فرآیند در حال اجراست.

Immich برای هر عکس به چه مقدار فضای دیسک نیاز دارد؟

حجم فایل اصلی به اضافه 10 تا 20 درصد فضا را در نظر بگیرید. مستندات Immich بیان می‌کنند که تصاویر بندانگشتی تولید شده و ویدیوهای تبدیل‌شده (transcoded)، حجم کتابخانه را به‌طور میانگین 10 تا 20 درصد افزایش می‌دهند و خود دیتابیس نیز معمولاً حتی برای کتابخانه‌های بزرگ، بین 1 تا 3 GB فضا اشغال می‌کند. ویدیوها عامل اصلی تعیین‌کننده حجم نهایی هستند، بنابراین پیش از انتخاب پلن، میانگین حجم فایل‌های خود را اندازه بگیرید و به جای ضرب کردن تعداد عکس‌ها در یک ضریب ثابت، بر اساس آن تصمیم بگیرید.

آیا برای Immich به GPU نیاز دارم؟

خیر. تمام بخش‌های Immich روی CPU اجرا می‌شوند. کارت گرافیک سرعت استنتاج مدل در کانتینر یادگیری ماشین و انکود ویدیو را افزایش می‌دهد، اما هیچ‌کدام الزامی نیستند. اکثر پلن‌های VPS کارت گرافیک ارائه نمی‌دهند. روی سخت‌افزارهایی که فقط CPU دارند، تعداد رشته‌های transcoding را روی 1 یا 2 تنظیم کنید، از مدل چهره buffalo_s استفاده کنید و اجازه دهید اولین import سنگین در طول شب انجام شود.