Docker Compose memory limit அமைப்பது எப்படி?

Docker Compose memory limit எதைச் செய்கிறது

Docker Compose memory limit என்பது Linux kernel ஒரு container-ன் cgroup-க்கு (control group, இது process-களின் தொகுப்பிற்கான வளங்களை அளவிடும் kernel அம்சம்) விதிக்கும் ஒரு கடுமையான வரம்பாகும். ஒரு service-ல் deploy.resources.limits.memory-ஐ அமைத்தால், அந்த container நீங்கள் குறிப்பிட்ட அளவை விட அதிகமாகப் பயன்படுத்த முடியாது. அது மீற முயலும்போது, kernel அந்த container-க்குள் இருக்கும் ஒரு process-ஐக் கொன்றுவிடும், மேலும் அந்த container பொதுவாக 137 என்ற code-உடன் வெளியேறும்.

RAM அளவு நிலையாக இருக்கும் மற்றும் கடன் வாங்க கூடுதல் host memory இல்லாத VPS-களில் இது மிக முக்கியமானது. memory leak அல்லது தவறான query கொண்ட ஒரு container, 8GB அளவுள்ள ஒரு server-ல் உள்ள அனைத்து free page-களையும் எடுத்துக்கொள்ளும். அப்போது kernel தனக்கு மோசமானதாகத் தோன்றும் process-ஐக் கொன்றுவிடும்; இது பெரும்பாலும் சிக்கலை உருவாக்கிய container-ஆக இருக்காது, மாறாக database அல்லது உங்கள் SSH session-ஆக இருக்கலாம். வரம்புகளை அமைப்பது, முழு server-ம் முடங்குவதைத் தவிர்த்து, ஒரு service மட்டும் restart ஆகுமாறு செய்கிறது.

services:
  app:
    image: ghcr.io/example/app:1.4
    deploy:
      resources:
        limits:
          cpus: "1.5"
          memory: 1g
        reservations:
          memory: 256m

இதைச் செயல்படுத்தி, வரம்பு நடைமுறையில் உள்ளதா என்பதை உறுதிப்படுத்தவும்:

docker compose up -d
docker stats --no-stream

MEM USAGE / LIMIT column-ல் 142MiB / 1GiB போன்ற ஒரு மதிப்பு இருக்க வேண்டும். limit column-ல் முழு host RAM-ம் காட்டப்பட்டால், அந்த அமைப்பு சரியாகப் பொருந்தவில்லை என்று அர்த்தம்; அது சரியாகப் பொருந்தும் வரை இந்த வழிகாட்டியின் பிற பகுதிகள் உதவாது. compose file உங்களுக்குப் புதியது என்றால், VPS-க்கான Docker Compose அடிப்படைகள் பகுதி, இதன் கட்டமைப்பை விளக்குகிறது.

deploy.resources.limits அல்லது mem_limit: எது பொருந்தும்

ஒரே கருத்தை குறிக்க இரண்டு எழுத்துப்பிழைகள் இருப்பதால், இது குழப்பத்தை ஏற்படுத்துகிறது.

mem_limit, mem_reservation, memswap_limit, cpus மற்றும் cpu_shares ஆகியவை பழைய Compose கோப்பு வடிவங்களிலிருந்து பெறப்பட்ட உயர்மட்ட service keys ஆகும். deploy.resources என்பது Swarm schema-விலிருந்து வந்தது, இது இப்போது Compose Specification-ன் ஒரு பகுதியாகும்; இதைத்தான் docker compose இன்று வாசிக்கிறது.

