Immich ต้องการ RAM และพื้นที่เก็บข้อมูลเท่าไหร่

Immich ต้องการ RAM เท่าไหร่?

Immich ระบุความต้องการ RAM (random access memory) ขั้นต่ำไว้ที่ 6 GB และแนะนำที่ 8 GB โดยใช้ CPU จำนวน 2 คอร์สำหรับระดับเริ่มต้น และ 4 คอร์สำหรับการติดตั้งที่ใช้งานได้อย่างราบรื่น ตัวเลขนี้ครอบคลุมทั้ง stack เนื่องจาก Immich ประกอบด้วยคอนเทนเนอร์ 4 ตัว ไม่ใช่แอปพลิเคชันเดียว การเรียกดูคลังภาพที่นำเข้าข้อมูลเรียบร้อยแล้วใช้ทรัพยากรน้อย หน่วยความจำส่วนใหญ่จะถูกใช้ไปกับการนำเข้าข้อมูล และส่วนใหญ่ของหน่วยความจำนั้นถูกใช้โดยคอนเทนเนอร์ตัวหนึ่งที่คุณสามารถปิดการทำงานได้

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

ตัวเลขเหล่านี้เป็นตัวเลขที่เผยแพร่อยู่ในหน้าความต้องการระบบของ Immich ณ เดือนสิงหาคม 2026 ซึ่งเป็นคำแนะนำในการจัดสรรขนาดทรัพยากร ไม่ใช่การตรวจสอบว่าซอฟต์แวร์จะทำงานได้หรือไม่ในขณะเริ่มต้นระบบ Immich สามารถเริ่มทำงานได้ด้วยหน่วยความจำที่น้อยกว่านั้น สิ่งที่จะเปลี่ยนไปบนเซิร์ฟเวอร์ขนาดเล็กคือการทำงานของงานเบื้องหลัง (background jobs) และสิ่งที่เกิดขึ้นระหว่างการนำเข้าข้อมูลเมื่อหน่วยความจำไม่เพียงพอ

มีข้อจำกัดที่สำคัญอยู่หนึ่งประการ Immich เวอร์ชัน 3 ขึ้นไปต้องการ CPU ที่รองรับ x86-64-v2 บนโฮสต์สถาปัตยกรรม amd64 ซึ่งครอบคลุมโปรเซสเซอร์ส่วนใหญ่ที่วางจำหน่ายตั้งแต่ช่วงปี 2012 เป็นต้นมา บนฮาร์ดแวร์ที่เก่ากว่านั้น คอนเทนเนอร์จะไม่สามารถเริ่มทำงานได้ แทนที่จะทำงานช้าลง

หากคุณยังไม่ได้เริ่มการติดตั้ง ให้เริ่มต้นด้วย การติดตั้ง Immich เต็มรูปแบบบน VPS ด้วย Docker Compose แล้วค่อยกลับมาที่นี่เพื่อประเมินขนาดของเซิร์ฟเวอร์อีกครั้ง

หน่วยความจำถูกใช้งานอย่างไร: คอนเทนเนอร์ทั้งสี่

ไฟล์ Compose อย่างเป็นทางการเริ่มต้นบริการ 4 รายการ แต่ละรายการมีรูปแบบการใช้หน่วยความจำที่แตกต่างกัน ดังนั้นตัวเลขรวมเพียงตัวเดียวจึงไม่สามารถบอกรายละเอียดที่เป็นประโยชน์ได้

immich-server ทำหน้าที่ให้บริการเว็บอินเทอร์เฟซและ API รวมถึงรัน background job worker โดยมี worker สองตัวทำงานอยู่ภายในคอนเทนเนอร์นี้ api ตอบสนองคำขอจากเบราว์เซอร์และแอปมือถือ microservices รันคิวงานต่างๆ รวมถึงการสร้างภาพตัวอย่าง (thumbnail) และการเข้ารหัสวิดีโอ ตัวแปร IMMICH_WORKERS_INCLUDE และ IMMICH_WORKERS_EXCLUDE จะแยกงานทั้งสองนี้ออกเป็นคอนเทนเนอร์ต่างหาก ซึ่งเป็นวิธีที่คุณจะกำหนดขีดจำกัดหน่วยความจำให้กับส่วนที่ทำงานหนักโดยไม่ไปจำกัดส่วนที่ให้บริการรูปภาพของคุณ

