כמה זיכרון RAM ושטח אחסון דורשת התקנת Immich?

כמה זיכרון RAM דורש Immich?

Immich דורש 6 GB של זיכרון RAM (זיכרון גישה אקראית) כמינימום המתועד שלו, ו-8 GB כהמלצה, על גבי 2 ליבות CPU ברף הנמוך, ו-4 ליבות להתקנה נוחה. נתון זה מכסה את כל ה-stack, כיוון ש-Immich מורכב מארבע מכולות ולא מיישום בודד. עיון בספרייה שכבר יובאה אינו צורך משאבים רבים. צריכת הזיכרון מתרחשת בעת הייבוא, ורובה מיוחסת למכולה אחת שניתן לכבות.

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

אלו הנתונים הרשמיים מדף הדרישות של Immich נכון לאוגוסט 2026. מדובר בהמלצת גודל, ולא בבדיקה שהתוכנה מבצעת בעת העלייה. Immich יתחיל לעבוד גם עם פחות זיכרון. מה שמשתנה בשרת קטן יותר הוא אילו משימות רקע יסתיימו, וכיצד הייבוא יתנהג כאשר הזיכרון אוזל.

קיים מגבלה טכנית אחת ממשית. גרסה 3 של Immich ומעלה דורשת CPU עם x86-64-v2 במארחי amd64, מה שמכסה את רוב המעבדים שנמכרו מאז שנת 2012 בערך. בחומרה ישנה יותר, המכולה תיכשל בעלייה במקום לעבוד לאט.

אם טרם ביצעת את ההתקנה, התחל עם התקנה מלאה של Immich על שרת VPS עם Docker Compose וחזור לכאן כדי להתאים את גודל השרת.

לאן הזיכרון הולך: ארבעה קונטיינרים

קובץ ה-Compose הרשמי מפעיל ארבעה שירותים. לכל אחד מהם דרישות זיכרון שונות, לכן מספר כולל אחד אינו משקף את המציאות בצורה מועילה.

immich-server משרת את ממשק האינטרנט ואת ה-API, והוא גם מריץ את ה-workers של משימות הרקע. שני workers חיים בתוך אותו קונטיינר בודד. api עונה לבקשות מהדפדפן ומאפליקציית המובייל. microservices מריץ את התורים, כולל יצירת תמונות ממוזערות וקידוד וידאו. המשתנים IMMICH_WORKERS_INCLUDE ו-IMMICH_WORKERS_EXCLUDE מפצלים את השניים הללו לקונטיינרים נפרדים, וכך ניתן להגדיר מגבלת זיכרון לחצי ה"רועש" מבלי להגביל את החצי שמגיש את התמונות שלכם.

database הוא אימג' של PostgreSQL 14 עם תוסף VectorChord מובנה. הוא מחזיק כל פיסת מטא-דאטה ווקטור חיפוש אחד לכל נכס. התיעוד של Immich מגדיר לשירות זה את רצפת הזיכרון היחידה ב-stack: אם אתם מגדירים מגבלות משאבים ב-Docker, מסד הנתונים זקוק ללפחות 2 GB. אותו דף מציין שמסד הנתונים חייב לשבת על אחסון SSD מקומי ולעולם לא על כונן רשת מכל סוג שהוא, כיוון שחיפושי וקטורים ואינדקסים הם פעולות קריאה אקראיות קטנות, כך שנפח רשת הופך כל פעולה כזו ל-round trip. אם בחירת התוכנית תלויה בכך, ההבדל בין אחסון NVMe לעומת SATA SSD ב-VPS משמעותי כאן יותר מאשר בכל מקום אחר ב-stack הזה.

redis מריץ את האימג' של Valkey ומחזיק את תורי המשימות. הוא הקטן ביותר מבין הארבעה בפער ניכר, כיוון שהוא מאחסן רשומות של משימות ולא נתוני תמונות.

