Immich కు ఎంత RAM మరియు disk అవసరం?

Immich కు ఎంత RAM అవసరం?

Immich కు దాని డాక్యుమెంటెడ్ కనిష్ఠ అవసరంగా 6 GB RAM (random access memory), అలాగే సిఫార్సుగా 8 GB RAM అవసరం. తక్కువ స్థాయిలో 2 CPU cores, సౌకర్యవంతమైన ఇన్‌స్టాలేషన్‌కు 4 CPU cores అవసరం. ఈ సంఖ్య మొత్తం stack కు వర్తిస్తుంది, ఎందుకంటే Immich ఒక అప్లికేషన్ కాకుండా నాలుగు containers ను ఉపయోగిస్తుంది. ఇప్పటికే import చేసిన library ను browse చేయడానికి తక్కువ వనరులు సరిపోతాయి. RAM వినియోగం ప్రధానంగా importing సమయంలో పెరుగుతుంది. అందులో ఎక్కువ భాగం మీరు నిలిపివేయగల ఒక container కు వెళ్తుంది.

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

ఇవి August 2026 నాటికి Immich requirements page లో ప్రచురించిన సంఖ్యలు. ఇవి sizing recommendation మాత్రమే; startup సమయంలో software తప్పనిసరిగా చేసే check కావు. Immich తక్కువ RAM తో కూడా ప్రారంభమవుతుంది. చిన్న server లో మారేది background jobs పూర్తయ్యే విధానం, అలాగే RAM అయిపోయినప్పుడు import ఎలా ప్రవర్తిస్తుందన్నది.

ఒక నిజమైన hard limit ఉంది. Immich version 3 మరియు తరువాతి versions కు amd64 hosts పై x86-64-v2 CPU అవసరం. సుమారు 2012 నుంచి విక్రయమైన చాలా processors ఈ అవసరాన్ని తీరుస్తాయి. పాత hardware పై container నెమ్మదిగా నడవదు; ప్రారంభం కావడంలో విఫలమవుతుంది.

మీరు ఇంకా installation ప్రారంభించకపోతే, ముందుగా Docker Compose తో VPS పై పూర్తి Immich installation ను ప్రారంభించండి. తరువాత server వనరులను నిర్ణయించడానికి ఇక్కడికి తిరిగి రండి.

మెమరీ ఎక్కడ వినియోగమవుతుంది: నాలుగు containers

అధికారిక Compose file నాలుగు services ను ప్రారంభిస్తుంది. ప్రతి service కు భిన్నమైన memory వినియోగ స్వరూపం ఉంటుంది. అందువల్ల మొత్తం memory సంఖ్య మాత్రమే చూస్తే ఉపయోగకరమైన సమాచారం కనిపించదు.

immich-server web interface మరియు API ను అందిస్తుంది. అలాగే background job workers ను కూడా నడుపుతుంది. ఆ ఒక్క container లోనే రెండు workers ఉంటాయి. api browser మరియు mobile app నుంచి వచ్చే requests కు సమాధానం ఇస్తుంది. microservices thumbnail generation, video encoding సహా queues ను నడుపుతుంది. IMMICH_WORKERS_INCLUDE మరియు IMMICH_WORKERS_EXCLUDE variables ఈ రెండింటిని వేర్వేరు containers గా విభజిస్తాయి. అందువల్ల photos ను అందించే భాగానికి limit విధించకుండా, ఎక్కువ memory వినియోగించే భాగానికి ప్రత్యేక memory limit ఇవ్వవచ్చు.

database లో VectorChord extension ముందుగానే కలిగిన PostgreSQL 14 image ఉంటుంది. ఇది మొత్తం metadata ను, ప్రతి asset కు ఒక search vector ను నిల్వ చేస్తుంది. ఈ stack లో explicit minimum memory limit ఇచ్చిన ఏకైక service ఇదే అని Immich documentation చెబుతుంది. Docker resource limits అమలు చేస్తే database కు కనీసం 2 GB అవసరం. Database local SSD storage పై ఉండాలి. ఏ రకమైన network share పై కూడా ఉండకూడదు. కారణం vector మరియు index lookups చిన్న random reads కావడం. Network volume ఉపయోగిస్తే ప్రతి lookup ఒక network round trip గా మారుతుంది. Plan ఎంపిక దీనిపై ఆధారపడితే, VPSలో NVMe మరియు SATA SSD storage మధ్య తేడా ఈ stack లోని ఇతర భాగాలకన్నా ఇక్కడ ఎక్కువ ప్రాధాన్యం కలిగి ఉంటుంది.