database คืออิมเมจ PostgreSQL 14 ที่ติดตั้งส่วนขยาย VectorChord ไว้ภายใน ทำหน้าที่เก็บข้อมูลเมทาดาตาทั้งหมดและเวกเตอร์การค้นหาหนึ่งรายการต่อหนึ่งสินทรัพย์ เอกสารของ Immich ระบุว่าบริการนี้เป็นบริการเดียวใน stack ที่ต้องมีการกำหนดค่าขั้นต่ำที่ชัดเจน หากคุณใช้ Docker resource limits ฐานข้อมูลจำเป็นต้องมีหน่วยความจำอย่างน้อย 2 GB หน้าเอกสารเดียวกันยังระบุว่าฐานข้อมูลต้องวางอยู่บน local SSD เท่านั้น ห้ามใช้ network share ทุกประเภท เนื่องจาก vector และ index lookup เป็นการอ่านแบบสุ่มขนาดเล็ก ดังนั้นการใช้ network volume จะทำให้แต่ละคำสั่งต้องรอการรับส่งข้อมูลไปกลับ หากแผนการเลือกเซิร์ฟเวอร์ขึ้นอยู่กับจุดนี้ ความแตกต่างระหว่าง NVMe และ SATA SSD storage บน VPS จะมีความสำคัญที่นี่มากกว่าส่วนอื่นๆ ใน stack นี้

redis รันอิมเมจ Valkey และทำหน้าที่เก็บคิวงาน เป็นบริการที่เล็กที่สุดในบรรดาทั้งสี่อย่างเห็นได้ชัด เนื่องจากเก็บเพียงบันทึกของงาน ไม่ใช่ข้อมูลรูปภาพ

immich-machine-learning คือบริการที่กำหนดขนาดของแผนการใช้งานของคุณ โดยจะโหลดโมเดลสำหรับการค้นหาอัจฉริยะ การตรวจจับใบหน้า และการจดจำข้อความ ซึ่งโมเดลที่โหลดแล้วจะคงอยู่ในหน่วยความจำ MACHINE_LEARNING_MODEL_TTL มีค่าเริ่มต้นที่ 300 ดังนั้นโมเดลจะถูกลบออกจากหน่วยความจำหลังจากไม่มีการเรียกใช้งานเป็นเวลา 5 นาที และจะถูกอ่านกลับมาจากโวลุ่ม /cache เมื่อมีการเรียกใช้งานครั้งถัดไป ในระหว่างการนำเข้าข้อมูลจำนวนมาก (bulk import) จะไม่มีช่วงเวลาว่างถึง 5 นาที ดังนั้นโมเดลจะถูกโหลดค้างไว้ตั้งแต่สินทรัพย์ชิ้นแรกจนถึงชิ้นสุดท้าย

สิ่งที่เปลี่ยนแปลงระหว่างการนำเข้าข้อมูล

เมื่อ Immich อยู่ในสถานะว่างงาน ระบบจะทำงานเงียบ การนำเข้าข้อมูลเป็นช่วงที่เซิร์ฟเวอร์ขนาดเล็กมักจะล่ม เนื่องจากหนึ่งไฟล์ที่อัปโหลดจะสร้างคิวงานต่อเนื่องกันหลายรายการ และคิวเหล่านั้นจะทำงานพร้อมกันหลายคิว

