Immich inahitaji RAM na diski kiasi gani?

Immich inahitaji kiasi gani cha RAM?

Immich inahitaji 6 GB ya RAM (random access memory) kama kiwango cha chini kilichoelekezwa na 8 GB kama pendekezo, ikiwa na 2 CPU cores kwa kiwango cha chini na 4 kwa usakinishaji wa kawaida. Takwimu hiyo inajumuisha stack nzima, kwa sababu Immich ni kontena nne badala ya programu moja. Kuvinjari maktaba ambayo tayari imeshaingizwa (imported) hakuhitaji rasilimali nyingi. Kumbukumbu hutumika wakati wa kuingiza data, na sehemu kubwa hutumiwa na kontena moja ambalo unaweza kulizima.

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

Hizo ni takwimu zilizochapishwa kutoka ukurasa wa mahitaji ya Immich kufikia Agosti 2026. Ni pendekezo la ukubwa, si kizuizi cha programu kuanza. Immich inaweza kuanza ikiwa na RAM ndogo zaidi. Kinachobadilika kwenye seva ndogo ni kazi za nyuma (background jobs) zinazokamilika, na kinachotokea wakati wa kuingiza data (import) kumbukumbu inapoisha.

Kuna kizuizi kimoja cha kweli. Immich toleo la 3 na kuendelea inahitaji CPU yenye x86-64-v2 kwenye seva za amd64, ambayo inajumuisha vichakataji vingi vilivyouzwa tangu mwaka 2012 hivi. Kwenye vifaa vya zamani, kontena hushindwa kuanza badala ya kufanya kazi polepole.

Ikiwa bado hujasakinisha, anza na usakinishaji kamili wa Immich kwenye VPS kwa kutumia Docker Compose kisha urudi hapa kupanga ukubwa wa seva yako.

Mahali ambapo kumbukumbu hutumika: kontena nne

Faili rasmi ya Compose inaanza huduma nne. Kila moja ina umbo tofauti la kumbukumbu, kwa hivyo nambari moja ya jumla huficha sehemu muhimu.

immich-server inahudumia kiolesura cha wavuti na API, na pia inaendesha wafanyakazi wa kazi za nyuma (background job workers). Wafanyakazi wawili wanaishi ndani ya kontena hilo moja. api inajibu maombi kutoka kwa kivinjari na programu ya simu. microservices inaendesha foleni, ikijumuisha utengenezaji wa vijipicha na usimbaji wa video. Vigezo IMMICH_WORKERS_INCLUDE na IMMICH_WORKERS_EXCLUDE hugawanya hayo mawili katika kontena tofauti, ambayo ndiyo njia unayoweza kuipa nusu yenye shughuli nyingi kikomo chake cha kumbukumbu bila kuzuia nusu inayohudumia picha zako.

database ni image ya PostgreSQL 14 yenye extension ya VectorChord iliyojengwa ndani. Inashikilia kila kipande cha metadata na vector moja ya utafutaji kwa kila kipengee. Nyaraka za Immich zinatoa huduma hii sakafu pekee iliyo wazi katika stack: ukiweka vikomo vya rasilimali vya Docker, database inahitaji angalau 2 GB. Ukurasa huo huo unasema database lazima ikae kwenye hifadhi ya ndani ya SSD na kamwe isiwe kwenye network share ya aina yoyote, kwa sababu utafutaji wa vector na index ni usomaji mdogo wa nasibu, kwa hivyo network volume hugeuza kila moja kuwa safari ya kwenda na kurudi. Ikiwa chaguo la mpango linategemea hilo, tofauti kati ya hifadhi ya NVMe na SATA SSD kwenye VPS ni muhimu zaidi hapa kuliko mahali pengine popote katika stack hii.

redis inaendesha image ya Valkey na inashikilia foleni za kazi. Hii ndiyo ndogo zaidi kati ya nne kwa kiasi kikubwa, kwa sababu inahifadhi rekodi za kazi badala ya data ya picha.