இவை இரண்டும் ஒரே host-ல் வேலை செய்யும். நீங்கள் docker compose up-ஐ இயக்கும்போது, Docker Compose எனும் docker compose plugin, deploy.resources.limits மற்றும் deploy.resources.reservations ஆகியவற்றைச் செயல்படுத்துகிறது; இதற்கு Swarm cluster தேவையில்லை. இந்த plugin இப்போது v5 வரிசையில் உள்ளது (2026-10-10 அன்று சரிபார்க்கப்பட்டபோது v5.6.0 சமீபத்திய stable release ஆகும்). பழைய Compose கோப்பு வடிவ பதிப்புகளுடன் குழப்பத்தைத் தவிர்க்க, v3 மற்றும் v4-ஐத் தவிர்த்துவிட்டு, v2-லிருந்து நேரடியாக v5-க்கு மாறியது. எந்தவொரு v5 release-ம் resource limits கையாளப்படும் விதத்தை மாற்றவில்லை. deploy தொகுதியின் Swarm சார்ந்த பகுதிகள் மற்ற keys ஆகும்; உதாரணமாக, placement, update_config மற்றும் endpoint_mode போன்றவை docker stack deploy-க்கான cluster of nodes முழுவதும் scheduling மற்றும் rollouts-ஐ விவரிக்கின்றன. எனவே, "deploy-க்கு Swarm தேவை" என்ற பொதுவான அறிவுரை resources subsection-க்கு தவறானது; அதைப் பின்பற்றினால் உங்கள் services-க்கு எந்த வரம்பும் (limit) இருக்காது.

ஒவ்வொரு project-க்கும் ஒரு எழுத்துப்பிழையைத் தேர்வு செய்யவும். ஒரே service-ல் mem_limit: 512m மற்றும் deploy.resources.limits.memory: 1g ஆகிய இரண்டையும் எழுதுவது வாசிப்பதற்கு கடினமாக இருப்பது மட்டுமல்லாமல், mem_limit அமைக்கப்பட்டிருக்கும்போது அது limits.memory-உடன் ஒத்துப்போக வேண்டும் என்று Compose Specification கூறுகிறது; அவை முரண்படும்போது எந்த மதிப்பு எடுத்துக்கொள்ளப்படும் என்று அது குறிப்பிடவில்லை. நீங்கள் எந்த எழுத்துப்பிழையைப் பயன்படுத்தினாலும், daemon உண்மையில் எதைச் செயல்படுத்தியது என்பதை உறுதிப்படுத்தவும்:

docker inspect --format '{{.HostConfig.Memory}} {{.HostConfig.MemoryReservation}} {{.HostConfig.NanoCpus}}' app-1

Memory மதிப்புகள் bytes-ல் இருக்கும், எனவே 1g என்பது 1073741824 என அச்சிடப்படும். CPU என்பது nano CPUs-ல் இருக்கும், எனவே 1.5 என்பது 1500000000 என அச்சிடப்படும். எந்தவொரு field-லும் 0 என்பது எந்த வரம்பும் அமைக்கப்படவில்லை என்பதைக் குறிக்கிறது. Docker ஏற்கும் மிகச்சிறிய memory limit 6m ஆகும்; அதற்கு குறைவாக இருந்தால் container தொடங்க மறுத்துவிடும்.

ஒரு container அதன் வரம்பை எட்டும்போது என்ன நடக்கும்

Container-ன் வேகம் குறையாது. அது செயலிழந்துவிடும்.

ஒரு process ஒரு page-ஐக் கேட்கும்போது, cgroup ஏற்கனவே அதன் memory.max-ல் இருந்தால், kernel முதலில் அந்த cgroup-க்குள் மீட்கக்கூடியவற்றை (clean page cache, பின்னர் swap செய்யக்கூடிய பக்கங்கள்) மீட்கும். மீட்பு நடவடிக்கை போதுமான நினைவகத்தை விடுவிக்கவில்லை என்றால், cgroup OOM (out of memory) killer அந்த container-க்குள் உள்ள ஒரு process-ஐத் தேர்ந்தெடுத்து அதற்கு SIGKILL-ஐ அனுப்பும். Container-ன் PID 1-ஐக் கொல்வது அந்த container-ஐ முடிவுக்குக் கொண்டுவரும். Exit code 137 என்பது 128 மற்றும் signal 9-ன் கூடுதல் ஆகும். எனவே, 137 என்பது எந்தவொரு SIGKILL-க்கும் பொதுவான அடையாளமே தவிர, அது மட்டுமே OOM-க்கான சான்று அல்ல.

docker compose ps -a
docker inspect --format '{{.State.OOMKilled}} {{.State.ExitCode}}' app-1