การดึงข้อมูล Metadata จะอ่านส่วนหัวของไฟล์ซึ่งใช้ทรัพยากรน้อย การสร้างภาพตัวอย่าง (Thumbnail) จะใช้ทรัพยากรมากกว่า Immich จะสร้างภาพตัวอย่าง 3 รูปต่อหนึ่งสินทรัพย์ ได้แก่ ภาพ placeholder แบบเบลอ (thumbhash), ภาพพรีวิวแบบ WebP และภาพตัวอย่างแบบ JPEG รวมถึงภาพตัวอย่างเพิ่มเติมสำหรับใบหน้าที่ตรวจพบแต่ละใบหน้า งานแต่ละอย่างเหล่านี้จะทำการถอดรหัสภาพ และค่า concurrency ของงานจะเป็นตัวกำหนดว่ามีการถอดรหัสพร้อมกันกี่งาน ค่า concurrency นี้เป็นตัวคูณที่เปลี่ยนภาระงานต่อหนึ่งงานให้กลายเป็นภาระงานของทั้งเซิร์ฟเวอร์ ซึ่งเป็นเหตุผลที่ FAQ ของ Immich ระบุให้ปรับค่านี้เป็นสิ่งแรกหากเครื่องมีทรัพยากรจำกัด ให้ตั้งค่า concurrency สำหรับคิวงานที่หนักให้เป็น 1 ที่เมนู Administration, Settings, Job Settings

สินทรัพย์ที่เป็นวิดีโอจะเพิ่มกระบวนการแปลงรหัส (Transcoding) งานแปลงรหัสแต่ละงานคือกระบวนการ FFmpeg แยกต่างหากที่มีการใช้หน่วยความจำของตัวเอง และมันจะใช้เธรด CPU ทั้งหมดที่คุณอนุญาต

ระบบค้นหาอัจฉริยะ (Smart search) จะส่งสินทรัพย์ใหม่ทุกรายการไปยังคอนเทนเนอร์ machine learning เพื่อคำนวณ embedding vector หนึ่งชุด การตรวจจับใบหน้าจะรันโมเดลชุดที่สองบนภาพเดียวกัน ในการนำเข้าคลังภาพที่มีอยู่เดิมเป็นครั้งแรก คิวงานทั้งสองนี้จะทำงานกับสินทรัพย์ทุกรายการที่คุณมีเป็นเวลาหลายชั่วโมง นั่นเป็นช่วงเวลาที่ใช้หน่วยความจำหนักที่สุดของการติดตั้งทั้งหมด และเหตุการณ์นี้จะเกิดขึ้นเพียงครั้งเดียวเท่านั้น

เหตุใดการจดจำใบหน้าและวัตถุจึงต้องการ RAM มากที่สุด

การจัดการใบหน้าประกอบด้วยสองงาน งานตรวจจับใบหน้าจะรันโมเดลในคอนเทนเนอร์ machine learning เพื่อหาตำแหน่งกรอบใบหน้า จากนั้นการจดจำใบหน้าจะจัดกลุ่มผลการตรวจจับเหล่านั้นเข้าเป็นบุคคล ซึ่งขั้นตอนนี้จะสืบค้นดัชนีเวกเตอร์ใน Postgres ดังนั้นคลังภาพขนาดใหญ่จะสร้างภาระให้กับทั้งสองบริการสลับกันไป คือคอนเทนเนอร์โมเดลในขณะที่การตรวจจับทำงาน และฐานข้อมูลในขณะที่การจัดกลุ่มทำงาน

การตั้งค่าสี่รายการต่อไปนี้จะเปลี่ยนสิ่งที่คอนเทนเนอร์ machine learning จัดเก็บไว้

• โมเดลใบหน้า Immich มาพร้อมกับ buffalo_l เป็นค่าเริ่มต้น และ FAQ แนะนำให้ใช้ buffalo_s บนเซิร์ฟเวอร์ขนาดเล็ก เนื่องจากเป็นโมเดลที่เล็กกว่า จึงใช้หน่วยความจำน้อยลงและทำงานได้เร็วกว่า แต่ต้องแลกมาด้วยความแม่นยำที่ลดลงสำหรับใบหน้าขนาดเล็กหรือใบหน้าที่หันข้าง
• จำนวน worker 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 ล่วงหน้าเพื่อป้องกันการกระจายตัวของหน่วยความจำ (fragmentation) และเปิดใช้งานเป็นค่าเริ่มต้น ให้เปลี่ยนค่านี้เป็นลำดับสุดท้าย ผลกระทบขึ้นอยู่กับตัวจัดสรรหน่วยความจำ (memory allocator) ที่ใช้งานอยู่ ดังนั้นวิธีเดียวที่จะประเมินผลได้อย่างถูกต้องคือการตรวจสอบ docker stats ก่อนและหลังการเปลี่ยนแปลง

