SSD Nodes Learn Hosting plans →
Panduan Matt ConnorOleh Matt Connor · Dikemas kini 2026-08-13

Keperluan RAM dan Storan Immich: Panduan Minimum

Immich memerlukan sekurang-kurangnya 6 GB RAM untuk prestasi optimum. Ketahui pecahan penggunaan memori bagi Postgres, Redis, dan ML serta cara menjalankan Immich pada 4 GB.

Berapakah jumlah RAM yang diperlukan oleh Immich?

Immich memerlukan 6 GB RAM (random access memory) sebagai minimum yang didokumentasikan dan 8 GB sebagai saranan, pada 2 teras CPU untuk tahap rendah dan 4 untuk pemasangan yang selesa. Angka tersebut merangkumi keseluruhan tindanan (stack), kerana Immich terdiri daripada empat kontena dan bukannya satu aplikasi tunggal. Melayari pustaka yang telah diimport tidak menggunakan banyak sumber. Penggunaan memori tertumpu pada proses import, dan sebahagian besarnya digunakan oleh satu kontena yang boleh anda matikan.

ChartImmich documented hardware requirements, August 2026
The data behind this chart
[
  {
    "label": "Documented minimum",
    "ram_gb": 6,
    "cpu_cores": 2
  },
  {
    "label": "Documented recommended",
    "ram_gb": 8,
    "cpu_cores": 4
  }
]

Ini adalah angka yang diterbitkan daripada halaman keperluan Immich setakat Ogos 2026. Ia merupakan saranan saiz, bukan pemeriksaan sama ada perisian tersebut berjalan semasa permulaan. Immich boleh bermula dengan jumlah yang lebih kecil. Perkara yang berubah pada pelayan yang lebih kecil ialah tugasan latar belakang yang berjaya diselesaikan, dan tindakan import apabila memori kehabisan.

Terdapat satu had keras yang sebenar. Immich versi 3 dan ke atas memerlukan CPU x86-64-v2 pada hos amd64, yang merangkumi kebanyakan pemproses yang dijual sejak sekitar tahun 2012. Pada perkakasan yang lebih lama, kontena akan gagal bermula dan bukannya berjalan dengan perlahan.

Jika anda belum memulakan pemasangan, mulakan dengan pemasangan penuh Immich pada VPS dengan Docker Compose dan kembali ke sini untuk menentukan saiz pelayan anda.

Ke mana perginya memori: empat kontena

Fail Compose rasmi memulakan empat servis. Setiap satu mempunyai bentuk memori yang berbeza, jadi satu angka jumlah keseluruhan menyembunyikan bahagian yang berguna.

immich-server menyediakan antara muka web dan API, serta menjalankan pekerja tugasan latar belakang. Dua pekerja berada di dalam satu kontena tersebut. api menjawab permintaan daripada pelayar dan aplikasi mudah alih. microservices menjalankan baris gilir, termasuk penjanaan lakaran kenit dan pengekodan video. Pemboleh ubah IMMICH_WORKERS_INCLUDE dan IMMICH_WORKERS_EXCLUDE memisahkan kedua-duanya ke dalam kontena berasingan, iaitu cara anda memberikan had memori kepada bahagian yang sibuk tanpa mengehadkan bahagian yang menyajikan foto anda.

database ialah imej PostgreSQL 14 dengan sambungan VectorChord terbina dalam. Ia menyimpan setiap keping metadata dan satu vektor carian bagi setiap aset. Dokumentasi Immich memberikan servis ini satu-satunya lantai eksplisit dalam tindanan: jika anda menggunakan had sumber Docker, pangkalan data memerlukan sekurang-kurangnya 2 GB. Halaman yang sama menyatakan pangkalan data mesti berada pada storan SSD tempatan dan bukan pada perkongsian rangkaian dalam apa jua bentuk, kerana carian vektor dan indeks adalah bacaan rawak kecil, jadi volum rangkaian akan menukarkan setiap satunya menjadi perjalanan pergi balik. Jika pilihan pelan bergantung pada perkara itu, perbezaan antara storan NVMe dan SATA SSD pada VPS lebih penting di sini berbanding tempat lain dalam tindanan ini.

redis menjalankan imej Valkey dan menyimpan baris gilir tugasan. Ia adalah yang paling kecil antara keempat-empatnya dengan margin yang luas, kerana ia menyimpan rekod tugasan dan bukannya data foto.