true 137 என்பது ஒரு OOM kill ஆகும். false 137 என்பது பொதுவாக வேறொரு காரணத்தால் SIGKILL அனுப்பப்பட்டதைக் குறிக்கும் (ஒரு program வேண்டுமென்றே 137-ஐக் கொண்டு வெளியேறலாம், ஆனால் அது அரிது). வழக்கமான காரணம், ஒரு application SIGTERM-ஐப் புறக்கணித்ததால் docker compose stop அதன் பத்து வினாடி கால அவகாசத்தை (grace period) எட்டியதே ஆகும். இந்த வேறுபாட்டை அறிந்துகொள்வது பல மணிநேரங்களை மிச்சப்படுத்தும், ஏனெனில் இவ்விரு சிக்கல்களுக்கும் எந்தத் தொடர்பும் இல்லை.

இந்த நிகழ்வை இன்னும் இரண்டு இடங்களில் பதிவு செய்யலாம். Daemon-ஐ நேரடியாகக் கவனிக்க:

docker events --filter event=oom

பின்னர், restart செய்த பிறகும் அழியாத பதிவான kernel log-ஐப் படிக்கவும்:

sudo dmesg -T | grep -i -E 'memory cgroup out of memory|killed process'

ஒரு cgroup kill, Memory cgroup out of memory: Killed process 24713 (node) என்று தொடங்கும் வரியைப் பதிவிடும். அந்த வரி, ஒரு container அதன் சொந்த வரம்பை எட்டியதைக் குறிக்கிறது. host-ல் போதுமான RAM இருக்கும்போதே இது நிகழலாம். Memory cgroup முன்னொட்டு இல்லாத வரி என்பது host OOM-ஐக் குறிக்கும்; அதாவது machine-ன் ஒட்டுமொத்த RAM தீர்ந்துவிட்டது என்று பொருள். இந்தத் தோல்வியைத் தடுப்பதற்காகவே வரம்புகள் (limits) அமைக்கப்படுகின்றன. எனவே, அத்தகைய வரி தென்பட்டால், உங்கள் வரம்புகளின் கூட்டுத்தொகை மிக அதிகமாக உள்ளது, சில services-க்கு வரம்புகள் இல்லை, அல்லது Docker-க்கு வெளியே ஏதோ ஒன்று நீங்கள் ஒதுக்கிய மீதமுள்ள நினைவகத்தை விட அதிகமாகப் பயன்படுத்துகிறது என்று பொருள்.

restart: unless-stopped-உடன், OOM loop எளிதில் மறைந்துவிடும், ஏனெனில் service இறந்த ஒரு வினாடிக்குள்ளேயே docker compose ps-ல் மீண்டும் உயிருடன் இருப்பது போலத் தோன்றும். Uptime column மற்றும் restart count-ஐச் சரிபார்க்கவும். வரம்புடன் சேர்த்து app-ஐ unhealthy என்று காட்டும் healthcheck-ஐப் பயன்படுத்தவும். அப்போதுதான், தொடர்ந்து இறக்கும் ஒரு container உங்கள் கண்காணிப்பு இல்லாமலேயே கண்டறியப்படும்.

Reservation என்பது ஒரு குறிப்பு மட்டுமே, limit என்பதே விதி

reservations.memory (பழைய mem_reservation) என்பது ஒரு soft floor ஆகும். ஹோஸ்ட் கணினியில் நினைவகப் பற்றாக்குறை அல்லது நெரிசல் ஏற்படும்போது, இந்த soft limit செயல்படும் என்று Docker குறிப்பிடுகிறது. இது ஒரு container-ஐ அந்த அளவுக்கு மேல் செல்வதைத் தடுப்பதில்லை; மேலும், container நினைவகத்தைக் கோரும்போது அது கிடைக்கும் என்பதற்கு எந்த உத்தரவாதமும் இல்லை. இது, தனது reservation அளவைத் தாண்டிய container-களிடமிருந்து நினைவகத்தை முதலில் திரும்பப் பெறுமாறு kernel-க்கு அறிவுறுத்துகிறது.

எனவே, ஒரு reservation எதையும் தனியாகப் பாதுகாப்பதில்லை. அழுத்தமான சூழலில் ஒரு service-க்கு முன்னுரிமை அளிக்க விரும்பினால் மட்டுமே இதைப் பயன்படுத்தவும்; பாதுகாப்பிற்கு limit-ஐச் சார்ந்திருக்கவும். Reservation அளவை limit-க்குக் குறைவாகவே வைக்கவும்; இல்லையெனில் container தொடங்காது: Docker அந்த உள்ளமைவை Minimum memory limit can not be less than memory reservation limit பிழையுடன் நிராகரித்துவிடும்.

