โดย Matt Connor 2026-10-21

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

Immich ระบุความต้องการขั้นต่ำที่ 6 GB ของ RAM เรียนรู้การจัดสรรทรัพยากรสำหรับ Postgres, Redis และ Machine Learning พร้อมเทคนิคการรันบนเซิร์ฟเวอร์ที่มี RAM เพียง 4 GB

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

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

แผนภูมิImmich documented hardware requirements, October 2026

label

ram_gb

cpu_cores

Documented minimum

Documented recommended

ข้อมูลเบื้องหลังแผนภูมินี้

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

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

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

หากคุณยังไม่ได้เริ่มการติดตั้ง ให้เริ่มต้นด้วย การติดตั้ง 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 storage และไม่ควรอยู่บน network share ใดๆ เนื่องจากเวกเตอร์และการค้นหาดัชนีเป็นการอ่านแบบสุ่มขนาดเล็ก ดังนั้น network volume จะทำให้การอ่านแต่ละครั้งกลายเป็นการรับส่งข้อมูลไปกลับ หากคุณกำลังตัดสินใจเลือกแผนบริการ ความแตกต่างระหว่าง NVMe และ SATA SSD storage บน VPS จะมีความสำคัญที่นี่มากกว่าส่วนอื่นๆ ใน stack นี้

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

immich-machine-learning คือบริการที่กำหนดขนาดของแผนบริการของคุณ โดยจะโหลดโมเดลสำหรับการค้นหาอัจฉริยะ การตรวจจับใบหน้า และการจดจำข้อความ ซึ่งโมเดลที่โหลดแล้วจะยังคงอยู่ในหน่วยความจำ MACHINE_LEARNING_MODEL_TTL มีค่าเริ่มต้นที่ 300 ดังนั้นโมเดลจะถูกลบออกจากหน่วยความจำหลังจากไม่มีการเรียกใช้งานเป็นเวลา 5 นาที และจะถูกอ่านกลับมาจาก volume /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

แผนภูมิCompose memory limits that fit each server size, in MB

label

server_limit_mb

db_limit_mb

ml_limit_mb

redis_limit_mb

notes

2 GB VPS

768

128

below every documented configuration, machine learning container removed

4 GB VPS

1024

2048

192

documented 4 GB setup: machine learning disabled or moved to another host, job concurrency 1

8 GB VPS

2048

2560

256

everything on at default settings

ข้อมูลเบื้องหลังแผนภูมินี้