immich-machine-learning ialah servis yang menentukan saiz pelan anda. Ia memuatkan model untuk carian pintar, pengesanan wajah dan pengecaman teks, dan model yang dimuatkan kekal dalam memori. MACHINE_LEARNING_MODEL_TTL ditetapkan kepada 300 secara lalai, jadi model akan digugurkan selepas lima minit tanpa permintaan dan dibaca semula daripada volum /cache pada permintaan seterusnya. Semasa import pukal, tidak pernah ada jurang lima minit, jadi model kekal dimuatkan dari aset pertama hingga yang terakhir.

Perubahan semasa proses import

Immich yang melahu tidak melakukan sebarang aktiviti. Proses import merupakan fasa di mana pelayan berspesifikasi rendah sering tergendala, kerana memuat naik satu aset akan menjana rantaian tugasan dan beberapa baris gilir (queue) akan berjalan serentak.

Pengekstrakan metadata membaca pengepala fail dan ia adalah proses yang ringan. Penjanaan imej kecil (thumbnail) adalah lebih berat. Immich menghasilkan tiga output thumbnail bagi setiap aset: pemegang tempat thumbhash yang kabur, pratonton WebP, dan thumbnail JPEG, ditambah satu lagi thumbnail bagi setiap wajah yang dikesan. Setiap tugasan tersebut menyahkod imej, dan konkurensi tugasan menentukan berapa banyak imej yang dinyahkod pada satu-satu masa. Konkurensi ialah pengganda yang menukarkan kos kecil bagi setiap tugasan kepada bebanan seluruh pelayan; itulah sebabnya FAQ Immich menyarankan perkara ini sebagai langkah pertama untuk dikurangkan pada mesin yang terhad sumbernya. Tetapkan konkurensi bagi baris gilir yang berat kepada 1 di bawah Administration, Settings, Job Settings.

Aset video menambah proses transkod. Setiap tugasan transkod adalah proses FFmpeg berasingan dengan penggunaan memorinya sendiri, dan ia akan menggunakan setiap thread CPU yang anda benarkan.

Carian pintar (smart search) menghantar setiap aset baharu ke kontena pembelajaran mesin untuk mengira satu vektor pembenaman (embedding vector). Pengesanan wajah menjalankan model kedua ke atas imej yang sama. Semasa import pertama pustaka foto sedia ada, kedua-dua baris gilir tersebut akan berjalan ke atas setiap aset yang anda miliki selama berjam-jam. Itu adalah detik paling kritikal bagi penggunaan memori dalam keseluruhan pemasangan, dan ia hanya berlaku sekali sahaja.

Mengapa pengecaman wajah dan objek memerlukan RAM yang paling banyak

Pengendalian wajah melibatkan dua tugas. Pengecaman wajah menjalankan model dalam kontena pembelajaran mesin dan mencari kotak-kotak tersebut. Pengecaman wajah kemudian mengumpulkan hasil pengesanan tersebut kepada individu, dan langkah itu membuat pertanyaan kepada indeks vektor dalam Postgres. Jadi, pustaka yang besar akan membebankan kedua-dua servis secara bergilir-gilir: kontena model semasa pengesanan dijalankan, kemudian pangkalan data semasa pengumpulan dijalankan.

Empat tetapan mengubah perkara yang ditampung oleh kontena pembelajaran mesin.

  • Model wajah. Immich menyertakan buffalo_l secara lalai, dan FAQ mengesyorkan buffalo_s pada pelayan kecil. Ia merupakan model yang lebih kecil, jadi ia menggunakan kurang memori dan berjalan lebih pantas, dengan pengorbanan pada ketepatan untuk wajah yang kecil atau dari sisi.
  • Bilangan pekerja. MACHINE_LEARNING_WORKERS ditetapkan kepada 1 secara lalai. Setiap pekerja adalah proses berasingan yang memuatkan salinan modelnya sendiri, jadi meningkatkannya kepada 2 akan menggandakan memori model yang digunakan secara kasar. Kekalkan pada 1 melainkan anda mempunyai RAM yang berlebihan.
  • Saiz kelompok. MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION mengehadkan berapa banyak wajah yang diproses pada satu-satu masa. Satu kelompok ditampung dalam memori secara bersama, jadi gambar berkumpulan dengan empat puluh wajah memerlukan lebih banyak memori berbanding potret.
  • Jenis model yang dijalankan. Carian pintar, pengesanan wajah, dan pengecaman teks masing-masing memuatkan model mereka sendiri. Mematikan model yang tidak digunakan, di bawah Administration, Settings, Machine Learning Settings, akan membuang penggunaan memorinya secara kekal dan bukan sekadar antara proses import.

