Immich cần bao nhiêu RAM và disk?

Immich cần bao nhiêu RAM?

Immich yêu cầu tối thiểu 6 GB RAM (bộ nhớ truy cập ngẫu nhiên) theo tài liệu và khuyến nghị 8 GB, với 2 CPU cores ở mức thấp nhất và 4 CPU cores để cài đặt thoải mái. Con số này bao gồm toàn bộ stack, vì Immich gồm 4 container chứ không phải một ứng dụng duy nhất. Việc duyệt thư viện đã import tốn ít tài nguyên. RAM chủ yếu được dùng khi import, và phần lớn được dùng bởi một container mà bạn có thể tắt.

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

Đây là các con số được công bố trên trang yêu cầu của Immich vào tháng 10 năm 2026. Đây là khuyến nghị để sizing, không phải điều kiện kiểm tra khiến phần mềm dừng ngay khi khởi động. Cùng trang đó ghi nhận một cấu hình nhỏ hơn là 4 GB khi tắt các tính năng machine learning, và không đưa ra cấu hình nào thấp hơn. Trên server nhỏ hơn, điều thay đổi là các background job nào hoàn tất và import sẽ xử lý ra sao khi hết RAM.

Có một giới hạn cứng thực sự. Từ version 3, machine learning container trên host amd64 cần CPU x86-64-v2, tương thích với phần lớn processor được bán từ khoảng năm 2012. Yêu cầu này áp dụng cho container đó, không áp dụng cho toàn bộ server. Vì vậy, trên hardware cũ, bạn có thể tắt machine learning, chạy nó trên một máy khác như mô tả bên dưới, hoặc dùng v2.7.5, là version cuối cùng còn tương thích theo tài liệu Immich.

Nếu bạn chưa bắt đầu cài đặt, hãy bắt đầu với hướng dẫn cài đặt Immich đầy đủ trên VPS bằng Docker Compose, sau đó quay lại đây để sizing server.

Nơi bộ nhớ được sử dụng: 4 container

File Compose chính thức khởi động 4 service. Mỗi service có mức sử dụng bộ nhớ khác nhau, nên một con số tổng sẽ che mất phần thông tin quan trọng.

immich-server cung cấp giao diện web và API, đồng thời chạy các background job worker. Hai worker nằm trong cùng container này. api xử lý request từ browser và mobile app. microservices chạy các queue, bao gồm tạo thumbnail và encode video. Các biến IMMICH_WORKERS_INCLUDE và IMMICH_WORKERS_EXCLUDE tách hai thành phần này thành các container riêng. Nhờ đó, bạn có thể đặt memory limit riêng cho phần gây tải cao mà không giới hạn phần phục vụ ảnh.

database là image PostgreSQL 14 được tích hợp sẵn extension VectorChord. Nó lưu toàn bộ metadata và một search vector cho mỗi asset. Tài liệu Immich đặt ra mức tối thiểu rõ ràng duy nhất trong stack cho service này: nếu áp dụng Docker resource limit, database cần ít nhất 2 GB. Cùng trang tài liệu đó cũng nêu rằng database nên đặt trên local SSD và tuyệt đối không đặt trên bất kỳ network share nào, vì việc tra cứu vector và index là các thao tác đọc ngẫu nhiên nhỏ. Network volume sẽ biến mỗi thao tác thành một round trip. Nếu lựa chọn plan phụ thuộc vào yếu tố này, khác biệt giữa lưu trữ NVMe và SATA SSD trên VPS quan trọng ở đây hơn bất kỳ thành phần nào khác trong stack.

redis chạy Valkey image và lưu các job queue. Đây là service nhỏ nhất trong 4 service, với khoảng cách lớn, vì nó lưu job record thay vì dữ liệu ảnh.

immich-machine-learning là service quyết định kích thước plan của bạn. Nó load model cho smart search, nhận diện khuôn mặt và nhận dạng văn bản. Model đã load sẽ tiếp tục nằm trong memory. MACHINE_LEARNING_MODEL_TTL mặc định là 300, nên model sẽ bị loại bỏ sau 5 phút không có request và được đọc lại từ volume /cache khi có request tiếp theo. Trong quá trình import hàng loạt, không bao giờ có khoảng nghỉ 5 phút. Vì vậy, model tiếp tục được load từ asset đầu tiên đến asset cuối cùng.

Thay đổi trong quá trình import