โปรไฟล์ที่ใช้งานได้ 3 รูปแบบ: 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 ควรจะสั่งยุติ (kill) บริการใดเมื่อเครื่องหน่วยความจำเต็ม ซึ่งการตัดสินใจนี้ควรเป็นของคุณเองดีกว่าปล่อยให้ kernel เป็นผู้เลือกตามคะแนนที่มันคำนวณขึ้นมาเอง

กล่องขนาด 2 GB: การนำคอนเทนเนอร์ machine learning ออก

ขนาด 2 GB นั้นต่ำกว่าเกณฑ์ขั้นต่ำที่ระบุไว้คือ 6 GB ดังนั้นนี่คือการประนีประนอมและจำเป็นต้องระบุให้ชัดเจน ให้ใส่เครื่องหมายคอมเมนต์ปิดการทำงานของบริการ immich-machine-learning ทั้งหมดในไฟล์ docker-compose.yml หรือจะปล่อยให้มันทำงานต่อไปแล้วปิดการใช้งานโมเดลทุกตัวในเมนู Administration, Settings, Machine Learning Settings ก็ได้ การนำคอนเทนเนอร์ออกเป็นทางเลือกที่ดีกว่า เพราะโมเดลที่ถูกปิดการใช้งานยังคงทิ้งกระบวนการ Python ค้างไว้ในหน่วยความจำ

คุณยังคงใช้งานการอัปโหลด, อัลบั้ม, การแชร์, การสำรองข้อมูลจากมือถือ, การสร้างภาพตัวอย่าง (thumbnails) และการค้นหาตามวันที่ สถานที่ และชื่อไฟล์ได้ แต่คุณจะสูญเสียความสามารถในการค้นหาตามคำอธิบาย, การจัดกลุ่มใบหน้าอัตโนมัติ และการจดจำข้อความภายในรูปภาพ

ขีดจำกัดทั้ง 4 รายการรวมกันได้ประมาณ 1.7 GB ซึ่งเหลือพื้นที่ให้โฮสต์ประมาณ 300 MB โปรดสังเกตว่าค่า 768 MB สำหรับฐานข้อมูลนั้นต่ำกว่าเกณฑ์ขั้นต่ำ 2 GB ที่ระบุไว้ นี่คือการประนีประนอมที่จำเป็นสำหรับขนาด 2 GB และเป็นเหตุผลว่าทำไม Postgres จึงเป็นบริการที่มีโอกาสถูก kernel สั่งยุติการทำงานมากที่สุดในกรณีนี้

สิ่งที่ล้มเหลวก่อนคือการนำเข้าข้อมูล (import) ไม่ใช่การเรียกดู คลังภาพที่มีรูปภาพจำนวนหลักหมื่นสามารถเรียกดูได้ตามปกติเมื่อนำเข้าเสร็จแล้ว เพราะการแสดงผลหน้าเว็บเป็นการสอบถาม metadata ควบคู่ไปกับการอ่านไฟล์ แต่การนำเข้าวิดีโอจำนวนมากบนเครื่องเดียวกันจะทำให้เกิดการ swap เพราะการแปลงรหัส (transcode) และคิวการสร้างภาพตัวอย่างต้องการหน่วยความจำพร้อมกัน ให้ตั้งค่าคิวงานหนักทุกรายการให้มีความพร้อมกัน (concurrency) ที่ 1 และเพิ่มไฟล์ swap

กล่องขนาด 4 GB: เปิดใช้งาน machine learning โดยทำงานทีละงาน