redis Valkey image ను నడుపుతుంది. ఇది job queues ను నిల్వ చేస్తుంది. ఈ నాలుగు services లో ఇది చాలా తక్కువ memory వినియోగిస్తుంది. కారణం ఇది photo data కాకుండా job records ను మాత్రమే నిల్వ చేయడం.

immich-machine-learning మీ plan size ను నిర్ణయించే service. ఇది smart search, face detection మరియు text recognition కోసం models ను load చేస్తుంది. Load అయిన model memory లోనే resident గా ఉంటుంది. MACHINE_LEARNING_MODEL_TTL default value 300. అందువల్ల requests ఏవీ లేకుండా ఐదు నిమిషాలు గడిస్తే model memory నుంచి తొలగించబడుతుంది. తదుపరి request వచ్చినప్పుడు అది /cache volume నుంచి మళ్లీ చదవబడుతుంది. Bulk import సమయంలో ఐదు నిమిషాల విరామం ఉండదు. అందువల్ల మొదటి asset నుంచి చివరి asset వరకు models load అయి ఉంటాయి.

దిగుమతి సమయంలో ఏమి మారుతుంది

నిష్క్రియంగా ఉన్న Immich నిశ్శబ్దంగా ఉంటుంది. చిన్న serverలు సాధారణంగా imports సమయంలో విఫలమవుతాయి. ఒక assetను upload చేయగానే jobs యొక్క శ్రేణి queueలో చేరుతుంది. అనేక queues ఒకేసారి నడుస్తాయి.

Metadata extraction file headerను చదువుతుంది. దీనికి తక్కువ వనరులు అవసరం. Thumbnail generationకు ఎక్కువ వనరులు అవసరం. Immich ప్రతి asset కోసం మూడు thumbnail outputsను సృష్టిస్తుంది: blurred thumbhash placeholder, WebP preview, JPEG thumbnail. అదనంగా గుర్తించిన ప్రతి face కోసం మరో thumbnailను సృష్టిస్తుంది. ఈ jobsలో ప్రతి ఒక్కటి imageను decode చేస్తుంది. ఒకేసారి ఎన్ని images decode చేయాలో job concurrency నిర్ణయిస్తుంది. ప్రతి jobకు తక్కువగా ఉండే వనరుల వినియోగాన్ని server మొత్తం మీద పెద్ద భారంగా మార్చేది concurrency. అందుకే పరిమిత వనరులున్న machineలో ముందుగా తగ్గించాల్సింది ఇదేనని Immich FAQ పేర్కొంటుంది. Administration, Settings, Job Settings కింద heavy queues కోసం concurrencyని 1గా సెట్ చేయండి.

Video assetsకు transcoding కూడా జరుగుతుంది. ప్రతి transcode job ప్రత్యేక FFmpeg processగా నడుస్తుంది. దానికి స్వంత memory అవసరం ఉంటుంది. మీరు అనుమతించిన ప్రతి CPU threadను అది ఉపయోగిస్తుంది.

Smart search ప్రతి కొత్త assetను machine learning containerకు పంపి ఒక embedding vectorను లెక్కిస్తుంది. Face detection అదే imageపై రెండో modelను అమలు చేస్తుంది. ఇప్పటికే ఉన్న photo libraryని మొదటిసారి import చేసినప్పుడు, మీ వద్ద ఉన్న ప్రతి assetపై ఈ రెండు queues నడుస్తాయి. దీనికి గంటలు పట్టవచ్చు. మొత్తం installationలో memory వినియోగం అత్యధికంగా ఉండే సమయం ఇదే. ఇది ఒక్కసారి మాత్రమే జరుగుతుంది.

