Docker Compose-এ মেমোরি লিমিট সেট করার নিয়ম

Docker Compose memory limit যা করে

Docker Compose memory limit হলো Linux kernel কর্তৃক একটি কন্টেইনারের cgroup (control group, যা প্রসেসগুলোর রিসোর্স পরিমাপের একটি কার্নেল ফিচার)-এর ওপর আরোপিত একটি কঠোর সীমা। কোনো সার্ভিসে deploy.resources.limits.memory সেট করলে সেই কন্টেইনার আপনার নির্ধারিত পরিমাণের বেশি মেমোরি ব্যবহার করতে পারবে না। যখনই এটি সীমা অতিক্রম করার চেষ্টা করে, কার্নেল কন্টেইনারের ভেতরের একটি প্রসেসকে বন্ধ করে দেয় এবং কন্টেইনারটি সাধারণত 137 কোড নিয়ে বন্ধ হয়ে যায়।

VPS-এর ক্ষেত্রে এটি সবচেয়ে গুরুত্বপূর্ণ, কারণ সেখানে RAM নির্দিষ্ট থাকে এবং ধার নেওয়ার মতো কোনো অতিরিক্ত হোস্ট মেমোরি থাকে না। মেমোরি লিক বা ত্রুটিপূর্ণ কুয়েরি থাকা একটি কন্টেইনার 8GB RAM-এর একটি সার্ভারের সমস্ত খালি মেমোরি দখল করে নিতে পারে। তখন কার্নেল তার বিচারে যে প্রসেসটিকে সবচেয়ে ক্ষতিকর মনে করে সেটিকে বন্ধ করে দেয়; এটি প্রায়শই ডেটাবেস বা আপনার SSH সেশন হতে পারে, সমস্যা সৃষ্টিকারী কন্টেইনারটি নয়। মেমোরি লিমিট পুরো সার্ভার ডাউন হওয়ার ঝুঁকি কমিয়ে শুধুমাত্র একটি সার্ভিস রিস্টার্ট হওয়ার মধ্যে সীমাবদ্ধ রাখে।

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 কলামে 142MiB / 1GiB-এর মতো কিছু লেখা থাকা উচিত। যদি লিমিট কলামে হোস্টের সম্পূর্ণ RAM দেখায়, তবে সেটিংসটি কার্যকর হয়নি এবং এটি ঠিক না হওয়া পর্যন্ত এই গাইডের বাকি অংশ কোনো কাজে আসবে না। যদি compose ফাইলটি আপনার কাছে নতুন মনে হয়, তবে VPS-এর জন্য Docker Compose-এর মৌলিক বিষয়সমূহ দেখুন, যা এই ফাইল লেআউটের ভিত্তি তৈরি করে।

deploy.resources.limits বনাম mem_limit: কোনটি কার্যকর

একই ধারণার জন্য দুটি ভিন্ন বানান থাকায় বিষয়টি বিভ্রান্তিকর।

mem_limit, mem_reservation, memswap_limit, cpus এবং cpu_shares হলো টপ-লেভেল সার্ভিস কি (key), যা পুরনো Compose ফাইল ফরম্যাট থেকে এসেছে। deploy.resources এসেছে Swarm স্কিমা থেকে এবং এটি এখন Compose Specification-এর অংশ, যা docker compose বর্তমানে রিড করে।

উভয়ই একটি সিঙ্গেল হোস্টে কাজ করে। Compose V2, যা একটি docker compose প্লাগইন, docker compose up কমান্ড চালানোর সময় deploy.resources.limits এবং deploy.resources.reservations প্রয়োগ করে, এমনকি কোনো Swarm ক্লাস্টার না থাকলেও। deploy ব্লকের শুধুমাত্র Swarm-এর জন্য প্রযোজ্য অংশগুলো হলো অন্যান্য কি: mode, placement, update_config এবং endpoint_mode, যা শুধুমাত্র docker stack deploy-এর কাছে অর্থবহ এবং docker compose up এগুলোকে উপেক্ষা করে। তাই সাধারণ পরামর্শ যে "deploy-এর জন্য Swarm প্রয়োজন" তা resources সাবসেকশনের ক্ষেত্রে ভুল, এবং এটি অনুসরণ করলে আপনার সার্ভিসগুলোতে কোনো লিমিটই সেট হবে না।

