Gaano karaming RAM at disk ang kailangan ng Immich?

Gaano karaming RAM ang kailangan ng Immich?

Nangangailangan ang Immich ng 6 GB ng RAM (random access memory) bilang documented minimum nito at 8 GB bilang rekomendasyon, sa 2 CPU cores sa pinakamababang antas at 4 para sa mas maayos na paggamit. Saklaw ng bilang na ito ang buong stack, dahil apat na container ang Immich at hindi isang application lamang. Kaunti lang ang memory na kailangan para mag-browse ng library na na-import na. Sa pag-i-import napupunta ang memory, at karamihan dito ay ginagamit ng isang container na maaari mong i-switch off.

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

Ito ang mga inilathalang bilang mula sa Immich requirements page noong August 2026. Rekomendasyon ito para sa sizing, hindi check na kailangang maipasa ng software sa startup. Nagsisimula ang Immich sa mas kaunting resource. Sa mas maliit na server, ang nagbabago ay kung aling mga background job ang matatapos at kung ano ang mangyayari sa isang import kapag naubusan ng memory.

May isang tunay na hard limit. Kailangan ng Immich version 3 at mga mas bago nito ng x86-64-v2 CPU sa amd64 hosts, na sumasaklaw sa karamihan ng mga processor na ibinenta mula noong humigit-kumulang 2012. Sa mas lumang hardware, hindi nagsisimula ang container sa halip na mabagal lang itong tumakbo.

Kung hindi mo pa sinisimulan ang pag-install, magsimula sa buong pag-install ng Immich sa isang VPS gamit ang Docker Compose at bumalik dito para i-size ang server.

Saan napupunta ang memory: apat na container

Nagsisimula ang opisyal na Compose file ng apat na serbisyo. Magkakaiba ang memory profile ng bawat isa, kaya itinatago ng isang pinagsamang total ang mahalagang detalye.

immich-server ang naghahatid ng web interface at API, at nagpapatakbo rin ito ng mga background job worker. Dalawang worker ang nasa loob ng iisang container na iyon. api ang sumasagot sa mga request mula sa browser at mobile app. microservices ang nagpapatakbo ng mga queue, kabilang ang paggawa ng thumbnail at video encoding. Hinahati ng mga variable na IMMICH_WORKERS_INCLUDE at IMMICH_WORKERS_EXCLUDE ang dalawang ito sa magkahiwalay na container. Sa ganitong paraan, mabibigyan mo ng sariling memory limit ang bahaging maraming aktibidad nang hindi nililimitahan ang bahaging naghahatid ng mga larawan mo.

database ay isang PostgreSQL 14 image na may built-in na VectorChord extension. Hawak nito ang lahat ng metadata at isang search vector para sa bawat asset. Sa Immich docs, ang serbisyong ito ang may tanging tahasang minimum requirement sa stack: kung maglalapat ka ng Docker resource limits, nangangailangan ang database ng hindi bababa sa 2 GB. Sinasabi rin sa parehong page na dapat nasa local SSD storage ang database at hindi kailanman nasa anumang uri ng network share. Ang vector at index lookup ay maliliit na random read, kaya ginagawang round trip ng network volume ang bawat isa. Kung nakasalalay dito ang pagpili ng plan, mas mahalaga rito kaysa sa iba pang bahagi ng stack ang pagkakaiba ng NVMe at SATA SSD storage sa isang VPS.

redis ang nagpapatakbo ng Valkey image at humahawak sa mga job queue. Pinakamaliit ito sa apat, at malaki ang agwat, dahil job record ang iniimbak nito sa halip na data ng larawan.

immich-machine-learning ang serbisyong nagtatakda ng laki ng plan mo. Naglo-load ito ng mga model para sa smart search, face detection, at text recognition, at nananatiling nasa memory ang na-load na model. Naka-default sa 300 ang MACHINE_LEARNING_MODEL_TTL, kaya dini-discard ang isang model pagkalipas ng limang minutong walang request at binabasa itong muli mula sa volume na /cache sa susunod na request. Sa panahon ng bulk import, walang limang minutong pagitan, kaya nananatiling naka-load ang mga model mula sa unang asset hanggang sa huli.