immich-machine-learning ndiyo huduma inayoamua ukubwa wa mpango wako. Inapakia mifano (models) kwa ajili ya utafutaji mahiri, utambuzi wa nyuso na utambuzi wa maandishi, na mfano uliopakiwa hukaa kwenye kumbukumbu. MACHINE_LEARNING_MODEL_TTL ina thamani chaguo-msingi ya 300, kwa hivyo mfano huondolewa baada ya dakika tano bila maombi na kusomwa tena kutoka kwa volume ya /cache kwenye ombi linalofuata. Wakati wa uingizaji wa data kwa wingi (bulk import) hakuna pengo la dakika tano, kwa hivyo mifano hukaa ikiwa imepakiwa kuanzia kipengee cha kwanza hadi cha mwisho.

Mabadiliko yanayotokea wakati wa import

Immich ikiwa haitumiki huwa kimya. Import ndipo seva ndogo zinaposhindwa kufanya kazi, kwa sababu kupakia faili moja huanzisha msururu wa kazi (jobs) na foleni kadhaa hufanya kazi kwa wakati mmoja.

Utoaji wa metadata husoma kichwa cha faili (file header) na ni kazi nyepesi. Utengenezaji wa thumbnail ni mzito zaidi. Immich hutengeneza matokeo matatu ya thumbnail kwa kila asset: placeholder ya thumbhash iliyofifishwa, preview ya WebP, na thumbnail ya JPEG, pamoja na thumbnail moja zaidi kwa kila uso unaotambuliwa. Kila moja ya kazi hizi hufungua (decode) picha, na concurrency ya kazi huamua ni ngapi zinafanyika kwa wakati mmoja. Concurrency ndiyo kigezo kinachobadilisha gharama ndogo ya kila kazi kuwa mzigo mkubwa kwa seva nzima, ndiyo maana FAQ ya Immich inaitaja kama kitu cha kwanza kupunguza kwenye mashine yenye rasilimali chache. Weka concurrency ya foleni nzito kuwa 1 chini ya Administration, Settings, Job Settings.

Assets za video huongeza transcoding. Kila kazi ya transcode ni mchakato wa FFmpeg unaojitegemea wenye kumbukumbu yake, na itatumia kila thread ya CPU unayoiruhusu.

Smart search hutuma kila asset mpya kwenye container ya machine learning ili kukokotoa vector moja ya embedding. Face detection huendesha model ya pili kwenye picha hiyo hiyo. Wakati wa import ya kwanza ya maktaba ya picha zilizopo, foleni zote mbili hufanya kazi kwenye kila asset unayomiliki, kwa saa kadhaa. Huo ndio wakati mgumu zaidi kwa kumbukumbu (memory) katika usakinishaji mzima, na hutokea mara moja tu.

Kwa nini utambuzi wa nyuso na vitu unahitaji RAM nyingi

Ushughulikiaji wa nyuso ni kazi mbili. Utambuzi wa nyuso (face detection) huendesha modeli katika container ya machine learning na kutafuta visanduku. Utambuzi wa sura (facial recognition) kisha hupanga utambuzi huo katika watu, na hatua hiyo huuliza (query) index ya vector katika Postgres. Kwa hivyo, maktaba kubwa huweka shinikizo kwenye huduma zote mbili kwa zamu: container ya modeli wakati utambuzi unafanyika, kisha hifadhidata wakati upangaji unafanyika.

Mipangilio minne hubadilisha kile ambacho container ya machine learning hushikilia.