Swap accounting, உண்மையான நிலை

பெரும்பாலான VPS images-ல் swap file இருப்பதில்லை. swapon --show மற்றும் free -h கட்டளைகளை இயக்கவும். swap-ன் மொத்த அளவு பூஜ்ஜியமாக இருந்தால், கீழே உள்ள swap தொடர்பான எந்த அமைப்பும் செயல்படாது; உங்கள் memory limit என்பது RAM-க்கான கட்டுப்பாடு மட்டுமே.

memswap_limit என்பது swap-ன் அளவு அல்ல. இது memory மற்றும் swap ஆகியவற்றின் மொத்தக் கூட்டுத்தொகை ஆகும். mem_limit: 1g மற்றும் memswap_limit: 2g அமைப்புகளைப் பயன்படுத்தினால், container-க்கு 1GB RAM மற்றும் 1GB swap கிடைக்கும். இந்த இரண்டு மதிப்புகளையும் சமமாக அமைத்தால், container-க்கு swap கிடைக்காது. mem_limit மதிப்பை அமைத்து, memswap_limit மதிப்பை மாற்றாமல் விட்டால், container அதன் memory limit அளவுக்கு மீண்டும் swap-ஐப் பயன்படுத்திக்கொள்ளும்.

Ubuntu 24.04 மற்றும் Debian 13 இயல்பாகவே cgroup v2-ஐப் பயன்படுத்துகின்றன. இதில் swap என்பது தனித்தனி counter (memory.swap.max) ஆக இருப்பதால், கூடுதல் அமைப்பு ஏதுமின்றி இது செயல்படும். Your kernel does not support swap limit capabilities என்ற பழைய செய்தி, swapaccount=1 இல்லாமல் boot செய்யப்பட்ட cgroup v1 hosts-லிருந்து வருகிறது. அத்தகைய சூழலில், memory limit செயல்படும், ஆனால் swap பகுதி புறக்கணிக்கப்படும்.

Swap-ஆல் உங்களுக்கு என்ன பயன் என்பதைத் தெளிவாகப் புரிந்துகொள்ளுங்கள். இது OOM kill-ஐத் தடுக்காது, மாறாக அதைத் தாமதப்படுத்தும்; ஏனெனில், memory leak உள்ள ஒரு process RAM-ஐ நிரப்புவது போலவே swap-ஐயும் நிரப்பிவிடும். அதே நேரத்தில், பகிரப்பட்ட VPS storage-ல் ஒரு container swap-ஐத் தொடர்ந்து பயன்படுத்தினால் (thrashing), அந்த server-ல் உள்ள மற்ற அனைத்து service-களும் மந்தமாகும். latency-ஐ உணரும் எந்தவொரு சேவைக்கும், swap இல்லாமல் சரியான limit-ஐ அமைப்பதே சிறந்தது; இது தோல்வியைத் துல்லியமாகவும் விரைவாகவும் கண்டறிய உதவும்.

நினைவகப் பயன்பாடு ஏன் உண்மையான அளவை விட அதிகமாகத் தெரிகிறது

Linux-ல், docker stats-ல் உள்ள MEM USAGE மதிப்பு, செயலற்ற page cache-ஐ (cgroup v2-ல் inactive_file) மட்டுமே கழிக்கிறது. எனவே, சமீபத்தில் பயன்படுத்தப்பட்ட cache தொடர்ந்து கணக்கிடப்படும். பெரிய கோப்புகளை வாசிக்கும் ஒரு container அதன் வரம்பை நோக்கி உயர்ந்து அங்கேயே தங்கிவிடும். இது இயல்பானது, இது நினைவகக் கசிவு (leak) அல்ல. ஏனெனில், OOM killer செயல்படுவதற்கு முன்பே clean cache விடுவிக்கப்பட்டுவிடும். சுயமாக இயங்கும் Jellyfin media server போன்ற ஒரு சேவை, சரியாக இந்த காரணத்திற்காகவே எப்போதும் அதன் உச்ச வரம்பிற்கு அருகிலேயே இருப்பது போலத் தோன்றும்.

Container-க்குள் இருந்து அந்த எண்ணை cache மற்றும் உண்மையான working set எனப் பிரிக்கவும்:

