ما هي متطلبات تشغيل Immich من الرام ومساحة التخزين؟

ما مقدار ذاكرة الوصول العشوائي (RAM) التي يحتاجها Immich؟

يطلب Immich مقدار 6 GB من ذاكرة الوصول العشوائي (RAM) كحد أدنى موثق، و8 GB كحد موصى به، مع 2 من أنوية المعالج (CPU) كحد أدنى، و4 لتثبيت مريح. يغطي هذا الرقم حزمة البرمجيات بالكامل، لأن Immich يتكون من أربع حاويات (containers) وليس تطبيقاً واحداً. تصفح مكتبة تم استيرادها بالفعل لا يستهلك الكثير من الموارد. يذهب استهلاك الذاكرة إلى عملية الاستيراد، ويستهلك الجزء الأكبر منها حاوية واحدة يمكنك إيقاف تشغيلها.

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

هذه هي الأرقام المنشورة في صفحة متطلبات Immich اعتباراً من أغسطس 2026. إنها توصية لتحديد الحجم، وليست فحصاً تقنياً يمنع البرنامج من العمل عند الإقلاع. يبدأ Immich العمل بموارد أقل. ما يتغير في الخادم الأصغر هو المهام الخلفية التي تكتمل، وما يحدث أثناء الاستيراد عند نفاد الذاكرة.

يوجد حد تقني صارم واحد. يحتاج الإصدار 3 من Immich وما بعده إلى معالج يدعم x86-64-v2 على مضيفات amd64، وهو ما يغطي معظم المعالجات التي بيعت منذ عام 2012 تقريباً. على الأجهزة الأقدم، تفشل الحاوية في البدء بدلاً من العمل ببطء.

إذا كنت لا تزال في مرحلة ما قبل التثبيت، ابدأ بـ التثبيت الكامل لـ Immich على خادم VPS باستخدام Docker Compose ثم عد إلى هنا لتحديد حجم الخادم المناسب.

أين تذهب الذاكرة: أربع حاويات

يبدأ ملف Compose الرسمي أربع خدمات. لكل منها متطلبات ذاكرة مختلفة، لذا فإن الرقم الإجمالي يخفي التفاصيل المفيدة.

تخدم immich-server واجهة الويب وAPI، كما تُشغّل مهام الخلفية. يعيش عاملان (workers) داخل تلك الحاوية الواحدة. تستجيب api للطلبات القادمة من المتصفح وتطبيق الهاتف. تُشغّل microservices طوابير الانتظار، بما في ذلك إنشاء الصور المصغرة وترميز الفيديو. تفصل المتغيرات IMMICH_WORKERS_INCLUDE وIMMICH_WORKERS_EXCLUDE هاتين الخدمتين إلى حاويتين منفصلتين، وهي الطريقة التي تمنح بها الجزء الذي يستهلك موارد كثيرة حد ذاكرة خاصاً به دون تقييد الجزء الذي يعرض صورك.

database هي صورة PostgreSQL 14 مع إضافة VectorChord مدمجة. تحتفظ بكل جزء من البيانات الوصفية ومتجه بحث واحد لكل أصل. تضع وثائق Immich لهذه الخدمة الحد الأدنى الوحيد الصريح في الحزمة: إذا طبقت حدود موارد Docker، تحتاج قاعدة البيانات إلى 2 GB على الأقل. تنص الصفحة نفسها على أن قاعدة البيانات يجب أن توضع على وحدة تخزين SSD محلية وليس على مشاركة شبكة من أي نوع، لأن عمليات البحث عن المتجهات والفهارس هي عمليات قراءة عشوائية صغيرة، لذا فإن وحدة تخزين الشبكة تحول كل عملية منها إلى رحلة ذهاب وإياب. إذا كان اختيار الخطة يعتمد على ذلك، فإن الفرق بين وحدات تخزين NVMe وSATA SSD على خادم افتراضي خاص (VPS) يهم هنا أكثر من أي مكان آخر في هذه الحزمة.

تُشغّل redis صورة Valkey وتحتفظ بطوابير المهام. هي الأصغر بين الأربع بفارق كبير، لأنها تخزن سجلات المهام بدلاً من بيانات الصور.

