Immich-க்கு எவ்வளவு RAM மற்றும் Disk தேவை?

Immich-க்கு எவ்வளவு RAM தேவை?

Immich அதன் ஆவணப்படுத்தப்பட்ட குறைந்தபட்ச தேவையாக 6 GB RAM-ஐயும் (random access memory), பரிந்துரைக்கப்பட்ட அளவாக 8 GB-ஐயும் கோருகிறது. குறைந்தபட்சம் 2 CPU cores-ம், வசதியான பயன்பாட்டிற்கு 4 CPU cores-ம் தேவைப்படும். Immich என்பது ஒரே application அல்ல, நான்கு containers-ன் தொகுப்பு என்பதால், இந்த அளவு முழு stack-க்கும் பொருந்தும். ஏற்கனவே இறக்குமதி செய்யப்பட்ட library-ஐப் பார்ப்பதற்கு அதிக நினைவகம் தேவைப்படாது. நினைவகம் பெரும்பாலும் இறக்குமதி செய்யும்போதே செலவாகும்; இதில் பெரும்பகுதி நீங்கள் தேவைப்பட்டால் அணைத்து வைக்கக்கூடிய ஒரு container-ஆல் பயன்படுத்தப்படுகிறது.

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

இவை ஆகஸ்ட் 2026 நிலவரப்படி Immich தேவைகள் பக்கத்தில் வெளியிடப்பட்ட புள்ளிவிவரங்கள் ஆகும். இவை ஒரு பரிந்துரை மட்டுமே, software தொடங்கும் போது சரிபார்க்கப்படும் கட்டாய வரம்புகள் அல்ல. Immich இதைவிடக் குறைவான நினைவகத்திலும் தொடங்கும். சிறிய server-களில் பின்னணி வேலைகள் (background jobs) முடிவடைவதிலும், நினைவகம் தீர்ந்துபோகும்போது இறக்குமதி செய்யும் செயல்முறை எவ்வாறு செயல்படுகிறது என்பதிலும் மட்டுமே மாற்றங்கள் இருக்கும்.

உண்மையான ஒரு கடினமான வரம்பு உள்ளது. Immich version 3 மற்றும் அதற்குப் பிந்தைய பதிப்புகளுக்கு amd64 hosts-ல் x86-64-v2 CPU தேவைப்படுகிறது. இது தோராயமாக 2012-க்கு பிறகு விற்பனை செய்யப்பட்ட பெரும்பாலான processors-க்கு பொருந்தும். பழைய hardware-ல் இந்த container மெதுவாக இயங்காது, மாறாகத் தொடங்கவே செய்யாது.

நீங்கள் இன்னும் install செய்யவில்லை என்றால், Docker Compose மூலம் முழுமையான Immich install என்பதைப் பார்த்துத் தொடங்கிவிட்டு, server-ன் அளவைத் தீர்மானிக்க மீண்டும் இங்கே வரவும்.

நினைவகம் எங்கே செல்கிறது: நான்கு containers

அதிகாரப்பூர்வ Compose கோப்பு நான்கு services-ஐத் தொடங்குகிறது. ஒவ்வொன்றும் வெவ்வேறு நினைவகத் தேவைகளைக் கொண்டிருப்பதால், மொத்த எண்ணிக்கையை மட்டும் பார்ப்பது பயனுள்ள தகவலைத் தராது.

immich-server இணைய இடைமுகம் மற்றும் API-ஐ வழங்குகிறது, மேலும் இது பின்னணி வேலைகளைச் செய்யும் workers-ஐயும் இயக்குகிறது. அந்த ஒரே container-க்குள் இரண்டு workers இயங்குகின்றன. api உலாவி மற்றும் மொபைல் செயலியின் கோரிக்கைகளுக்குப் பதிலளிக்கிறது. microservices thumbnail உருவாக்கம் மற்றும் video encoding உள்ளிட்ட வரிசைகளை (queues) இயக்குகிறது. IMMICH_WORKERS_INCLUDE மற்றும் IMMICH_WORKERS_EXCLUDE ஆகிய மாறிகள் அந்த இரண்டையும் தனித்தனி containers-ஆகப் பிரிக்கின்றன; இதன் மூலம் உங்கள் புகைப்படங்களை வழங்கும் பகுதிக்குத் தடையின்றி, அதிக சுமை கொண்ட பகுதிக்கு மட்டும் தனி நினைவக வரம்பை ஒதுக்க முடியும்.