• Modeli ya uso. Immich husafirisha buffalo_l kwa chaguo-msingi, na FAQ inapendekeza buffalo_s kwenye seva ndogo. Hii ni modeli ndogo zaidi, kwa hivyo inachukua kumbukumbu kidogo na inaenda haraka, kwa gharama ya usahihi kwenye nyuso ndogo au za pembeni.
• Idadi ya wafanyakazi (worker count). MACHINE_LEARNING_WORKERS ina thamani ya msingi ya 1. Kila mfanyakazi ni mchakato tofauti unaopakia nakala yake ya modeli, kwa hivyo kuiongeza hadi 2 takriban mara mbili ya kumbukumbu ya modeli inayokaa kwenye RAM. Iache kwenye 1 isipokuwa kama una RAM ya ziada.
• Ukubwa wa kundi (batch size). MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION huweka kikomo cha nyuso ngapi zinashughulikiwa kwa wakati mmoja. Kundi hushikiliwa kwenye kumbukumbu pamoja, kwa hivyo picha ya kikundi yenye nyuso arobaini hugharimu zaidi kuliko picha ya mtu mmoja.
• Ni aina zipi za modeli zinazoendeshwa. Utafutaji mahiri (smart search), utambuzi wa nyuso, na utambuzi wa maandishi kila moja hupakia modeli zake. Kuzima zile ambazo hutumii, chini ya Administration, Settings, Machine Learning Settings, huondoa kumbukumbu zao kabisa badala ya kati ya import.

Pia kuna MACHINE_LEARNING_MODEL_ARENA, iliyoandikwa kama inayotenga mapema (pre-allocating) kumbukumbu ya CPU ili kuepuka kugawanyika (fragmentation) na imewashwa kwa chaguo-msingi. Ibadilishe mwisho. Athari yake inategemea kigawaji cha kumbukumbu (memory allocator) kilicho chini, kwa hivyo njia pekee ya kweli ya kuijaji ni kufuatilia docker stats kabla na baada ya kuibadilisha.

Profaili tatu zilizosanidiwa: 2 GB, 4 GB na 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"
  }
]

Zichukulie hizi kama vikomo vya kuingiza kwenye Compose, si vipimo vya kile Immich inachotumia. Kikomo ni ukomo wa juu. Hakihifadhi chochote, na hakifanyi huduma kuwa ndogo. Huamua ni huduma ipi kernel itakayoifunga seva ikikosa kumbukumbu, na hilo ni uamuzi bora kufanywa na wewe kuliko na mfumo wa alama wa kernel yenyewe.

Seva ya 2 GB: ondoa kontena la machine learning

2 GB iko chini ya kiwango cha chini kilichopendekezwa cha 6 GB, kwa hivyo huu ni uamuzi wa kupunguza ubora na ni vyema kutambua hivyo. Toa maoni (comment out) huduma nzima ya immich-machine-learning katika docker-compose.yml, au iache ikiwaka huku ukiizima kila model chini ya Administration, Settings, Machine Learning Settings. Kuondoa kontena ndiyo chaguo bora zaidi, kwa sababu model iliyozimwa bado huacha mchakato wa Python ukiendelea kukaa kwenye kumbukumbu.

Utahifadhi uwezo wa kupakia picha, albamu, kushiriki, backup ya simu, thumbnails, na utafutaji kwa tarehe, mahali na jina la faili. Utapoteza utafutaji kwa maelezo, upangaji wa kiotomatiki wa nyuso kuwa watu, na utambuzi wa maandishi ndani ya picha.

Vikomo vinne vinajumlisha takriban 1.7 GB, jambo linaloiachia seva takriban 300 MB. Kumbuka kuwa 768 MB kwa ajili ya database iko chini ya kiwango cha chini cha 2 GB kilichopendekezwa. Hiyo ndiyo hasa hali ya kupunguza ubora inayolazimishwa na 2 GB, na ndiyo sababu Postgres ndiyo huduma inayoweza kufungwa zaidi hapa.

Kinachoharibika kwanza ni uingizaji wa picha (import), si kuvinjari. Maktaba yenye makumi ya maelfu ya picha huvinjarika vizuri mara tu inapokamilika, kwa sababu kuonyesha ukurasa ni swali la metadata pamoja na kusoma faili. Uingizaji wa video nyingi kwenye seva hiyo hiyo utasababisha swap, kwa sababu transcode na foleni ya thumbnail huhitaji kumbukumbu kwa wakati mmoja. Weka kila foleni nzito kwenye concurrency 1 na uongeze swap file.