Mga nagbabago habang nag-i-import

Tahimik ang Immich kapag walang ginagawa. Sa mga import nagkakaproblema ang maliliit na server, dahil ang pag-upload ng isang asset ay naglalagay ng magkakasunod na job sa queue at sabay-sabay na tumatakbo ang ilang queue.

Binabasa ng metadata extraction ang file header at magaan ito. Mas mabigat ang thumbnail generation. Gumagawa ang Immich ng tatlong thumbnail output para sa bawat asset: isang blurred thumbhash placeholder, isang WebP preview, at isang JPEG thumbnail. Gumagawa rin ito ng isa pang thumbnail para sa bawat nade-detect na mukha. Bawat job ay nagde-decode ng image, at tinutukoy ng job concurrency kung ilang image ang sabay-sabay na ide-decode. Ang concurrency ang multiplier na nagpapalawak sa maliit na per-job cost hanggang maging load ito sa buong server. Kaya ito ang unang ipinapababa ng Immich FAQ sa isang limitadong machine. Itakda sa 1 ang concurrency para sa heavy queue sa Administration, Settings, Job Settings.

Nagdudulot ng transcoding ang mga video asset. Ang bawat transcode job ay hiwalay na FFmpeg process na may sariling memory, at gagamit ito ng lahat ng CPU thread na pinapayagan mo.

Ipinapadala ng Smart Search ang bawat bagong asset sa machine learning container upang kalkulahin ang isang embedding vector. Nagpapatakbo ang face detection ng ikalawang model sa parehong image. Sa unang pag-import ng dati nang photo library, pinoproseso ng dalawang queue na ito ang lahat ng asset na mayroon ka, at maaaring tumagal ito nang ilang oras. Ito ang pinakamabigat na sandali para sa memory sa buong installation, at isang beses lang itong nangyayari.

Bakit pinakamaraming RAM ang kailangan ng pagkilala sa mukha at object

Dalawang trabaho ang face handling. Nagpapatakbo ang face detection ng model sa machine learning container at hinahanap nito ang mga box. Pagkatapos, pinagbubukod ng facial recognition ang mga detection ayon sa tao, at kumokonsulta ang hakbang na ito sa vector index sa Postgres. Kaya parehong naaapektuhan ng malaking library ang dalawang serbisyo: ang model container habang tumatakbo ang detection, at ang database habang isinasagawa ang pag-group.

May apat na setting na nagbabago sa laman ng machine learning container.

• Ang face model. Bilang default, ginagamit ng Immich ang buffalo_l, at inirerekomenda ng FAQ ang buffalo_s para sa maliit na server. Mas maliit itong model, kaya mas kaunti ang memory na ginagamit at mas mabilis itong tumatakbo. Kapalit nito, mas mababa ang accuracy sa maliliit o nakatagilid na mukha.
• Ang worker count. Ang default ng MACHINE_LEARNING_WORKERS ay 1. Hiwalay na process ang bawat worker na naglo-load ng sarili nitong kopya ng mga model, kaya kapag tinaasan ito sa 2, humigit-kumulang dodoble ang resident model memory. Manatili sa 1 maliban kung may ekstrang RAM.
• Ang batch size. Nililimitahan ng MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION kung ilang mukha ang pinoproseso nang sabay. Pinananatiling nasa memory nang magkakasama ang isang batch, kaya mas malaking memory ang kailangan ng group photo na may forty na mukha kaysa sa isang portrait.
• Kung aling mga uri ng model ang aktuwal na tatakbo. May sarili nitong mga model ang smart search, face detection, at text recognition. Kapag isinara mo ang mga hindi ginagamit, sa Administration, Settings, Machine Learning Settings, tuluyang aalisin ang memory na ginagamit ng mga ito sa halip na alisin lamang ito sa pagitan ng mga import.

Mayroon ding MACHINE_LEARNING_MODEL_ARENA, na ayon sa dokumentasyon ay nagpa-pre-allocate ng CPU memory upang maiwasan ang fragmentation at naka-enable bilang default. Huli itong baguhin. Depende ang epekto nito sa memory allocator na nasa ilalim nito, kaya ang tanging maaasahang paraan para masuri ito ay i-monitor ang docker stats bago at pagkatapos.