ముఖ మరియు వస్తు గుర్తింపుకు అత్యధిక RAM ఎందుకు అవసరం

ముఖాల నిర్వహణలో రెండు పనులు ఉంటాయి. ముఖ గుర్తింపు machine learning container లో model ను నడిపి ముఖాల bounding boxes ను కనుగొంటుంది. తరువాత facial recognition ఆ గుర్తింపులను వ్యక్తులుగా సమూహపరుస్తుంది. ఈ దశ Postgres లోని vector index ను query చేస్తుంది. అందువల్ల పెద్ద library రెండు services పై వరుసగా ఒత్తిడి కలిగిస్తుంది: ముందుగా detection నడుస్తున్నప్పుడు model container పై, తరువాత grouping నడుస్తున్నప్పుడు database పై.

Machine learning container లో ఉండే డేటాను నాలుగు settings మార్చుతాయి.

• Face model. Immich డిఫాల్ట్‌గా buffalo_l ను ship చేస్తుంది. చిన్న server కోసం FAQ buffalo_s ను సిఫారసు చేస్తుంది. ఇది చిన్న model కావడంతో తక్కువ memory ఉపయోగిస్తుంది, వేగంగా నడుస్తుంది. అయితే చిన్నగా కనిపించే లేదా పక్కకు తిరిగిన ముఖాలపై accuracy తగ్గవచ్చు.
• Worker count. MACHINE_LEARNING_WORKERS డిఫాల్ట్‌గా 1 గా ఉంటుంది. ప్రతి worker ప్రత్యేక process గా ఉండి models యొక్క స్వంత copy ను load చేస్తుంది. అందువల్ల దాన్ని 2 కు పెంచితే resident model memory సుమారుగా రెండింతలు అవుతుంది. అదనపు RAM అందుబాటులో ఉంటే తప్ప దాన్ని 1 గానే ఉంచండి.
• Batch size. MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION ఒకేసారి process చేసే ముఖాల సంఖ్యకు గరిష్ఠ పరిమితిని విధిస్తుంది. ఒక batch మొత్తం memory లో కలిసి ఉంచబడుతుంది. అందువల్ల నలభై ముఖాలు ఉన్న group photo కు portrait కంటే ఎక్కువ memory అవసరం.
• ఏ model types నడవాలి. Smart search, face detection, text recognition ఒక్కొక్కటి తమ స్వంత models ను load చేస్తాయి. మీరు ఉపయోగించని వాటిని Administration, Settings, Machine Learning Settings లో disable చేస్తే, imports మధ్యలో మాత్రమే కాకుండా శాశ్వతంగా వాటి memory వినియోగం తొలగుతుంది.

ఇంకా MACHINE_LEARNING_MODEL_ARENA ఉంది. ఇది memory fragmentation ను నివారించడానికి CPU memory ను ముందుగానే allocate చేస్తుంది మరియు డిఫాల్ట్‌గా on గా ఉంటుంది. దీన్ని చివరగా మార్చండి. దీని ప్రభావం కింద పనిచేసే memory allocator పై ఆధారపడి ఉంటుంది. అందువల్ల docker stats ను మార్పుకు ముందు మరియు తరువాత monitor చేయడం మాత్రమే దాని ప్రభావాన్ని నిజాయితీగా అంచనా వేయగల మార్గం.

మూడు అమలు ప్రొఫైళ్లు: 2 GB, 4 GB మరియు 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"
  }
]

వాటిని Immich ఎంత వనరులను ఉపయోగిస్తుందో కొలిచే సంఖ్యలుగా కాకుండా, Compose లో నమోదు చేయాల్సిన పరిమితులుగా పరిగణించండి. పరిమితి గరిష్ఠ స్థాయి మాత్రమే. అది ఏ వనరునూ ముందుగా కేటాయించదు, సేవను చిన్నదిగా కూడా చేయదు. సర్వర్‌లో వనరులు అయిపోయినప్పుడు kernel ఏ సేవను terminate చేయాలో అది నిర్ణయిస్తుంది. ఈ నిర్ణయాన్ని kernel యొక్క స్వంత scoring కంటే మీరే తీసుకోవడం మంచిది.

