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 அடிப்படைகள் பகுதியில் இந்த file அமைப்பு பற்றி விளக்கப்பட்டுள்ளது.

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 இன்று படிக்கிறது.

இவை இரண்டும் ஒரு single host-ல் வேலை செய்யும். நீங்கள் docker compose up-ஐ இயக்கும்போது, Swarm cluster இல்லாமலேயே docker compose plugin-ஆன Compose V2, deploy.resources.limits மற்றும் deploy.resources.reservations ஆகியவற்றைச் செயல்படுத்தும். deploy தொகுதியில் உள்ள Swarm-க்கு மட்டுமேயான பிற keys இவை: mode, placement, update_config மற்றும் endpoint_mode ஆகியவை docker stack deploy-க்கு மட்டுமே அர்த்தமுள்ளவை, மேலும் இவை docker compose up-ஆல் புறக்கணிக்கப்படும். எனவே, "deploy-க்கு Swarm தேவை" என்ற பொதுவான அறிவுரை resources உட்பிரிவுக்குப் பொருந்தாது; அதைப் பின்பற்றுவது உங்கள் services-க்கு எந்தவிதமான வரம்பும் இல்லாமல் செய்துவிடும்.

ஒவ்வொரு project-க்கும் ஒரு எழுத்துப்பிழையைத் தேர்வு செய்யவும். ஒரே service-ல் mem_limit: 512m மற்றும் deploy.resources.limits.memory: 1g ஆகிய இரண்டையும் எழுதுவது, கோப்பை எவராலும் எளிதில் புரிந்துகொள்ள முடியாதபடி மாற்றும். எந்த மதிப்பு அமல்படுத்தப்பட்டது என்று ஊகிப்பதற்குப் பதிலாக, 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 வரம்பு 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-ஐ அனுப்பியதைக் குறிக்கிறது. பொதுவாக, application SIGTERM-ஐப் புறக்கணிப்பதால், docker compose stop அதன் பத்து வினாடி grace period-ஐக் கடப்பதே இதற்கு முக்கியக் காரணமாகும். இந்த வேறுபாட்டைப் புரிந்துகொள்வது பல மணிநேரங்களை மிச்சப்படுத்தும், ஏனெனில் இவ்விரு சிக்கல்களுக்கும் எந்தத் தொடர்பும் இல்லை.

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

docker events --filter event=oom

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

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

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

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-ல் swap-ஐத் தொடர்ந்து பயன்படுத்தும் (thrashing) ஒரு container, அந்த server-ல் உள்ள மற்ற அனைத்து service-களையும் மெதுவாக்கும். latency-ஐ உணரும் எந்தவொரு சேவைக்கும், swap இல்லாமல் சரியான வரம்பை அமைப்பதே சிறந்தது; இது தோல்வியை விரைவாகவும், கணிக்கக்கூடிய வகையிலும் வெளிப்படுத்தும்.

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

MEM USAGE மதிப்பானது docker stats-ல் page cache-ஐயும் உள்ளடக்கியது. எனவே, பெரிய கோப்புகளை வாசிக்கும் ஒரு container அதன் வரம்பை நோக்கி உயர்ந்து அங்கேயே தங்கிவிடும். இது இயல்பானது, இது memory 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-க்கான அளவு வரம்புகள்

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

8GB box-க்கு ஒரு நடைமுறைப் பகிர்வு:

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

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

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

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

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

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

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

FAQ

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

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

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

இதன் பொருள் main process SIGKILL-ஐப் பெற்றுள்ளது என்பதாகும், ஏனெனில் 137 என்பது 128 உடன் signal 9-ஐக் கூட்டியதாகும். பொதுவாக 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-ஐத் தொடரவும். ஒரே service-ல் இரண்டையும் அமைப்பது கோப்பைப் புரிந்துகொள்வதைக் கடினமாக்கும், எனவே ஏதேனும் ஒன்றை மட்டும் தேர்வு செய்து, docker inspect மூலம் முடிவைச் சரிபார்க்கவும்.

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

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

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

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