Tatlong aktuwal na profile: 2 GB, 4 GB, at 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"
  }
]

Ituring ang mga ito bilang mga limitasyong ilalagay sa Compose, hindi bilang sukat ng aktuwal na ginagamit ng Immich. Ang limit ay ceiling lamang. Wala itong nire-reserve, at hindi nito pinapaliit ang isang service. Tinutukoy nito kung aling service ang papatayin ng kernel kapag maubusan ng resources ang server. Mas mainam na ikaw ang gumawa ng desisyong iyon kaysa ipaubaya ito sa sariling scoring ng kernel.

Ang 2 GB server: alisin ang machine learning container

Mas mababa ang 2 GB sa dokumentadong minimum na 6 GB. Kaya kompromiso ito, at dapat itong tukuyin bilang ganoon. I-comment out ang buong immich-machine-learning service sa docker-compose.yml, o panatilihin itong tumatakbo at i-disable ang bawat model sa Administration, Settings, Machine Learning Settings. Mas matibay na opsyon ang pag-alis ng container, dahil mananatiling resident ang Python process kahit naka-disable ang model.

Mananatili ang uploads, albums, sharing, mobile backup, thumbnails, at paghahanap ayon sa date, lugar, at filename. Mawawala ang paghahanap ayon sa description, awtomatikong pagpapangkat ng mga mukha bilang mga tao, at text recognition sa loob ng mga image.

Humigit-kumulang 1.7 GB ang kabuuan ng apat na limit. Nag-iiwan ito ng halos 300 MB para sa host. Tandaan na ang 768 MB para sa database ay mas mababa sa dokumentadong 2 GB floor. Ito mismo ang kompromisong ipinipilit ng 2 GB. Kaya ang Postgres ang service na pinakamalamang na mapatay dito.

Ang unang maaapektuhan ay ang import, hindi ang pag-browse. Katanggap-tanggap ang pag-browse sa library na nasa mababang sampu-sampung libong photo kapag na-import na ito, dahil ang paghahatid ng page ay metadata query at file read lamang. Magkakaroon ng swap ang server kapag sabay na nagsasagawa ng mabigat na video import, dahil kailangan ng transcode at thumbnail queue ang memory sa parehong oras. Itakda sa concurrency 1 ang bawat heavy queue at magdagdag ng swap file.

Ang 4 GB server: naka-enable ang machine learning, isang job sa bawat pagkakataon

Ang 4 GB ang pinakamaliit na laki kung saan sulit nang i-enable ang face at object recognition. Limitahan ang machine learning container sa 0 MB, ilipat ang facial recognition sa buffalo_s, at itakda sa 1 ang job concurrency para sa thumbnail generation, face detection, at smart search.

Tatagal nang maraming oras ang unang pagproseso sa kasalukuyang library. Sa malaking library, maaari itong lumampas sa isang araw. CPU limit ito, hindi memory limit. Kaya hindi ito paiikliin ng karagdagang RAM.

Ang unang maaapektuhan dito ay ang machine learning container habang isinasagawa ang unang bulk pass. Kapag walang limit, lumalaki ito habang lumalaki rin ang isang transcode job, at pinapatay ng kernel ang mas malaki sa dalawa. Makikita mo ang Exited (137) sa docker ps -a at ang isang nag-restart na container. Tahimik ding mas mahuhuli ang queue kaysa noong huli mo itong sinuri.

Ang 8 GB server: ang dokumentadong rekomendasyon

Ang 8 GB na may 4 cores ay tumutugma sa rekomendasyon ng Immich. Tumatakbo ang lahat gamit ang default settings: smart search, face detection, text recognition, at transcoding, na may default concurrency. Komportable rito ang mga library na lampas isang daang libong asset. Lumilipat ang pressure mula sa memory papunta sa bilis ng disk, dahil buong araw na pinoproseso ng database ang vector index at metadata queries.