database என்பது VectorChord extension உடன் கட்டமைக்கப்பட்ட PostgreSQL 14 image ஆகும். இது ஒவ்வொரு metadata மற்றும் ஒவ்வொரு asset-க்கும் ஒரு search vector-ஐச் சேமிக்கிறது. Immich ஆவணங்கள் இந்த service-க்கு மட்டுமே தெளிவான குறைந்தபட்ச நினைவக அளவை வழங்குகின்றன: நீங்கள் Docker resource limits-ஐப் பயன்படுத்தினால், database-க்குக் குறைந்தபட்சம் 2 GB தேவை. அதே பக்கத்தில், database-ஐ local SSD storage-ல் மட்டுமே வைக்க வேண்டும் என்றும், எந்தவொரு network share-லும் வைக்கக்கூடாது என்றும் குறிப்பிடப்பட்டுள்ளது. ஏனெனில், vector மற்றும் index தேடல்கள் சிறிய random reads ஆகும்; network volume-ஐப் பயன்படுத்தினால் ஒவ்வொன்றும் ஒரு round trip-ஆக மாறி வேகம் குறையும். உங்கள் திட்டமிடல் இதற்கு உட்பட்டது என்றால், VPS-ல் NVMe மற்றும் SATA SSD storage இடையிலான வேறுபாடு இந்த stack-ல் மற்ற இடங்களை விட இங்கே மிக முக்கியமானது.

redis என்பது Valkey image-ஐ இயக்குகிறது மற்றும் இது job queues-ஐக் கையாளுகிறது. இதுவே நான்கில் மிகச் சிறியது, ஏனெனில் இது புகைப்படத் தரவுகளுக்குப் பதிலாக job records-ஐ மட்டுமே சேமிக்கிறது.

immich-machine-learning என்பது உங்கள் திட்டத்தின் அளவைத் தீர்மானிக்கும் service ஆகும். இது smart search, face detection மற்றும் text recognition ஆகியவற்றிற்கான மாதிரிகளை (models) ஏற்றுகிறது; ஏற்றப்பட்ட மாதிரி நினைவகத்திலேயே இருக்கும். MACHINE_LEARNING_MODEL_TTL இயல்பாக 300 என அமைக்கப்பட்டுள்ளது, எனவே ஐந்து நிமிடங்கள் கோரிக்கைகள் இல்லையெனில் மாதிரி நீக்கப்பட்டு, அடுத்த கோரிக்கையின் போது /cache volume-லிருந்து மீண்டும் வாசிக்கப்படும். மொத்தமாகப் பதிவேற்றம் (bulk import) செய்யும்போது ஐந்து நிமிட இடைவெளி இருக்காது என்பதால், முதல் asset முதல் கடைசி asset வரை மாதிரிகள் நினைவகத்திலேயே இருக்கும்.

இறக்குமதியின் போது என்ன மாற்றங்கள் நிகழ்கின்றன

Immich செயலற்ற நிலையில் இருக்கும்போது அமைதியாக இருக்கும். இறக்குமதி செய்யும் போதுதான் சிறிய server-கள் செயலிழக்கின்றன, ஏனெனில் ஒரு asset-ஐ பதிவேற்றும்போது அது பல பணிகளை (jobs) வரிசைப்படுத்துகிறது மற்றும் பல queues ஒரே நேரத்தில் இயங்குகின்றன.

Metadata extraction என்பது கோப்பின் தலைப்பை (header) வாசிப்பது, இது எளிதானது. Thumbnail generation சற்று அதிக சுமை கொண்டது. Immich ஒவ்வொரு asset-க்கும் மூன்று thumbnail வெளியீடுகளை உருவாக்குகிறது: ஒரு மங்கலான thumbhash placeholder, ஒரு WebP preview மற்றும் ஒரு JPEG thumbnail, மேலும் கண்டறியப்பட்ட ஒவ்வொரு முகத்திற்கும் கூடுதலாக ஒரு thumbnail. இந்த ஒவ்வொரு பணியும் ஒரு படத்தை decode செய்கிறது, மேலும் job concurrency எத்தனை பணிகளை ஒரே நேரத்தில் decode செய்வது என்பதைத் தீர்மானிக்கிறது. Concurrency என்பது ஒரு பணியின் சிறிய சுமையை server முழுமைக்குமான சுமையாக மாற்றும் பெருக்கி (multiplier) ஆகும். இதனால்தான் Immich FAQ-வில், திறன் குறைந்த கணினிகளில் முதலில் குறைக்க வேண்டிய விஷயமாக இது குறிப்பிடப்பட்டுள்ளது. Administration, Settings, Job Settings பகுதிக்குச் சென்று, அதிக சுமை கொண்ட queues-க்கான concurrency-ஐ 1 என அமைக்கவும்.

Video assets-க்கு transcoding சேர்க்கப்படுகிறது. ஒவ்வொரு transcode பணியும் தனித்தனி FFmpeg process ஆகும்; இதற்குத் தனிப்பட்ட memory தேவைப்படும், மேலும் நீங்கள் அனுமதிக்கும் அனைத்து CPU thread-களையும் இது பயன்படுத்தும்.