Terdapat juga MACHINE_LEARNING_MODEL_ARENA, yang didokumentasikan sebagai pra-peruntukan memori CPU untuk mengelakkan pemecahan (fragmentation) dan diaktifkan secara lalai. Ubah tetapan ini sebagai langkah terakhir. Kesannya bergantung pada pengurus memori di bawahnya, jadi satu-satunya cara yang tepat untuk menilainya adalah dengan memantau docker stats sebelum dan selepas perubahan.

Tiga profil yang berfungsi: 2 GB, 4 GB dan 8 GB

ChartCompose memory limits that fit each server size, in MB
The data behind this chart
[
  {
    "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"
  }
]

Baca nilai tersebut sebagai had untuk ditaip ke dalam Compose, bukan sebagai ukuran penggunaan sebenar Immich. Had ialah siling. Ia tidak menempah apa-apa, dan ia tidak menjadikan servis lebih kecil. Ia menentukan servis mana yang akan dimatikan oleh kernel apabila pelayan kehabisan memori, dan itu adalah keputusan yang lebih baik dibuat oleh anda berbanding sistem pemarkahan kernel sendiri.

Kotak 2 GB: alih keluar kontena pembelajaran mesin

2 GB berada di bawah minimum yang didokumenkan sebanyak 6 GB, jadi ini adalah satu kompromi dan perlu dinyatakan sedemikian. Komen keseluruhan servis immich-machine-learning dalam docker-compose.yml, atau biarkan ia berjalan dan nyahdayakan setiap model di bawah Administration, Settings, Machine Learning Settings. Mengalih keluar kontena adalah pilihan yang lebih berkesan, kerana model yang dinyahdayakan masih meninggalkan proses Python yang aktif.

Anda mengekalkan fungsi muat naik, album, perkongsian, sandaran mudah alih, imej kecil (thumbnail), serta carian mengikut tarikh, tempat dan nama fail. Anda kehilangan fungsi carian mengikut deskripsi, pengumpulan wajah secara automatik kepada orang, dan pengecaman teks di dalam imej.

Keempat-empat had tersebut berjumlah kira-kira 1.7 GB, yang meninggalkan ruang kira-kira 300 MB untuk hos. Perhatikan bahawa 768 MB untuk pangkalan data adalah di bawah had minimum 2 GB yang didokumenkan. Itulah kompromi yang terpaksa dibuat pada 2 GB, dan itulah sebabnya Postgres merupakan servis yang paling berkemungkinan dimatikan di sini.

Perkara yang tergendala dahulu ialah proses import, bukan pelayaran. Pustaka dengan puluhan ribu foto boleh dilayari dengan baik setelah ia dimasukkan, kerana memaparkan halaman hanyalah pertanyaan metadata ditambah dengan bacaan fail. Import yang berat dengan video pada kotak yang sama akan menyebabkan swap, kerana proses transkod dan baris gilir imej kecil memerlukan memori pada masa yang sama. Tetapkan setiap baris gilir yang berat kepada konkurensi 1 dan tambah fail swap.

Kotak 4 GB: pembelajaran mesin dihidupkan, satu tugasan pada satu masa

4 GB ialah saiz terkecil di mana pengecaman wajah dan objek berbaloi untuk dihidupkan. Hadkan kontena pembelajaran mesin kepada 0 MB, tukar pengecaman wajah kepada buffalo_s, dan tetapkan konkurensi tugasan kepada 1 untuk penjanaan imej kecil, pengesanan wajah dan carian pintar.

Laluan pertama ke atas pustaka sedia ada akan berjalan selama berjam-jam, dan pada pustaka yang besar, ia boleh mengambil masa lebih daripada sehari. Itu adalah had CPU dan bukannya memori, jadi lebih banyak RAM tidak akan memendekkan tempoh tersebut.

Perkara yang tergendala dahulu di sini ialah kontena pembelajaran mesin semasa laluan pukal pertama. Jika tidak dihadkan, ia akan membesar sementara tugasan transkod juga membesar, dan kernel akan mematikan salah satu yang lebih besar. Anda akan melihat Exited (137) dalam docker ps -a dan kontena yang dimulakan semula, dengan baris gilir yang tertinggal lebih jauh daripada kali terakhir anda melihatnya.

Kotak 8 GB: cadangan yang didokumenkan