Itakda pa rin ang mga limit. Sa server na may sapat na resources, pinipigilan ng mga limit na ibagsak ng isang runaway queue ang database. Kung ikinukumpara mo ang gastos nito sa mas maliliit na opsyon, ang aktuwal na gastos ng isang VPS ayon sa memory tier ang karaniwang nagpapakitang ang 8 GB plan ang pinakamurang paraan para maiwasan ang patuloy na pag-tune.

Paano magtakda ng memory cap sa bawat service gamit ang Compose limits

Huwag i-edit ang docker-compose.yml para dito. Pinapalitan ang file na iyon sa bawat pag-upgrade gamit ang wget. Ilagay ang mga limit sa docker-compose.override.yml sa tabi nito. Awtomatikong pinagsasama ito ng 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

Dapat nang ipakita ng docker stats ang itinakda mong ceiling sa column na MEM USAGE / LIMIT sa halip na ang kabuuang memory ng host. Kung buong laki pa rin ng host ang nakalagay sa limit column, hindi nabasa ang override file. Suriin ang file name at patakbuhin ang docker compose config upang makita ang pinagsamang resulta.

Kapag masyadong mababa ang limit, maaaring tuluyang huminto ang mabagal na service. Itaas ang limit kung paulit-ulit na nagre-restart ang container. Higit pang detalye tungkol sa mechanics ang nasa pagtatakda ng memory limits sa bawat service sa Docker Compose, kabilang kung bakit gumagana ang deploy sa labas ng Swarm gamit ang Compose v2.

Paano i-off o ilipat ang machine learning container

Sa maliit na server, ang paglipat ng container na ito sa ibang lugar ang pinakamalaking pagbabagong maaari mong gawin. Sinusuportahan ng Immich ang pagpapatakbo nito sa ibang machine. Gawin ang file na ito sa pangalawang host, na maaaring isang desktop na binubuksan lamang tuwing gabi:

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

Pagkatapos, pumunta sa Administration, Settings, Machine Learning Settings sa web interface, i-click ang Add URL, at ilagay ang http://<host>:3003. Panatilihing pareho ang version sa dalawang host, dahil nagbababala ang Immich docs na nagdudulot ng mga bug at instability ang hindi pagtutugma ng version ng mga ito.

Dahil ipinapadala ng port na ito ang iyong mga larawan sa kabilang machine nang walang encryption, panatilihin ito sa private network o patakbuhin ito sa WireGuard tunnel sa pagitan ng dalawang host. Huwag kailanman ilantad ang 3003 sa internet.

Kung ang mismong pagkakaroon ng resident model container ang problema, makatuwiran ding ikumpara muna ang pagkakaiba ng PhotoPrism at Immich sa mga component na tumatakbo habang idle bago magpasya sa isang plan size.

Gaano karaming disk space ang kailangan ng Immich library?

Walang iisang multiplier, dahil apat na magkakaibang bagay ang lumalaki sa magkakaibang bilis. Narito ang kalkulasyon para sa library na may 50,000 photos at 500 maiikling video.

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

Mga palagay ang 200 GB na photos at 60 GB na video. Palitan ang mga ito batay sa sarili mong average bago bumili ng storage, dahil ang video ang nagpapasya sa bilang na ito: mas malaki ang isang minuto ng phone video kaysa sa isang daang photos.

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

Ang 39 GB na row ang tanging published ratio na ibinibigay ng Immich: ang generated thumbnails at transcoded video ay karaniwang nagdaragdag ng 10 hanggang 20 porsiyento sa laki ng library. Saklaw ito dahil nakadepende sa dami ng assets na video at kailangang i-re-encode para sa browser compatibility. Ang library na puro JPEG ay karaniwang malapit sa ibabang dulo ng saklaw na iyon.

Ang database ay 3 GB, at halos fixed cost ito. Idinodokumento ng Immich na karaniwang 1 hanggang 3 GB ang database files, dahil metadata at search vectors ang laman ng mga ito, hindi pixels. Ang model cache ay 2 GB at lalaki kung mag-enable ka ng ilang model o magsubok ng iba’t ibang model. Tinutukoy ng FAQ ang volume na ito bilang kumokonsumo ng space dahil mismo sa kadahilanang iyon.

