ద్వారా Matt Connor 2026-10-10 · అప్‌డేట్ చేయబడింది 2026-10-21

Docker Composeలో OOM ఆపే memory limits ఎలా సెట్ చేయాలి

Q: deploy.resources.limits Docker Swarm లేకుండా పనిచేస్తుందా?

అవును. Docker Compose లోని docker compose plugin (ఇప్పుడు దాని v5 line లో ఉంది) ఒకే host పై docker compose up నడిపినప్పుడు deploy.resources.limits మరియు deploy.resources.reservations ను వర్తింపజేస్తుంది. ఇది అమలైందో లేదో docker inspect --format '{{.HostConfig.Memory}}' తో నిర్ధారించండి. ఈ command limit ను bytes లో ముద్రిస్తుంది. ఎలాంటి limit వర్తించనప్పుడు 0 ను ముద్రిస్తుంది. Swarm ను దృష్టిలో ఉంచుకుని deploy లో రాసిన keys cluster కు సంబంధించినవి. ఉదాహరణకు placement, update_config మరియు endpoint_mode.

Q: mem_limit లేదా deploy.resources.limits.memory లో ఏది సెట్ చేయాలి?

docker compose తో రెండూ పనిచేస్తాయి. deploy.resources.limits.memory ప్రస్తుత Compose Specification రూపం. కొత్త file కు ఇది మెరుగైన default. మీ file లో మిగతా భాగం ఇప్పటికే పాత top-level keys ను ఉపయోగిస్తే mem_limit ను కొనసాగించండి. రెండింటినీ సెట్ చేసినప్పుడు అవి పరస్పరం consistent గా ఉండాలని Compose Specification నిర్దేశిస్తుంది. అందువల్ల ఒకదానినే ఎంచుకుని, ఫలితాన్ని docker inspect తో నిర్ధారించండి.

Q: నా container kill కాకుండా దాని పూర్తి memory limit వద్ద ఎందుకు కొనసాగుతోంది?

docker stats లోని usage figure ఇటీవల ఉపయోగించిన page cache ను కూడా లెక్కిస్తుంది. Memory pressure వచ్చినప్పుడు kernel OOM kill ను ప్రారంభించకుండా ఈ cache ను తొలగిస్తుంది. docker compose exec grep -E '^(anon|file) ' /sys/fs/cgroup/memory.stat నడిపి anon value ను పరిశీలించండి. Reclaim చేయలేని working set ను ఇదే సూచిస్తుంది. తక్కువ anon value పక్కన ఎక్కువ file value కనిపిస్తే, అది disk input మరియు output చేస్తున్న container. త్వరలో ఆగిపోబోయే container కాదు.

VPSలో ఒక container మొత్తం RAMను ఖర్చు చేయకుండా Docker Composeలో deploy.resources, mem_limit, CPU, swap పరిమితులు సెట్ చేయండి. exit 137 కారణం, sizing తెలుసుకోండి.

Docker Compose memory limit ఏమి చేస్తుంది

Docker Compose memory limit అనేది ఒక container యొక్క cgroup పై Linux kernel విధించే గరిష్ఠ పరిమితి. cgroup అనేది process సమూహం వినియోగించే వనరులను కొలిచే kernel feature. Service పై deploy.resources.limits.memory సెట్ చేస్తే, ఆ container మీరు పేర్కొన్న పరిమాణం కంటే ఎక్కువ memory ఎప్పటికీ ఉపయోగించలేదు. అది ఆ పరిమితిని మించేందుకు ప్రయత్నించినప్పుడు, kernel container లోని ఒక process ను terminate చేస్తుంది. సాధారణంగా container code 137 తో exit అవుతుంది.

ఈ విషయం ముఖ్యంగా VPS లో ప్రాధాన్యమైనది. VPS లో RAM పరిమితంగా ఉంటుంది, అదనపు host memory అందుబాటులో ఉండదు. Memory leak లేదా తప్పు query ఉన్న ఒక container 8GB server లోని ఖాళీ memory మొత్తం వినియోగించవచ్చు. అప్పుడు kernel సమస్యకు అత్యంత బాధ్యత వహిస్తుందని భావించిన process ను terminate చేస్తుంది. అది సమస్యకు కారణమైన container కాకుండా database లేదా మీ SSH session కూడా కావచ్చు. Limits ఉపయోగిస్తే మొత్తం server outage బదులుగా ఒక service మాత్రమే restart అవుతుంది.

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