ขนาด 4 GB เป็นขนาดที่เล็กที่สุดที่คุ้มค่าจะเปิดใช้งานการจดจำใบหน้าและวัตถุ ให้จำกัดคอนเทนเนอร์ machine learning ไว้ที่ 0 MB, ปรับการจดจำใบหน้าเป็น buffalo_s และตั้งค่าความพร้อมกันของงาน (job concurrency) เป็น 1 สำหรับการสร้างภาพตัวอย่าง, การตรวจจับใบหน้า และการค้นหาอัจฉริยะ

การประมวลผลรอบแรกสำหรับคลังภาพที่มีอยู่จะใช้เวลาหลายชั่วโมง และหากเป็นคลังภาพขนาดใหญ่จะใช้เวลามากกว่าหนึ่งวัน นี่เป็นข้อจำกัดด้าน CPU ไม่ใช่หน่วยความจำ ดังนั้นการเพิ่ม RAM จะไม่ช่วยให้งานเสร็จเร็วขึ้น

สิ่งที่ล้มเหลวก่อนในกรณีนี้คือคอนเทนเนอร์ machine learning ในระหว่างการประมวลผลรอบแรก หากไม่จำกัดค่าไว้ มันจะขยายตัวขึ้นในขณะที่งานแปลงรหัสก็ขยายตัวเช่นกัน และ kernel จะสั่งยุติบริการที่ใช้หน่วยความจำมากกว่า คุณจะพบ Exited (137) ใน docker ps -a และคอนเทนเนอร์จะถูกรีสตาร์ท ส่งผลให้คิวงานล่าช้ากว่าที่คุณตรวจสอบครั้งล่าสุด

กล่องขนาด 8 GB: คำแนะนำตามมาตรฐานที่ระบุไว้

ขนาด 8 GB พร้อมด้วย 4 คอร์ ตรงตามที่ Immich แนะนำ และทุกอย่างจะทำงานด้วยการตั้งค่าเริ่มต้น ทั้งการค้นหาอัจฉริยะ, การตรวจจับใบหน้า, การจดจำข้อความ และการแปลงรหัส ด้วยค่าความพร้อมกันเริ่มต้น คลังภาพที่มีสินทรัพย์เกินหนึ่งแสนรายการสามารถทำงานได้อย่างราบรื่นที่ขนาดนี้ และภาระจะเปลี่ยนจากหน่วยความจำไปอยู่ที่ความเร็วของดิสก์แทน เนื่องจากดัชนีเวกเตอร์และการสอบถาม metadata คือสิ่งที่ฐานข้อมูลต้องทำตลอดทั้งวัน

อย่างไรก็ตามควรตั้งค่าขีดจำกัดไว้เสมอ บนเครื่องที่มีทรัพยากรเหลือเฟือ ขีดจำกัดเหล่านี้จะช่วยป้องกันไม่ให้คิวงานที่ผิดปกติเพียงรายการเดียวทำให้ฐานข้อมูลล่มตามไปด้วย หากคุณกำลังเปรียบเทียบราคากับตัวเลือกที่เล็กกว่า ราคา 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 แทนที่จะแสดงหน่วยความจำรวมของโฮสต์ หากคอลัมน์จำกัดยังคงแสดงขนาดเต็มของโฮสต์ แสดงว่าไฟล์ 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 tunnel ระหว่างโฮสต์ทั้งสองเครื่อง ห้ามเปิดพอร์ต 3003 สู่สาธารณะโดยเด็ดขาด

หากแนวคิดเรื่องการมีคอนเทนเนอร์โมเดลทำงานค้างไว้ตลอดเวลาคือปัญหา นี่ก็เป็นเหตุผลที่สมเหตุสมผลในการเปรียบเทียบ ความแตกต่างระหว่าง PhotoPrism และ Immich ในแง่ของสิ่งที่ทำงานอยู่เบื้องหลัง ก่อนที่จะตัดสินใจเลือกขนาดของแผนการใช้งาน

Immich library ต้องการพื้นที่ดิสก์เท่าใด

