కంటైనర్‌ల కోసం మెమరీ మరియు CPU పరిమితులు

డిఫాల్ట్‌గా, ఒక కంటైనర్ మెషీన్‌లోని మొత్తం మెమరీని, మొత్తం కోర్లను తీసుకోగలదు. రెండు గిగాబైట్‌లున్న VDS-1లో ఇది ఊహించిన విధంగానే ముగుస్తుంది: ఒక సర్వీస్ పెద్దదైపోతుంది, కర్నెల్ ప్రాసెస్‌లను చంపడం మొదలుపెడుతుంది, కిందపడేది అది కాదు — పక్కనున్న డేటాబేస్.

పరిమితిని ఎలా సెట్ చేయాలి

services:
  app:
    image: ghcr.io/example/app:1.5.0
    deploy:
      resources:
        limits:
          memory: 768M
          cpus: "1.0"
        reservations:
          memory: 256M

సాధారణ docker compose up -d తో కూడా Compose deploy.resources.limits ను వర్తింపజేస్తుంది. docker run కోసం సమానమైనది:

docker run -d --memory 768m --cpus 1.0 --memory-swap 768m <image>

--memory-swap ను --memory కు సమానంగా సెట్ చేయడం స్వాపింగ్‌ను నిషేధిస్తుంది: గంటల తరబడి కదలకుండా ఉండే మెషీన్ కంటే నిజాయితీగా క్రాష్ అవ్వడం మేలు.

ఎంత కేటాయించాలి

మీ టియర్ నుండి మొదలుపెట్టి, సిస్టమ్ కోసం కొంత స్థలం వదిలేయండి.

మిగిలినది సిస్టమ్, ఫైల్ క్యాష్ మరియు Docker కు అవసరం. మెమరీ పరిమాణం కంటే ఎక్కువ పరిమితుల మొత్తం కాన్ఫిగరేషన్ పొరపాటు కాదు — అది జరగబోయే విపత్తు.

CPU కోసం: cpus: "1.0" అంటే ఒక పూర్తి కోర్. VDS-1లో ఒకే కోర్ ఉంది, కాబట్టి అక్కడ CPU ను పరిమితం చేయడంలో అర్థం లేదు, కానీ VDS-4 మరియు అంతకంటే పైన సర్వర్ సెటప్ మొత్తం ఆరు కోర్లను తీసుకోకుండా ఉంచడం మంచిది.

వాస్తవంగా ఏమి వినియోగమవుతుంది

docker stats --no-stream
docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.CPUPerc}}"
free -h

ఒక రోజు లోడ్‌లో సర్వీస్‌ను గమనించి, పీక్ కంటే సుమారు ఒకటిన్నర రెట్లు పరిమితిని సెట్ చేయండి. మరీ కఠినమైన పరిమితి పరిమితి లేకపోవడం కంటే అధ్వానం: మీకు అత్యవసరంగా అవసరమైన సమయంలోనే సర్వీస్ రీస్టార్ట్ అవుతుంది.

ఫుల్-స్క్రీన్ htop మరియు btop “Screen” కన్సోల్ (VNC)లో మాత్రమే పనిచేస్తాయి. టెక్స్ట్ కన్సోల్ విండో పరిమాణాన్ని అందించదు, అక్కడ ఎప్పుడూ 80×24 ఉంటుంది, ఇంటర్‌ఫేస్ చెదిరిపోతుంది. టెక్స్ట్ కన్సోల్‌లో త్వరిత కొలతల కోసం docker stats --no-stream మరియు free -h ఉపయోగించండి.

మెమరీ వల్లే చంపబడిందని ఎలా తెలుసుకోవాలి

docker inspect -f '{{.State.ExitCode}} {{.State.OOMKilled}}' <container>
sudo dmesg -T | grep -i -E "out of memory|killed process"

ఎగ్జిట్ కోడ్ 137 తో పాటు OOMKilled: true ఉండటం స్పష్టమైన తీర్పు. అక్కడి నుండి మీకు రెండు ఎంపికలు ఉన్నాయి: పరిమితి మరీ తక్కువగా సెట్ చేయబడి ఉంటే దాన్ని పెంచండి, లేదా అప్లికేషన్ ఎందుకు పెరుగుతూనే ఉందో కనుగొనండి — మెమరీ జోడించడం వల్ల లీక్ నయం కాదు, వాయిదా మాత్రమే పడుతుంది.

Java మరియు ఇతర ప్రత్యేక సందర్భాలు

Java వర్చువల్ మెషీన్ ఇప్పటికీ కొన్నిసార్లు కంటైనర్ పరిమితి కాకుండా హోస్ట్ మెమరీని చూస్తుంది, అక్కడ లేని స్థలంతో హీప్‌ను సైజ్ చేస్తుంది. దాన్ని స్పష్టంగా సెట్ చేయండి:

environment:
  JAVA_TOOL_OPTIONS: "-Xmx512m -Xms256m"

ఇదే PostgreSQL (shared_buffers) మరియు స్వంత పూల్ ఉన్న ఏ సర్వీస్‌కైనా వర్తిస్తుంది.

సాధారణ పొరపాట్లు

• పరిమితులే అసలు సెట్ చేయకపోవడం. “మెషీన్ గడ్డకట్టింది, ఏదీ స్పందించడం లేదు” అనే దానికి అత్యంత సాధారణ కారణం.
• పరిమితి ఉంది, కానీ హెల్త్ చెక్ లేదు. కంటైనర్ చంపబడింది, మళ్లీ రీస్టార్ట్ కాలేదు. restart: unless-stopped మరియు healthcheck జోడించండి — కంటైనర్లను అప్‌డేట్ చేయడం చూడండి.
• డిస్క్ గురించి మర్చిపోవడం. మెమరీని పరిమితం చేశారు, కానీ రైట్‌లు ఒక పరిమితిని తాకుతాయి: డిస్క్ వేగం చూడండి.