2 GB సర్వర్: machine learning container ను తొలగించండి

2 GB, 6 GBగా పేర్కొన్న కనిష్ఠ అవసరం కంటే తక్కువ. కాబట్టి ఇది ఒక రాజీ అని స్పష్టంగా గుర్తించాలి. docker-compose.yml లోని మొత్తం immich-machine-learning service ను comment out చేయండి. లేదా దాన్ని నడుపుతూ Administration, Settings, Machine Learning Settings లోని ప్రతి model ను disable చేయండి. Container ను తొలగించడం మరింత ప్రభావవంతమైన ఎంపిక. ఎందుకంటే disabled model అయినా Python process ను memoryలో ఉంచుతుంది.

మీకు uploads, albums, sharing, mobile backup, thumbnails, అలాగే date, place మరియు filename ఆధారిత search కొనసాగుతాయి. Description ఆధారిత search, faces ను people గా automatic grouping చేయడం, images లోని text recognition మాత్రం ఉండవు.

నాలుగు పరిమితుల మొత్తం సుమారు 1.7 GB. అందువల్ల hostకు సుమారు 300 MB మిగులుతుంది. Database కోసం 768 MB, documentationలో పేర్కొన్న 2 GB కనిష్ఠ పరిమితి కంటే తక్కువ అని గమనించండి. 2 GB వల్ల తప్పనిసరిగా ఏర్పడే రాజీ ఇదే. అందుకే ఇక్కడ Postgres terminate అయ్యే అవకాశం ఎక్కువగా ఉన్న service.

మొదట విఫలమయ్యేది browsing కాదు, import. కొన్ని వేల నుంచి తక్కువ పదివేల పరిధిలో ఉన్న photos library, import పూర్తయిన తర్వాత సాధారణంగా సరిగ్గా browse అవుతుంది. కారణం, page అందించడం metadata query మరియు file read కలయిక మాత్రమే. అదే సర్వర్‌లో video ఎక్కువగా ఉన్న import చేస్తే swap ఉపయోగించబడుతుంది. Transcode మరియు thumbnail queue రెండింటికీ ఒకేసారి memory అవసరం అవుతుంది. ప్రతి భారమైన queue యొక్క concurrency ను 1కి పరిమితం చేసి, swap file జోడించండి.

4 GB సర్వర్: machine learning ప్రారంభించి, ఒకేసారి ఒక job మాత్రమే

4 GB అనేది face మరియు object recognition ప్రారంభించడం ఉపయోగకరంగా ఉండే కనిష్ఠ పరిమాణం. Machine learning container ను 0 MBకు పరిమితం చేయండి. Facial recognition ను buffalo_sకు మార్చండి. Thumbnail generation, face detection మరియు smart search కోసం job concurrency ను 1గా ఉంచండి.

ఇప్పటికే ఉన్న libraryపై మొదటి pass పూర్తవడానికి అనేక గంటలు పడుతుంది. పెద్ద library అయితే ఒక రోజుకంటే ఎక్కువ సమయం పడవచ్చు. ఇది memory పరిమితి కంటే CPU పరిమితి. అందువల్ల ఎక్కువ RAM దీనిని వేగవంతం చేయదు.

మొదటి bulk pass సమయంలో ఇక్కడ ముందుగా సమస్యకు గురయ్యేది machine learning container. పరిమితి లేకపోతే అది పెరుగుతూనే ఉంటుంది. అదే సమయంలో transcode job కూడా memoryని పెంచుతుంది. అప్పుడు kernel ఈ రెండింటిలో ఎక్కువ memory ఉపయోగిస్తున్నదాన్ని terminate చేస్తుంది. docker ps -a లో Exited (137) కనిపిస్తుంది. Container మళ్లీ ప్రారంభమవుతుంది. మీరు చివరిసారి చూసినప్పటి కంటే queue మరింత వెనుకబడి ఉంటుంది.

8 GB సర్వర్: documentationలోని సిఫార్సు