প্রতিটি প্রজেক্টের জন্য একটি বানান বেছে নিন। একই সার্ভিসে mem_limit: 512m এবং deploy.resources.limits.memory: 1g উভয়ই লিখলে ফাইলটি পড়া কঠিন হয়ে পড়ে। কোন সংখ্যাটি কার্যকর হয়েছে তা অনুমান না করে সরাসরি ডেমনের কাছে জিজ্ঞাসা করুন:

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

মেমোরি ভ্যালুগুলো বাইটে থাকে, তাই 1g প্রিন্ট হয় 1073741824 হিসেবে। CPU ন্যানো-CPU-তে পরিমাপ করা হয়, তাই 1.5 প্রিন্ট হয় 1500000000 হিসেবে। যেকোনো ফিল্ডে 0 থাকার অর্থ হলো কোনো লিমিট সেট করা হয়নি। Docker যে সর্বনিম্ন মেমোরি লিমিট গ্রহণ করে তা হলো 6m, এর নিচে মেমোরি লিমিট সেট করলে কন্টেইনার স্টার্ট হতে অস্বীকার করবে।

কন্টেইনার লিমিট অতিক্রম করলে কী ঘটে

কন্টেইনারের গতি কমে না। এটি বন্ধ হয়ে যায়।

যখন কোনো প্রসেস মেমোরি পেজের অনুরোধ করে এবং cgroup ইতিমধ্যে তার memory.max-এ পৌঁছে যায়, তখন কার্নেল প্রথমে সেই cgroup-এর ভেতর থেকে যা সম্ভব তা পুনরুদ্ধার (reclaim) করে: প্রথমে ক্লিন পেজ ক্যাশ, তারপর সোয়াপ করা যায় এমন পেজ। যদি এই পুনরুদ্ধারে পর্যাপ্ত মেমোরি খালি না হয়, তবে cgroup OOM (out of memory) কিলার কন্টেইনারের ভেতর থেকে একটি প্রসেস বেছে নেয় এবং সেটিকে SIGKILL পাঠায়। কন্টেইনারের PID 1-কে মেরে ফেলার অর্থ হলো কন্টেইনারটি বন্ধ হয়ে যাওয়া। এক্সিট কোড 137 হলো মূলত 128 যোগ সিগন্যাল 9, তাই 137 যেকোনো SIGKILL-এর চিহ্ন, এটি নিজে কোনো OOM-এর প্রমাণ নয়।

docker compose ps -a
docker inspect --format '{{.State.OOMKilled}} {{.State.ExitCode}}' app-1

true 137 হলো একটি OOM কিল। false 137 মানে অন্য কোনো কারণে SIGKILL পাঠানো হয়েছে, এবং এর সাধারণ কারণ হলো docker compose stop তার দশ সেকেন্ডের গ্রেস পিরিয়ড শেষ করে ফেলেছে কারণ অ্যাপটি SIGTERM উপেক্ষা করেছে। এই পার্থক্যটি বুঝতে পারলে ঘণ্টার পর ঘণ্টা সময় বাঁচে, কারণ এই দুটি সমস্যার মধ্যে কোনো মিল নেই।

আরও দুটি জায়গায় এই ঘটনাটি রেকর্ড করা থাকে। ডেমনের লাইভ কার্যক্রম পর্যবেক্ষণ করুন:

docker events --filter event=oom

তারপর কার্নেল লগ পড়ুন, যা রিস্টার্টের পরেও টিকে থাকে:

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

একটি cgroup কিল Memory cgroup out of memory: Killed process 24713 (node) দিয়ে শুরু হওয়া একটি লাইন প্রিন্ট করে। Memory cgroup প্রিফিক্স ছাড়া কোনো লাইন মানে এটি হোস্ট OOM, যার অর্থ পুরো মেশিনটিরই র‍্যাম শেষ হয়ে গেছে। লিমিট ব্যবহারের মূল উদ্দেশ্যই হলো এই ব্যর্থতা রোধ করা, তাই এটি দেখা মানে হলো আপনার লিমিটগুলোর যোগফল অনেক বেশি, অথবা কিছু সার্ভিসের কোনো লিমিটই সেট করা নেই।