Immich ở trạng thái nhàn rỗi thường không hoạt động nhiều. Import là lúc các máy chủ nhỏ dễ quá tải, vì tải lên một asset sẽ xếp hàng nhiều job và nhiều queue chạy cùng lúc.

Trích xuất metadata đọc header của file và tiêu tốn ít tài nguyên. Tạo thumbnail nặng hơn. Immich tạo 3 đầu ra thumbnail cho mỗi asset: placeholder thumbhash bị làm mờ, bản preview WebP và thumbnail JPEG, cùng thêm 1 thumbnail cho mỗi khuôn mặt được phát hiện. Mỗi job này đều phải decode một ảnh, còn job concurrency quyết định có bao nhiêu ảnh được decode cùng lúc. Concurrency là hệ số biến chi phí nhỏ của từng job thành tải trên toàn server. Vì vậy, Immich FAQ xác định đây là thông số đầu tiên cần giảm trên máy có tài nguyên hạn chế. Đặt concurrency của các queue nặng thành 1 trong Administration, Settings, Job Settings.

Asset video cần transcoding. Mỗi job transcode chạy trong một tiến trình FFmpeg riêng, có vùng nhớ riêng và sẽ sử dụng mọi CPU thread mà bạn cho phép.

Smart search gửi mỗi asset mới đến machine learning container để tính 1 vector embedding. Face detection chạy model thứ 2 trên cùng ảnh đó. Trong lần import đầu tiên của thư viện ảnh hiện có, cả 2 queue này sẽ xử lý mọi asset bạn có trong nhiều giờ. Đây là thời điểm bộ nhớ bị sử dụng nhiều nhất trong toàn bộ quá trình cài đặt, và chỉ xảy ra 1 lần.

Vì sao nhận diện khuôn mặt và vật thể cần nhiều RAM nhất

Xử lý khuôn mặt gồm 2 công việc. Phát hiện khuôn mặt chạy model trong machine learning container để tìm các bounding box. Nhận diện khuôn mặt sau đó nhóm các kết quả phát hiện thành từng người. Bước này truy vấn vector index trong Postgres. Vì vậy, thư viện ảnh lớn lần lượt gây áp lực lên cả 2 service: trước tiên là container chứa model khi chạy phát hiện, sau đó là database khi thực hiện nhóm.

Bốn thiết lập ảnh hưởng đến lượng dữ liệu mà machine learning container giữ trong bộ nhớ.

• Model khuôn mặt. Immich mặc định dùng buffalo_l, còn FAQ khuyến nghị buffalo_s trên server nhỏ. Đây là model nhỏ hơn nên chiếm ít memory hơn và chạy nhanh hơn, nhưng độ chính xác với khuôn mặt nhỏ hoặc nhìn nghiêng sẽ thấp hơn.
• Số worker. MACHINE_LEARNING_WORKERS mặc định là 1. Mỗi worker là một process riêng và load một bản sao riêng của các model. Vì vậy, tăng lên 2 sẽ gần như làm tăng gấp đôi resident model memory. Giữ ở mức 1 nếu bạn không dư RAM.
• Batch size. MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION giới hạn số khuôn mặt được xử lý cùng lúc. Một batch được giữ đồng thời trong memory, nên ảnh nhóm có 40 khuôn mặt sẽ tốn nhiều memory hơn ảnh chân dung.
• Các loại model được chạy. Smart search, phát hiện khuôn mặt và nhận dạng văn bản đều load model riêng. Tắt những tính năng bạn không dùng trong Administration, Settings, Machine Learning Settings sẽ giải phóng phần memory đó lâu dài, thay vì chỉ giải phóng giữa các lần import.

Ngoài ra còn có MACHINE_LEARNING_MODEL_ARENA. Thiết lập này được mô tả là cấp phát trước CPU memory để tránh fragmentation và mặc định đang bật. Hãy thay đổi nó sau cùng. Tác động của nó phụ thuộc vào memory allocator bên dưới. Vì vậy, cách đánh giá chính xác duy nhất là theo dõi docker stats trước và sau khi thay đổi.

Ba cấu hình mẫu: 2 GB, 4 GB và 8 GB

[
  {
    "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"
  }
]

Hãy hiểu đây là các giới hạn cần nhập vào Compose, không phải số đo mức sử dụng của Immich. Giới hạn là mức trần. Nó không reserve tài nguyên và không làm service nhỏ hơn. Nó quyết định service nào bị kernel kill khi máy chủ hết tài nguyên. Bạn nên quyết định việc này thay vì để cơ chế chấm điểm của kernel tự quyết định.