8 GB మరియు 4 cores కలయిక Immich సిఫార్సుకు సరిపోతుంది. Default settingsతో smart search, face detection, text recognition మరియు transcoding నడుస్తాయి. వాటి concurrency కూడా defaultగానే ఉంటుంది. లక్షకు పైగా assets ఉన్న libraries కూడా ఇక్కడ సౌకర్యంగా నడుస్తాయి. ఈ దశలో ఒత్తిడి memory నుంచి disk speed వైపు మారుతుంది. ఎందుకంటే vector index మరియు metadata queriesనే database రోజంతా నిర్వహిస్తుంది.

అయినా limits అమలు చేయండి. వనరులు అందుబాటులో ఉన్న సర్వర్‌లో కూడా runaway queue కారణంగా database ఆగిపోకుండా ఈ limits నిరోధిస్తాయి. చిన్న ఎంపికలతో ఖర్చును పోల్చుతున్నట్లయితే, memory tier ఆధారంగా VPS వాస్తవ ఖర్చు సాధారణంగా tuning తగ్గించడానికి 8 GB plan చౌకైన మార్గమని చూపిస్తుంది.

Compose limits తో ప్రతి service కు memory పరిమితిని ఎలా నిర్ణయించాలి

దీని కోసం docker-compose.yml ను సవరించవద్దు. మీరు wget తో upgrade చేసిన ప్రతిసారి ఆ file మళ్లీ భర్తీ చేయబడుతుంది. పరిమితులను దాని పక్కన ఉన్న docker-compose.override.yml లో ఉంచండి. దాన్ని docker compose స్వయంచాలకంగా merge చేస్తుంది.

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 లో host మొత్తం memory బదులు MEM USAGE / LIMIT column లో మీరు నిర్ణయించిన గరిష్ఠ పరిమితి కనిపించాలి. Limit column లో ఇంకా host మొత్తం పరిమాణమే కనిపిస్తే override file తీసుకోబడలేదు. File name ను తనిఖీ చేసి, merge అయిన ఫలితాన్ని చూడటానికి docker compose config అమలు చేయండి.

పరిమితి చాలా తక్కువగా ఉంటే నెమ్మదిగా నడిచే service పూర్తిగా ఆగిపోతుంది. కాబట్టి container పదేపదే restart అవుతుంటే పరిమితిని పెంచండి. విధానం గురించి Docker Compose లో ప్రతి service కు memory పరిమితులను నిర్ణయించడం లో మరింత సమాచారం ఉంది. Compose v2 తో Swarm వెలుపల కూడా deploy ఎందుకు పనిచేస్తుందో అక్కడ వివరించబడింది.

Machine learning container ను ఎలా ఆపాలి లేదా తరలించాలి

చిన్న serverలో ఈ container ను వేరే చోట నడపడం మీరు చేయగలిగే అతి పెద్ద మార్పు. Immich దీనిని మరొక machineలో నడపడానికి మద్దతు ఇస్తుంది. రెండో hostలో ఈ fileను సృష్టించండి. ఇది సాయంత్రాల్లో మాత్రమే ఆన్‌లో ఉండే desktop కావచ్చు:

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

తర్వాత web interfaceలో Administration, Settings, Machine Learning Settings కు వెళ్లి, Add URLను క్లిక్ చేసి, http://<host>:3003 ను నమోదు చేయండి. రెండు hostలలో version ఒకేలా ఉంచండి. రెండు versionల మధ్య తేడాలు bugs మరియు instability కు కారణమవుతాయని Immich documentation హెచ్చరిస్తుంది.

ఈ port మీ photosను encryption లేకుండా మరొక machineకు పంపుతుంది. అందువల్ల దీన్ని private networkలో ఉంచండి లేదా రెండు hostల మధ్య WireGuard tunnel ద్వారా నడపండి. 3003ను internetకు ఎప్పుడూ expose చేయవద్దు.

నిరంతరం నడిచే model container ఉండటమే సమస్య అయితే, plan sizeను నిర్ణయించే ముందు PhotoPrism మరియు Immich idle సమయంలో ఏ సేవలను నడుపుతాయో ఎలా భిన్నంగా ఉంటాయో పోల్చడం కూడా సముచితమే.