immich-machine-learning هي الخدمة التي تحدد حجم خطتك. تقوم بتحميل نماذج للبحث الذكي، واكتشاف الوجوه، والتعرف على النصوص، ويبقى النموذج المحمّل مقيماً في الذاكرة. القيمة الافتراضية لـ MACHINE_LEARNING_MODEL_TTL هي 300، لذا يتم إسقاط النموذج بعد خمس دقائق من عدم وجود طلبات، ثم يُقرأ مجدداً من وحدة التخزين /cache عند الطلب التالي. أثناء الاستيراد الجماعي، لا توجد فجوة مدتها خمس دقائق، لذا تظل النماذج محمّلة من أول أصل إلى آخره.

ما الذي يتغير أثناء الاستيراد

يكون Immich هادئاً في حالة الخمول. الاستيراد هو المرحلة التي تتعثر فيها الخوادم الصغيرة، لأن رفع أصل واحد يضع سلسلة من المهام في قائمة الانتظار، وتعمل عدة قوائم في وقت واحد.

استخراج البيانات الوصفية يقرأ ترويسة الملف وهو إجراء خفيف. أما توليد الصور المصغرة فهو أثقل. ينتج Immich ثلاثة مخرجات للصور المصغرة لكل أصل: عنصر نائب مشوش (thumbhash)، ومعاينة بصيغة WebP، وصورة مصغرة بصيغة JPEG، بالإضافة إلى صورة مصغرة إضافية لكل وجه يتم اكتشافه. كل مهمة من هذه المهام تقوم بفك ترميز صورة، وتحدد "تزامن المهام" (job concurrency) عدد المهام التي يتم فك ترميزها في وقت واحد. التزامن هو المضاعف الذي يحوّل التكلفة الصغيرة لكل مهمة إلى تكلفة على مستوى الخادم بالكامل، ولهذا السبب يذكر FAQ الخاص بـ Immich هذا الإعداد كأول شيء يجب خفضه على الأجهزة ذات الموارد المحدودة. اضبط التزامن للقوائم الثقيلة على 1 من خلال Administration، ثم Settings، ثم Job Settings.

تضيف أصول الفيديو عملية تحويل الترميز (transcoding). كل مهمة تحويل ترميز هي عملية FFmpeg منفصلة لها ذاكرتها الخاصة، وستستخدم كل خيط معالجة (CPU thread) تسمح لها به.

يرسل البحث الذكي (Smart search) كل أصل جديد إلى حاوية تعلم الآلة لحساب متجه تضمين واحد. يعمل اكتشاف الوجوه (Face detection) بنموذج ثانٍ على نفس الصورة. عند الاستيراد الأول لمكتبة صور موجودة، تعمل كلتا القائمتين على كل أصل تمتلكه، وذلك لساعات. تلك هي اللحظة الأسوأ بالنسبة للذاكرة في التثبيت بالكامل، وهي تحدث مرة واحدة فقط.

لماذا تتطلب ميزتا التعرف على الوجوه والأجسام أكبر قدر من ذاكرة الوصول العشوائي (RAM)

تتكون معالجة الوجوه من مهمتين. تقوم ميزة اكتشاف الوجوه بتشغيل نموذج داخل حاوية تعلم الآلة لتحديد مربعات الوجوه. بعد ذلك، تقوم ميزة التعرف على الوجوه بتجميع هذه الاكتشافات وتصنيفها كأشخاص، وتستعلم هذه الخطوة عن فهرس المتجهات (vector index) في Postgres. لذا، فإن المكتبة الكبيرة تضغط على الخدمتين بالتناوب: حاوية النموذج أثناء تشغيل الاكتشاف، ثم قاعدة البيانات أثناء تشغيل التجميع.

تغير الإعدادات الأربعة التالية ما تحتفظ به حاوية تعلم الآلة:

• نموذج الوجه. يشحن Immich الإعداد buffalo_l افتراضياً، ويوصي قسم FAQ باستخدام buffalo_s على الخوادم الصغيرة. إنه نموذج أصغر، لذا فهو يشغل ذاكرة أقل ويعمل بشكل أسرع، على حساب الدقة في الوجوه الصغيرة أو الجانبية.
• عدد العاملين (worker count). القيمة الافتراضية لـ MACHINE_LEARNING_WORKERS هي 1. كل عامل هو عملية منفصلة تقوم بتحميل نسختها الخاصة من النماذج، لذا فإن رفع هذا العدد إلى 2 يضاعف تقريباً ذاكرة النموذج المقيمة. أبقِ القيمة عند 1 ما لم تكن لديك ذاكرة RAM فائضة.
• حجم الدفعة (batch size). يحدد MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION الحد الأقصى لعدد الوجوه التي تتم معالجتها في وقت واحد. يتم الاحتفاظ بالدفعة في الذاكرة معاً، لذا فإن صورة جماعية تحتوي على أربعين وجهاً تستهلك ذاكرة أكبر من صورة شخصية واحدة.
• أنواع النماذج التي تعمل فعلياً. تقوم ميزات البحث الذكي، واكتشاف الوجوه، والتعرف على النصوص بتحميل نماذجها الخاصة. إيقاف الميزات التي لا تستخدمها، من خلال Administration، ثم Settings، ثم Machine Learning Settings، يزيل استهلاكها للذاكرة بشكل دائم وليس فقط بين عمليات الاستيراد.