restart: unless-stopped-এর ক্ষেত্রে, একটি OOM লুপ সহজে ধরা পড়ে না, কারণ সার্ভিসটি মারা যাওয়ার এক সেকেন্ড পরেই docker compose ps-এ আবার চালু হতে দেখা যায়। আপটাইম কলাম এবং রিস্টার্ট কাউন্ট চেক করুন, এবং লিমিটের সাথে এমন একটি হেলথচেক যুক্ত করুন যা অ্যাপটিকে অস্বাস্থ্যকর হিসেবে রিপোর্ট করবে, যাতে কন্টেইনার বারবার মারা গেলে তা আপনার নজর এড়িয়ে না যায়।

Reservation একটি ইঙ্গিত মাত্র, limit-ই হলো নিয়ম

reservations.memory (পুরানো mem_reservation) হলো একটি soft floor। Docker একে একটি soft limit হিসেবে বর্ণনা করে, যা হোস্ট মেশিনে মেমোরির সংকট বা চাপ দেখা দিলে কার্যকর হয়। এটি কোনো কন্টেইনারকে এর চেয়ে বেশি মেমোরি ব্যবহার করা থেকে আটকায় না এবং কন্টেইনার মেমোরি চাইলে তা পাওয়ার নিশ্চয়তাও দেয় না। এটি কেবল কার্নেলকে নির্দেশ দেয় যেন তারা প্রথমে সেই কন্টেইনারগুলোর মেমোরি রিক্লেইম (reclaim) করে, যেগুলো তাদের reservation সীমার উপরে আছে।

সুতরাং, একটি reservation নিজে থেকে কোনো কিছু সুরক্ষা করে না। চাপের মুখে কোনো সার্ভিসকে অগ্রাধিকার দিতে এটি ব্যবহার করুন এবং নিরাপত্তার জন্য limit-এর ওপর নির্ভর করুন। Reservation-কে সবসময় limit-এর নিচে রাখুন, অন্যথায় কন্টেইনারটি চালু হবে না: Docker এই কনফিগারেশনটিকে Minimum memory limit can not be less than memory reservation limit ত্রুটির মাধ্যমে প্রত্যাখ্যান করবে।

Swap accounting, সত্যি বলতে

বেশিরভাগ VPS ইমেজ কোনো swap file ছাড়াই আসে। swapon --show এবং free -h কমান্ডগুলো চালান। যদি swap-এর মোট পরিমাণ শূন্য হয়, তবে নিচের swap-সংক্রান্ত কোনো সেটিংই কাজ করবে না এবং আপনার memory limit তখন শুধুমাত্র RAM-এর সীমাবদ্ধতা হিসেবে কাজ করবে।

memswap_limit কোনো swap-এর পরিমাণ নয়। এটি হলো memory এবং swap-এর যোগফল। mem_limit: 1g এবং memswap_limit: 2g ব্যবহার করলে, কন্টেইনারটি 1GB RAM এবং 1GB swap পাবে। এই দুটি মান সমান সেট করলে কন্টেইনারটি কোনো swap পাবে না। mem_limit সেট করে memswap_limit খালি রাখলে কন্টেইনারটি তার memory limit-এর সমান পরিমাণ swap ব্যবহার করতে পারবে।

Ubuntu 24.04 এবং Debian 13 ডিফল্টভাবে cgroup v2 ব্যবহার করে, যেখানে swap একটি আলাদা কাউন্টার (memory.swap.max) হিসেবে থাকে এবং এটি কোনো অতিরিক্ত সেটআপ ছাড়াই কাজ করে। পুরনো বার্তা Your kernel does not support swap limit capabilities আসে cgroup v1 হোস্ট থেকে, যা swapaccount=1 ছাড়া বুট করা হয়েছে। সেগুলোতে memory limit কার্যকর থাকলেও swap অংশটি উপেক্ষা করা হয়।