Seva ya 4 GB: machine learning imewashwa, kazi moja kwa wakati mmoja

4 GB ndiyo ukubwa mdogo zaidi ambapo utambuzi wa nyuso na vitu unafaa kuwashwa. Weka kikomo cha kontena la machine learning kwenye 0 MB, badilisha utambuzi wa nyuso kuwa buffalo_s, na uweke job concurrency kuwa 1 kwa ajili ya utengenezaji wa thumbnail, utambuzi wa nyuso na utafutaji mahiri.

Mzunguko wa kwanza wa kuchanganua maktaba iliyopo utachukua saa nyingi, na kwenye maktaba kubwa utachukua zaidi ya siku moja. Hilo ni kikomo cha CPU badala ya kumbukumbu, kwa hivyo RAM zaidi haitaufanya mchakato huo kuwa mfupi.

Kinachoharibika kwanza hapa ni kontena la machine learning wakati wa mzunguko huo wa kwanza wa wingi. Bila kikomo, hukua huku kazi ya transcode nayo ikikua, na kernel huifunga ile inayotumia kumbukumbu nyingi zaidi. Unaona Exited (137) katika docker ps -a na kontena lililoanzishwa upya, huku foleni ikiwa imebaki nyuma zaidi kuliko ulivyoiacha mara ya mwisho.

Seva ya 8 GB: pendekezo lililoandikwa rasmi

8 GB ikiwa na 4 cores inalingana na kile Immich inachopendekeza, na kila kitu hufanya kazi kwa mipangilio ya kawaida: utafutaji mahiri, utambuzi wa nyuso, utambuzi wa maandishi na transcoding, kwa concurrency ya kawaida. Maktaba zinazozidi laki moja ya vitu hufanya kazi vizuri hapa, na shinikizo huhama kutoka kumbukumbu kwenda kasi ya diski, kwa sababu vector index na maswali ya metadata ndiyo mambo ambayo database inafanya siku nzima.

Weka vikomo hata hivyo. Kwenye seva yenye nafasi, vikomo huzuia foleni moja inayokimbia ovyo isiharibu database nzima. Ikiwa unalinganisha bei hii na chaguzi ndogo, gharama halisi ya VPS kulingana na kiwango cha kumbukumbu kwa kawaida hufanya mpango wa 8 GB kuwa njia rahisi zaidi ya kuacha kuhangaika na marekebisho.

Jinsi ya kupunguza matumizi ya kumbukumbu kwa kila huduma kwa kutumia limits za Compose

Usihariri docker-compose.yml kwa ajili ya hili. Faili hilo hubadilishwa kila unapofanya upgrade kwa kutumia wget. Weka mipaka hiyo kwenye docker-compose.override.yml kando yake, ambayo docker compose huiunganisha kiotomatiki.

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 sasa inapaswa kuonyesha ukomo wako katika safu ya MEM USAGE / LIMIT badala ya jumla ya kumbukumbu ya seva pangaji (host). Ikiwa safu ya ukomo bado inaonyesha ukubwa kamili wa seva pangaji, faili la override halikuchukuliwa: kagua jina la faili na uendeshe docker compose config ili kuona matokeo yaliyounganishwa.

Ukomo uliowekwa chini sana hugeuza huduma inayofanya kazi polepole kuwa huduma iliyokufa, kwa hivyo uongeze ikiwa container inaanza kujianzisha upya mara kwa mara. Kuna maelezo zaidi kuhusu utaratibu huu katika kuweka mipaka ya kumbukumbu kwa kila huduma katika Docker Compose, ikijumuisha sababu kwa nini deploy inafanya kazi nje ya Swarm na Compose v2.

Jinsi ya kuzima au kuhamisha kontena la machine learning

Kwenye seva ndogo, kuhamisha kontena hili kwenda sehemu nyingine ndilo badiliko kubwa zaidi unaloweza kufanya. Immich inaruhusu kuliendesha kwenye mashine nyingine. Tengeneza faili hili kwenye host ya pili, ambayo inaweza kuwa kompyuta ya mezani inayowashwa nyakati za jioni pekee:

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