8 GB dengan 4 teras sepadan dengan apa yang disyorkan oleh Immich, dan semuanya berjalan pada tetapan lalai: carian pintar, pengesanan wajah, pengecaman teks dan transkod, pada konkurensi lalai. Pustaka yang melebihi seratus ribu aset boleh dikendalikan dengan selesa di sini, dan tekanan beralih daripada memori kepada kelajuan cakera, kerana indeks vektor dan pertanyaan metadata adalah perkara yang dilakukan oleh pangkalan data sepanjang hari.

Tetapkan had tersebut walau bagaimanapun. Pada kotak yang mempunyai ruang, had tersebut menghalang satu baris gilir yang tidak terkawal daripada menjatuhkan pangkalan data bersamanya. Jika anda membandingkan harga ini dengan pilihan yang lebih kecil, kos sebenar VPS mengikut tier memori biasanya menjadikan pelan 8 GB sebagai cara paling murah untuk mengelakkan penalaan.

Cara mengehadkan memori setiap servis dengan had Compose

Jangan sunting docker-compose.yml untuk tujuan ini. Fail tersebut diganti setiap kali anda melakukan naik taraf dengan wget. Letakkan had tersebut di dalam docker-compose.override.yml bersebelahannya, yang mana docker compose akan gabungkan secara automatik.

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 kini sepatutnya memaparkan had anda dalam lajur MEM USAGE / LIMIT dan bukannya jumlah memori hos. Jika lajur had masih memaparkan saiz penuh hos, fail ganti (override) tidak dikesan: semak nama fail dan jalankan docker compose config untuk melihat hasil gabungan.

Had yang terlalu rendah menukarkan servis yang perlahan kepada servis yang mati, jadi tingkatkan had tersebut jika kontena mula berulang (cycling). Terdapat maklumat lanjut mengenai mekanismenya dalam menetapkan had memori setiap servis dalam Docker Compose, termasuk sebab deploy berfungsi di luar Swarm dengan Compose v2.

Cara mematikan atau memindahkan kontena pembelajaran mesin

Pada pelayan kecil, memindahkan kontena ini ke tempat lain merupakan perubahan paling besar yang boleh anda lakukan. Immich menyokong pelaksanaan kontena ini pada mesin lain. Cipta fail ini pada hos kedua, yang boleh berupa komputer meja yang hanya dihidupkan pada waktu malam:

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

Kemudian pergi ke Administration, Settings, Machine Learning Settings dalam antara muka web, klik Add URL, dan masukkan http://<host>:3003. Pastikan versi pada kedua-dua hos adalah sama, kerana dokumentasi Immich memberi amaran bahawa ketidakpadanan versi antara kedua-duanya akan menyebabkan pepijat dan ketidakstabilan.

Port tersebut membawa foto anda ke mesin lain tanpa penyulitan, jadi pastikan ia berada dalam rangkaian peribadi atau jalankannya melalui terowong WireGuard antara kedua-dua hos. Jangan sekali-kali mendedahkan 3003 kepada internet.

Jika keseluruhan idea mengenai kontena model residen menjadi masalah, itu juga merupakan alasan yang wajar untuk membandingkan perbezaan antara PhotoPrism dan Immich dari segi apa yang dijalankan semasa melahu sebelum menetapkan saiz pelan.

Berapakah ruang cakera yang diperlukan oleh pustaka Immich?

Tiada pengganda tunggal, kerana empat perkara berbeza berkembang pada kadar yang berbeza. Berikut adalah pengiraan untuk pustaka yang mengandungi 50,000 foto dan 500 video pendek.