దాన్ని వర్తింపజేసి, limit అమల్లో ఉందని నిర్ధారించండి:

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

MEM USAGE / LIMIT column లో సాధారణంగా 142MiB / 1GiB వంటి విలువ కనిపించాలి. Limit column లో మొత్తం host RAM కనిపిస్తే, setting వర్తించలేదు. అది వర్తించే వరకు ఈ guide లోని మిగతా సూచనలు ఉపయోగపడవు. Compose file మీకు కొత్తగా ఉంటే, VPS కోసం Docker Compose ప్రాథమికాలు ఈ file layout పై మరింత వివరణ ఇస్తాయి.

deploy.resources.limits లేదా mem_limit: ఏది వర్తిస్తుంది

ఒకే భావానికి రెండు రకాల రాతలు ఉన్నాయి. అందుకే ఇది గందరగోళంగా ఉంటుంది.

mem_limit, mem_reservation, memswap_limit, cpus మరియు cpu_shares పాత Compose file formatల నుంచి వచ్చిన top-level service keys. deploy.resources Swarm schema నుంచి వచ్చింది. ప్రస్తుతం docker compose చదివే format అయిన Compose Specificationలో ఇది భాగంగా ఉంది.

ఒకే hostపై రెండూ పనిచేస్తాయి. Docker Compose అయిన docker compose plugin, మీరు docker compose up నడిపినప్పుడు deploy.resources.limits మరియు deploy.resources.reservations ను వర్తింపజేస్తుంది. దీనికి ఎక్కడా Swarm cluster అవసరం లేదు. ప్రస్తుతం ఈ plugin v5 శ్రేణిలో ఉంది. 2026-10-10న పరిశీలించినప్పుడు తాజా stable release v5.6.0. పాత Compose file format versionలతో గందరగోళం రాకుండా v2 నుంచి నేరుగా v5కి మారి, 3 మరియు 4ను దాటింది. ఏ v5 release కూడా resource limits నిర్వహణ విధానాన్ని మార్చలేదు. deploy blockలో Swarmకు సంబంధించిన ఇతర భాగాలు placement, update_config మరియు endpoint_mode వంటి keys. ఇవి docker stack deploy కోసం nodes cluster అంతటా scheduling మరియు rollouts ను వివరిస్తాయి. అందువల్ల resources subsectionకు "deploy needs Swarm" అనే సాధారణ సలహా తప్పు. దాన్ని అనుసరిస్తే మీ servicesకు ఎలాంటి limit ఉండదు.

ప్రతి projectకు ఒకే spelling ఎంచుకోండి. ఒకే serviceలో mem_limit: 512m మరియు deploy.resources.limits.memory: 1g రెండూ రాయడం చదవడానికి కష్టంగా ఉండటమే కాదు. mem_limit సెట్ చేసినప్పుడు అది limits.memoryతో consistentగా ఉండాలని Compose Specification చెబుతుంది. అవి భిన్నంగా ఉన్నప్పుడు ఏ valueకు ప్రాధాన్యం ఇవ్వాలో అది చెప్పదు. మీరు ఏ spelling ఉపయోగించినా, daemon వాస్తవంగా ఏది వర్తింపజేసిందో నిర్ధారించండి:

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

Memory values bytesలో ఉంటాయి. అందువల్ల 1g ను 1073741824గా చూపిస్తుంది. CPU nano CPUsలో ఉంటుంది. అందువల్ల 1.5 ను 1500000000గా చూపిస్తుంది. ఏ fieldలోనైనా 0 ఉంటే limit సెట్ కాలేదని అర్థం. Docker అంగీకరించే కనిష్ఠ memory limit 6m. దానికంటే తక్కువగా ఉంటే container start కాదు.

కంటైనర్ పరిమితిని చేరుకున్నప్పుడు ఏమి జరుగుతుంది

కంటైనర్ నెమ్మదించదు. అది ఆగిపోతుంది.