Máy chủ 2 GB: xóa container machine learning

2 GB thấp hơn mức tối thiểu được tài liệu hóa là 6 GB, đồng thời thấp hơn cấu hình rút gọn duy nhất được Immich tài liệu hóa: 4 GB khi tắt machine learning. Immich không công bố cấu hình 2 GB. Vì vậy, đây là một phương án thỏa hiệp không được hỗ trợ, không phải công thức triển khai. Nếu vẫn muốn thử, hãy comment toàn bộ service immich-machine-learning trong docker-compose.yml, hoặc để service này chạy và tắt mọi model trong Administration, Settings, Machine Learning Settings. Xóa container là lựa chọn tốt hơn, vì model bị tắt vẫn để lại một tiến trình Python trong memory.

Bạn vẫn có upload, album, chia sẻ, mobile backup và tìm kiếm theo ngày, địa điểm, tên file. Bạn mất tìm kiếm theo mô tả, tính năng tự động gom khuôn mặt thành người và nhận dạng văn bản trong ảnh.

Bốn giới hạn cộng lại khoảng 1.7 GB, chỉ còn khoảng 300 MB cho host. Tài liệu Immich cho biết riêng database cần ít nhất 2 GB khi dùng Docker resource limits, tức bằng toàn bộ dung lượng của máy. Vì vậy, 768 MB cho database thấp hơn nhiều so với mức này. Đây là lý do Postgres là service có khả năng bị kill cao nhất.

Import sẽ gặp vấn đề đầu tiên. Hiển thị một trang chỉ gồm truy vấn metadata và đọc file, nên duyệt một library đã có sẵn không gây nhiều tải cho máy. Ngược lại, import nhiều video sẽ gây swap, vì transcode và thumbnail queue cần memory cùng lúc. Nếu chỉ có 2 GB, hãy đặt concurrency của mọi queue nặng thành 1 và thêm swap file. Nếu đang chọn gói dịch vụ, hãy xem 4 GB là mức tối thiểu thực tế.

Máy chủ 4 GB: bật machine learning, mỗi lần chạy một job

Immich tài liệu hóa 4 GB là mức có thể sử dụng được khi tắt các tính năng machine learning. Đây là cấu hình rút gọn duy nhất trên trang yêu cầu hệ thống. Khi database ở mức tối thiểu được tài liệu hóa là 2 GB, ba giới hạn trong biểu đồ cộng lại khoảng 3.2 GB, còn khoảng 800 MB cho host. Hãy đặt job concurrency thành 1 cho việc tạo thumbnail và giữ số thread transcoding ở mức thấp.

Để giữ tính năng nhận dạng khuôn mặt và vật thể, cách được tài liệu hóa là chạy container machine learning trên một máy khác, như mô tả bên dưới, rồi trỏ server này đến máy đó. Chạy container này trên cùng máy chủ 4 GB vượt ngoài cấu hình Immich đã tài liệu hóa, vì sau khi dành mức tối thiểu cho database, server, Redis, model và host chỉ còn khoảng 2 GB. Nếu vẫn muốn thử, hãy giới hạn container machine learning bằng Compose limit, chuyển facial recognition sang buffalo_s và đặt job concurrency thành 1 cho việc tạo thumbnail, phát hiện khuôn mặt và smart search.

Lần xử lý đầu tiên trên library hiện có sẽ mất nhiều giờ, còn với library lớn có thể hơn một ngày. Đây là giới hạn CPU chứ không phải memory, nên thêm RAM sẽ không rút ngắn thời gian.

Nếu machine learning chạy trên máy này, container đó sẽ gặp vấn đề đầu tiên trong lần xử lý hàng loạt đầu tiên. Khi không có giới hạn, container tăng mức sử dụng trong lúc một transcode job cũng tăng mức sử dụng, rồi kernel kill tiến trình lớn hơn. Vì container khởi động lại trong vài giây, docker ps -a hiển thị container đó Up với uptime ngắn hơn nhiều so với các container lân cận thay vì Exited (137), còn queue âm thầm chậm hơn so với lần kiểm tra trước.

Máy chủ 8 GB: cấu hình được khuyến nghị

8 GB với 4 core phù hợp với khuyến nghị của Immich. Mọi tính năng chạy ở setting mặc định: smart search, phát hiện khuôn mặt, nhận dạng văn bản và transcoding, với concurrency mặc định. Library có hơn một trăm nghìn asset vẫn hoạt động thoải mái ở cấu hình này. Áp lực chuyển từ memory sang tốc độ disk, vì vector index và các truy vấn metadata là những tác vụ database thực hiện cả ngày.