Smart search ஒவ்வொரு புதிய asset-ஐயும் machine learning container-க்கு அனுப்பி, ஒரு embedding vector-ஐக் கணக்கிடுகிறது. Face detection அதே படத்தின் மீது இரண்டாவது மாதிரியை (model) இயக்குகிறது. ஏற்கனவே உள்ள photo library-ஐ முதல்முறை இறக்குமதி செய்யும்போது, இந்த இரண்டு queues-ம் நீங்கள் வைத்திருக்கும் ஒவ்வொரு asset-க்கும் பல மணிநேரம் இயங்கும். இது முழு நிறுவலிலும் memory-க்கு மிக மோசமான தருணம், இது ஒருமுறை மட்டுமே நிகழும்.

முக மற்றும் பொருள் கண்டறிதலுக்கு ஏன் அதிக RAM தேவைப்படுகிறது

முகத்தைக் கையாளுதல் என்பது இரண்டு பணிகளைக் கொண்டது. முகத்தைக் கண்டறிதல் (Face detection) என்பது machine learning container-ல் ஒரு மாதிரியை (model) இயக்கி, முகங்கள் இருக்கும் இடத்தைக் கண்டறியும். அதன் பிறகு, முக அங்கீகாரம் (Facial recognition) அந்தத் தரவுகளை நபர்களாக வகைப்படுத்தும்; இந்தச் செயல்முறை Postgres-ல் உள்ள vector index-ஐ வினவுகிறது. எனவே, ஒரு பெரிய library-ஐச் செயலாக்கும்போது, இந்த இரண்டு சேவைகளும் மாறி மாறி அழுத்தத்திற்கு உள்ளாகின்றன: கண்டறிதல் நடக்கும்போது model container-ம், வகைப்படுத்துதல் நடக்கும்போது database-ம் அதிகச் சுமையைச் சுமக்கின்றன.

நான்கு அமைப்புகள் machine learning container-ன் நினைவகப் பயன்பாட்டை மாற்றுகின்றன.

• முக மாதிரி (Face model). Immich இயல்பாகவே buffalo_l-ஐ வழங்குகிறது, மேலும் சிறிய server-களில் buffalo_s-ஐப் பயன்படுத்த FAQ பரிந்துரைக்கிறது. இது சிறிய மாதிரி என்பதால், குறைந்த நினைவகத்தையே எடுத்துக்கொள்ளும் மற்றும் வேகமாக இயங்கும்; ஆனால், சிறிய அல்லது பக்கவாட்டு முகங்களை அடையாளம் காண்பதில் துல்லியம் சற்று குறையலாம்.
• பணியாளர் எண்ணிக்கை (Worker count). MACHINE_LEARNING_WORKERS இயல்பாக 1 என இருக்கும். ஒவ்வொரு worker-ம் ஒரு தனி process ஆகும், இது மாதிரிகளின் சொந்த நகலை நினைவகத்தில் ஏற்றும். எனவே, இதை 2 என உயர்த்தினால், மாதிரிக்கான நினைவகப் பயன்பாடு தோராயமாக இருமடங்காகும். உங்களிடம் கூடுதல் RAM இருந்தால் ஒழிய, இதை 1-லேயே வைத்திருங்கள்.
• தொகுதி அளவு (Batch size). MACHINE_LEARNING_MAX_BATCH_SIZE__FACIAL_RECOGNITION ஒரே நேரத்தில் எத்தனை முகங்கள் செயலாக்கப்பட வேண்டும் என்பதைக் கட்டுப்படுத்துகிறது. ஒரு தொகுதி (batch) முழுமையாக நினைவகத்தில் வைக்கப்படுவதால், நாற்பது முகங்கள் கொண்ட ஒரு குழுப் புகைப்படம், ஒரு தனி நபர் புகைப்படத்தை விட அதிக நினைவகத்தை எடுத்துக்கொள்ளும்.
• எந்தெந்த மாதிரி வகைகள் இயங்குகின்றன. Smart search, முகத்தைக் கண்டறிதல் மற்றும் உரை அங்கீகாரம் (text recognition) ஆகிய ஒவ்வொன்றும் தனித்தனி மாதிரிகளை ஏற்றுகின்றன. நீங்கள் பயன்படுத்தாதவற்றை Administration, Settings, Machine Learning Settings என்பதில் முடக்கினால், அவை இறக்குமதிக்கு இடையில் மட்டுமல்லாமல், நிரந்தரமாகவே நினைவகத்திலிருந்து நீக்கப்படும்.

மேலும் MACHINE_LEARNING_MODEL_ARENA என்ற அமைப்பும் உள்ளது. இது CPU நினைவகத்தை முன்கூட்டியே ஒதுக்கி (pre-allocating), துண்டாடப்படுவதைத் (fragmentation) தவிர்க்கிறது; இது இயல்பாகவே செயல்பாட்டில் இருக்கும். இதை மாற்ற வேண்டியிருந்தால் கடைசியாக மாற்றவும். இதன் தாக்கம் அடிப்படையிலான memory allocator-ஐப் பொறுத்தது, எனவே இதைச் சரியாக மதிப்பிட, மாற்றத்திற்கு முன்னும் பின்னும் docker stats-ஐக் கண்காணிப்பதே சிறந்த வழியாகும்.

மூன்று செயல்பாட்டு profile-கள்: 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"
  }
]