يوجد أيضاً الإعداد MACHINE_LEARNING_MODEL_ARENA، وهو موثق على أنه يقوم بالحجز المسبق لذاكرة المعالج (CPU memory) لتجنب التجزئة، وهو مفعل افتراضياً. قم بتغيير هذا الإعداد كخيار أخير. يعتمد تأثيره على مخصص الذاكرة الأساسي، لذا فإن الطريقة الوحيدة الصادقة لتقييمه هي مراقبة 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 فعلياً. الحد هو سقف أقصى. هو لا يحجز أي موارد، ولا يجعل الخدمة أصغر حجماً. هو يحدد أي خدمة سيقوم النواة (kernel) بإنهاؤها عند نفاد موارد الخادم، وهذا قرار من الأفضل أن تتخذه أنت بدلاً من تركه لآلية التقييم الخاصة بالنواة.

خادم 2 جيجابايت: إزالة حاوية التعلم الآلي

سعة 2 جيجابايت تقع تحت الحد الأدنى الموثق البالغ 6 جيجابايت، لذا فهذا حل وسط يستحق التسمية. قم بالتعليق على خدمة immich-machine-learning بالكامل في ملف docker-compose.yml، أو اتركها تعمل مع تعطيل كل نموذج تحت Administration، Settings، Machine Learning Settings. إزالة الحاوية هي الخيار الأقوى، لأن النموذج المعطل يترك عملية Python مقيمة في الذاكرة.

ستحتفظ بميزات الرفع، والألبومات، والمشاركة، والنسخ الاحتياطي للهاتف، والصور المصغرة، والبحث حسب التاريخ والمكان واسم الملف. ستفقد ميزة البحث حسب الوصف، والتجميع التلقائي للوجوه في أشخاص، والتعرف على النصوص داخل الصور.

تصل الحدود الأربعة مجتمعة إلى حوالي 1.7 جيجابايت، مما يترك للخادم المضيف حوالي 300 ميجابايت. لاحظ أن 768 ميجابايت لقاعدة البيانات هي أقل من الحد الأدنى الموثق البالغ 2 جيجابايت. هذا هو بالضبط الحل الوسط الذي تفرضه سعة 2 جيجابايت، وهو السبب في أن Postgres هي الخدمة الأكثر عرضة للإنهاء هنا.

ما يتعطل أولاً هو عملية الاستيراد، وليس التصفح. مكتبة تحتوي على عشرات الآلاف من الصور يمكن تصفحها بشكل مقبول بمجرد استيرادها، لأن عرض الصفحة هو استعلام عن البيانات الوصفية متبوعاً بقراءة ملف. عملية استيراد مكثفة للفيديوهات على نفس الخادم ستؤدي إلى استخدام الـswap، لأن عملية تحويل الترميز (transcode) وطابور الصور المصغرة يحتاجان الذاكرة في نفس اللحظة. اضبط كل طابور ثقيل على توازي (concurrency) يساوي 1 وأضف ملف swap.

خادم 4 جيجابايت: التعلم الآلي مفعّل، مهمة واحدة في كل مرة

سعة 4 جيجابايت هي أصغر حجم يستحق فيه تفعيل التعرف على الوجوه والأشياء. حدد سقف حاوية التعلم الآلي بـ 0 ميجابايت، وحوّل التعرف على الوجوه إلى buffalo_s، واضبط توازي المهام على 1 لتوليد الصور المصغرة، واكتشاف الوجوه، والبحث الذكي.

ستستمر الجولة الأولى على مكتبة موجودة لعدة ساعات، وفي حال كانت المكتبة كبيرة، لأكثر من يوم. هذا حد متعلق بالمعالج (CPU) وليس بالذاكرة، لذا فإن زيادة الرام لن تقصر المدة.