immich-machine-learning הוא השירות שקובע את גודל התוכנית שלכם. הוא טוען מודלים לחיפוש חכם, זיהוי פנים וזיהוי טקסט, ומודל טעון נשאר בזיכרון. MACHINE_LEARNING_MODEL_TTL מוגדר כברירת מחדל ל-300, כך שמודל מוסר מהזיכרון לאחר חמש דקות ללא בקשות, ונקרא בחזרה מנפח ה-/cache בבקשה הבאה. במהלך ייבוא מסיבי לעולם אין הפסקה של חמש דקות, לכן המודלים נשארים טעונים מהנכס הראשון ועד האחרון.

מה משתנה במהלך ייבוא

Immich במצב המתנה אינו צורך משאבים. תהליכי ייבוא הם הנקודה שבה שרתים קטנים קורסים, כיוון שהעלאת נכס בודד מפעילה שרשרת של משימות, כאשר כמה תורים רצים בו-זמנית.

חילוץ מטא-דאטה קורא את כותרת הקובץ והוא תהליך קל. יצירת תמונות ממוזערות (thumbnails) היא תהליך כבד יותר. Immich מייצר שלושה פלטים של תמונות ממוזערות לכל נכס: placeholder מסוג thumbhash מטושטש, תצוגה מקדימה בפורמט WebP ותמונה ממוזערת בפורמט JPEG, בתוספת תמונה ממוזערת אחת נוספת עבור כל פנים מזוהות. כל אחת מהמשימות הללו מפענחת תמונה, ורמת ה-concurrency של המשימות קובעת כמה פענוחים יתבצעו בו-זמנית. ה-concurrency הוא המכפיל שהופך עלות נמוכה למשימה בודדת לעומס על השרת כולו; זו הסיבה ש-FAQ של Immich מציין אותו כדבר הראשון שיש להפחית במכונה בעלת משאבים מוגבלים. הגדירו את ה-concurrency עבור התורים הכבדים ל-1 תחת Administration, Settings, Job Settings.

נכסי וידאו מוסיפים תהליך של transcoding. כל משימת transcode היא תהליך FFmpeg נפרד עם זיכרון משלו, והוא ינצל כל thread של ה-CPU שתאפשרו לו.

חיפוש חכם (Smart search) שולח כל נכס חדש למכולת ה-machine learning כדי לחשב וקטור הטמעה (embedding vector) אחד. זיהוי פנים מריץ מודל שני על אותה תמונה. בייבוא הראשון של ספריית תמונות קיימת, שני התורים הללו רצים על כל נכס שבבעלותכם, במשך שעות. זהו רגע השיא של צריכת הזיכרון בכל ההתקנה, והוא מתרחש פעם אחת בלבד.

מדוע זיהוי פנים ועצמים דורש את מירב ה-RAM

טיפול בפנים מורכב משתי משימות. זיהוי פנים מריץ מודל בתוך מכולת ה-machine learning ומאתר את תיבות התוחם. לאחר מכן, זיהוי פנים מקבץ את הזיהויים הללו לאנשים, ושלב זה מבצע שאילתות לאינדקס הווקטורים ב-Postgres. לכן, ספרייה גדולה מעמיסה על שני השירותים בזה אחר זה: מכולת המודל בזמן ריצת הזיהוי, ולאחר מכן מסד הנתונים בזמן ריצת הקיבוץ.

ארבע הגדרות משנות את מה שמכולת ה-machine learning מחזיקה בזיכרון.

• מודל הפנים. Immich מספקת את buffalo_l כברירת מחדל, וה-FAQ ממליץ על buffalo_s בשרת קטן. זהו מודל קטן יותר, לכן הוא תופס פחות זיכרון ורץ מהר יותר, במחיר של דיוק נמוך יותר בפנים קטנות או בפרופיל.
• מספר ה-workers. הערך MACHINE_LEARNING_WORKERS מוגדר כברירת מחדל ל-1. כל worker הוא תהליך נפרד הטוען עותק משלו של המודלים, לכן העלאת הערך ל-2 מכפילה בערך את זיכרון המודל בשימוש. השאירו את הערך על 1 אלא אם יש לכם RAM פנוי.
• גודל ה-batch. הערך MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION מגביל את כמות הפנים המעובדות בבת אחת. קבוצת batch מוחזקת בזיכרון יחד, לכן תמונת קבוצה עם ארבעים פנים דורשת יותר משאבים מאשר דיוקן.
• אילו סוגי מודלים מופעלים. חיפוש חכם, זיהוי פנים וזיהוי טקסט טוענים כל אחד את המודלים שלו. כיבוי המודלים שאינכם משתמשים בהם, תחת 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. מגבלה היא תקרה. היא אינה משריינת דבר, והיא אינה הופכת שירות לקטן יותר. היא קובעת איזה שירות ה-kernel יסיים כאשר השרת אוזל מזיכרון, וזו החלטה שעדיף שתקבלו אתם מאשר ה-kernel על סמך הניקוד הפנימי שלו.

