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

Docker Compose মেমরি লিমিট যা করে

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

এটি VPS-এর ক্ষেত্রে সবচেয়ে গুরুত্বপূর্ণ, যেখানে RAM নির্দিষ্ট থাকে এবং ধার নেওয়ার মতো কোনো অতিরিক্ত হোস্ট মেমরি থাকে না। মেমরি লিক বা ত্রুটিপূর্ণ কুয়েরিযুক্ত একটি কন্টেইনার 8GB-এর একটি মেশিনের সমস্ত ফ্রি পেজ দখল করে নিতে পারে। তখন কার্নেল যে প্রসেসটিকে সবচেয়ে ক্ষতিকর মনে করে সেটিকে বন্ধ করে দেয়, যা প্রায়শই ডাটাবেস বা আপনার 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 প্লাগইন, সেটি deploy.resources.limits এবং deploy.resources.reservations প্রয়োগ করে যখন আপনি docker compose up রান করেন, এমনকি সেখানে কোনো Swarm ক্লাস্টার না থাকলেও। deploy ব্লকের শুধুমাত্র Swarm-এর জন্য প্রযোজ্য অংশগুলো হলো অন্যান্য কি (key): 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, এবং এর নিচে মেমোরি লিমিট সেট করলে কন্টেইনার স্টার্ট হতে অস্বীকার করে।

যখন একটি কন্টেইনার তার সীমার (limit) সম্মুখীন হয় তখন কী ঘটে

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

যখন কোনো প্রসেস একটি পেজের জন্য অনুরোধ করে এবং cgroup ইতিমধ্যে তার memory.max-এ পৌঁছে যায়, তখন কার্নেল প্রথমে সেই cgroup-এর ভেতরে যা কিছু পুনরুদ্ধার করা সম্ভব তা করে: ক্লিন পেজ ক্যাশ, তারপর যে পেজগুলো সোয়াপ (swap) করা যায়। যদি পুনরুদ্ধারের মাধ্যমে পর্যাপ্ত জায়গা খালি না হয়, তবে cgroup OOM (আউট অফ মেমরি) কিলার কন্টেইনারের ভেতরে একটি প্রসেসকে নির্বাচন করে এবং সেটিকে 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, যার অর্থ মেশিনটির নিজেরই RAM শেষ হয়ে গেছে। এটি সেই ব্যর্থতা যা সীমা নির্ধারণের মাধ্যমে প্রতিরোধ করার কথা, তাই এটি দেখা মানে হলো আপনার নির্ধারিত সীমার সমষ্টি অনেক বেশি, অথবা কিছু সার্ভিসের কোনো সীমা নেই।

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

রিজার্ভেশন একটি ইঙ্গিত, লিমিট হলো নিয়ম

reservations.memory (পুরানো mem_reservation) হলো একটি সফট ফ্লোর। Docker একে একটি সফট লিমিট হিসেবে বর্ণনা করে, যা হোস্ট মেশিনে মেমোরির স্বল্পতা বা চাপের সময় সক্রিয় হয়। এটি কোনো কন্টেইনারকে এর চেয়ে বেশি মেমোরি ব্যবহার করা থেকে আটকায় না এবং কন্টেইনার মেমোরি চাইলে তা যে সবসময় পাওয়া যাবে, তার নিশ্চয়তাও দেয় না। এটি কেবল কার্নেলকে নির্দেশ দেয় যেন মেমোরির প্রয়োজন হলে প্রথমে সেই কন্টেইনারগুলো থেকে মেমোরি রিক্লেইম করা হয়, যেগুলো তাদের রিজার্ভেশনের চেয়ে বেশি মেমোরি ব্যবহার করছে।

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

Swap অ্যাকাউন্টিং, সত্যি বলতে

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

memswap_limit হলো swap-এর পরিমাণ নয়। এটি হলো মেমোরি এবং swap-এর যোগফল। mem_limit: 1g এবং memswap_limit: 2g ব্যবহার করলে, কন্টেইনারটি 1GB RAM এবং 1GB swap পাবে। এই দুটি মান সমান সেট করলে কন্টেইনারে কোনো swap থাকবে না। mem_limit সেট করে memswap_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 ছাড়া বুট করা হয়েছে। সেগুলোতে মেমোরি লিমিট কার্যকর থাকলেও swap অংশটি উপেক্ষা করা হয়।

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

মেমরি ব্যবহারের পরিসংখ্যান কেন বিভ্রান্তিকর হতে পারে