Dù máy còn dư tài nguyên, vẫn nên đặt các giới hạn. Trên máy còn nhiều tài nguyên, giới hạn sẽ ngăn một queue chạy không kiểm soát làm database bị ảnh hưởng theo. Nếu đang so sánh chi phí với các lựa chọn nhỏ hơn, chi phí thực tế của VPS theo từng mức memory thường cho thấy gói 8 GB là cách rẻ nhất để không phải tiếp tục tinh chỉnh.

Cách giới hạn bộ nhớ cho từng service bằng giới hạn của Compose

Không chỉnh sửa docker-compose.yml. File đó sẽ bị thay thế mỗi lần bạn nâng cấp bằng wget. Đặt các giới hạn trong docker-compose.override.yml bên cạnh file đó. docker compose sẽ tự động hợp nhất file này.

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 hiện phải hiển thị mức giới hạn bạn đặt trong cột MEM USAGE / LIMIT, thay vì tổng bộ nhớ của host. Nếu cột giới hạn vẫn hiển thị toàn bộ dung lượng của host, file override chưa được nạp. Kiểm tra tên file và chạy docker compose config để xem kết quả đã hợp nhất.

Giữ giới hạn cho database ở mức 2048M trở lên. Tài liệu Immich quy định 2 GB là mức tối thiểu cho database khi sử dụng giới hạn tài nguyên của Docker. Giới hạn quá thấp có thể biến một service chạy chậm thành service không thể hoạt động, vì vậy hãy tăng giới hạn nếu container bắt đầu liên tục khởi động lại. Xem thêm về cơ chế này trong đặt giới hạn bộ nhớ cho từng service trong Docker Compose, bao gồm lý do deploy hoạt động bên ngoài Swarm với Compose v2.

Cách tắt hoặc chuyển container machine learning

Trên một server nhỏ, chuyển container này sang nơi khác là thay đổi có tác động lớn nhất mà bạn có thể thực hiện. Immich hỗ trợ chạy container này trên một máy khác. Tạo file sau trên host thứ hai. Host này có thể là một desktop chỉ bật vào buổi tối:

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

Sau đó vào Administration, Settings, Machine Learning Settings trong giao diện web, nhấp vào Add URL và nhập http://<host>:3003. Giữ cùng version trên cả hai host, vì tài liệu Immich cảnh báo rằng version không khớp giữa hai bên có thể gây lỗi và làm hệ thống không ổn định.

Cổng đó truyền bản xem trước ảnh của bạn đến máy kia mà không mã hóa. Tài liệu Immich cũng cảnh báo rằng container machine learning không có biện pháp bảo mật riêng. Vì vậy, hãy giữ nó trong private network hoặc chạy qua một tunnel WireGuard giữa hai host. Không bao giờ expose cổng 3003 ra Internet.

Nếu vấn đề là bạn không muốn duy trì một model container chạy thường trực, đó cũng là lý do hợp lý để so sánh PhotoPrism và Immich khác nhau thế nào về các thành phần chạy thường trực trước khi chọn plan.

Cần bao nhiêu dung lượng đĩa cho library Immich?

Không có một hệ số duy nhất, vì 4 thành phần khác nhau tăng theo 4 tốc độ khác nhau. Dưới đây là phép tính cho một library gồm 50,000 ảnh và 500 video ngắn.