השרת של 2 GB: הסרת ה-container של למידת המכונה

2 GB נמצא מתחת למינימום המתועד של 6 GB, לכן מדובר בפשרה שראוי לציין אותה. בצעו comment לכל ה-service של immich-machine-learning בתוך docker-compose.yml, או השאירו אותו פועל ובטלו כל מודל תחת Administration, Settings, Machine Learning Settings. הסרת ה-container היא האופציה העדיפה, כיוון שמודל מבוטל עדיין משאיר תהליך Python פעיל בזיכרון.

אתם שומרים על יכולות העלאה, אלבומים, שיתוף, גיבוי מהנייד, תמונות ממוזערות וחיפוש לפי תאריך, מיקום ושם קובץ. אתם מאבדים חיפוש לפי תיאור, קיבוץ אוטומטי של פנים לאנשים, וזיהוי טקסט בתוך תמונות.

ארבע המגבלות מסתכמות בכ-1.7 GB, מה שמשאיר למארח כ-300 MB בערך. שימו לב ש-768 MB עבור מסד הנתונים נמצא מתחת לרף המינימום המתועד של 2 GB. זו בדיוק הפשרה ש-2 GB מחייב, וזו הסיבה ש-Postgres הוא השירות בעל הסיכוי הגבוה ביותר להיסגר כאן.

מה שקורס ראשון הוא תהליך הייבוא, לא הגלישה. ספרייה עם עשרות אלפי תמונות בודדות נסרקת בצורה סבירה לאחר שהיא בפנים, כיוון שהצגת דף היא שאילתת metadata בתוספת קריאת קובץ. ייבוא כבד של סרטונים על אותו שרת יגרום ל-swap, כיוון שטרנסקוד ותור תמונות ממוזערות דורשים את הזיכרון באותו רגע. הגדירו כל תור כבד ל-concurrency 1 והוסיפו swap file.

השרת של 4 GB: למידת מכונה פעילה, משימה אחת בכל פעם

4 GB הוא הגודל הקטן ביותר שבו כדאי להפעיל זיהוי פנים ועצמים. הגבילו את ה-container של למידת המכונה ל-0 MB, העבירו את זיהוי הפנים ל-buffalo_s, והגדירו concurrency של משימות ל-1 עבור יצירת תמונות ממוזערות, זיהוי פנים וחיפוש חכם.

המעבר הראשון על ספרייה קיימת ירוץ במשך שעות רבות, ובספרייה גדולה אף יותר מיום. זו מגבלת CPU ולא זיכרון, לכן תוספת RAM לא תקצר את הזמן.

מה שקורס כאן ראשון הוא ה-container של למידת המכונה במהלך המעבר הראשוני. ללא הגבלה, הוא גדל בזמן שתהליך טרנסקוד גם גדל, וה-kernel מסיים את הגדול מביניהם. אתם תראו Exited (137) בתוך docker ps -a ו-container שאתחל את עצמו, כשהתור נשאר בפיגור גדול יותר ממה שהיה קודם.

השרת של 8 GB: ההמלצה המתועדת

8 GB עם 4 ליבות תואם למה ש-Immich ממליצה, והכל רץ בהגדרות ברירת המחדל: חיפוש חכם, זיהוי פנים, זיהוי טקסט וטרנסקוד, ב-concurrency של ברירת המחדל. ספריות מעבר למאה אלף פריטים עובדות כאן בנוחות, והעומס עובר מזיכרון למהירות דיסק, כיוון שאינדקס הווקטורים ושאילתות ה-metadata הם מה שמסד הנתונים עושה כל היום.