Kisha nenda kwenye Administration, Settings, Machine Learning Settings katika kiolesura cha wavuti, bofya Add URL, na uweke http://<host>:3003. Hakikisha toleo (version) ni sawa kwenye host zote mbili, kwa sababu nyaraka za Immich zinaonya kuwa kutofautiana kwa matoleo kati ya hizo mbili husababisha hitilafu na kutokuwa thabiti kwa mfumo.

Port hiyo husafirisha picha zako kwenda kwenye mashine nyingine bila encryption, kwa hivyo iweke kwenye mtandao wa ndani (private network) au iendeshe kupitia tunnel ya WireGuard kati ya host hizo mbili. Usiweke kamwe port 3003 kwenye Internet.

Ikiwa wazo zima la kuwa na kontena la model linaloendelea kufanya kazi ndilo tatizo, hilo pia ni sababu nzuri ya kulinganisha jinsi PhotoPrism na Immich zinavyotofautiana katika kile zinachoendesha wakati zimetulia kabla ya kuamua mpango wa ukubwa wa seva.

Immich library inahitaji nafasi kiasi gani ya diski?

Hakuna kigezo kimoja cha kuzidisha, kwa sababu vitu vinne tofauti hukua kwa viwango vinne tofauti. Hii hapa ni hesabu ya library yenye picha 50,000 na video fupi 500.

[
  {
    "label": "Originals: 50,000 photos at 4 MB",
    "gb": 200
  },
  {
    "label": "Originals: 500 videos at 120 MB",
    "gb": 60
  },
  {
    "label": "Thumbnails and encoded video at 15%",
    "gb": 39
  },
  {
    "label": "Postgres database",
    "gb": 3
  },
  {
    "label": "Machine learning model cache",
    "gb": 2
  }
]

200 GB ya picha na 60 GB ya video ni makadirio tu. Badilisha namba hizi na wastani wako kabla ya kununua chochote, kwa sababu video ndiyo huamua namba hii: dakika moja ya video ya simu ni kubwa kuliko picha mia moja.

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

Safu ya 39 GB ndiyo uwiano pekee uliotolewa na Immich: thumbnails zinazozalishwa na video zilizobadilishwa mfumo (transcoded) huongeza asilimia 10 hadi 20 ya ukubwa wa library kwa wastani. Hii ni makadirio ya masafa kwa sababu inategemea ni kiasi gani cha maudhui yako ni video inayohitaji kubadilishwa mfumo ili iendane na vivinjari. Library yenye picha za JPEG huwa karibu na mwisho wa chini wa masafa hayo.

Database ni 3 GB, na hiyo ni karibu na gharama isiyobadilika. Immich inaeleza kuwa faili za database kwa kawaida ni 1 hadi 3 GB, kwa sababu huhifadhi metadata na search vectors badala ya pixels. Model cache ni 2 GB na hukua ukiamsha models kadhaa au ukijaribu tofauti. FAQ inaashiria kiasi hiki kama mtumiaji wa nafasi kwa sababu hiyo hiyo.

Safu tano hizo jumla yake ni zaidi kidogo ya 300 GB, kwa hivyo volume ya 500 GB huacha nafasi ya kukua na volume ya 250 GB haitoshi. Fuatilia mgawanyo huu kwa:

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

Folder sita hukaa chini ya UPLOAD_LOCATION. upload na library huhifadhi faili asilia, thumbs huhifadhi previews na thumbnails za nyuso, encoded-video huhifadhi nakala zilizobadilishwa mfumo, profile huhifadhi avatars, na backups huhifadhi dumps za database za kiotomatiki. Ni upload, library na profile pekee ambazo haziwezi kubadilishwa, kwa kuwa kila kitu kingine huzalishwa upya kutoka hapo.