ఒక process ఒక page కోసం అభ్యర్థించినప్పుడు, cgroup ఇప్పటికే దాని memory.max వద్ద ఉంటే, kernel ముందుగా ఆ cgroup లో సాధ్యమైనవన్నీ reclaim చేస్తుంది: clean page cache ను, తరువాత swap చేయగల pages ను. Reclaim ద్వారా తగినంత memory విడుదల కాకపోతే, cgroup OOM (out of memory) killer కంటైనర్‌లోని ఒక process ను ఎంచుకుని దానికి SIGKILL పంపుతుంది. కంటైనర్‌ యొక్క PID 1 ను terminate చేస్తే కంటైనర్ ఆగిపోతుంది. 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తో exit కావచ్చు, కానీ అది అరుదు.) సాధారణ కారణం: app SIGTERM ను పట్టించుకోకపోవడంతో docker compose stop దాని పది సెకన్ల grace period ను చేరుకోవడం. ఈ తేడాను గుర్తించడం వల్ల గంటల సమయం ఆదా అవుతుంది, ఎందుకంటే ఈ రెండు సమస్యలకు పరస్పర సంబంధం లేదు.

ఈ event ను మరో రెండు చోట్ల నమోదు చేస్తారు. Daemon ను live గా monitor చేయండి:

docker events --filter event=oom

తరువాత restart ను తట్టుకుని మిగిలే record అయిన 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) తో ప్రారంభమయ్యే line కనిపిస్తుంది. అంటే ఒక కంటైనర్ తన స్వంత పరిమితిని చేరుకుంది. Host వద్ద ఇంకా చాలినంత free RAM ఉన్నప్పటికీ ఈ line కనిపించవచ్చు. Memory cgroup prefix లేని line host OOM ను సూచిస్తుంది. అంటే machine కే RAM అయిపోయిందని అర్థం. Limits ఉద్దేశించినదే ఈ వైఫల్యాన్ని నివారించడం. కాబట్టి ఈ line కనిపిస్తే సాధారణంగా మీ limits మొత్తం చాలా ఎక్కువగా ఉన్నాయని, కొన్ని services కు limit లేదని, లేదా మీరు ఉంచిన headroom కంటే Docker వెలుపల ఉన్న ఏదో ఎక్కువ memory ఉపయోగిస్తోందని అర్థం.

restart: unless-stopped తో OOM loop సులభంగా గుర్తించబడకుండా ఉండవచ్చు, ఎందుకంటే service ఆగిన ఒక సెకను తరువాత docker compose ps లో up గా కనిపిస్తుంది. Uptime column మరియు restart count ను పరిశీలించండి. అలాగే limit ను app ను unhealthy గా నివేదించే healthcheck తో కలిపి ఉపయోగించండి. అప్పుడు నిరంతరం ఆగిపోతున్న కంటైనర్‌ను మీరు ప్రత్యక్షంగా గమనించకపోయినా గుర్తించవచ్చు.

Reservation ఒక సూచన మాత్రమే; limit నియమం

reservations.memory (పాత mem_reservation) ఒక soft floor. Hostపై contention లేదా తక్కువ memory ఉందని daemon గుర్తించినప్పుడు ఇది అమలయ్యే soft limit అని Docker వివరిస్తుంది. ఇది container ఆ పరిమితిని మించకుండా ఎప్పుడూ ఆపదు. Container memory అడిగే సమయంలో అది ఖాళీగా ఉంటుందని కూడా ఎప్పుడూ హామీ ఇవ్వదు. Reservation కంటే ఎక్కువ memory ఉపయోగిస్తున్న containers నుంచి ముందుగా memory reclaim చేయాలని ఇది kernel‌కు ప్రాధాన్యతను మాత్రమే ఇస్తుంది.

అందువల్ల reservation ఒక్కటే ఏదినీ రక్షించదు. ఒత్తిడి సమయంలో ప్రత్యేక శ్రద్ధతో నిర్వహించాలనుకునే service‌ను గుర్తించడానికి దీన్ని ఉపయోగించండి. భద్రత కోసం limit‌పై ఆధారపడండి. Reservation‌ను limit కంటే తక్కువగా ఉంచండి. లేకపోతే container ప్రారంభం కాదు: Docker Minimum memory limit can not be less than memory reservation limit తో config‌ను తిరస్కరిస్తుంది.

Swap లెక్కింపు, వాస్తవ పరిస్థితి

చాలా VPS images లో swap file ఏదీ ఉండదు. swapon --show మరియు free -h ను అమలు చేయండి. మొత్తం swap విలువ zero అయితే, కింద ఉన్న swap సంబంధిత settings ఏవీ పనిచేయవు. అప్పుడు మీ memory limit పూర్తిగా RAM పరిమితిగానే ఉంటుంది.