ไม่มีตัวคูณตายตัวเนื่องจากองค์ประกอบ 4 อย่างมีการเติบโตในอัตราที่ต่างกัน ต่อไปนี้คือการคำนวณสำหรับคลังภาพที่มีรูปถ่าย 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 ระบุไว้ โดยเฉลี่ยแล้ว thumbnail ที่สร้างขึ้นและวิดีโอที่ผ่านการแปลงรหัส (transcoded) จะเพิ่มขนาดคลังภาพขึ้น 10 ถึง 20 เปอร์เซ็นต์ ตัวเลขนี้เป็นช่วงเพราะขึ้นอยู่กับว่าสินทรัพย์ของคุณเป็นวิดีโอที่ต้องเข้ารหัสใหม่เพื่อให้รองรับการแสดงผลบนเบราว์เซอร์มากน้อยเพียงใด คลังภาพที่เป็นไฟล์ JPEG จะมีขนาดใกล้เคียงกับช่วงล่างของค่านี้

ฐานข้อมูลมีขนาด 3 GB ซึ่งถือเป็นค่าใช้จ่ายคงที่ Immich ระบุว่าไฟล์ฐานข้อมูลมักจะมีขนาด 1 ถึง 3 GB เนื่องจากเก็บข้อมูล metadata และ search vector แทนที่จะเป็นพิกเซล ส่วน model cache มีขนาด 2 GB และจะเพิ่มขึ้นหากคุณเปิดใช้งานหลายโมเดลหรือทดสอบโมเดลที่แตกต่างกัน FAQ ได้ระบุว่าส่วนนี้เป็นส่วนที่ใช้พื้นที่ด้วยเหตุผลดังกล่าว

ทั้ง 5 แถวรวมกันได้มากกว่า 300 GB เล็กน้อย ดังนั้น volume ขนาด 500 GB จึงมีพื้นที่เหลือให้ขยาย แต่ขนาด 250 GB จะไม่เพียงพอ คุณสามารถตรวจสอบการแบ่งส่วนพื้นที่ได้ด้วย:

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

มี 6 โฟลเดอร์ที่อยู่ภายใต้ UPLOAD_LOCATION โดย upload และ library เก็บไฟล์ต้นฉบับ thumbs เก็บภาพตัวอย่างและ thumbnail ใบหน้า encoded-video เก็บสำเนาที่เข้ารหัสใหม่ profile เก็บรูปโปรไฟล์ และ backups เก็บไฟล์สำรองฐานข้อมูลอัตโนมัติ มีเพียง upload, library และ profile เท่านั้นที่ไม่สามารถหาทดแทนได้ เนื่องจากส่วนอื่นทั้งหมดสามารถสร้างใหม่จากไฟล์เหล่านี้ได้

มีสองสิ่งที่มักทำให้ผู้ใช้ประหลาดใจ ประการแรก สินทรัพย์ที่ถูกลบจะย้ายไปที่ถังขยะก่อนและยังคงใช้พื้นที่จนกว่าจะล้างถังขยะ ดังนั้นการล้างข้อมูลครั้งใหญ่จะไม่เพิ่มพื้นที่ว่างในวันที่คุณดำเนินการ ประการที่สอง ไฟล์สำรองฐานข้อมูลมีเพียง metadata เท่านั้น จึงไม่มีประโยชน์หากไม่มีไฟล์ต้นฉบับ:

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 ระบุไว้ว่ามีการเร่งความเร็วเฉพาะขั้นตอนการเข้ารหัสเท่านั้น ดังนั้น CPU ยังคงต้องทำหน้าที่ถอดรหัสและทำ tone mapping ด้วยซอฟต์แวร์อยู่ดี

การเร่งความเร็วด้วยฮาร์ดแวร์จำเป็นต้องใช้ไฟล์ hwaccel.transcoding.yml Compose เพิ่มเติม รวมถึงอุปกรณ์ที่รองรับการส่งผ่านข้อมูล (pass-through) โดยใช้ NVENC, Quick Sync, RKMPP หรือ VAAPI แผนบริการ VPS ส่วนใหญ่ไม่มีคุณสมบัติเหล่านี้ให้ ดังนั้นควรวางแผนโดยอิงจากประสิทธิภาพของ CPU เป็นหลัก