Swap আপনাকে কী সুবিধা দেয় সে বিষয়ে সৎ থাকুন। এটি OOM kill-কে ধীর করে, কিন্তু সম্ভাবনা কমায় না, কারণ একটি মেমোরি লিক করা প্রসেস RAM-এর মতোই swap-কেও দ্রুত পূর্ণ করে ফেলে। এদিকে, শেয়ারড VPS স্টোরেজে কোনো কন্টেইনার যদি swap thrashing করে, তবে তা ওই সার্ভারের অন্য সব সার্ভিসকে ধীর করে দেয়। ল্যাটেন্সি-সংবেদনশীল যেকোনো কিছুর জন্য, swap ছাড়া একটি সঠিক limit সেট করা বেশি কার্যকর, কারণ এতে ব্যর্থতা দ্রুত এবং আরও অনুমানযোগ্যভাবে ঘটে।

কেন মেমরি ব্যবহার বাস্তবে যতটা তার চেয়ে বেশি মনে হয়

MEM USAGE এর মান docker stats এ page cache অন্তর্ভুক্ত করে, তাই যে কন্টেইনার বড় ফাইল পড়ে তার মেমরি ব্যবহার সীমার কাছাকাছি পৌঁছে সেখানে স্থির থাকে। এটি স্বাভাবিক এবং কোনো leak নয়, কারণ OOM killer সক্রিয় হওয়ার আগেই clean cache পুনরুদ্ধার করা হয়। একটি self-hosted Jellyfin media server-এর মতো সার্ভিস এই কারণেই সবসময় তার মেমরি সীমার কাছাকাছি থাকে।

কন্টেইনারের ভেতর থেকে সংখ্যাটিকে 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, যা মুছে ফেলা সম্ভব। আপনার মেমরি সীমা নির্ধারণ করুন anon এবং কিছু অতিরিক্ত জায়গার (margin) ওপর ভিত্তি করে, মোট মেমরির ওপর নয়। memory.events ফাইলটি এই বিতর্কের চূড়ান্ত সমাধান দেয়: যদি oom_kill কাউন্টার শূন্যের বেশি হয়, তবে বুঝতে হবে কার্নেল কন্টেইনারটি শুরু হওয়ার পর থেকে কোনো কিছু বন্ধ (kill) করেছে। আর যদি max কাউন্টার বাড়তে থাকে, তবে কন্টেইনারটি বর্তমানে তার মেমরি সীমার চাপে আছে। এই কমান্ডগুলো চালানোর জন্য ইমেজের ভেতর shell এবং coreutils থাকা প্রয়োজন, তাই distroless বা scratch ইমেজে এগুলো কাজ করবে না।

8GB VPS-এর জন্য সাইজিং লিমিট

অ্যাপ্লিকেশন থেকে নয়, হোস্ট থেকে শুরু করুন। একটি 8GB VPS-এ কার্নেল, Docker daemon, sshd, journald এবং আপনার নিজের লগইন শেলের জন্য প্রায় 1GB জায়গা ছেড়ে দিন। এতে ব্যবহারের জন্য প্রায় 7GB অবশিষ্ট থাকে এবং প্রতিটি কন্টেইনারের লিমিটের যোগফল এর নিচে থাকা উচিত। ওভারকমিট করা ততক্ষণই কাজ করে, যতক্ষণ না দুটি সার্ভিস একসাথে তাদের সর্বোচ্চ রিসোর্স ব্যবহার করে।

8GB বক্সে একটি কার্যকর বিভাজন:

• Reverse proxy: 128m লিমিট। এটি একটি ছোট প্রসেস এবং এই কঠোর লিমিটটি কোনো ভুল কনফিগারেশন রিলোড হলে তা দ্রুত শনাক্ত করতে সাহায্য করে।
• PostgreSQL: 2g লিমিট, ডাটাবেস কনফিগারেশনে shared_buffers প্রায় 512MB সেট করা।
• Application container: 1g লিমিট।
• Background worker: 512m লিমিট।
• Media বা file service: 2g লিমিট, যার বেশিরভাগই পেজ ক্যাশে হিসেবে ব্যবহৃত হবে।