Vitu viwili huwashangaza watu. Maudhui yaliyofutwa huenda kwenye trash kwanza na kuendelea kutumia nafasi hadi trash itakapofutwa, kwa hivyo usafishaji mkubwa haufungui nafasi yoyote siku unayoufanya. Na dump ya database ni metadata pekee, kwa hivyo haina thamani bila faili zenyewe:

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

Oanisha hilo na nakala ya faili asilia kwenye kiwango cha faili mahali fulani nje ya seva, ambayo ndiyo kazi ya restic backups kutoka VPS kwenda hifadhi ya nje ya seva.

Transcoding hutumia CPU, si RAM

Kuongeza RAM hakutafanya transcoding kuwa ya haraka. Immich hufanya transcoding kwa kutumia FFmpeg, na kwenye VPS ya kawaida kila fremu husimbuliwa (decoded) na kusimbwa (encoded) na CPU. Hata pale ambapo hardware acceleration inapatikana, Immich inaeleza kuwa encoding pekee ndiyo inayoharakishwa, hivyo CPU bado hufanya software decoding na tone mapping.

Hardware acceleration inahitaji faili la ziada la hwaccel.transcoding.yml Compose pamoja na kifaa cha kupitisha (pass through), kwa kutumia NVENC, Quick Sync, RKMPP au VAAPI. Mipango mingi ya VPS haikupi chochote kati ya hivyo, kwa hivyo panga kutumia CPU.

Mpangilio wa kiutendaji ni idadi ya thread. Chini ya Administration, Settings, Video Transcoding Settings, thamani ya thread ikiwa 0 inamaanisha cores zote, jambo linaloweza kufanya video moja ifungie interface ya wavuti kwenye mpango wa 2 core. Iweke iwe 1 au 2 hapo, kama FAQ ya Immich inavyopendekeza, na transcode itakuwa ya polepole badala ya kusababisha usumbufu.

Kwa nini uingizaji wa data unaokwama kwenye swap unaonekana kama mfumo umeganda

Hili ndilo kosa ambalo watu wengi hulitafsiri vibaya. Wakati Immich inapoishiwa na kumbukumbu (RAM), kuna matokeo mawili, na moja tu kati ya hayo ndilo linaloonekana kama hitilafu.

Bila swap, kernel huua mchakato (process). Container huanza upya ndani ya sekunde chache, kwa hivyo kwenye kivinjari, foleni ya kazi husimama tu na kisha kuendelea. Ushahidi unapatikana katika 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) inamaanisha mchakato uliua kwa signal 9. 137 ni 128 jumlisha 9. Thamani ya OOMKilled ya true inathibitisha kuwa iliuawa kwa sababu ya kumbukumbu badala ya kuanguka (crash).

Ukiwa na swap, hakuna kinachouawa na hakuna hitilafu inayotokea. Kernel huanza kuhamisha kurasa (pages) kwenye diski, uingizaji wa data hupungua kasi kwa kiasi kikubwa, na kiolesura cha wavuti huacha kujibu ndani ya muda wa kawaida wa kusubiri (timeout). Kila container inaendelea kufanya kazi. Kila ukaguzi wa afya (health check) unaweza bado kufaulu. Inaonekana kama mfumo umeganda, na watu huwasha upya seva katika hatua hii, jambo ambalo hupoteza maendeleo ya foleni na halibadilishi chochote.

free -m
vmstat 1 5

Thamani zisizo sifuri zinazoendelea katika safu wima za si na so za vmstat inamaanisha kuwa mashine inasoma na kuandika kwenye swap mfululizo, ambayo ndiyo ufafanuzi wa thrashing. Safu ya free -m ya Swap inayotumika itakuwa ikipanda wakati huo huo.

Ongeza swap hata hivyo kwenye mashine ya 2 GB au 4 GB, kwa sababu uingizaji wa data wa polepole unaoweza kuutambua ni bora kuliko container iliyouawa ambayo huwezi kuigundua:

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

Kisha rekebisha chanzo cha tatizo. Punguza concurrency ya kazi hadi 1, wekea kikomo container ya machine learning, au iondoe kwenye host hii. Swap inakupa muda wa kufanya hivyo. Sio suluhisho pekee.