ChartWorked disk estimate: 50,000 photos and 500 videos
The data behind this chart
[
  {
    "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 untuk foto dan 60 GB untuk video adalah andaian. Gantikan nilai ini dengan purata anda sendiri sebelum membeli apa-apa, kerana video menentukan angka ini: satu minit video telefon adalah lebih besar daripada seratus keping foto.

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

Baris 39 GB adalah satu-satunya nisbah yang diterbitkan oleh Immich: lakaran kenit (thumbnail) yang dijana dan video yang ditranskod menambah 10 hingga 20 peratus kepada saiz pustaka secara purata. Ia merupakan julat kerana ia bergantung pada berapa banyak aset anda merupakan video yang memerlukan pengekodan semula untuk keserasian pelayar. Pustaka yang mengandungi fail JPEG berada di bahagian bawah julat tersebut.

Pangkalan data adalah 3 GB, dan ini hampir kepada kos tetap. Immich mendokumentasikan fail pangkalan data sebagai biasanya 1 hingga 3 GB, kerana ia menyimpan metadata dan vektor carian dan bukannya piksel. Cache model adalah 2 GB dan akan berkembang jika anda mendayakan beberapa model atau menguji model yang berbeza. FAQ menandakan volum ini sebagai pengguna ruang atas sebab tersebut.

Lima baris tersebut berjumlah sedikit lebih daripada 300 GB, jadi volum 500 GB memberikan ruang untuk berkembang manakala volum 250 GB tidak mencukupi. Pantau pembahagian tersebut dengan:

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

Enam folder berada di bawah UPLOAD_LOCATION. upload dan library menyimpan fail asal, thumbs menyimpan pratonton dan lakaran kenit wajah, encoded-video menyimpan salinan yang telah dikodkan semula, profile menyimpan avatar, dan backups menyimpan dump pangkalan data automatik. Hanya upload, library dan profile yang tidak boleh diganti, kerana semua yang lain boleh dijana semula daripadanya.

Dua perkara mengejutkan pengguna. Aset yang dipadam akan masuk ke dalam tong sampah terlebih dahulu dan terus menggunakan ruang sehingga tong sampah dikosongkan, jadi pembersihan besar-besaran tidak membebaskan ruang pada hari anda melakukannya. Dan dump pangkalan data hanyalah metadata, jadi ia tidak bernilai tanpa fail asal:

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

Gandingkan perkara itu dengan salinan fail asal pada peringkat fail ke lokasi di luar pelayan, iaitu tujuan sandaran restic dari VPS ke storan luar pelayan.

Transcoding menggunakan CPU, bukan RAM

Menambah RAM tidak akan mempercepatkan proses transcoding. Immich melakukan transcoding menggunakan FFmpeg, dan pada VPS biasa, setiap bingkai dinyahkod dan dikodkan oleh CPU. Walaupun pecutan perkakasan tersedia, dokumentasi Immich menyatakan bahawa hanya pengekodan yang dipecutkan, jadi CPU masih melakukan penyahkodan perisian dan pemetaan tona (tone mapping).

Pecutan perkakasan memerlukan fail hwaccel.transcoding.yml Compose tambahan serta peranti untuk dilalui (passthrough), menggunakan NVENC, Quick Sync, RKMPP atau VAAPI. Kebanyakan pelan VPS tidak menyediakan ciri ini, jadi rancanglah penggunaan CPU anda.

Tetapan praktikal yang perlu diubah ialah bilangan thread. Di bawah Administration, Settings, Video Transcoding Settings, nilai thread 0 bermaksud semua teras digunakan, yang boleh menyebabkan satu video membekukan antara muka web pada pelan 2 teras. Tetapkan nilai kepada 1 atau 2 di situ, seperti yang dicadangkan dalam FAQ Immich, supaya proses transcode menjadi perlahan dan bukannya mengganggu sistem.

Mengapa import yang mengalami swap thrashing kelihatan seperti sistem tergantung

Ini adalah kegagalan yang paling kerap disalah tafsir oleh pengguna. Apabila Immich kehabisan memori, terdapat dua hasil yang mungkin berlaku, dan hanya satu daripadanya kelihatan seperti kegagalan.

Tanpa swap, kernel akan mematikan proses tersebut. Kontena akan dimulakan semula dalam beberapa saat, jadi daripada pelayar web, baris gilir tugasan hanya terhenti seketika dan kemudian bersambung semula. Buktinya terdapat dalam 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) bermaksud proses tersebut dimatikan dengan isyarat 9. 137 adalah hasil tambah 128 dan 9. Nilai OOMKilled sebanyak true mengesahkan bahawa ia dimatikan kerana masalah memori dan bukannya disebabkan oleh kerosakan perisian (crash).

Dengan swap, tiada apa-apa yang dimatikan dan tiada ralat yang berlaku. Kernel mula memindahkan halaman memori ke cakera, proses import menjadi perlahan secara drastik, dan antara muka web berhenti memberi respons dalam tempoh masa tamat (timeout) biasa. Setiap kontena sedang berjalan. Setiap pemeriksaan kesihatan (health check) mungkin masih lulus. Ia kelihatan seperti sistem tergantung, dan pengguna biasanya akan but semula pelayan pada tahap ini, yang menyebabkan kemajuan baris gilir hilang dan tidak menyelesaikan masalah.

free -m
vmstat 1 5

Nilai bukan sifar yang berterusan dalam lajur si dan so pada vmstat bermaksud mesin sedang membaca dan menulis swap secara berterusan, yang merupakan definisi bagi thrashing. Baris free -m untuk penggunaan Swap akan meningkat pada masa yang sama.

Tambahkan swap pada mesin dengan 2 GB atau 4 GB RAM, kerana proses import yang perlahan dan boleh didiagnosis adalah lebih baik daripada kontena yang dimatikan tanpa sebab yang jelas:

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

Kemudian, selesaikan punca masalah tersebut. Kurangkan konkurensi tugasan kepada 1, hadkan penggunaan sumber untuk kontena pembelajaran mesin (machine learning), atau pindahkan ia ke hos lain. Swap memberikan anda masa untuk melakukan perkara tersebut. Ia bukanlah penyelesaian muktamad.

FAQ

Bolehkah saya menjalankan Immich pada VPS 2 GB?

Boleh, dengan syarat servis immich-machine-learning dinyahaktifkan dalam docker-compose.yml dan konkurensi kerja ditetapkan kepada 1. Ini adalah di bawah keperluan minimum yang didokumenkan sebanyak 6 GB, jadi anggap ia sebagai kompromi yang diketahui. Anda masih boleh memuat naik, membuat album, berkongsi, sandaran mudah alih serta mencari mengikut tarikh, lokasi dan nama fail. Anda akan kehilangan keupayaan mencari mengikut deskripsi, pengumpulan wajah secara automatik kepada individu, dan pengecaman teks dalam imej. Tambahkan fail swap sebesar 2 GB supaya lonjakan import hanya melambatkan pelayan dan bukannya menyebabkan kontena ditamatkan.

Mengapa import Immich saya terhenti tanpa mesej ralat?

Dua punca berbeza kelihatan sama daripada pelayar. Sama ada kontena ditamatkan kerana kehabisan memori, yang mana docker ps -a akan menunjukkan Exited (137) dan kontena telah dimulakan semula, atau hos sedang melakukan swapping, yang mana setiap kontena masih berjalan dan semuanya menjadi sangat perlahan. vmstat 1 5 membezakan kedua-duanya: angka bukan sifar yang berterusan dalam kolum si dan so bermakna swapping sedang berlaku. Kurangkan konkurensi kerja untuk penjanaan lakaran kecil (thumbnail), pengesanan wajah dan carian pintar dalam kedua-dua keadaan.

Apakah maksud exit code 137 dalam log Immich?

137 ialah 128 ditambah isyarat 9, bermakna proses tersebut ditamatkan dengan SIGKILL. Secara praktikal, ini bermakna had memori telah dicapai, sama ada had kontena itu sendiri atau hos kehabisan memori. Semak dengan docker inspect immich_machine_learning | grep -i oomkilled. Nilai true mengesahkan kernel menamatkan proses tersebut kerana memori, dan free -m serta sudo dmesg -T | grep -i oom-kill kemudian memberitahu anda sama ada ia disebabkan oleh had kontena atau keseluruhan hos. Kontena pembelajaran mesin (machine learning) biasanya menjadi mangsa kerana ia merupakan proses yang paling besar.

Berapakah ruang cakera yang diperlukan oleh Immich bagi setiap foto?

Peruntukkan saiz fail asal ditambah 10 hingga 20 peratus. Immich mendokumenkan bahawa lakaran kecil yang dijana dan video yang ditranskod meningkatkan saiz pustaka sebanyak 10 hingga 20 peratus secara purata, dan pangkalan data itu sendiri biasanya bersaiz 1 hingga 3 GB walaupun untuk pustaka yang besar. Video adalah faktor sebenar yang menentukan jumlah saiz anda, jadi ukur purata saiz fail anda sendiri sebelum memilih pelan dan bukannya sekadar menggunakan pengganda pada jumlah foto.

Adakah saya memerlukan GPU untuk Immich?

Tidak. Setiap bahagian Immich berjalan pada CPU. Kad grafik mempercepatkan inferens model dalam kontena pembelajaran mesin dan pengekodan video, namun kedua-duanya tidak diwajibkan. Kebanyakan pelan VPS tidak menawarkan GPU. Pada perkakasan yang hanya menggunakan CPU, tetapkan thread transkod kepada 1 atau 2, gunakan model wajah buffalo_s, dan biarkan import pukal pertama berjalan sepanjang malam.