இவற்றை Compose-ல் உள்ளிட வேண்டிய வரம்புகளாகக் கருதவும், Immich எவ்வளவு பயன்படுத்துகிறது என்பதற்கான அளவீடாகக் கருத வேண்டாம். ஒரு வரம்பு என்பது உச்சவரம்பு (ceiling) ஆகும். இது எதையும் ஒதுக்கீடு செய்யாது, மேலும் ஒரு service-ன் அளவைக் குறைக்காது. கணினியில் நினைவகம் தீரும்போது எந்த service-ஐ kernel நிறுத்த வேண்டும் என்பதை இது தீர்மானிக்கிறது; இந்த முடிவை kernel-ன் தானியங்கி மதிப்பீட்டை விட நீங்களே எடுப்பது சிறந்தது.

2 GB box: machine learning container-ஐ நீக்குதல்

2 GB என்பது ஆவணப்படுத்தப்பட்ட குறைந்தபட்ச அளவான 6 GB-க்கும் குறைவாக இருப்பதால், இது ஒரு சமரசமே, அதை அவ்வாறே குறிப்பிட வேண்டும். docker-compose.yml-ல் உள்ள முழு immich-machine-learning service-ஐயும் comment செய்யவும், அல்லது அதை இயங்க விட்டுவிட்டு Administration, Settings, Machine Learning Settings என்பவற்றின் கீழ் உள்ள அனைத்து model-களையும் முடக்கவும். Container-ஐ நீக்குவதே சிறந்த வழி, ஏனெனில் முடக்கப்பட்ட model-ம் ஒரு Python process-ஐ நினைவகத்தில் வைத்திருக்கும்.

நீங்கள் uploads, albums, sharing, mobile backup, thumbnails மற்றும் தேதி, இடம், கோப்பு பெயர் மூலம் தேடுதல் ஆகியவற்றைத் தக்கவைக்கலாம். விளக்கம் மூலம் தேடுதல், முகங்களை நபர்களாகத் தானாக வகைப்படுத்துதல் மற்றும் படங்களுக்குள் உள்ள உரையை அடையாளம் காணுதல் ஆகியவற்றை இழப்பீர்கள்.

நான்கு வரம்புகளும் சேர்ந்து சுமார் 1.7 GB ஆகிறது, இது host-க்கு சுமார் 300 MB-ஐ மட்டுமே மீதி வைக்கிறது. database-க்கான 768 MB என்பது ஆவணப்படுத்தப்பட்ட 2 GB குறைந்தபட்ச அளவை விடக் குறைவு என்பதைக் கவனிக்கவும். 2 GB-ல் கட்டாயமாகச் செய்ய வேண்டிய சமரசம் இதுதான், இதனால்தான் Postgres இங்கே kernel-ஆல் நிறுத்தப்பட அதிக வாய்ப்புள்ள service-ஆக உள்ளது.

இங்கே முதலில் பாதிக்கப்படுவது import, browsing அல்ல. பத்தாயிரக்கணக்கான புகைப்படங்களைக் கொண்ட library-ஐ browsing செய்வது எளிது, ஏனெனில் ஒரு பக்கத்தைக் காட்டுவது என்பது metadata query மற்றும் கோப்பு வாசிப்பு மட்டுமே. அதே box-ல் அதிக வீடியோக்களை import செய்யும்போது swap ஏற்படும், ஏனெனில் transcode மற்றும் thumbnail queue ஆகிய இரண்டும் ஒரே நேரத்தில் நினைவகத்தைக் கோரும். ஒவ்வொரு heavy queue-ன் concurrency-ஐ 1 என அமைத்து, swap file ஒன்றைச் சேர்க்கவும்.

4 GB box: machine learning ஆன், ஒரு நேரத்தில் ஒரு பணி

4 GB என்பது முகம் மற்றும் பொருள் கண்டறிதலை (face and object recognition) ஆன் செய்யத் தகுந்த குறைந்தபட்ச அளவு. machine learning container-ஐ 0 MB-க்குள் கட்டுப்படுத்தவும், facial recognition-ஐ buffalo_s-க்கு மாற்றவும், மேலும் thumbnail generation, face detection மற்றும் smart search ஆகியவற்றிற்கான job concurrency-ஐ 1 என அமைக்கவும்.

ஏற்கனவே உள்ள library-ல் முதல்முறை இயக்கும்போது பல மணிநேரம் ஆகும், பெரிய library-ஆக இருந்தால் ஒரு நாளுக்கு மேல் ஆகலாம். இது நினைவகத்தை விட CPU தொடர்பான வரம்பு, எனவே கூடுதல் RAM இதை வேகப்படுத்தாது.

இங்கே முதலில் பாதிக்கப்படுவது அந்த முதல் bulk pass-ன் போது machine learning container ஆகும். கட்டுப்பாடு இல்லையெனில், transcode job வளரும்போது இதுவும் வளரும், அப்போது இரண்டில் பெரியதை kernel நிறுத்திவிடும். docker ps -a-ல் Exited (137)-ஐக் காண்பீர்கள், container restart ஆகும், queue நீங்கள் கடைசியாகப் பார்த்ததை விடப் பின் தங்கியிருக்கும்.