এই সংখ্যাগুলো সরাসরি আপনার স্ট্যাকে কপি করবেন না। একদিন সার্ভিসগুলোকে প্রকৃত লোডের অধীনে চালান, docker stats পর্যবেক্ষণ করুন, প্রতিটি কন্টেইনারের সর্বোচ্চ anon মান নিন এবং তার সাথে আরও প্রায় অর্ধেক পরিমাণ হেডরুম হিসেবে যোগ করুন। খুব কঠোর লিমিট সেট করা লিমিট না থাকার চেয়েও খারাপ, কারণ এটি স্বাভাবিক ট্রাফিক স্পাইকের সময় একটি সচল সার্ভিসকে বন্ধ করে দিতে পারে।

একটি ফাঁদ বিশেষভাবে উল্লেখ করা প্রয়োজন। বেশিরভাগ রানটাইমকে না জানালে তারা এই লিমিট দেখতে পায় না। PostgreSQL তার কন্টেইনার লিমিটের চেয়ে বেশি shared_buffers এবং work_mem সাইজ করে ফেলবে এবং বন্ধ হয়ে যাবে। একটি JVM (Java virtual machine)-এর হোস্ট র‍্যামের পরিবর্তে cgroup লিমিট থেকে তার হিপ সাইজ করার জন্য -XX:MaxRAMPercentage=75 প্রয়োজন। Node.js-এর জন্য মেগাবাইটে --max-old-space-size প্রয়োজন, যা কন্টেইনার লিমিটের নিচে সেট করতে হবে, অন্যথায় এর গার্বেজ কালেক্টর হিপকে বাড়তে দেয় যতক্ষণ না কার্নেল হস্তক্ষেপ করে। Ollama-এর ক্ষেত্রেও একই ঘটনা ঘটে, তবে ভিন্ন প্যারামিটার ব্যবহার করতে হয়, কারণ raising num_ctx grows the KV cache কয়েকশ মেগাবাইট পর্যন্ত KV ক্যাশ বাড়িয়ে দেয় এবং দীর্ঘ প্রম্পট চলাকালীন কন্টেইনারটি বন্ধ হয়ে যায়। cgroup কোনো আলোচনা করে না। এটি সরাসরি বন্ধ করে দেয়।

CPU limit-এর আচরণ সম্পূর্ণ ভিন্ন

cpus: "1.5" মানে হলো একটি কোরের 150% ক্ষমতা, যা CFS (completely fair scheduler) কোটা হিসেবে কার্যকর করা হয়। কন্টেইনারটি প্রতি 100ms পিরিয়ডে 150ms CPU সময় পায়, যা এর সকল থ্রেডের মধ্যে ভাগ করে দেওয়া হয়। যখন এই সময় শেষ হয়ে যায়, কার্নেল সেটিকে পরবর্তী পিরিয়ড পর্যন্ত অপেক্ষা করতে বাধ্য করে।

এটিই গুরুত্বপূর্ণ পার্থক্য। মেমোরি লিমিট অতিক্রম করলে একটি কন্টেইনারকে বন্ধ (kill) করে দেওয়া হয়। কিন্তু CPU লিমিট অতিক্রম করলে কন্টেইনারটিকে থ্রটল (throttle) করা হয় এবং সেটি ধীরগতিতে চলতে থাকে। তাই CPU লিমিট কিছুটা কঠোরভাবে সেট করা নিরাপদ, কিন্তু মেমোরি লিমিটের ক্ষেত্রে পর্যাপ্ত জায়গা (headroom) রাখা প্রয়োজন।

cpu_shares একটি ভিন্ন টুল: এটি একটি আপেক্ষিক ওয়েট (relative weight), যা শুধুমাত্র তখনই কার্যকর হয় যখন CPU পুরোপুরি ব্যস্ত থাকে। 1024 এবং 512 শেয়ারের দুটি কন্টেইনার একটি ব্যস্ত কোরকে প্রায় দুই-এক অনুপাতে ভাগ করে নেয়, আর সিস্টেম অলস থাকলে কোনোটিই সীমাবদ্ধ থাকে না। সার্ভিসগুলোর গুরুত্ব অনুযায়ী র‍্যাঙ্কিং করতে শেয়ার ব্যবহার করুন, আর যখন সত্যিকারের সিলিং বা সর্বোচ্চ সীমা নির্ধারণের প্রয়োজন হয় তখন cpus ব্যবহার করুন; উদাহরণস্বরূপ, রাতের কোনো ট্রান্সকোড জব যেন আপনার ওয়েব সার্ভারের রিসোর্স দখল করে না ফেলে তা নিশ্চিত করতে এটি কার্যকর।