docker compose exec app grep -E '^(anon|file) ' /sys/fs/cgroup/memory.stat
docker compose exec app cat /sys/fs/cgroup/memory.events

anon என்பது anonymous memory, அதாவது கைவிட முடியாத working set. file என்பது page cache, இதை விடுவிக்க முடியும். உங்கள் வரம்பை (limit) மொத்த அளவை வைத்து நிர்ணயிக்காமல், anon மற்றும் ஒரு சிறிய கூடுதல் அளவை (margin) வைத்து நிர்ணயிக்கவும். memory.events கோப்பு இந்த விவாதத்திற்கு முற்றுப்புள்ளி வைக்கிறது: oom_kill counter பூஜ்ஜியத்திற்கு மேல் இருந்தால், container தொடங்கியதிலிருந்து kernel ஏதோ ஒன்றை நீக்கியுள்ளது என்று அர்த்தம். max counter அதிகரித்துக்கொண்டே இருந்தால், container தற்போது அதன் உச்ச வரம்பில் கட்டுப்படுத்தப்படுகிறது என்று அர்த்தம். இந்த இரண்டு கட்டளைகளுக்கும் image-க்குள் shell மற்றும் coreutils தேவை; எனவே distroless அல்லது scratch image-களில் இவை இயங்காது.

8GB VPS-க்கான அளவு வரம்புகள்

Host-லிருந்து தொடங்கவும், application-களிலிருந்து அல்ல. 8GB VPS-ல், kernel, Docker daemon, sshd, journald மற்றும் உங்கள் login shell ஆகியவற்றுக்கு சுமார் 1GB-ஐ ஒதுக்கிவிடவும். மீதமுள்ள 7GB-ஐப் பகிர்ந்தளிக்கலாம்; அனைத்து container வரம்புகளின் கூட்டுத்தொகை இதற்குள் இருக்க வேண்டும். இரண்டு சேவைகள் ஒரே நேரத்தில் உச்சகட்ட பயன்பாட்டை எட்டும் நாள் வரை, அதிகப்படியான ஒதுக்கீடு (overcommitting) வேலை செய்யும்.

8GB வசதி கொண்ட ஒரு server-ல் நடைமுறைக்குச் சாத்தியமான பகிர்வு:

• Reverse proxy: 128m வரம்பு. இது ஒரு சிறிய process; இந்த இறுக்கமான வரம்பு, தவறான config reload ஏற்பட்டால் உடனடியாக அதைக் கண்டறிய உதவும்.
• PostgreSQL: 2g வரம்பு, database config-ல் shared_buffers சுமார் 512MB என அமைக்கப்பட வேண்டும்.
• Application container: 1g வரம்பு.
• Background worker: 512m வரம்பு.
• Media அல்லது file service: 2g வரம்பு, இதில் பெரும்பகுதி page cache-ஆக இருக்கும்.

இந்த எண்களை அப்படியே உங்கள் stack-ல் நகலெடுக்க வேண்டாம். சேவைகளை ஒரு நாள் முழுமையான சுமையின் கீழ் இயக்கி, docker stats-ஐக் கவனிக்கவும். ஒவ்வொரு container-க்கும் உச்சகட்ட anon மதிப்பைக் குறித்துக்கொண்டு, அதனுடன் கூடுதலாக சுமார் பாதி அளவு headroom-ஐச் சேர்க்கவும். மிக இறுக்கமான வரம்பு, வரம்பு இல்லாமலிருப்பதை விட மோசமானது; ஏனெனில் இது சாதாரண traffic spike-ன் போது ஆரோக்கியமான சேவையையும் நிறுத்திவிடும்.