[
  {
    "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 ảnh và 60 GB video là các giả định. Hãy thay bằng mức trung bình của bạn trước khi mua thiết bị, vì video quyết định con số này: 1 phút video từ điện thoại lớn hơn 100 ảnh.

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}'

Dòng 39 GB là tỷ lệ duy nhất được Immich công bố: thumbnail được tạo và video được transcode trung bình làm tăng kích thước library thêm 10 đến 20 phần trăm. Đây là một khoảng ước tính vì còn phụ thuộc vào số asset là video cần re-encode để tương thích với trình duyệt. Library chỉ gồm JPEG thường nằm gần mức thấp của khoảng này.

Database chiếm 3 GB và gần như là chi phí cố định. Immich ghi rõ các file database thường chiếm 1 đến 3 GB, vì chúng lưu metadata và vector tìm kiếm thay vì pixel. Cache của model chiếm 2 GB và tăng lên nếu bạn bật nhiều model hoặc thử các model khác nhau. FAQ nêu rõ volume này tiêu tốn dung lượng vì chính lý do đó.

5 dòng này cộng lại thành hơn 300 GB một chút, nên volume 500 GB vẫn còn chỗ để tăng trưởng, còn volume 250 GB thì không. Kiểm tra phần phân bổ bằng:

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

Có 6 thư mục nằm dưới UPLOAD_LOCATION. upload và library chứa bản gốc, thumbs chứa preview và thumbnail khuôn mặt, encoded-video chứa các bản sao đã re-encode, profile chứa avatar, còn backups chứa các database dump tự động. Chỉ upload, library và profile là không thể thay thế, vì mọi thứ khác đều có thể được tạo lại từ chúng.

Có 2 điều thường khiến người dùng bất ngờ. Asset đã xóa trước tiên được chuyển vào trash và tiếp tục chiếm dung lượng cho đến khi trash được dọn, nên một lần dọn dẹp lớn không giải phóng dung lượng ngay trong ngày thực hiện. Database dump chỉ chứa metadata, nên không có giá trị nếu thiếu các file:

docker exec -t immich_postgres pg_dump --clean --if-exists \
  --dbname=immich --username=postgres | gzip > /srv/backups/immich-dump.sql.gz

Kết hợp việc đó với một bản sao cấp file của các bản gốc được lưu ở nơi khác ngoài server. Đây là mục đích của restic backup từ VPS đến storage ngoài server.

Transcoding bị giới hạn bởi CPU, không phải RAM

Tăng RAM không làm transcoding nhanh hơn. Immich dùng FFmpeg để transcoding, và trên VPS thông thường, CPU phải decode và encode từng frame. Mỗi tiến trình FFmpeg vẫn giữ các buffer chứa frame đã decode trong memory. Vì vậy, phần import tính mỗi tác vụ transcoding là một khoản tiêu thụ memory riêng. Tuy nhiên, tốc độ vẫn do CPU quyết định. Ngay cả khi có hardware acceleration, tài liệu Immich cho biết mặc định chỉ có encoding được tăng tốc. CPU vẫn thực hiện decoding và tone mapping, trừ khi bạn cũng bật hardware decoding.

Hardware acceleration cần thêm file hwaccel.transcoding.yml Compose và một device để pass through, sử dụng NVENC, Quick Sync, RKMPP hoặc VAAPI. Phần lớn gói VPS không cung cấp các thành phần này. Vì vậy, hãy lập kế hoạch theo năng lực CPU.

Thiết lập thực tế cần quan tâm là số thread. Trong Administration, Settings, Video Transcoding Settings, giá trị thread bằng 0 nghĩa là dùng toàn bộ core. Điều này có thể khiến một video làm treo web interface trên gói 2 core. Hãy đặt giá trị này thành 1 hoặc 2 như Immich FAQ khuyến nghị. Khi đó, transcoding sẽ chậm nhưng không làm gián đoạn hệ thống.

Vì sao tác vụ import làm swap thrashing trông như bị treo

Đây là lỗi thường bị hiểu sai nhất. Khi Immich hết memory, có 2 khả năng xảy ra và chỉ một khả năng trông giống lỗi.

Không có swap, kernel sẽ kill một process. Container khởi động lại trong vài giây, nên trên browser, hàng đợi job chỉ bị dừng rồi tiếp tục. Bằng chứng nằm trong 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) nghĩa là process đã bị kill bằng signal 9. 137 bằng 128 cộng 9. Bạn chỉ thấy status này khi container đang dừng. Sau khi restart policy đưa container chạy lại, docker ps -a lại hiển thị Up, và uptime ngắn hơn nhiều so với các container Immich khác là dấu hiệu cần chú ý. Chỉ riêng signal 9 không chứng minh được vấn đề memory, vì Docker cũng gửi signal này khi một lệnh stop bình thường vượt quá timeout. Giá trị OOMKilled là true xác nhận process bị kill vì memory, và sau khi container đã khởi động lại, các dòng oom-kill từ dmesg mới là thông tin cần tin cậy.

Có swap, không process nào bị kill và cũng không có lỗi nào xuất hiện. Kernel bắt đầu chuyển các page vào disk, import chậm hơn hàng chục lần, còn web interface ngừng phản hồi trong khoảng timeout bình thường. Mọi container vẫn đang chạy. Mọi health check vẫn có thể pass. Nó trông như bị treo, nên nhiều người reboot máy ở thời điểm này. Việc đó làm mất tiến độ của queue nhưng không giải quyết được gì.