8 GB box: ஆவணப்படுத்தப்பட்ட பரிந்துரை

8 GB மற்றும் 4 cores என்பது Immich பரிந்துரைக்கும் அளவு, இங்கே அனைத்தும் default அமைப்புகளில் இயங்கும்: smart search, face detection, text recognition மற்றும் transcoding ஆகியவை default concurrency-ல் இருக்கும். நூறாயிரத்திற்கும் மேற்பட்ட assets கொண்ட library-கள் இங்கே தடையின்றி இயங்கும். இங்கே அழுத்தம் நினைவகத்திலிருந்து disk வேகத்திற்கு மாறுகிறது, ஏனெனில் vector index மற்றும் metadata queries ஆகியவையே database-ன் முக்கிய வேலைகளாக இருக்கும்.

இருப்பினும் வரம்புகளை அமைக்கவும். போதுமான வசதி உள்ள box-ல், ஒரு runaway queue முழு database-ஐயும் முடக்குவதைத் தடுக்க இந்த வரம்புகள் உதவும். சிறிய விருப்பங்களுடன் ஒப்பிடும்போது, memory tier அடிப்படையில் ஒரு VPS-ன் உண்மையான விலை என்ன என்பதைப் பார்த்தால், 8 GB திட்டம் என்பது கூடுதல் மாற்றங்கள் செய்யத் தேவையில்லாத மலிவான வழியாகும்.

Compose limits மூலம் ஒரு service-க்கான memory-ஐ எவ்வாறு கட்டுப்படுத்துவது

இதற்காக docker-compose.yml-ஐ திருத்த வேண்டாம். நீங்கள் wget மூலம் upgrade செய்யும் ஒவ்வொரு முறையும் அந்த file மாற்றப்படும். அதற்குப் பதிலாக docker-compose.override.yml-ல் வரம்புகளைக் குறிப்பிடவும்; இதை 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

docker stats இப்போது host-ன் மொத்த memory-க்கு பதிலாக, நீங்கள் நிர்ணயித்த உச்சவரம்பை MEM USAGE / LIMIT column-ல் காட்ட வேண்டும். limit column இன்னும் host-ன் முழு அளவைக் காட்டினால், override file கண்டறியப்படவில்லை என்று அர்த்தம்: file-ன் பெயரைச் சரிபார்த்து, இணைக்கப்பட்ட முடிவைப் பார்க்க docker compose config-ஐ இயக்கவும்.

மிகக் குறைவான வரம்பு ஒரு மெதுவான service-ஐ செயலிழக்கச் செய்துவிடும், எனவே container அடிக்கடி restart ஆனால் வரம்பை அதிகரிக்கவும். Docker Compose-ல் service வாரியாக memory வரம்புகளை அமைப்பது என்பதில் இதன் செயல்பாடுகள் குறித்த கூடுதல் தகவல்கள் உள்ளன; Swarm இல்லாமலேயே Compose v2-ல் deploy எவ்வாறு செயல்படுகிறது என்பதையும் அதில் காணலாம்.

Machine learning container-ஐ எவ்வாறு அணைப்பது அல்லது நகர்த்துவது

சிறிய server-களில், இந்த container-ஐ வேறொரு இடத்திற்கு நகர்த்துவது நீங்கள் செய்யக்கூடிய மிக முக்கியமான மாற்றமாகும். Immich-ஐ மற்றொரு machine-ல் இயக்குவதை இது ஆதரிக்கிறது. இரண்டாவது host-ல் இந்த கோப்பை உருவாக்கவும்; இது மாலை நேரங்களில் மட்டும் இயங்கும் 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 மாறுபட்டால் பிழைகளும் நிலைத்தன்மையற்ற தன்மையும் ஏற்படும் என்று Immich ஆவணங்கள் எச்சரிக்கின்றன.

அந்த port உங்கள் புகைப்படங்களை மற்ற machine-க்கு குறியாக்கப்படாமல் (unencrypted) கொண்டு செல்லும், எனவே அதை ஒரு private network-ல் வைத்திருக்கவும் அல்லது இரண்டு host-களுக்கும் இடையே ஒரு WireGuard tunnel மூலம் இயக்கவும். 3003 port-ஐ ஒருபோதும் internet-ல் திறக்க வேண்டாம்.

ஒரு resident model container-ஐ வைத்திருக்கும் யோசனையே சிக்கலாக இருந்தால், ஒரு திட்டத்தை முடிவு செய்வதற்கு முன் PhotoPrism மற்றும் Immich ஆகியவை இயங்கும் நிலையில் எவ்வாறு வேறுபடுகின்றன என்பதை ஒப்பிட்டுப் பார்ப்பது சரியான அணுகுமுறையாகும்.