הגדירו את המגבלות בכל מקרה. בשרת עם מרווח נשימה, המגבלות מונעות מתור אחד שיצא משליטה להפיל את מסד הנתונים יחד איתו. אם אתם משווים מחירים מול האופציות הקטנות יותר, מה באמת עולה VPS לפי שכבת זיכרון הופך בדרך כלל את תוכנית ה-8 GB לדרך הזולה ביותר להפסיק לבצע כוונונים.

כיצד להגביל צריכת זיכרון לכל שירות באמצעות מגבלות ב-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 במקום את סך הזיכרון של המארח. אם עמודת המגבלה עדיין מציגה את גודל הזיכרון המלא של המארח, סימן שקובץ ה-override לא נטען: בדוק את שם הקובץ והרץ את docker compose config כדי לראות את התוצאה הממוזגת.

מגבלה נמוכה מדי הופכת שירות איטי לשירות מושבת, לכן העלה אותה אם מכולה מתחילה לבצע מחזורי הפעלה מחדש. מידע נוסף על המנגנון זמין ב-הגדרת מגבלות זיכרון לכל שירות ב-Docker Compose, כולל הסיבה לכך ש-deploy פועל מחוץ ל-Swarm עם Compose v2.

כיצד לכבות או להעביר את מכולת ה-machine learning

בשרת קטן, העברת מכולה זו למקום אחר היא השינוי המשמעותי ביותר שניתן לבצע. 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 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: תמונות ממוזערות (thumbnails) שנוצרו וסרטונים שעברו קידוד מחדש מוסיפים בממוצע 10 עד 20 אחוזים לנפח הספרייה. זהו טווח משתנה התלוי בכמות הנכסים שלכם שהם סרטונים הדורשים קידוד מחדש לצורך תאימות לדפדפן. ספרייה המורכבת מ-JPEGs תהיה קרובה לקצה התחתון של טווח זה.

מסד הנתונים תופס 3 GB, וזהו נתון הקרוב לעלות קבועה. התיעוד של Immich מציין שקבצי מסד הנתונים הם בדרך כלל בגודל 1 עד 3 GB, כיוון שהם מכילים מטא-דאטה ווקטורי חיפוש ולא פיקסלים. מטמון המודלים (model cache) הוא 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 משרת VPS לאחסון חיצוני.

קידוד וידאו (Transcoding) צורך CPU, לא RAM

הוספת RAM לא תאיץ את פעולת הקידוד. Immich מבצע קידוד באמצעות FFmpeg, ובשרת VPS סטנדרטי כל פריים מפוענח ומקודד על ידי ה-CPU. גם במקרים שבהם קיימת האצה חומרתית, התיעוד של Immich מציין שרק הקידוד (encoding) מואץ, כך שה-CPU עדיין מבצע את פעולות הפענוח (decoding) ומיפוי הגוונים (tone mapping).

האצה חומרתית דורשת את קובץ ה-hwaccel.transcoding.yml Compose הנוסף וכן התקן (device) להעברה (pass-through), תוך שימוש ב-NVENC, Quick Sync, RKMPP או VAAPI. רוב חבילות ה-VPS אינן מספקות רכיבים אלו, לכן יש לתכנן את המשאבים בהתאם ל-CPU.

ההגדרה המעשית היא מספר התהליכונים (thread count). תחת Administration, Settings, Video Transcoding Settings, ערך של 0 אומר שימוש בכל הליבות, מה שעלול לגרום לסרטון אחד להקפיא את ממשק ה-web בתוכנית של 2 ליבות. הגדירו ערך של 1 או 2, כפי שמומלץ ב-FAQ של Immich, וכך פעולת הקידוד תהיה איטית יותר אך לא תשבש את עבודת המערכת.

מדוע גריסת swap נראית כמו תקיעה של המערכת

זהו הכשל שאנשים מפרשים בצורה שגויה בתדירות הגבוהה ביותר. כאשר ל-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) משמעותו שהתהליך חוסל באמצעות signal 9. הערך 137 הוא 128 ועוד 9. ערך OOMKilled של true מאשר שהתהליך חוסל עקב מחסור בזיכרון ולא בגלל קריסה.