ما يتعطل هنا أولاً هو حاوية التعلم الآلي أثناء تلك الجولة الجماعية الأولى. بدون سقف، تنمو الحاوية بينما تنمو أيضاً مهمة تحويل الترميز، وسيقوم النواة بإنهاء الأكبر بينهما. سترى Exited (137) في docker ps -a وحاوية تمت إعادة تشغيلها، مع طابور مهام متأخر أكثر مما كان عليه عند آخر فحص.

خادم 8 جيجابايت: التوصية الموثقة

سعة 8 جيجابايت مع 4 أنوية تطابق ما يوصي به Immich، ويعمل كل شيء بالإعدادات الافتراضية: البحث الذكي، اكتشاف الوجوه، التعرف على النصوص، وتحويل الترميز، بالتوازي الافتراضي. المكتبات التي تتجاوز مئة ألف أصل تعمل براحة هنا، وينتقل الضغط من الذاكرة إلى سرعة القرص، لأن فهرس المتجهات (vector index) واستعلامات البيانات الوصفية هي ما تقوم به قاعدة البيانات طوال اليوم.

اضبط الحدود على أي حال. على خادم يمتلك مساحة، تمنع الحدود أي طابور مهام جامح من إسقاط قاعدة البيانات معه. إذا كنت تقارن التكلفة بالخيارات الأصغر، فإن التكلفة الفعلية لخادم VPS حسب فئة الذاكرة تجعل خطة 8 جيجابايت عادةً هي الطريقة الأرخص للتوقف عن الضبط اليدوي.

كيفية تحديد سقف الذاكرة لكل خدمة باستخدام قيود Compose

لا تُعدّل 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 لرؤية النتيجة المدمجة.

القيد المنخفض جداً يحوّل الخدمة البطيئة إلى خدمة متوقفة، لذا ارفعه إذا بدأ الحاوية في دورة إعادة التشغيل. يوجد المزيد حول الآليات في ضبط قيود الذاكرة لكل خدمة في 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: تضيف الصور المصغرة المُنشأة والفيديو المُعاد ترميزه ما بين 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 إلى وحدة تخزين خارجية.

تعتمد عملية تحويل الترميز (Transcoding) على المعالج لا على الذاكرة

إضافة المزيد من الذاكرة (RAM) لن تسرّع عملية تحويل الترميز. يستخدم Immich برنامج FFmpeg للتحويل، وفي خوادم VPS العادية، يتم فك تشفير كل إطار وإعادة تشفيره بواسطة المعالج (CPU). حتى في الحالات التي يتوفر فيها تسريع عتادي، يوضح توثيق Immich أن التسريع يقتصر على التشفير فقط، مما يعني أن المعالج لا يزال يتولى مهام فك التشفير البرمجي وتعيين النغمات (tone mapping).

يتطلب التسريع العتادي ملف hwaccel.transcoding.yml Compose إضافي وجهازاً لتمريره (pass through)، باستخدام تقنيات مثل NVENC أو Quick Sync أو RKMPP أو VAAPI. معظم خطط VPS لا توفر أياً من هذه الميزات، لذا خطط لعملياتك بناءً على قدرة المعالج.

الإعداد العملي هنا هو عدد الخيوط (thread count). ضمن قسم الإدارة (Administration)، ثم الإعدادات (Settings)، ثم إعدادات تحويل ترميز الفيديو (Video Transcoding Settings)، تعني القيمة 0 استخدام جميع الأنوية، وهو ما قد يؤدي إلى تجميد واجهة الويب عند معالجة فيديو واحد على خطة ذات نواتين. اضبط القيمة على 1 أو 2 كما تقترح الأسئلة الشائعة لـ Immich، وبذلك ستصبح عملية تحويل الترميز بطيئة بدلاً من أن تكون معطلة للنظام.

لماذا يبدو استهلاك الـ swap المفرط (thrashing) كأنّه تعليق للنظام

هذا هو الفشل الذي يسيء المستخدمون فهمه في أغلب الأحيان. عندما تنفد ذاكرة Immich، هناك نتيجتان محتملتان، وواحدة منهما فقط تبدو كفشل واضح.