memswap_limit అనేది swap పరిమాణం కాదు. ఇది memory మరియు swap కలిపిన మొత్తం. mem_limit: 1g మరియు memswap_limit: 2g తో container కు 1GB RAM మరియు 1GB swap లభిస్తాయి. రెండు values ను సమానంగా సెట్ చేస్తే container కు swap ఉండదు. mem_limit ను సెట్ చేసి memswap_limit ను unset గా ఉంచితే, container మళ్లీ తన memory limit పరిమాణం వరకు swap ఉపయోగించగలదు.

Ubuntu 24.04 మరియు Debian 13 డిఫాల్ట్‌గా cgroup v2 ను ఉపయోగిస్తాయి. ఇందులో swap ప్రత్యేక counter (memory.swap.max) గా ఉంటుంది. అదనపు setup లేకుండానే ఇది పనిచేస్తుంది. Your kernel does not support swap limit capabilities అనే పాత message, swapaccount=1 లేకుండా boot చేసిన cgroup v1 hosts నుంచి వస్తుంది. అలాంటి hosts లో memory limit అమలవుతుంది, కానీ swap భాగం పట్టించుకోబడదు.

swap వల్ల కలిగే ప్రయోజనాన్ని వాస్తవికంగా అంచనా వేయండి. ఇది OOM kill ను నెమ్మదిగా చేస్తుంది, కానీ అది సంభవించే అవకాశాన్ని తగ్గించదు. ఎందుకంటే memory leak ఉన్న process RAM ను నింపినట్లే swap ను కూడా నింపుతుంది. అదే సమయంలో shared VPS storage పై swap ను అధికంగా ఉపయోగించే container, ఆ server లోని ఇతర సేవలన్నింటినీ నెమ్మదింపజేస్తుంది. latency కు సున్నితమైన సేవలకు swap లేకుండా సరైన limit సెట్ చేయడం వల్ల వైఫల్యం వేగంగా మరియు మరింత ఊహించదగిన విధంగా జరుగుతుంది.

మెమరీ వినియోగం వాస్తవం కంటే ఎక్కువగా కనిపించడానికి కారణం

Linuxలో, docker stats లోని MEM USAGE గణాంకం inactive page cache ను మాత్రమే (cgroup v2లో inactive_file) తీసివేస్తుంది. అందువల్ల ఇటీవల ఉపయోగించిన cache కూడా లెక్కలో ఉంటుంది. పెద్ద ఫైళ్లను చదివే container దాని limit వైపు పెరిగి అక్కడే ఉండవచ్చు. ఇది సాధారణ ప్రవర్తన. ఇది leak కాదు, ఎందుకంటే OOM killer ను పిలిచే ముందు clean cache ను తిరిగి వినియోగించుకోవచ్చు. స్వయంగా నిర్వహించే Jellyfin media server వంటి సేవ ఈ కారణంగానే తన memory ceiling కు శాశ్వతంగా దగ్గరగా ఉన్నట్లు కనిపిస్తుంది.

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 అందులోని ఏదో process ను చంపింది. max counter పెరుగుతుంటే, container ప్రస్తుతం తన ceiling వద్ద పరిమితం చేయబడుతోంది. రెండు commands పనిచేయడానికి image లో shell మరియు coreutils అవసరం. అందువల్ల distroless లేదా scratch image లో అవి విఫలమవుతాయి.

8GB VPS‌లో పరిమాణ పరిమితులు

అప్లికేషన్ల నుంచి కాకుండా host నుంచి ప్రారంభించండి. 8GB VPS‌లో kernel, Docker daemon, sshd, journald మరియు మీ స్వంత login shell కోసం సుమారు 1GB విడిగా ఉంచండి. అప్పుడు కేటాయించడానికి సుమారు 7GB మిగులుతుంది. ప్రతి container limit మొత్తం ఈ పరిమితిలోనే ఉండాలి. రెండు సేవలు ఒకేసారి గరిష్ఠ వినియోగానికి చేరుకునే రోజు వరకు overcommit పనిచేస్తుంది.

8GB సిస్టమ్‌లో ఉపయోగించగల విభజన:

Reverse proxy: 128m limit. ఇది చిన్న process. ఇంత కఠినమైన limit runaway config reload ను వెంటనే గుర్తిస్తుంది.
PostgreSQL: 2g limit. Database config లో shared_buffers ను సుమారు 512MBగా సెట్ చేయండి.
Application container: 1g limit.
Background worker: 512m limit.
Media లేదా file service: 2g limit. ఇందులో ఎక్కువ భాగం page cache కోసం ఉపయోగించబడుతుంది.