Immich library-க்கு எவ்வளவு disk இடம் தேவை?

இதற்கு ஒரே ஒரு பெருக்கல் காரணி (multiplier) கிடையாது, ஏனெனில் நான்கு வெவ்வேறு விஷயங்கள் நான்கு வெவ்வேறு வேகத்தில் வளர்கின்றன. 50,000 புகைப்படங்கள் மற்றும் 500 சிறிய வீடியோக்கள் கொண்ட 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 புகைப்படங்கள் மற்றும் 60 GB வீடியோக்கள் என்பது ஒரு அனுமானம் மட்டுமே. எதையும் வாங்குவதற்கு முன் உங்கள் சொந்த சராசரி அளவுகளைக் கொண்டு இதை மாற்றிக்கொள்ளுங்கள், ஏனெனில் வீடியோவே இந்த எண்ணைத் தீர்மானிக்கிறது: ஒரு நிமிட போன் வீடியோ, நூறு புகைப்படங்களை விட அதிக இடத்தைப் பிடிக்கும்.

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 அதிகாரப்பூர்வமாக வழங்கும் விகிதமாகும்: உருவாக்கப்பட்ட thumbnails மற்றும் transcoded வீடியோக்கள், library-ன் அளவில் சராசரியாக 10 முதல் 20 சதவீதம் வரை கூடுதலாகச் சேர்க்கின்றன. இது ஒரு வரம்பாகும், ஏனெனில் உங்கள் assets-ல் எத்தனை வீடியோக்கள் browser compatibility-க்காக re-encode செய்யப்பட வேண்டும் என்பதைப் பொறுத்தது. JPEG-கள் மட்டுமே கொண்ட library இந்த வரம்பின் கீழ் எல்லையில் இருக்கும்.

Database என்பது 3 GB, இது கிட்டத்தட்ட ஒரு நிலையான செலவு போன்றது. Immich-ன் database கோப்புகள் பொதுவாக 1 முதல் 3 GB வரை இருக்கும் என்று ஆவணப்படுத்தப்பட்டுள்ளது, ஏனெனில் அவை pixels-க்கு பதிலாக metadata மற்றும் search vectors-ஐச் சேமிக்கின்றன. Model cache என்பது 2 GB, நீங்கள் பல models-ஐ இயக்கினால் அல்லது வெவ்வேறு models-ஐச் சோதித்தால் இது வளரும். இதே காரணத்திற்காகத்தான் FAQ இந்த அளவை ஒரு space consumer என்று குறிப்பிடுகிறது.

இந்த ஐந்து வரிசைகளும் சேர்ந்து 300 GB-க்கு மேல் வருகின்றன, எனவே 500 GB volume வளர்வதற்கு இடம் கொடுக்கும், ஆனால் 250 GB volume போதாது. இந்த இடப் பகிர்வை இதன் மூலம் கவனிக்கலாம்:

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

UPLOAD_LOCATION-ன் கீழ் ஆறு கோப்புறைகள் (folders) உள்ளன. upload மற்றும் library ஆகியவை originals-ஐக் கொண்டுள்ளன, thumbs previews மற்றும் face thumbnails-ஐக் கொண்டுள்ளது, encoded-video re-encoded பிரதிகளைக் கொண்டுள்ளது, profile avatars-ஐக் கொண்டுள்ளது, மற்றும் backups தானியங்கி database dumps-ஐக் கொண்டுள்ளது. upload, library மற்றும் profile மட்டுமே மாற்ற முடியாதவை, ஏனெனில் மற்ற அனைத்தும் அவற்றிலிருந்து மீண்டும் உருவாக்கப்படக்கூடியவை.

இரண்டு விஷயங்கள் பயனர்களை ஆச்சரியப்படுத்துகின்றன. நீக்கப்பட்ட assets முதலில் trash-க்குச் செல்லும், trash காலி செய்யப்படும் வரை அவை இடத்தைப் பிடித்துக்கொண்டே இருக்கும், எனவே நீங்கள் பெரிய அளவில் cleanup செய்தாலும் அன்றைய தினம் எந்த இடமும் காலியாகாது. மேலும், database dump என்பது metadata மட்டுமே, எனவே கோப்புகள் இல்லாமல் அது பயனற்றது:

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

அசல் கோப்புகளை server-க்கு வெளியே எங்காவது file level-ல் நகலெடுத்து வைத்துக்கொள்ளுங்கள், இதற்காகத்தான் restic backups from a VPS to off-server storage பயன்படுகிறது.

Transcoding-க்கு RAM அல்ல, CPU-வே தேவை

RAM-ஐ அதிகரிப்பது transcoding வேகத்தை அதிகரிக்காது. Immich, FFmpeg-ஐப் பயன்படுத்தி transcoding செய்கிறது. சாதாரண VPS-களில் ஒவ்வொரு frame-ம் CPU-வால் decode மற்றும் encode செய்யப்படுகிறது. Hardware acceleration வசதி இருந்தாலும், encoding மட்டுமே accelerate செய்யப்படுவதாக Immich ஆவணங்கள் குறிப்பிடுகின்றன. எனவே, decoding மற்றும் tone mapping ஆகியவற்றை CPU-வே செய்கிறது.