بدون وجود مساحة swap، يقوم النواة (kernel) بإنهاء العملية. يعيد الحاوية التشغيل في غضون ثوانٍ، لذا من منظور المتصفح، تتوقف قائمة المهام مؤقتاً ثم تستأنف العمل. تظهر الأدلة في 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، فلا يتم إنهاء أي شيء ولا تظهر أي أخطاء. يبدأ النواة بنقل الصفحات إلى القرص، وتتباطأ عملية الاستيراد بمقدار عشرة أضعاف، وتتوقف واجهة الويب عن الاستجابة ضمن مهلة الانتظار العادية. كل الحاويات تعمل، وقد تظل جميع فحوصات السلامة (health checks) ناجحة. يبدو الأمر كأن النظام معلّق، فيقوم المستخدمون بإعادة تشغيل الخادم عند هذه النقطة، مما يؤدي إلى فقدان تقدم قائمة المهام دون حل المشكلة.

free -m
vmstat 1 5

وجود قيم مستمرة غير صفرية في عمودي si وso في vmstat يعني أن الجهاز يقرأ ويكتب في الـ swap بشكل متواصل، وهذا هو تعريف الـ thrashing. في الوقت نفسه، ستلاحظ ارتفاعاً في صف free -m الخاص بـ Swap المستخدم.

أضف مساحة swap على أي حال إذا كان جهازك بذاكرة 2 GB أو 4 GB، لأن عملية استيراد بطيئة يمكنك تشخيصها أفضل من حاوية مُنهاة لا يمكنك معرفة سبب توقفها:

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

هل يمكنني تشغيل Immich على خادم افتراضي (VPS) بذاكرة 2 GB؟

نعم، بشرط التعليق على الخدمة immich-machine-learning في ملف docker-compose.yml وضبط التزامن (concurrency) للمهام على 1. هذا أقل من الحد الأدنى الموثق البالغ 6 GB، لذا تعامل مع الأمر كحل وسط معروف. ستحتفظ بميزات الرفع، والألبومات، والمشاركة، والنسخ الاحتياطي للهاتف، والبحث حسب التاريخ والمكان واسم الملف. ستفقد ميزات البحث حسب الوصف، والتجميع التلقائي للوجوه في أشخاص، والتعرف على النصوص داخل الصور. أضف ملف تبديل (swap file) بحجم 2 GB لضمان تباطؤ الخادم عند حدوث ذروة في الاستيراد بدلاً من إنهاء الحاوية (container).

لماذا يتوقف استيراد Immich دون ظهور رسالة خطأ؟

هناك سببان مختلفان يبدوان متطابقين من المتصفح. إما أن الحاوية أُنهيت بسبب نفاد الذاكرة، وفي هذه الحالة يُظهر الأمر docker ps -a القيمة Exited (137) وتكون الحاوية قد أعادت التشغيل بالفعل، أو أن الخادم المضيف يستخدم الذاكرة الافتراضية (swapping)، وفي هذه الحالة تظل جميع الحاويات قيد التشغيل ولكن كل شيء يصبح بطيئاً جداً. يميّز الأمر vmstat 1 5 بينهما: الأرقام غير الصفرية المستمرة في العمودين si وso تعني حدوث تبديل (swapping). قلل تزامن المهام لإنشاء الصور المصغرة، واكتشاف الوجوه، والبحث الذكي في كلتا الحالتين.

ماذا يعني رمز الخروج 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 أن الصور المصغرة المُنشأة ومقاطع الفيديو المُعاد ترميزها تزيد من حجم المكتبة بنسبة 10 إلى 20 بالمئة في المتوسط، وعادة ما يكون حجم قاعدة البيانات نفسها من 1 إلى 3 GB حتى للمكتبات الكبيرة. الفيديو هو العامل الحاسم في إجمالي المساحة، لذا قِس متوسط حجم ملفاتك قبل اختيار خطة التخزين بدلاً من تطبيق معامل ضرب على عدد الصور.

هل أحتاج إلى وحدة معالجة رسومية (GPU) لـ Immich؟

لا. يعمل كل جزء من Immich على وحدة المعالجة المركزية (CPU). تسرّع بطاقة الرسوميات استنتاج النماذج في حاوية تعلم الآلة وترميز الفيديو، وكلاهما ليس ضرورياً. معظم خطط الخوادم الافتراضية (VPS) لا توفر GPU. على الأجهزة التي تعتمد على CPU فقط، اضبط خيوط الترميز (transcoding threads) على 1 أو 2، واستخدم نموذج الوجوه buffalo_s، واترك عملية الاستيراد الجماعي الأولى تعمل طوال الليل.