ஒரு சிக்கல் தனியாகக் கவனிக்கப்பட வேண்டியது. சில runtimes-க்கு நீங்கள் சொல்லும் வரை அவை வரம்புகளைப் புறக்கணிக்கும்; சில runtimes வரம்பைப் படித்தாலும், நீங்கள் எதிர்பார்ப்பது போல தங்களைச் சரிசெய்து கொள்ளாது. PostgreSQL அதன் container வரம்பைத் தாண்டி shared_buffers மற்றும் work_mem-ஐ அமைத்துக்கொள்ளும், இதனால் அது கொல்லப்படும் (killed). நவீன JVM (Java virtual machine) இயல்பாகவே cgroup வரம்பைக் கண்டறியும், ஆனால் OpenJDK போன்ற HotSpot builds அதன் heap-க்கு 25 சதவீதத்தை மட்டுமே ஒதுக்கும். எனவே, heap-க்கு அதிக இடமளிக்கவும், அதே சமயம் heap-க்கு வெளியே நினைவகத்திற்கு இடம் விடவும் -XX:MaxRAMPercentage=75-ஐப் பயன்படுத்துவது வழக்கம். Node.js அதன் default heap-ஐ version 12 முதல் cgroup வரம்பிலிருந்து, அதாவது container வரம்பில் பாதியாக, 2GB வரை அமைக்கிறது. எனவே, உங்களுக்கு வேறு உச்சவரம்பு தேவைப்படும்போது மட்டும் --max-old-space-size-ஐ megabytes-ல் அமைக்கவும். kernel தலையிடுவதற்கு முன்பே garbage collector வேலை செய்ய, இதை container வரம்பிற்குள் வைத்திருக்கவும். Ollama-விலும் இதே நிலைதான், ஆனால் வேறு knob-ஐப் பயன்படுத்த வேண்டும். ஏனெனில் num_ctx-ஐ அதிகரிப்பது KV cache-ஐ பல நூறு megabytes உயர்த்தும், இதனால் நீண்ட prompt-களின் போது container பாதியிலேயே நின்றுவிடும். cgroup பேச்சுவார்த்தை நடத்தாது. அது நேரடியாக நிறுத்திவிடும்.

CPU வரம்புகள் முற்றிலும் மாறுபட்ட முறையில் செயல்படுகின்றன

cpus: "1.5" என்பது ஒரு core-ன் 150% திறனைக் குறிக்கிறது, இது CFS (completely fair scheduler) ஒதுக்கீடாக அமல்படுத்தப்படுகிறது. ஒவ்வொரு 100ms கால அளவிலும், அந்த container-க்கு 150ms CPU நேரம் வழங்கப்படுகிறது; இது அதன் அனைத்து threads-க்கும் பகிரப்படுகிறது. இந்த நேரத்தைப் பயன்படுத்திய பிறகு, அடுத்த கால அளவு தொடங்கும் வரை kernel அந்தச் செயல்பாட்டை நிறுத்தி வைக்கும்.

இதுவே மிக முக்கியமான வேறுபாடு. Memory வரம்பைத் தாண்டும் container-ஐ kernel உடனடியாக நிறுத்திவிடும் (killed). ஆனால், CPU வரம்பைத் தாண்டும் container throttled செய்யப்பட்டு, மெதுவான வேகத்தில் தொடர்ந்து இயங்கும். எனவே, CPU வரம்பை மிகக் கடுமையாக நிர்ணயிப்பது பாதுகாப்பானது, ஆனால் memory வரம்பிற்கு கூடுதல் இடம் (headroom) தேவை.

cpu_shares என்பது ஒரு மாறுபட்ட கருவி: இது CPU முழுமையாகப் பயன்படுத்தப்படும்போது (saturated) மட்டுமே செயல்படும் ஒரு சார்பு எடை (relative weight) ஆகும். 1024 மற்றும் 512 shares கொண்ட இரண்டு containers, ஒரு busy core-ஐ ஏறக்குறைய இரண்டுக்கு ஒன்று என்ற விகிதத்தில் பகிர்ந்து கொள்ளும்; அதே சமயம், CPU சும்மா இருக்கும்போது (idle) எந்தக் கட்டுப்பாடும் இருக்காது. சேவைகளின் முக்கியத்துவத்தை வரிசைப்படுத்த shares-ஐப் பயன்படுத்தவும். ஒரு குறிப்பிட்ட பணியின் வேகத்தைக் கட்டுப்படுத்த (உதாரணமாக, இரவு நேர transcode வேலை உங்கள் web server-ஐப் பாதிக்காமல் இருக்க) cpus-ஐப் பயன்படுத்தவும்.

FAQ

Docker Swarm இல்லாமல் deploy.resources.limits வேலை செய்யுமா?