การตั้งค่าที่ใช้งานได้จริงคือจำนวน thread ในส่วน Administration, Settings, Video Transcoding Settings ค่า thread ที่ 0 หมายถึงการใช้ทุกคอร์ ซึ่งอาจทำให้วิดีโอเพียงรายการเดียวส่งผลให้หน้าเว็บค้างบนแผนบริการที่มี 2 คอร์ ให้ตั้งค่าเป็น 1 หรือ 2 ตามที่ FAQ ของ Immich แนะนำ เพื่อให้การแปลงรหัสทำงานช้าลงแทนที่จะส่งผลกระทบต่อการใช้งานส่วนอื่นของระบบ

เหตุใดการเกิด swap thrashing จึงดูเหมือนระบบค้าง

นี่คือความล้มเหลวที่ผู้คนมักเข้าใจผิดบ่อยที่สุด เมื่อ Immich ใช้หน่วยความจำจนหมด จะมีผลลัพธ์เกิดขึ้น 2 รูปแบบ และมีเพียงรูปแบบเดียวเท่านั้นที่ดูเหมือนความล้มเหลว

หากไม่มี swap เคอร์เนลจะสั่งยุติกระบวนการทำงาน (kill process) คอนเทนเนอร์จะเริ่มทำงานใหม่ภายในไม่กี่วินาที ดังนั้นจากมุมมองของเบราว์เซอร์ คิวงานจะหยุดชะงักไปชั่วครู่แล้วกลับมาทำงานต่อ หลักฐานปรากฏอยู่ใน 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 จะไม่มีกระบวนการใดถูกยุติและไม่มีข้อผิดพลาดเกิดขึ้น เคอร์เนลจะเริ่มย้ายหน้าหน่วยความจำ (page) ไปยังดิสก์ ส่งผลให้การนำเข้าข้อมูลช้าลงกว่าเดิมหลายเท่า และอินเทอร์เฟซเว็บจะหยุดตอบสนองภายในระยะเวลา 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

จากนั้นจึงแก้ไขที่ต้นเหตุ ให้ลดค่า job concurrency ลงเหลือ 1, จำกัดการใช้ทรัพยากรของคอนเทนเนอร์ machine learning หรือย้ายคอนเทนเนอร์นั้นออกจากโฮสต์นี้ swap เป็นเพียงสิ่งที่ช่วยซื้อเวลาให้คุณดำเนินการดังกล่าว ไม่ใช่ทางแก้ปัญหาด้วยตัวมันเอง

FAQ

ฉันสามารถรัน Immich บน VPS ขนาด 2 GB ได้หรือไม่?

ได้ โดยต้องใส่เครื่องหมายคอมเมนต์หน้าบริการ immich-machine-learning ในไฟล์ docker-compose.yml และตั้งค่า job concurrency เป็น 1 เนื่องจากสเปกนี้ต่ำกว่าขั้นต่ำที่ระบุไว้ใน 6 GB จึงถือเป็นการยอมรับข้อจำกัดที่ทราบกันดี คุณยังสามารถใช้งานการอัปโหลด, อัลบั้ม, การแชร์, การสำรองข้อมูลจากมือถือ และการค้นหาตามวันที่ สถานที่ และชื่อไฟล์ได้ แต่คุณจะเสียความสามารถในการค้นหาตามคำบรรยาย, การจัดกลุ่มใบหน้าอัตโนมัติ และการตรวจจับข้อความในรูปภาพ แนะนำให้เพิ่ม swap file ขนาด 2 GB เพื่อให้ช่วงที่มีการนำเข้าข้อมูลจำนวนมาก ระบบจะทำงานช้าลงแทนที่จะถูกสั่ง kill คอนเทนเนอร์

ทำไมการนำเข้าข้อมูลของ Immich ถึงหยุดทำงานโดยไม่มีข้อความแจ้งเตือน?