free -m
vmstat 1 5

Các giá trị khác 0 duy trì trong các cột si và so của vmstat nghĩa là máy đang liên tục đọc và ghi swap. Đây chính là thrashing. Đồng thời, giá trị Swap used trong dòng free -m cũng sẽ tăng dần.

Dù vậy, hãy thêm swap trên máy 2 GB hoặc 4 GB, vì một tác vụ import chậm nhưng có thể chẩn đoán vẫn tốt hơn một container bị kill mà bạn không thể điều tra:

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

Sau đó xử lý nguyên nhân. Giảm concurrency của job xuống 1, giới hạn memory của container machine learning hoặc chuyển container đó sang host khác. Swap chỉ giúp bạn có thời gian xử lý. Tự nó không phải là giải pháp.

FAQ

Tôi có thể chạy Immich trên VPS 2 GB không?

Không theo bất kỳ cấu hình nào được Immich ghi trong tài liệu. Trang yêu cầu hệ thống đặt 6 GB là mức tối thiểu, nêu 4 GB với tính năng machine learning bị tắt là cấu hình nhỏ hơn duy nhất, đồng thời cho biết riêng database đã cần ít nhất 2 GB khi dùng giới hạn tài nguyên Docker. Comment dòng immich-machine-learning và đặt concurrency của job thành 1 có thể giúp hệ thống chạy được, nhưng đây là một phương án thỏa hiệp không được hỗ trợ. Postgres là service có khả năng bị kill cao nhất trong lúc import. Nếu bạn chỉ có 2 GB, hãy thêm swap file 2 GB để khi import tăng đột biến, server chậm lại thay vì container bị kill. Nếu đang chọn plan, hãy bắt đầu với 4 GB.

Vì sao quá trình import Immich của tôi dừng mà không có thông báo lỗi?

Từ phía browser, có 2 nguyên nhân trông giống hệt nhau. Một là container bị kill vì thiếu memory rồi đã restart; khi đó docker ps -a hiển thị Up với uptime ngắn bất thường (Exited (137) chỉ xuất hiện nếu bạn bắt gặp lúc container đang stopped). Hai là host đang swap; khi đó mọi container vẫn running nhưng toàn hệ thống rất chậm. vmstat 1 5 giúp phân biệt 2 trường hợp: các giá trị khác 0 duy trì trong các cột si và so cho biết hệ thống đang swap. Trong cả 2 trường hợp, hãy giảm concurrency của job tạo thumbnail, nhận diện khuôn mặt và smart search.

Exit code 137 trong log Immich có nghĩa là gì?

137 bằng 128 cộng signal 9, nên process đã bị kill bằng SIGKILL. Trên máy chạy Immich, nguyên nhân thường là chạm giới hạn memory: hoặc giới hạn riêng của container, hoặc host hết memory. Tuy nhiên, chỉ exit code này chưa chứng minh được nguyên nhân. Docker cũng gửi SIGKILL khi container không dừng trong thời gian timeout, mặc định là 10 giây trên Linux. Kiểm tra bằng docker inspect immich_machine_learning | grep -i oomkilled. Giá trị true xác nhận kernel đã kill process vì memory. Sau đó, free -m cùng sudo dmesg -T | grep -i oom-kill cho biết nguyên nhân là giới hạn của container hay toàn bộ host. Machine learning container thường là container bị ảnh hưởng vì đây thường là process lớn nhất.

Immich cần bao nhiêu dung lượng disk cho mỗi ảnh?

Hãy dự trù dung lượng file gốc cộng thêm 10 đến 20 phần trăm. Immich ghi rõ thumbnail được tạo và video được transcode làm tăng kích thước library trung bình 10 đến 20 phần trăm. Database thường chiếm thêm 1 đến 3 GB, kể cả với library lớn. Video mới là yếu tố quyết định tổng dung lượng. Vì vậy, hãy đo kích thước file trung bình của chính bạn trước khi chọn plan, thay vì áp dụng một hệ số cố định cho số lượng ảnh.

Tôi có cần GPU cho Immich không?

Không. Mọi thành phần của Immich đều chạy trên CPU. GPU giúp tăng tốc model inference trong machine learning container và quá trình encode video, nhưng không bắt buộc cho cả 2 tác vụ này. Hầu hết plan VPS không cung cấp GPU. Trên phần cứng chỉ có CPU, hãy đặt số thread transcoding thành 1 hoặc 2, dùng face model buffalo_s và để lần bulk import đầu tiên chạy qua đêm.