עם swap, שום דבר לא מופסק ושום שגיאה לא מופיעה. ה-kernel מתחיל להעביר דפי זיכרון לדיסק, תהליך הייבוא מואט בסדר גודל, וממשק ה-web מפסיק להגיב בתוך זמן הקצוב (timeout) רגיל. כל מכולה רצה. כל בדיקת תקינות (health check) עשויה עדיין לעבור בהצלחה. זה נראה כמו תקיעה, ובשלב זה אנשים מאתחלים את השרת, מה שגורם לאובדן התקדמות התור ולא פותר דבר.

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

לאחר מכן, טפלו בגורם לבעיה. הפחיתו את רמת ה-concurrency של המשימות ל-1, הגבילו את המכולה של ה-machine learning, או העבירו אותה למארח אחר. ה-swap קונה לכם זמן לבצע זאת. הוא אינו הפתרון כשלעצמו.

FAQ

האם ניתן להריץ את Immich על שרת VPS עם 2 GB RAM?

כן, בתנאי שהשירות immich-machine-learning מוער (commented out) בתוך docker-compose.yml, ושהגדרת ה-concurrency של המשימות מכוונת ל-1. זהו נפח זיכרון הנמוך מהדרישה המינימלית הרשמית של 6 GB, לכן יש להתייחס לכך כאל פשרה מודעת. תוכלו להמשיך להשתמש בהעלאות, אלבומים, שיתוף, גיבוי מהנייד וחיפוש לפי תאריך, מיקום ושם קובץ. עם זאת, תאבדו את היכולת לחפש לפי תיאור, קיבוץ אוטומטי של פנים לאנשים, וזיהוי טקסט בתוך תמונות. מומלץ להוסיף קובץ swap בנפח 2 GB כדי שעלייה פתאומית בעומס הייבוא תגרום להאטה של השרת במקום להריגת המכולה (container).

מדוע הייבוא ב-Immich נעצר ללא הודעת שגיאה?

שתי סיבות שונות נראות זהות בדפדפן. ייתכן שמכולה נהרגה עקב חוסר בזיכרון, ובמקרה זה docker ps -a יציג Exited (137) והמכולה כבר עברה אתחול, או שהמארח (host) משתמש ב-swap, ובמקרה זה כל המכולות עדיין רצות והכל פשוט איטי מאוד. הפקודה vmstat 1 5 תבדיל ביניהן: מספרים שאינם אפס בעמודות si ו-so מעידים על שימוש ב-swap. בכל מקרה, הפחיתו את ה-concurrency של המשימות עבור יצירת תמונות ממוזערות, זיהוי פנים וחיפוש חכם.

מה משמעות קוד יציאה 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 יצביעו אם מדובר במגבלה של המכולה או של המארח כולו. מכולת הלמידה החישובית (machine learning) היא בדרך כלל הנפגעת העיקרית, כיוון שהיא לרוב התהליך הכבד ביותר.

כמה שטח דיסק Immich דורש לכל תמונה?

תכננו לפי גודל הקובץ המקורי בתוספת 10 עד 20 אחוזים. התיעוד של Immich מציין שתמונות ממוזערות שנוצרות וסרטוני וידאו שעוברים קידוד (transcoding) מגדילים את נפח הספרייה ב-10 עד 20 אחוזים בממוצע, ומסד הנתונים עצמו תופס בדרך כלל 1 עד 3 GB, גם עבור ספרייה גדולה. וידאו הוא הגורם המכריע בנפח הכולל, לכן מדדו את גודל הקובץ הממוצע שלכם לפני בחירת תוכנית אחסון, במקום להחיל מכפיל על כמות התמונות.

האם אני זקוק ל-GPU עבור Immich?

לא. כל חלקי Immich רצים על ה-CPU. כרטיס גרפי מאיץ את הסקת המודלים (model inference) במכולת הלמידה החישובית ואת קידוד הווידאו, אך אף אחד מהם אינו דרישת חובה. רוב תוכניות ה-VPS אינן מציעות GPU. בחומרה המבוססת על CPU בלבד, הגדירו את מספר תהליכוני הקידוד (transcoding threads) ל-1 או 2, השתמשו במודל הפנים buffalo_s, ותנו לייבוא המאסיבי הראשון לרוץ במהלך הלילה.