Immich library కి ఎంత disk స్థలం అవసరం?

ఒకే multiplier వర్తించదు, ఎందుకంటే నాలుగు వేర్వేరు అంశాలు నాలుగు వేర్వేరు రేట్లతో పెరుగుతాయి. 50,000 photos మరియు 500 short videos ఉన్న library కోసం లెక్క ఇలా ఉంటుంది.

[
  {
    "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 photos మరియు 60 GB video అనేవి అంచనాలు. ఏదైనా కొనుగోలు చేసే ముందు వాటిని మీ సగటు పరిమాణాలతో మార్చండి, ఎందుకంటే ఈ సంఖ్యను video నిర్ణయిస్తుంది: phone videoలోని ఒక నిమిషం, వంద 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}'

39 GB వరుస Immich ప్రచురించిన ఏకైక ratio ను చూపిస్తుంది: generated thumbnails మరియు transcoded video కలిపి library పరిమాణానికి సగటున 10 నుంచి 20 శాతం జోడిస్తాయి. ఇది ఒక range, ఎందుకంటే browser compatibility కోసం re-encoding అవసరమైన మీ assetsలో video ఎంత ఉందో దానిపై ఇది ఆధారపడి ఉంటుంది. JPEGs ఉన్న library సాధారణంగా ఈ range దిగువ భాగానికి దగ్గరగా ఉంటుంది.

Database పరిమాణం 3 GB. ఇది దాదాపు fixed cost. Metadata మరియు search vectors ను నిల్వ చేస్తుంది, pixels ను కాదు కాబట్టి database files సాధారణంగా 1 నుంచి 3 GB ఉంటాయని Immich documentation చెబుతుంది. Model cache పరిమాణం 2 GB. మీరు అనేక models ను enable చేసినా లేదా వేర్వేరు models ను test చేసినా ఇది పెరుగుతుంది. ఇదే కారణంగా FAQ ఈ volume ను space consumer గా పేర్కొంటుంది.

ఈ ఐదు వరుసల మొత్తం 300 GB కంటే కొద్దిగా ఎక్కువ. అందువల్ల 500 GB volume లో పెరుగుదలకు స్థలం ఉంటుంది, కానీ 250 GB volume లో ఉండదు. ఈ విభజనను కింది command తో పరిశీలించండి:

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

UPLOAD_LOCATION కింద ఆరు folders ఉంటాయి. Originals ను upload మరియు library లో ఉంచుతారు. Previews మరియు face thumbnails ను thumbs లో ఉంచుతారు. Re-encoded copies ను encoded-video లో ఉంచుతారు. Avatars ను profile లో ఉంచుతారు. Automatic database dumps ను backups లో ఉంచుతారు. upload, library మరియు profile మాత్రమే తిరిగి పొందలేనివి, ఎందుకంటే మిగతావన్నీ వీటి నుంచి మళ్లీ generate చేయవచ్చు.

రెండు విషయాలు చాలామందికి ఆశ్చర్యం కలిగిస్తాయి. Deleted assets ముందుగా trash కు వెళ్తాయి. Trash empty చేసే వరకు అవి తమ స్థలాన్ని ఆక్రమిస్తూనే ఉంటాయి. అందువల్ల పెద్ద cleanup చేసిన రోజునే స్థలం ఖాళీ కాకపోవచ్చు. అలాగే database dump లో metadata మాత్రమే ఉంటుంది. Files లేకుండా దానికి ఉపయోగం ఉండదు:

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

దీనితో పాటు originals కు file-level copy ను server బయట ఉన్న ఏదైనా స్థలంలో ఉంచండి. VPS నుంచి server వెలుపలి storage కు restic backups ఇందుకోసమే ఉపయోగపడతాయి.

Transcodingకు RAM కాదు, CPU అవసరం

RAM పెంచితే transcoding వేగవంతం కాదు. Immich, FFmpegను ఉపయోగించి transcoding చేస్తుంది. సాధారణ VPSలో ప్రతి frameను CPU decode చేసి encode చేస్తుంది. Hardware acceleration అందుబాటులో ఉన్నా, encoding మాత్రమే accelerate అవుతుందని Immich documentation చెబుతోంది. కాబట్టి CPU software decoding మరియు tone mappingను కొనసాగిస్తుంది.

Hardware acceleration కోసం అదనపు hwaccel.transcoding.yml Compose fileతో పాటు pass through చేయాల్సిన device అవసరం. దీనికి NVENC, Quick Sync, RKMPP లేదా VAAPI ఉపయోగిస్తారు. చాలా VPS plansలో ఇవేవీ ఉండవు. కాబట్టి CPU ఆధారంగా ప్రణాళిక రూపొందించండి.

ఆచరణలో మార్చాల్సిన setting thread count. Administration, Settings, Video Transcoding Settings కింద thread విలువ 0 అంటే అన్ని cores ఉపయోగించబడతాయి. 2 core planలో దీనివల్ల ఒక video web interfaceను నిలిపివేయవచ్చు. Immich FAQ సూచించినట్లుగా అక్కడ 1 లేదా 2గా సెట్ చేయండి. అప్పుడు transcode నెమ్మదిగా జరుగుతుంది, కానీ ఇతర సేవలకు అంతరాయం కలగదు.

swap thrashing కారణంగా import hang అయినట్లు ఎందుకు కనిపిస్తుంది

ఇది తరచుగా తప్పుగా అర్థం చేసుకునే failure. Immich కు memory అందుబాటులో లేకపోతే రెండు పరిణామాలు ఉంటాయి. వాటిలో ఒకటి మాత్రమే failure లాగా కనిపిస్తుంది.

swap లేకపోతే kernel ఒక process ను terminate చేస్తుంది. Container కొన్ని సెకన్లలో restart అవుతుంది. అందువల్ల browser లో job queue కొద్దిసేపు ఆగి, మళ్లీ కొనసాగుతుంది. దీనికి ఆధారం 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) అంటే process signal 9 తో terminate అయిందని అర్థం. 137 అనేది 128 plus 9. OOMKilled విలువ true గా ఉండటం వల్ల crash కారణంగా కాకుండా memory కొరత కారణంగా process terminate అయిందని నిర్ధారించవచ్చు.

swap ఉంటే ఏదీ terminate కాదు. ఏ error కూడా కనిపించదు. Kernel pages ను disk కు తరలించడం ప్రారంభిస్తుంది. Import వేగం ఒక order of magnitude మేర తగ్గుతుంది. Web interface సాధారణ timeout లోపు response ఇవ్వడం ఆపుతుంది. ప్రతి container నడుస్తూనే ఉంటుంది. ప్రతి health check కూడా pass కావచ్చు. ఇది hang లాగా కనిపిస్తుంది. ఈ సమయంలో చాలామంది server ను reboot చేస్తారు. దాంతో queue progress కోల్పోతారు. సమస్యలో మాత్రం ఎలాంటి మార్పు ఉండదు.

free -m
vmstat 1 5

vmstat లోని si మరియు so columns లో non zero విలువలు నిరంతరం కనిపిస్తే, machine swap ను నిరంతరం read మరియు write చేస్తోందని అర్థం. ఇదే thrashing కు నిర్వచనం. అదే సమయంలో Swap కోసం free -m row లో used విలువ కూడా పెరుగుతుంది.

2 GB లేదా 4 GB machine పై అయినా swap జోడించండి. ఎందుకంటే diagnose చేయగల slow import, diagnose చేయలేని killed container కంటే మెరుగైనది:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

తర్వాత అసలు కారణాన్ని పరిష్కరించండి. Job concurrency ను 1 కు తగ్గించండి. Machine learning container కు memory పరిమితి విధించండి. లేదా దాన్ని ఈ host నుంచి తరలించండి. Swap దీనికి సమయం ఇస్తుంది. Swap ఒక్కటే పరిష్కారం కాదు.

FAQ

నేను 2 GB VPSపై Immich నడపవచ్చా?

అవును. docker-compose.yml నుంచి immich-machine-learning service ను comment చేసి, job concurrency ను 1గా సెట్ చేయాలి. ఇది documentationలో పేర్కొన్న కనిష్ఠ 6 GB కంటే తక్కువ. కాబట్టి దీన్ని తెలిసిన పరిమితిగా పరిగణించాలి. Uploads, albums, sharing, mobile backup, అలాగే date, place, filename ఆధారిత search కొనసాగుతాయి. Description ఆధారిత search, faces ను వ్యక్తులుగా automatic grouping చేయడం, images లోని text recognition అందుబాటులో ఉండవు. 2 GB swap file జోడించండి. అప్పుడు import సమయంలో memory వినియోగం పెరిగినా container kill కాకుండా server నెమ్మదిగా పనిచేస్తుంది.

Immich import ఎటువంటి error message లేకుండా ఎందుకు ఆగిపోతుంది?

Browserలో రెండు వేర్వేరు కారణాలు ఒకేలా కనిపిస్తాయి. ఒక container memory కారణంగా kill అయి ఉండవచ్చు. ఆ సందర్భంలో docker ps -a లో Exited (137) కనిపిస్తుంది, అలాగే container ఇప్పటికే restart అయి ఉంటుంది. లేదా host swapping చేస్తుండవచ్చు. ఆ సందర్భంలో ప్రతి container ఇంకా runningలోనే ఉంటుంది, కానీ మొత్తం వ్యవస్థ చాలా నెమ్మదిగా పనిచేస్తుంది. vmstat 1 5 ఈ రెండింటినీ వేరు చేస్తుంది. si మరియు so columnsలో నిరంతరం non zero సంఖ్యలు కనిపిస్తే swapping జరుగుతోంది. ఏ సందర్భంలోనైనా thumbnail generation, face detection, smart search కోసం job concurrency తగ్గించండి.

Immich logsలో exit code 137 అంటే ఏమిటి?

137 అనేది 128కు signal 9 కలిపిన విలువ. అందువల్ల process SIGKILLతో kill చేయబడింది. సాధారణంగా memory ceiling చేరిందని దీని అర్థం. కారణం container యొక్క స్వంత limit కావచ్చు లేదా hostలో memory అయిపోవచ్చు. docker inspect immich_machine_learning | grep -i oomkilled తో తనిఖీ చేయండి. true విలువ కనిపిస్తే kernel memory కారణంగా processను kill చేసిందని నిర్ధారించవచ్చు. తరువాత free -m మరియు sudo dmesg -T | grep -i oom-kill విలువలు కారణం container limitనా లేదా మొత్తం hostలో memory కొరతనా అనేది తెలియజేస్తాయి. సాధారణంగా machine learning container ప్రభావితమవుతుంది, ఎందుకంటే అది ఎక్కువగా అతిపెద్ద processగా ఉంటుంది.

Immichకు ఒక్కో photoకు ఎంత disk space అవసరం?

Original file పరిమాణంతో పాటు 10 నుంచి 20 శాతం అదనంగా కేటాయించండి. Generated thumbnails మరియు transcoded video వల్ల library పరిమాణం సగటున 10 నుంచి 20 శాతం పెరుగుతుందని Immich documentation చెబుతోంది. పెద్ద library ఉన్నప్పటికీ database సాధారణంగా 1 నుంచి 3 GB ఉంటుంది. అయితే మొత్తం పరిమాణాన్ని వాస్తవంగా నిర్ణయించేది video. కాబట్టి photo countకు ఒక multiplier వర్తింపజేయకుండా, plan ఎంచుకునే ముందు మీ స్వంత సగటు file sizeను కొలవండి.

Immichకు GPU అవసరమా?

లేదు. Immichలోని ప్రతి భాగం CPUపై నడుస్తుంది. Graphics card machine learning containerలో model inferenceను మరియు video encodingను వేగవంతం చేస్తుంది. అయితే రెండింటికీ అది అవసరం లేదు. చాలా VPS plans GPUను అందించవు. CPU మాత్రమే ఉన్న hardwareపై transcoding threadsను 1 లేదా 2గా సెట్ చేయండి, buffalo_s face modelను ఉపయోగించండి, మొదటి bulk importను రాత్రంతా కొనసాగనివ్వండి.