Hardware acceleration-க்கு கூடுதல் hwaccel.transcoding.yml Compose file மற்றும் NVENC, Quick Sync, RKMPP அல்லது VAAPI போன்ற device-களை pass-through செய்ய வேண்டியது அவசியம். பெரும்பாலான VPS திட்டங்களில் இந்த வசதிகள் இருப்பதில்லை, எனவே CPU-வையே முதன்மையாகக் கருதவும்.

இதற்கான நடைமுறை அமைப்பு thread count ஆகும். Administration, Settings, Video Transcoding Settings என்பதில், thread மதிப்பை 0 என வைத்தால் அது அனைத்து cores-களையும் பயன்படுத்தும். இதனால் 2 core கொண்ட திட்டங்களில் ஒரு வீடியோவை process செய்யும்போது web interface முடங்கலாம். Immich FAQ பரிந்துரைப்பது போல, அந்த மதிப்பை 1 அல்லது 2 என அமைக்கவும். இது transcode வேகத்தைக் குறைத்தாலும், ஒட்டுமொத்த system-ன் செயல்பாட்டைப் பாதிக்காது.

Swap thrashing-ஐ ஏன் hang என்று தவறாகப் புரிந்துகொள்கிறோம்

இதுவே மக்கள் அடிக்கடி தவறாகப் புரிந்துகொள்ளும் தோல்வியாகும். Immich-ன் memory தீர்ந்துவிட்டால் இரண்டு விளைவுகள் ஏற்படும், அதில் ஒன்று மட்டுமே தோல்வியாகத் தெரியும்.

Swap இல்லையென்றால், kernel ஒரு process-ஐக் கொன்றுவிடும். Container சில நொடிகளில் மீண்டும் தொடங்கும், எனவே 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 மூலம் கொல்லப்பட்டது என்பதைக் குறிக்கிறது. 137 என்பது 128 மற்றும் 9-ன் கூட்டுத்தொகை. OOMKilled-ன் மதிப்பு true ஆக இருப்பது, அது crash ஆகாமல் memory பற்றாக்குறையால்தான் கொல்லப்பட்டது என்பதை உறுதிப்படுத்துகிறது.

Swap இருந்தால், எதுவும் கொல்லப்படாது, எந்தப் பிழையும் ஏற்படாது. Kernel பக்கங்களை (pages) disk-க்கு மாற்றத் தொடங்கும், import வேகம் பல மடங்கு குறையும், web interface குறிப்பிட்ட நேரத்திற்குள் பதில் அளிக்காமல் நின்றுவிடும். அனைத்து container-களும் இயங்கிக்கொண்டிருக்கும். அனைத்து health check-களும் தேர்ச்சி பெறலாம். இது ஒரு hang போலத் தெரியும், இந்த நிலையில் மக்கள் server-ஐ reboot செய்வார்கள், இதனால் queue-ன் முன்னேற்றம் இழக்கப்படும், எந்த மாற்றமும் நிகழாது.

free -m
vmstat 1 5

vmstat-ன் si மற்றும் so நெடுவரிசைகளில் தொடர்ந்து பூஜ்ஜியமற்ற மதிப்புகள் இருந்தால், கணினி தொடர்ந்து swap-ஐ வாசித்து எழுதுகிறது என்று அர்த்தம், இதுவே thrashing-ன் வரையறையாகும். அதே நேரத்தில் Swap பயன்பாட்டிற்கான free -m வரிசை அதிகரித்துக்கொண்டே இருக்கும்.

2 GB அல்லது 4 GB அளவுள்ள கணினிகளில் எப்படியும் swap-ஐச் சேர்க்கவும், ஏனெனில் கண்டறிய முடியாத ஒரு container தோல்வியை விட, மெதுவாக நடக்கும் import-ஐக் கண்டறிவது சிறந்தது:

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-ன் பயன்பாட்டைக் கட்டுப்படுத்தவும் அல்லது அதை வேறொரு host-க்கு மாற்றவும். Swap உங்களுக்கு அதைச் செய்வதற்கான கால அவகாசத்தை மட்டுமே வழங்கும். அதுவே தீர்வாகாது.

FAQ

2 GB VPS-ல் என்னால் Immich-ஐ இயக்க முடியுமா?