มีสาเหตุสองประการที่แสดงอาการเหมือนกันบนเบราว์เซอร์ ประการแรกคือคอนเทนเนอร์ถูกสั่ง kill เนื่องจากหน่วยความจำไม่พอ ซึ่งในกรณีนี้ docker ps -a จะแสดงค่า Exited (137) และคอนเทนเนอร์จะรีสตาร์ทตัวเองไปแล้ว ประการที่สองคือโฮสต์กำลังใช้งาน swap ซึ่งในกรณีนี้ทุกคอนเทนเนอร์ยังทำงานอยู่แต่ระบบจะทำงานช้าลงอย่างมาก คำสั่ง vmstat 1 5 จะช่วยแยกแยะสาเหตุได้ หากพบตัวเลขที่ไม่ใช่ศูนย์อย่างต่อเนื่องในคอลัมน์ si และ so แสดงว่ามีการใช้งาน swap ให้ลดค่า job concurrency สำหรับการสร้างภาพตัวอย่าง (thumbnail), การตรวจจับใบหน้า และการค้นหาอัจฉริยะในทั้งสองกรณี

exit code 137 ใน log ของ Immich หมายความว่าอย่างไร?

137 คือ 128 บวกกับสัญญาณ 9 ซึ่งหมายความว่ากระบวนการถูกสั่งยุติด้วย SIGKILL ในทางปฏิบัติหมายความว่ามีการใช้งานหน่วยความจำเกินขีดจำกัด ไม่ว่าจะเป็นขีดจำกัดของคอนเทนเนอร์เองหรือหน่วยความจำของโฮสต์หมด ให้ตรวจสอบด้วย docker inspect immich_machine_learning | grep -i oomkilled หากพบค่า true ยืนยันได้ว่าเคอร์เนลสั่ง kill กระบวนการเนื่องจากหน่วยความจำไม่พอ และ free -m รวมกับ sudo dmesg -T | grep -i oom-kill จะบอกคุณว่าปัญหาเกิดจากขีดจำกัดของคอนเทนเนอร์หรือของทั้งโฮสต์ โดยปกติคอนเทนเนอร์ machine learning มักจะเป็นส่วนที่ถูกสั่ง kill เพราะเป็นกระบวนการที่ใช้หน่วยความจำมากที่สุด

Immich ต้องการพื้นที่ดิสก์เท่าใดต่อรูปภาพหนึ่งรูป?

ให้เผื่อพื้นที่เท่ากับขนาดไฟล์ต้นฉบับบวกเพิ่มอีก 10 ถึง 20 เปอร์เซ็นต์ Immich ระบุว่าภาพตัวอย่างที่สร้างขึ้นและวิดีโอที่ถูกแปลงไฟล์จะเพิ่มขนาดคลังข้อมูลโดยเฉลี่ย 10 ถึง 20 เปอร์เซ็นต์ และตัวฐานข้อมูลเองมักจะมีขนาด 1 ถึง 3 GB แม้จะเป็นคลังข้อมูลขนาดใหญ่ก็ตาม วิดีโอคือปัจจัยหลักที่กำหนดขนาดพื้นที่ทั้งหมด ดังนั้นควรวัดขนาดไฟล์เฉลี่ยของคุณเองก่อนเลือกแผนบริการ แทนที่จะใช้ตัวคูณกับจำนวนรูปภาพเพียงอย่างเดียว

ฉันจำเป็นต้องใช้ GPU สำหรับ Immich หรือไม่?

ไม่จำเป็น ทุกส่วนของ Immich สามารถรันบน CPU ได้ การ์ดจอจะช่วยเพิ่มความเร็วในการประมวลผลโมเดลในคอนเทนเนอร์ machine learning และการแปลงไฟล์วิดีโอ ซึ่งทั้งสองอย่างนี้ไม่ใช่สิ่งที่จำเป็น แผนบริการ VPS ส่วนใหญ่ไม่มี GPU ให้ใช้งาน หากใช้ฮาร์ดแวร์ที่เป็น CPU เพียงอย่างเดียว ให้ตั้งค่า transcoding threads เป็น 1 หรือ 2, ใช้โมเดลใบหน้าแบบ buffalo_s และปล่อยให้การนำเข้าข้อมูลจำนวนมากครั้งแรกทำงานข้ามคืนไปได้เลย