ఈ సంఖ్యలను మీ స్వంత stackలో నేరుగా ఉపయోగించవద్దు. సేవలను ఒక రోజు నిజమైన load కింద నడపండి. docker stats ను monitor చేయండి. ప్రతి containerకు గరిష్ఠ anon విలువను తీసుకుని, దానికి సుమారు సగం అదనంగా headroomగా జోడించండి. చాలా తక్కువగా సెట్ చేసిన limit, limit లేకపోవడం కంటే ప్రమాదకరం. సాధారణ network traffic పెరుగుదల సమయంలో అది ఆరోగ్యంగా ఉన్న సేవను నిలిపివేస్తుంది.

ఒక ముఖ్యమైన సమస్యకు ప్రత్యేకంగా శ్రద్ధ అవసరం. కొన్ని runtimes వాటికి limit ఉందని స్పష్టంగా తెలియజేయకపోతే ఆ limitను పట్టించుకోవు. Limitను చదివే runtimes కూడా మీరు ఆశించిన విధంగా తమ పరిమాణాన్ని సెట్ చేసుకోకపోవచ్చు. PostgreSQL shared_buffers మరియు work_mem ను తన container limit కంటే ఎక్కువగా సెట్ చేసి, చివరకు kill అవుతుంది. ఆధునిక JVM (Java virtual machine) సాధారణంగా cgroup limit ను గుర్తిస్తుంది. అయితే OpenJDK వంటి HotSpot builds heapకు దాని 25 percent మాత్రమే కేటాయిస్తాయి. అందువల్ల heapకు limitలో ఎక్కువ భాగం ఉపయోగించనివ్వడంతో పాటు heap వెలుపల memory కోసం స్థలం ఉంచడానికి -XX:MaxRAMPercentage=75 సాధారణంగా ఉపయోగిస్తారు. version 12 నుంచి Node.js తన default heap పరిమాణాన్ని cgroup limit ఆధారంగా సెట్ చేస్తుంది. ఇది container limitలో సుమారు సగం వరకు ఉంటుంది, దాదాపు 2GB వద్ద స్థిరపడుతుంది. కాబట్టి వేరే ceiling కావాలనుకున్నప్పుడు మాత్రమే --max-old-space-size ను megabytesలో సెట్ చేయండి. దాన్ని container limit కంటే తక్కువగా ఉంచండి. అప్పుడు kernel జోక్యం చేసుకునేలోపు garbage collector పనిచేయగలదు. Ollamaలో కూడా ఇదే పరిస్థితి, కానీ వేరే knob ఉపయోగించాలి. ఎందుకంటే num_ctx పెంచితే KV cache వందల megabytes మేర పెరుగుతుంది మరియు దీర్ఘమైన prompt మధ్యలో container నిలిచిపోతుంది. cgroup చర్చలు జరపదు. అది kill చేస్తుంది.

CPU limits పూర్తిగా భిన్నంగా పనిచేస్తాయి

cpus: "1.5" అంటే ఒక core సామర్థ్యంలో 150%. ఇది CFS (completely fair scheduler) quotaగా అమలు చేయబడుతుంది. ప్రతి 100ms వ్యవధిలో containerకు 150ms CPU సమయం లభిస్తుంది. ఈ సమయం దాని అన్ని threads మధ్య భాగస్వామ్యం అవుతుంది. ఆ సమయం పూర్తయినప్పుడు, తదుపరి వ్యవధి వరకు kernel దాన్ని వేచి ఉండేలా చేస్తుంది.

ఇదే ముఖ్యమైన తేడా. Memory limit ను మించిన container kill అవుతుంది. CPU limit ను మించిన container throttle చేయబడుతుంది, కానీ నెమ్మదిగా కొనసాగుతుంది. అందువల్ల CPU limit ను కొంత కఠినంగా సెట్ చేయడం సురక్షితం. Memory limit కు మాత్రం అదనపు headroom అవసరం.

cpu_shares వేరే సాధనం. ఇది relative weight. CPUs వాస్తవంగా పూర్తిగా వినియోగంలో ఉన్నప్పుడు మాత్రమే దీనికి ప్రభావం ఉంటుంది. 1024 మరియు 512 shares ఉన్న రెండు containers busy core ను సుమారు two-to-one నిష్పత్తిలో పంచుకుంటాయి. Idle systemలో అయితే ఏ containerకూ పరిమితి ఉండదు. Services ప్రాధాన్యతను క్రమబద్ధీకరించడానికి shares ను ఉపయోగించండి. వాస్తవ ceiling అవసరమైనప్పుడు cpus ను ఉపయోగించండి. ఉదాహరణకు, ప్రతి రాత్రి జరిగే transcode job మీ web serverకు CPU కొరత కలిగించకుండా ఆపడానికి ఇది ఉపయోగపడుతుంది.