Kapag pinagsama, bahagyang higit sa 300 GB ang limang row. Kaya may puwang pang lumaki ang isang 500 GB volume, samantalang hindi sapat ang 250 GB volume. Subaybayan ang paghahati ng space gamit ang:

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

Anim na folder ang nasa ilalim ng UPLOAD_LOCATION. Nasa upload at library ang originals, nasa thumbs ang previews at face thumbnails, nasa encoded-video ang mga re-encoded copy, nasa profile ang avatars, at nasa backups ang automatic database dumps. Tanging upload, library at profile ang hindi maaaring palitan, dahil nire-regenerate mula sa mga ito ang lahat ng iba pa.

Dalawang bagay ang madalas ikinagugulat ng mga tao. Nauuna munang mapunta sa trash ang mga dinelete na asset at nananatili roon ang space na ginagamit ng mga ito hanggang sa ma-empty ang trash. Kaya walang space na agad nababawi sa araw ng cleanup. At metadata lamang ang laman ng database dump, kaya walang silbi ito kung wala ang mga file:

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

Ipares ito sa file-level copy ng originals sa isang lokasyong nasa labas ng server. Ito ang gamit ng restic backups mula sa VPS papunta sa off-server storage.

Ang transcoding ay gumagamit ng CPU, hindi RAM

Hindi bibilis ang transcoding kapag nagdagdag ka ng RAM. Gumagamit ang Immich ng FFmpeg para sa transcoding, at sa karaniwang VPS, ang CPU ang nagde-decode at nag-e-encode ng bawat frame. Kahit may available na hardware acceleration, ayon sa dokumentasyon ng Immich, encoding lamang ang pinapabilis nito. Software decoding at tone mapping pa rin ang ginagawa ng CPU.

Kailangan ng hardware acceleration ang karagdagang hwaccel.transcoding.yml Compose file at isang device na ipapasa, gamit ang NVENC, Quick Sync, RKMPP, o VAAPI. Kadalasan, walang ganitong device ang mga VPS plan. Kaya magplano batay sa kapasidad ng CPU.

Ang praktikal na setting ay ang thread count. Sa Administration, Settings, Video Transcoding Settings, ang thread value na 0 ay nangangahulugang lahat ng core. Dahil dito, maaaring ma-freeze ng isang video ang web interface sa 2 core plan. Itakda ito sa 1 o 2, gaya ng mungkahi sa Immich FAQ. Sa ganitong paraan, magiging mabagal ang transcoding sa halip na makaistorbo sa ibang serbisyo.

Bakit mukhang nag-hang ang import dahil sa swap thrashing

Ito ang failure na pinakamadalas maling nababasa ng mga tao. Kapag naubusan ng memory ang Immich, may dalawang posibleng resulta, at isa lamang sa mga ito ang mukhang failure.

Kapag walang swap, pinapatay ng kernel ang isang process. Nire-restart ang container sa loob ng ilang segundo, kaya sa browser ay tumitigil lang ang job queue at pagkatapos ay nagpapatuloy. Makikita ang ebidensiya sa 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'

Ang Exited (137) ay nangangahulugang pinatay ang process gamit ang signal 9. Ang 137 ay 128 plus 9. Kinukumpirma ng value na true ng OOMKilled na pinatay ito dahil sa memory, hindi dahil sa crash.

Kapag may swap, walang napapatay at walang nag-e-error. Sinisimulan ng kernel na ilipat ang mga page sa disk, bumabagal nang sampung beses ang import, at hindi na sumasagot ang web interface sa loob ng normal na timeout. Tumatakbo ang bawat container. Maaari pa ring pumasa ang bawat health check. Para itong nag-hang, kaya nire-reboot ng mga tao ang server sa puntong ito. Nawawala ang progreso ng queue, at walang nagbabago.

free -m
vmstat 1 5

Ang patuloy na non-zero na mga value sa mga column na si at so ng vmstat ay nangangahulugang patuloy na nagbabasa at nagsusulat sa swap ang machine. Ito ang tinatawag na thrashing. Kasabay nito, tataas ang row na free -m para sa Swap na ginagamit.