FAQ

Je, ninaweza kuendesha Immich kwenye VPS ya 2 GB?

Ndiyo, kwa kutoa maoni (comment out) huduma ya immich-machine-learning kutoka kwenye docker-compose.yml na kuweka concurrency ya kazi kuwa 1. Hiyo ni chini ya kiwango cha chini kilichopendekezwa cha 6 GB, kwa hivyo ichukulie kama maelewano ya kiufundi. Utaweza kuhifadhi picha, albamu, kushiriki, backup ya simu, na utafutaji kwa tarehe, mahali, na jina la faili. Utapoteza uwezo wa kutafuta kwa maelezo, upangaji wa kiotomatiki wa nyuso kuwa watu, na utambuzi wa maandishi ndani ya picha. Ongeza swap file ya 2 GB ili ongezeko la ghafla la uingizaji wa data lipunguze kasi ya seva badala ya kusababisha container kufungwa.

Kwa nini uingizaji wa data wa Immich unasimama bila ujumbe wa kosa?

Kuna sababu mbili tofauti zinazoonekana sawa kutoka kwenye kivinjari. Aidha container ilifungwa kwa sababu ya kumbukumbu (memory), ambapo docker ps -a inaonyesha Exited (137) na container imekwisha anzishwa upya, au seva mwenyeji (host) inatumia swap, ambapo kila container inaendelea kufanya kazi na kila kitu kinakuwa na kasi ndogo sana. vmstat 1 5 hutofautisha sababu hizi: namba zisizo sifuri zinazoendelea katika safu za si na so inamaanisha matumizi ya swap. Punguza concurrency ya kazi kwa ajili ya kutengeneza thumbnail, utambuzi wa nyuso, na utafutaji mahiri katika hali zote mbili.

Nambari ya kutoka (exit code) 137 inamaanisha nini kwenye logi za Immich?

137 ni 128 pamoja na signal 9, kwa hivyo mchakato ulifungwa kwa kutumia SIGKILL. Kwa vitendo, hii inamaanisha kikomo cha kumbukumbu kilifikiwa, aidha kikomo cha container yenyewe au seva mwenyeji kuishiwa na kumbukumbu. Angalia kwa kutumia docker inspect immich_machine_learning | grep -i oomkilled. Thamani ya true inathibitisha kuwa kernel ilifunga mchakato huo kwa sababu ya kumbukumbu, na free -m pamoja na sudo dmesg -T | grep -i oom-kill itakuambia kama ilikuwa ni kikomo cha container au seva nzima. Container ya machine learning ndiyo inayopata madhara mara nyingi kwa sababu kwa kawaida ndiyo mchakato mkubwa zaidi.

Immich inahitaji nafasi ngapi ya diski kwa kila picha?

Tenga nafasi ya faili asilia pamoja na asilimia 10 hadi 20. Immich inaeleza kuwa thumbnail zinazotengenezwa na video zilizobadilishwa mfumo (transcoded) huongeza ukubwa wa maktaba kwa asilimia 10 hadi 20 kwa wastani, na database yenyewe kwa kawaida ni 1 hadi 3 GB hata kwa maktaba kubwa. Video ndiyo inayochangia zaidi katika ukubwa wa jumla, kwa hivyo pima wastani wa ukubwa wa faili zako kabla ya kuchagua mpango wa hifadhi badala ya kutumia kizio cha hesabu ya picha.

Je, ninahitaji GPU kwa ajili ya Immich?

Hapana. Kila sehemu ya Immich inaendeshwa kwenye CPU. Kadi ya michoro (graphics card) huharakisha inference ya modeli kwenye container ya machine learning na encoding ya video, lakini hakuna kati ya hizi inayohitajika. Mipango mingi ya VPS haitoi GPU. Kwenye vifaa vinavyotumia CPU pekee, weka threads za transcoding kuwa 1 au 2, tumia modeli ya nyuso ya buffalo_s, na uache uingizaji mkubwa wa kwanza wa data ufanyike usiku kucha.