[
  {
    "label": "2 GB VPS",
    "server_limit_mb": 768,
    "db_limit_mb": 768,
    "ml_limit_mb": 0,
    "redis_limit_mb": 128,
    "notes": "below every documented configuration, machine learning container removed"
  },
  {
    "label": "4 GB VPS",
    "server_limit_mb": 1024,
    "db_limit_mb": 2048,
    "ml_limit_mb": 0,
    "redis_limit_mb": 192,
    "notes": "documented 4 GB setup: machine learning disabled or moved to another host, job concurrency 1"
  },
  {
    "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 GB: นำคอนเทนเนอร์ machine learning ออก

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

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

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

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

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

Immich ระบุว่า 4 GB สามารถใช้งานได้หากปิดฟีเจอร์ machine learning ซึ่งเป็นเพียงการตั้งค่าแบบลดสเปกเดียวที่ระบุไว้ในหน้าความต้องการของระบบ เมื่อฐานข้อมูลใช้หน่วยความจำตามเกณฑ์ขั้นต่ำที่ 2 GB ขีดจำกัดทั้งสามรายการในตารางจะรวมกันได้ประมาณ 3.2 GB ซึ่งเหลือพื้นที่ให้ host ประมาณ 800 MB ให้ตั้งค่า job concurrency เป็น 1 สำหรับการสร้างภาพตัวอย่างและจำกัดจำนวนเธรดในการแปลงรหัส

หากต้องการคงความสามารถในการจดจำใบหน้าและวัตถุ วิธีที่แนะนำคือการรันคอนเทนเนอร์ machine learning บนเครื่องอื่นตามที่อธิบายไว้ด้านล่าง แล้วชี้เซิร์ฟเวอร์นี้ไปที่เครื่องดังกล่าว การรันบนเครื่อง 4 GB เครื่องเดียวกันถือว่าเกินกว่าที่ Immich แนะนำ เพราะเกณฑ์ขั้นต่ำของฐานข้อมูลจะเหลือพื้นที่เพียง 2 GB สำหรับเซิร์ฟเวอร์, Redis, โมเดล และ host รวมกัน หากคุณยังต้องการทดลอง ให้จำกัดคอนเทนเนอร์ machine learning ด้วย Compose limit, เปลี่ยนการจดจำใบหน้าเป็น buffalo_s และตั้งค่า job concurrency เป็น 1 สำหรับการสร้างภาพตัวอย่าง, การตรวจจับใบหน้า และการค้นหาอัจฉริยะ

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

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

เครื่องขนาด 8 GB: คำแนะนำตามเอกสาร

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

อย่างไรก็ตามควรตั้งค่าขีดจำกัดไว้เสมอ ในเครื่องที่มีทรัพยากรเหลือเฟือ ขีดจำกัดจะช่วยป้องกันไม่ให้คิวงานที่ทำงานผิดปกติฉุดให้ฐานข้อมูลล่มไปด้วย หากคุณกำลังเปรียบเทียบราคากับตัวเลือกที่เล็กกว่า ต้นทุนที่แท้จริงของ VPS ตามระดับหน่วยความจำ มักจะทำให้แผน 8 GB เป็นวิธีที่ประหยัดที่สุดในการหลีกเลี่ยงการปรับแต่งระบบในภายหลัง

วิธีการจำกัดหน่วยความจำต่อบริการด้วย limits ใน 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: 2048M
  redis:
    deploy:
      resources:
        limits:
          memory: 192M

docker compose up -d
docker stats --no-stream

docker stats ควรแสดงเพดานหน่วยความจำของคุณในคอลัมน์ MEM USAGE / LIMIT แทนที่จะแสดงหน่วยความจำรวมทั้งหมดของโฮสต์ หากคอลัมน์จำกัดยังคงแสดงขนาดเต็มของโฮสต์ แสดงว่าไฟล์ override ไม่ถูกนำไปใช้งาน ให้ตรวจสอบชื่อไฟล์และรันคำสั่ง docker compose config เพื่อดูผลลัพธ์ที่รวมแล้ว

คงค่าหน่วยความจำของฐานข้อมูลไว้ที่ 2048M หรือสูงกว่า เอกสารของ Immich ระบุว่า 2 GB คือค่าขั้นต่ำของฐานข้อมูลเมื่อมีการใช้ทรัพยากรจำกัดของ Docker หากตั้งค่าต่ำเกินไปจะทำให้บริการที่ทำงานช้ากลายเป็นบริการที่หยุดทำงาน ดังนั้นให้เพิ่มค่าหากคอนเทนเนอร์เริ่มมีการรีสตาร์ทวนซ้ำ คุณสามารถอ่านรายละเอียดเพิ่มเติมเกี่ยวกับกลไกนี้ได้ที่ การตั้งค่าจำกัดหน่วยความจำต่อบริการใน 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 เตือนว่าความไม่สอดคล้องกันของเวอร์ชันระหว่างสองเครื่องอาจทำให้เกิดบั๊กและความไม่เสถียรได้

พอร์ตดังกล่าวจะส่งตัวอย่างรูปภาพของคุณไปยังอีกเครื่องโดยไม่มีการเข้ารหัส และเอกสารของ Immich ได้เตือนไว้ว่าคอนเทนเนอร์ Machine Learning ไม่มีมาตรการรักษาความปลอดภัยในตัว ดังนั้นควรเก็บไว้ในเครือข่ายส่วนตัวหรือรันผ่าน WireGuard tunnel ระหว่างโฮสต์ทั้งสองเครื่อง ห้ามเปิดพอร์ต 3003 สู่สาธารณะบนอินเทอร์เน็ตโดยเด็ดขาด

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

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

ไม่มีตัวคูณตายตัวเนื่องจากองค์ประกอบ 4 อย่างมีการเติบโตในอัตราที่ต่างกัน ต่อไปนี้คือการคำนวณสำหรับคลังภาพที่มีรูปถ่าย 50,000 รูปและวิดีโอสั้น 500 รายการ

แผนภูมิWorked disk estimate: 50,000 photos and 500 videos

label

Originals: 50,000 photos at 4 MB

200

Originals: 500 videos at 120 MB

Thumbnails and encoded video at 15%

Postgres database

Machine learning model cache

ข้อมูลเบื้องหลังแผนภูมินี้

[
  {
    "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 กระบวนการ FFmpeg แต่ละตัวจะเก็บ buffer ของเฟรมที่ถอดรหัสไว้ในหน่วยความจำ ซึ่งเป็นเหตุผลว่าทำไมส่วนการนำเข้าข้อมูลจึงนับการแปลงรหัสเป็นภาระของหน่วยความจำ แต่ความเร็วในการทำงานนั้นถูกกำหนดโดย CPU แม้ในกรณีที่มีการเร่งความเร็วด้วยฮาร์ดแวร์ Immich ระบุไว้ว่าโดยค่าเริ่มต้นจะเร่งความเร็วเฉพาะการเข้ารหัสเท่านั้น ดังนั้น CPU จึงยังคงทำหน้าที่ถอดรหัสและทำ tone mapping เว้นแต่คุณจะเปิดใช้งานการถอดรหัสด้วยฮาร์ดแวร์เพิ่มเติม

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

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

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

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

หากไม่มี swap เคอร์เนลจะสั่งยุติกระบวนการทำงาน (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) หมายความว่ากระบวนการถูกสั่งยุติด้วย signal 9 โดยค่า 137 มาจาก 128 บวกกับ 9 คุณจะเห็นสถานะนี้เฉพาะในขณะที่คอนเทนเนอร์หยุดทำงานเท่านั้น เมื่อนโยบายการรีสตาร์ททำให้คอนเทนเนอร์กลับมาทำงานอีกครั้ง docker ps -a จะแสดงสถานะเป็น Up อีกครั้ง และค่า uptime ที่สั้นกว่าคอนเทนเนอร์ Immich ตัวอื่นอย่างเห็นได้ชัดคือเบาะแสสำคัญ การได้รับ signal 9 เพียงอย่างเดียวไม่ได้พิสูจน์ว่าเป็นปัญหาหน่วยความจำ เพราะ Docker จะส่งสัญญาณนี้เช่นกันเมื่อการหยุดทำงานปกติใช้เวลานานเกินกว่า timeout ที่กำหนด ค่า OOMKilled ที่เป็น true จะยืนยันว่ามันถูกสั่งยุติเนื่องจากปัญหาหน่วยความจำ และเมื่อคอนเทนเนอร์รีสตาร์ทแล้ว บรรทัด oom-kill จาก dmesg คือบันทึกที่เชื่อถือได้มากที่สุด

หากมี swap จะไม่มีกระบวนการใดถูกสั่งยุติและไม่มีข้อผิดพลาดเกิดขึ้น เคอร์เนลจะเริ่มย้ายหน้าหน่วยความจำ (pages) ไปยังดิสก์ ส่งผลให้การนำเข้าข้อมูลช้าลงอย่างมากจนสังเกตได้ และอินเทอร์เฟซเว็บจะหยุดตอบสนองภายในเวลา 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 ระบุไว้ หน้าความต้องการของระบบกำหนดให้ 6 GB เป็นค่าขั้นต่ำ และระบุว่า 4 GB โดยปิดฟีเจอร์ machine learning เป็นการตั้งค่าที่เล็กที่สุดที่ทำได้ อีกทั้งยังระบุว่าเฉพาะตัวฐานข้อมูลเพียงอย่างเดียวก็ต้องการอย่างน้อย 2 GB เมื่อมีการจำกัดทรัพยากรใน Docker การคอมเมนต์ปิด service immich-machine-learning และตั้งค่า job concurrency เป็น 1 อาจทำให้รันได้ แต่เป็นการตั้งค่าที่ไม่ได้รับการสนับสนุน และ Postgres คือ service ที่มีโอกาสถูกสั่ง kill มากที่สุดระหว่างการ import หากคุณมีแรมเพียง 2 GB ให้เพิ่ม swap file ขนาด 2 GB เพื่อให้ช่วงที่การใช้งานพุ่งสูงขึ้นทำให้เซิร์ฟเวอร์ทำงานช้าลงแทนที่จะทำให้ container ถูกสั่ง kill หากคุณกำลังเลือกแผนบริการ ให้เริ่มต้นที่ 4 GB

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

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

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

137 คือ 128 บวกกับ signal 9 ดังนั้นกระบวนการจึงถูกสั่ง kill ด้วย SIGKILL บนเครื่องที่รัน Immich มักเกิดจากเพดานหน่วยความจำ ไม่ว่าจะเป็นขีดจำกัดของตัว container เองหรือหน่วยความจำของ host หมด แต่ตัวเลข code เพียงอย่างเดียวไม่สามารถยืนยันได้: Docker จะส่ง SIGKILL เมื่อ container ไม่หยุดทำงานภายในระยะเวลาที่กำหนด (ค่าเริ่มต้นบน Linux คือ 10 วินาที) ให้ตรวจสอบด้วย docker inspect immich_machine_learning | grep -i oomkilled ค่า true ยืนยันว่า kernel สั่ง kill เนื่องจากหน่วยความจำไม่พอ และ free -m รวมกับ sudo dmesg -T | grep -i oom-kill จะบอกคุณว่ามาจากขีดจำกัดของ container หรือของทั้ง host ตัว container ที่ทำหน้าที่ machine learning มักเป็นส่วนที่ได้รับผลกระทบเพราะเป็นกระบวนการที่ใช้ทรัพยากรมากที่สุด

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

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

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

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

#immich #self-hosted #sizing #docker #photos