कंटेनर के लिए मेमोरी और CPU लिमिट

डिफ़ॉल्ट रूप से, एक कंटेनर मशीन की पूरी मेमोरी और सभी कोर ले सकता है। दो गीगाबाइट वाले VDS-1 पर यह अनुमानित तरीके से खत्म होता है: एक सर्विस फूल जाती है, कर्नेल प्रोसेस को मारना शुरू कर देता है, और जो गिरता है वह वह नहीं बल्कि उसके पास वाला डेटाबेस होता है।

सीमा कैसे तय करें

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

Compose deploy.resources.limits को सादे docker compose up -d के साथ भी लागू करता है। docker run के लिए समकक्ष:

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

--memory-swap को --memory के बराबर सेट करना स्वैपिंग को मना करता है: घंटों तक barely चलने वाली मशीन से एक ईमानदार क्रैश बेहतर है।

कितना आवंटित करें

अपने टियर से शुरू करें और सिस्टम के लिए कुछ हेडरूम छोड़ें।

बाकी हिस्सा सिस्टम, फ़ाइल कैश और 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 जोड़ें — देखें कंटेनर अपडेट करना।
• डिस्क भूल गए। आपने मेमोरी सीमित की, लेकिन राइट्स एक सीमा से टकराती हैं: देखें डिस्क स्पीड।