Magdagdag pa rin ng swap sa isang box na may 2 GB o 4 GB, dahil mas mainam nang ma-diagnose ang mabagal na import kaysa sa container na na-kill at hindi mo na maaayos:

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

Pagkatapos, ayusin ang sanhi. Ibaba sa 1 ang job concurrency, lagyan ng limit ang machine learning container, o ilipat ito sa ibang host. Binibigyan ka ng swap ng oras para gawin iyon. Hindi ito sapat na solusyon nang mag-isa.

FAQ

Maaari ko bang patakbuhin ang Immich sa isang 2 GB VPS?

Oo, kung naka-comment out ang immich-machine-learning service sa docker-compose.yml at nakatakda sa 1 ang job concurrency. Mas mababa ito sa dokumentadong minimum na 6 GB, kaya ituring itong tinatanggap na compromise. Magagamit mo pa rin ang uploads, albums, sharing, mobile backup, at paghahanap ayon sa petsa, lugar, at filename. Mawawala ang paghahanap ayon sa description, awtomatikong pagpapangkat ng mga mukha bilang mga tao, at text recognition sa loob ng mga image. Magdagdag ng 2 GB swap file upang bumagal ang server kapag may biglang pagtaas ng import load, sa halip na ma-kill ang isang container.

Bakit humihinto ang Immich import ko nang walang error message?

Dalawang magkaibang sanhi ang maaaring magmukhang pareho sa browser. Maaaring na-kill ang isang container dahil sa kakulangan ng memory; sa ganitong kaso, ipinapakita ng docker ps -a ang Exited (137) at nakapag-restart na ang container. Maaari ring nag-swap ang host; sa ganitong kaso, tumatakbo pa rin ang lahat ng container at napakabagal lang ng buong system. Pinaghihiwalay ng vmstat 1 5 ang dalawang sitwasyon: ang tuloy-tuloy na non-zero na mga value sa mga column na si at so ay nangangahulugang nagso-swap ang system. Bawasan ang job concurrency para sa thumbnail generation, face detection, at smart search sa alinmang sitwasyon.

Ano ang ibig sabihin ng exit code 137 sa Immich logs?

Ang 137 ay 128 dagdag ang signal 9, kaya na-kill ang process gamit ang SIGKILL. Sa aktuwal, nangangahulugan ito na naabot ang memory ceiling, maaaring limit ng container mismo o pagkaubos ng memory ng host. Suriin ito gamit ang docker inspect immich_machine_learning | grep -i oomkilled. Kinukumpirma ng value na true na na-kill ito ng kernel dahil sa memory. Ipinapakita naman ng free -m kasama ng sudo dmesg -T | grep -i oom-kill kung limit ng container o buong host ang sanhi. Karaniwang naaapektuhan ang machine learning container dahil ito kadalasan ang pinakamalaking process.

Gaano kalaking disk space ang kailangan ng Immich bawat photo?

Maglaan ng space para sa original file, kasama ang 10 hanggang 20 porsiyento. Ayon sa dokumentasyon ng Immich, ang generated thumbnails at transcoded video ay karaniwang nagdaragdag ng 10 hanggang 20 porsiyento sa library size. Karaniwan ding umaabot sa 1 hanggang 3 GB ang database kahit malaki ang library. Ang video ang aktuwal na pangunahing nagpapasya sa kabuuang kailangan mong space. Kaya sukatin ang sarili mong average file size bago pumili ng plan, sa halip na maglapat ng multiplier sa dami ng photo.

Kailangan ko ba ng GPU para sa Immich?

Hindi. Tumatakbo sa CPU ang bawat bahagi ng Immich. Pinabibilis ng graphics card ang model inference sa machine learning container at ang video encoding, pero hindi kinakailangan ang alinman sa mga ito. Karamihan sa VPS plan ay walang GPU. Sa hardware na CPU-only, itakda sa 1 o 2 ang transcoding threads, gamitin ang buffalo_s face model, at hayaang tumakbo nang magdamag ang unang bulk import.