ஆம். Docker Compose, docker compose plugin (தற்போது v5 வரிசையில் உள்ளது), நீங்கள் ஒரு single host-ல் docker compose up இயக்கும்போது deploy.resources.limits மற்றும் deploy.resources.reservations ஆகியவற்றைச் செயல்படுத்தும். இதை docker inspect --format '{{.HostConfig.Memory}}' <container> மூலம் உறுதிப்படுத்தலாம்; இது வரம்பை bytes-ல் காட்டும், வரம்பு எதுவும் விதிக்கப்படவில்லை எனில் 0 என்று காட்டும். deploy-க்குள் உள்ள Swarm-ஐ மையமாகக் கொண்ட keys, cluster சார்ந்தவை, உதாரணமாக placement, update_config மற்றும் endpoint_mode.

Docker Compose-ல் exit code 137 எதைக் குறிக்கிறது?

இது பெரும்பாலும் முதன்மை process SIGKILL-ஐப் பெற்றுள்ளது என்பதையே குறிக்கும், ஏனெனில் 137 என்பது 128 உடன் signal 9-ஐக் கூட்டினால் கிடைப்பது (ஒரு program வேண்டுமென்றே 137-ஐ exit code-ஆகக் கொடுக்கலாம், ஆனால் அது அரிது). Kernel OOM killer தான் இதற்குப் பொதுவான காரணம், ஆனால் ஒரு application SIGTERM-ஐப் புறக்கணிக்கும்போது shutdown timeout-ம் இதே code-ஐ உருவாக்கும். இரண்டையும் வேறுபடுத்தி அறிய docker inspect --format '{{.State.OOMKilled}} {{.State.ExitCode}}' <container>-ஐ இயக்கவும். true 137 என்பது memory kill, false 137 என்பது அதுவல்ல.

நான் mem_limit அல்லது deploy.resources.limits.memory எதை அமைக்க வேண்டும்?

இரண்டுமே docker compose-உடன் வேலை செய்யும். deploy.resources.limits.memory என்பது தற்போதைய Compose Specification வடிவம், புதிய கோப்புகளுக்கு இதுவே சிறந்த தேர்வு. உங்கள் கோப்பின் பிற பகுதிகள் பழைய top-level keys-ஐப் பயன்படுத்தினால், mem_limit-ஐத் தொடரவும். Compose Specification, இரண்டையும் அமைக்கும்போது அவை சீராக இருக்க வேண்டும் என்று வலியுறுத்துகிறது, எனவே ஏதேனும் ஒன்றை மட்டும் தேர்வு செய்து docker inspect மூலம் முடிவைச் சரிபார்க்கவும்.

எனது container கொல்லப்படாமல் அதன் முழு memory வரம்பிலேயே இருப்பது ஏன்?

docker stats-ல் உள்ள பயன்பாட்டு எண்ணிக்கை, சமீபத்தில் பயன்படுத்தப்பட்ட page cache-ஐயும் கணக்கில் கொள்கிறது. OOM kill-ஐத் தூண்டுவதற்குப் பதிலாக, அழுத்தம் ஏற்படும்போது kernel இந்த cache-ஐ நீக்கிவிடும். docker compose exec <service> grep -E '^(anon|file) ' /sys/fs/cgroup/memory.stat-ஐ இயக்கி, மீட்க முடியாத working set-ஐக் குறிக்கும் anon மதிப்பைப் படிக்கவும். anon மதிப்பு குறைவாக இருக்கும்போது file மதிப்பு அதிகமாக இருந்தால், அந்த container disk input மற்றும் output செய்கிறது என்று பொருள், அது அழியப்போகும் நிலையில் இல்லை.

8GB VPS-ல் எவ்வளவு RAM ஒதுக்கீடு செய்யாமல் வைத்திருக்க வேண்டும்?

Kernel, Docker daemon, sshd, journald மற்றும் உங்கள் shell ஆகியவற்றிற்காக சுமார் 1GB-ஐ ஒதுக்கிவிட்டு, மீதமுள்ள 7GB-க்குள் அனைத்து container வரம்புகளின் கூட்டுத்தொகையை வைத்திருக்கவும். எண்களை உறுதிப்படுத்தும் முன், ஒரு நாள் முழுவதும் உண்மையான சுமையின் கீழ் ஒவ்வொரு container-ன் உச்சகட்ட anon மதிப்பைக் கவனிக்கவும். மொத்தத் தொகையை ஒரு இலக்காகக் கருதாமல், ஒரு வரவு-செலவுத் திட்டமாக (budget) அணுகவும்.