کنٹینرز کے لیے میموری اور 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 عام docker compose up -d کے ساتھ بھی 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 شامل کریں — دیکھیں کنٹینرز کی اپ ڈیٹ۔
• آپ ڈسک بھول گئے۔ آپ نے میموری محدود کر دی، لیکن رائٹس کسی حد سے ٹکرا رہی ہیں: دیکھیں ڈسک کی رفتار۔