FAQ

Docker Swarm ছাড়া কি deploy.resources.limits কাজ করে?

হ্যাঁ। আপনি যখন একটি সিঙ্গেল হোস্টে docker compose up চালান, তখন Compose V2 deploy.resources.limits এবং deploy.resources.reservations প্রয়োগ করে। এটি নিশ্চিত করতে docker inspect --format '{{.HostConfig.Memory}}' <container> ব্যবহার করুন, যা লিমিট বাইটে প্রদর্শন করে এবং কোনো লিমিট সেট করা না থাকলে 0 দেখায়। deploy-এর ভেতরে থাকা যে কি (key) গুলো শুধুমাত্র Swarm-এর জন্য প্রয়োজন, সেগুলো হলো mode, placement, update_config এবং endpoint_mode।

Docker Compose-এ exit code 137-এর অর্থ কী?

এর অর্থ হলো মেইন প্রসেসটি SIGKILL পেয়েছে, কারণ 137 হলো 128 যোগ সিগন্যাল 9। কার্নেলের OOM killer সাধারণত এর প্রধান কারণ, তবে অ্যাপ্লিকেশন SIGTERM উপেক্ষা করলে শাটডাউন টাইমআউটের কারণেও একই কোড তৈরি হতে পারে। পার্থক্য বোঝার জন্য docker inspect --format '{{.State.OOMKilled}} {{.State.ExitCode}}' <container> চালান। true 137 হলো মেমোরি কিল, আর false 137 তা নয়।

আমার কি mem_limit নাকি deploy.resources.limits.memory সেট করা উচিত?

উভয়ই docker compose-এর সাথে কাজ করে। deploy.resources.limits.memory হলো বর্তমান Compose Specification ফরম্যাট এবং নতুন ফাইলের জন্য এটিই উত্তম। যদি আপনার ফাইলের বাকি অংশ পুরনো টপ-লেভেল কি (key) ব্যবহার করে, তবে mem_limit বজায় রাখুন। একটি সার্ভিসে উভয়ই সেট করলে ফাইলটি পড়া কঠিন হয়ে যায়, তাই যেকোনো একটি বেছে নিন এবং docker inspect দিয়ে ফলাফল যাচাই করুন।

আমার কন্টেইনার কেন কিল না হয়ে মেমোরি লিমিটের সর্বোচ্চ পর্যায়ে আটকে থাকে?

docker stats-এ দেখানো ব্যবহারের পরিসংখ্যানে পেজ ক্যাশ অন্তর্ভুক্ত থাকে, যা কার্নেল চাপের মুখে OOM কিল ট্রিগার করার পরিবর্তে মুছে ফেলে। docker compose exec <service> grep -E '^(anon|file) ' /sys/fs/cgroup/memory.stat চালান এবং anon মানটি দেখুন, যা হলো ওয়ার্কিং সেট এবং এটি রিক্লেইম করা সম্ভব নয়। একটি কম anon মানের পাশে উচ্চ file মান থাকার অর্থ হলো কন্টেইনারটি ডিস্ক ইনপুট এবং আউটপুট করছে, এটি মারা যাওয়ার উপক্রম নয়।

8জিবি ভিপিএস (VPS)-এ আমার কতটুকু র‍্যাম বরাদ্দহীন রাখা উচিত?

কার্নেল, Docker daemon, sshd, journald এবং আপনার নিজের শেলের জন্য প্রায় 1জিবি জায়গা রাখুন, তারপর বাকি 7জিবির মধ্যে সমস্ত কন্টেইনারের লিমিটের যোগফল রাখুন। কোনো সংখ্যা চূড়ান্ত করার আগে একদিন বাস্তব লোডের অধীনে প্রতিটি কন্টেইনারের সর্বোচ্চ anon মান পর্যবেক্ষণ করুন এবং মোট বরাদ্দকে পূরণ করার লক্ষ্যমাত্রার চেয়ে বাজেট হিসেবে বিবেচনা করুন।