FAQ

deploy.resources.limits Docker Swarm లేకుండా పనిచేస్తుందా?

అవును. Docker Compose లోని docker compose plugin (ఇప్పుడు దాని v5 line లో ఉంది) ఒకే host పై docker compose up నడిపినప్పుడు deploy.resources.limits మరియు deploy.resources.reservations ను వర్తింపజేస్తుంది. ఇది అమలైందో లేదో docker inspect --format '{{.HostConfig.Memory}}' <container> తో నిర్ధారించండి. ఈ command limit ను bytes లో ముద్రిస్తుంది. ఎలాంటి limit వర్తించనప్పుడు 0 ను ముద్రిస్తుంది. Swarm ను దృష్టిలో ఉంచుకుని deploy లో రాసిన keys cluster కు సంబంధించినవి. ఉదాహరణకు placement, update_config మరియు endpoint_mode.

Docker Compose లో exit code 137 అంటే ఏమిటి?

దాదాపు ఎల్లప్పుడూ main process కు SIGKILL signal అందిందని అర్థం. ఎందుకంటే 137 అనేది 128కి signal 9 ను కలిపిన విలువ. ఒక program ఉద్దేశపూర్వకంగా 137తో exit కావచ్చు. అయితే అది అరుదు. సాధారణ కారణం kernel OOM killer. అయితే ఒక app SIGTERM ను పట్టించుకోనప్పుడు shutdown timeout కూడా ఇదే code ను ఉత్పత్తి చేస్తుంది. ఈ రెండు కారణాలను వేరు చేయడానికి docker inspect --format '{{.State.OOMKilled}} {{.State.ExitCode}}' <container> నడపండి. true 137 memory kill ను సూచిస్తుంది. false 137 మాత్రం memory kill ను సూచించదు.

mem_limit లేదా deploy.resources.limits.memory లో ఏది సెట్ చేయాలి?

docker compose తో రెండూ పనిచేస్తాయి. deploy.resources.limits.memory ప్రస్తుత Compose Specification రూపం. కొత్త file కు ఇది మెరుగైన default. మీ file లో మిగతా భాగం ఇప్పటికే పాత top-level keys ను ఉపయోగిస్తే mem_limit ను కొనసాగించండి. రెండింటినీ సెట్ చేసినప్పుడు అవి పరస్పరం consistent గా ఉండాలని Compose Specification నిర్దేశిస్తుంది. అందువల్ల ఒకదానినే ఎంచుకుని, ఫలితాన్ని docker inspect తో నిర్ధారించండి.

నా container kill కాకుండా దాని పూర్తి memory limit వద్ద ఎందుకు కొనసాగుతోంది?

docker stats లోని usage figure ఇటీవల ఉపయోగించిన page cache ను కూడా లెక్కిస్తుంది. Memory pressure వచ్చినప్పుడు kernel OOM kill ను ప్రారంభించకుండా ఈ cache ను తొలగిస్తుంది. docker compose exec <service> grep -E '^(anon|file) ' /sys/fs/cgroup/memory.stat నడిపి anon value ను పరిశీలించండి. Reclaim చేయలేని working set ను ఇదే సూచిస్తుంది. తక్కువ anon value పక్కన ఎక్కువ file value కనిపిస్తే, అది disk input మరియు output చేస్తున్న container. త్వరలో ఆగిపోబోయే container కాదు.

8GB VPS లో ఎంత RAM ను కేటాయించకుండా ఉంచాలి?

Kernel, Docker daemon, sshd, journald మరియు మీ స్వంత shell కోసం సుమారు 1GB ఉంచండి. తరువాత అన్ని container limits మొత్తం మిగిలిన 7GB కంటే తక్కువగా ఉండేలా చూసుకోండి. వాస్తవ load లో ఒక రోజు ప్రతి container యొక్క గరిష్ఠ anon value ను monitor చేసిన తరువాత సంఖ్యలను నిర్ణయించండి. మొత్తం మొత్తాన్ని నింపాల్సిన target గా కాకుండా budget గా పరిగణించండి.

ఈ వ్యాసం ఉపయోగకరంగా ఉందా?

#docker-compose #docker #memory #oom #vps