MEM USAGE এর মান docker stats এ পেজ ক্যাশ অন্তর্ভুক্ত করে। তাই কোনো কন্টেইনার যখন বড় ফাইল পড়ে, তখন এর মেমরি ব্যবহার সীমার কাছাকাছি পৌঁছে যায় এবং সেখানেই স্থির থাকে। এটি স্বাভাবিক এবং কোনো মেমরি লিক নয়, কারণ OOM killer সক্রিয় হওয়ার আগেই ক্লিন ক্যাশ পুনরায় ব্যবহারযোগ্য করা হয়। একটি সেলফ-হোস্টেড Jellyfin মিডিয়া সার্ভার এর মতো সার্ভিসগুলো ঠিক এই কারণেই সবসময় তাদের মেমরি সীমার কাছাকাছি থাকে।

কন্টেইনারের ভেতর থেকে মেমরিকে ক্যাশ এবং প্রকৃত ওয়ার্কিং সেটে আলাদা করুন:

docker compose exec app grep -E '^(anon|file) ' /sys/fs/cgroup/memory.stat
docker compose exec app cat /sys/fs/cgroup/memory.events

anon হলো অ্যানোনিমাস মেমরি, যা ওয়ার্কিং সেট এবং এটি মুছে ফেলা যায় না। file হলো পেজ ক্যাশ, যা মুছে ফেলা সম্ভব। আপনার মেমরি লিমিট নির্ধারণ করুন anon এবং কিছু অতিরিক্ত মার্জিন যোগ করে, মোট মেমরির ওপর ভিত্তি করে নয়। memory.events ফাইলটি এই বিতর্কের চূড়ান্ত সমাধান দেয়: যদি oom_kill কাউন্টার শূন্যের বেশি হয়, তবে বুঝতে হবে কন্টেইনারটি চালু হওয়ার পর কার্নেল কোনো প্রসেস বন্ধ করেছে। আর যদি max কাউন্টার বাড়তে থাকে, তবে বুঝতে হবে কন্টেইনারটি বর্তমানে তার মেমরি সীমার চাপে রয়েছে। এই কমান্ডগুলো চালানোর জন্য ইমেজের ভেতরে shell এবং coreutils থাকা প্রয়োজন, তাই distroless বা scratch ইমেজে এগুলো কাজ করবে না।

8GB VPS-এ সাইজিং লিমিট

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

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

• রিভার্স প্রক্সি: 128m লিমিট। এটি একটি ছোট প্রসেস এবং এই কঠোর লিমিটটি ভুল কনফিগারেশন রিলোডকে তাৎক্ষণিকভাবে শনাক্ত করতে সাহায্য করে।
• PostgreSQL: 2g লিমিট, যেখানে ডাটাবেস কনফিগারেশনে shared_buffers প্রায় 512MB সেট করা থাকে।
• অ্যাপ্লিকেশন কন্টেইনার: 1g লিমিট।
• ব্যাকগ্রাউন্ড ওয়ার্কার: 512m লিমিট।
• মিডিয়া বা ফাইল সার্ভিস: 2g লিমিট, যার বেশিরভাগই পেজ ক্যাশে হিসেবে ব্যবহৃত হবে।

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

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

CPU লিমিট সম্পূর্ণ ভিন্নভাবে কাজ করে

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

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

cpu_shares একটি ভিন্ন টুল: এটি একটি আপেক্ষিক ওয়েট (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-এর ভেতরে থাকা যে কি (keys) গুলোর জন্য প্রকৃতপক্ষে Swarm প্রয়োজন, সেগুলো হলো mode, placement, update_config এবং endpoint_mode।

Docker Compose-এ এক্সিট কোড 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 ফরম্যাট এবং নতুন ফাইলের জন্য এটিই উত্তম। যদি আপনার ফাইলের বাকি অংশ ইতিমধ্যে পুরনো টপ-লেভেল কি (keys) ব্যবহার করে থাকে, তবে mem_limit বজায় রাখুন। একটি সার্ভিসে উভয়ই সেট করলে ফাইলটি পড়া কঠিন হয়ে যায়, তাই যেকোনো একটি বেছে নিন এবং docker inspect দিয়ে ফলাফল যাচাই করুন।

আমার কন্টেইনারটি কেন কিল না হয়ে তার পূর্ণ মেমোরি লিমিটে আটকে আছে?

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

8GB RAM-এর একটি VPS-এ আমার কতটুকু RAM বরাদ্দহীন রাখা উচিত?

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