ஆம், immich-machine-learning service-ஐ docker-compose.yml-ல் comment செய்துவிட்டு, job concurrency-ஐ 1 என அமைத்தால் இயக்கலாம். இது ஆவணப்படுத்தப்பட்ட குறைந்தபட்ச தேவையான 6 GB-க்கும் குறைவு என்பதால், இதை ஒரு சமரசமாகவே கருத வேண்டும். நீங்கள் uploads, albums, sharing, mobile backup மற்றும் தேதி, இடம், கோப்பு பெயர் வாரியான தேடல் வசதிகளைப் பெறலாம். ஆனால், விவரணை (description) வாரியான தேடல், முகங்களை தானாகவே குழுப்படுத்துதல் மற்றும் படங்களுக்குள் இருக்கும் உரையை அடையாளம் காணுதல் ஆகிய வசதிகளை இழப்பீர்கள். 2 GB swap file-ஐச் சேர்ப்பது நல்லது; அப்போதுதான் import செய்யும்போது வேகம் குறைந்தாலும், container திடீரென நிறுத்தப்படாமல் (killed) இருக்கும்.

எனது Immich import ஏன் எந்த பிழைச் செய்தியும் இன்றி நிற்கிறது?

உலாவி (browser) பார்வையில் இரண்டு வெவ்வேறு காரணங்கள் ஒரே மாதிரியாகத் தெரியும். ஒன்று, நினைவகப் பற்றாக்குறையால் container நிறுத்தப்பட்டிருக்கலாம்; அப்போது docker ps -a கட்டளையில் Exited (137) என்று காட்டும் மற்றும் container ஏற்கனவே restart ஆகியிருக்கும். அல்லது, host கணினி swap ஆகிக்கொண்டிருக்கலாம்; அப்போது அனைத்து container-களும் இயங்கிக்கொண்டிருக்கும், ஆனால் வேகம் மிகக் குறைவாக இருக்கும். vmstat 1 5 இவற்றை வேறுபடுத்திக் காட்டும்: si மற்றும் so நெடுவரிசைகளில் தொடர்ந்து பூஜ்ஜியம் அல்லாத எண்கள் இருந்தால், அது swap ஆவதைக் குறிக்கும். எந்தச் சூழலிலும், thumbnail உருவாக்கம், முகத்தை அடையாளம் காணுதல் மற்றும் smart search ஆகியவற்றிற்கான job concurrency-ஐக் குறைக்கவும்.

Immich logs-ல் exit code 137 என்றால் என்ன?

137 என்பது 128 உடன் signal 9-ஐக் கூட்டியது; அதாவது, அந்த process SIGKILL மூலம் நிறுத்தப்பட்டுள்ளது. நடைமுறையில், இது நினைவக வரம்பை (memory ceiling) எட்டியதைக் குறிக்கிறது; இது container-ன் சொந்த வரம்பாகவோ அல்லது host கணினியின் நினைவகம் தீர்ந்ததாகவோ இருக்கலாம். docker inspect immich_machine_learning | grep -i oomkilled மூலம் இதைச் சரிபார்க்கவும். true என்ற மதிப்பு, நினைவகப் பற்றாக்குறையால் kernel அந்த process-ஐ நிறுத்தியதை உறுதிப்படுத்தும். மேலும், free -m மற்றும் sudo dmesg -T | grep -i oom-kill ஆகியவற்றைச் சரிபார்ப்பதன் மூலம், அது container வரம்பா அல்லது முழு host கணினியின் வரம்பா என்பதை அறியலாம். பொதுவாக machine learning container தான் பெரிய process என்பதால், அதுவே முதலில் பாதிக்கப்படும்.

ஒரு புகைப்படத்திற்கு Immich-க்கு எவ்வளவு disk space தேவை?

அசல் கோப்புடன் கூடுதலாக 10 முதல் 20 சதவீதம் வரை ஒதுக்கீடு செய்யவும். உருவாக்கப்பட்ட thumbnails மற்றும் மாற்றப்பட்ட (transcoded) வீடியோக்கள், library-ன் அளவை சராசரியாக 10 முதல் 20 சதவீதம் வரை அதிகரிக்கும் என்று Immich ஆவணங்கள் கூறுகின்றன. பெரிய library-ஆக இருந்தாலும், database-ன் அளவு பொதுவாக 1 முதல் 3 GB வரை மட்டுமே இருக்கும். வீடியோக்களே உங்கள் மொத்தத் தேவையைத் தீர்மானிக்கும் என்பதால், புகைப்படங்களின் எண்ணிக்கையை மட்டும் கணக்கிடாமல், உங்கள் சராசரி கோப்பு அளவை அளவிட்டுத் திட்டத்தைத் தேர்ந்தெடுக்கவும்.

Immich-க்கு GPU தேவையா?

இல்லை. Immich-ன் அனைத்துப் பகுதிகளும் CPU-விலேயே இயங்கும். ஒரு graphics card இருந்தால் machine learning container-ல் model inference மற்றும் video encoding வேகமடையும், ஆனால் இவை கட்டாயமல்ல. பெரும்பாலான VPS திட்டங்களில் GPU வசதி இருக்காது. CPU-வில் மட்டும் இயங்கும் வன்பொருளில், transcoding threads-ஐ 1 அல்லது 2 என அமைக்கவும், buffalo_s face model-ஐப் பயன்படுத்தவும், முதல்முறை பெரிய அளவிலான import-ஐ இரவு நேரத்தில் இயங்க விடவும்.