কন্টেইনারের জন্য মেমরি ও CPU লিমিট

কীভাবে কন্টেইনারের জন্য মেমরি ও 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-এর সমান সেট করলে সোয়াপিং নিষিদ্ধ হয়: ঘণ্টার পর ঘণ্টা কোনোমতে চলা মেশিনের চেয়ে সৎভাবে ক্র্যাশ করা ভালো।

কতটা বরাদ্দ করবেন

আপনার টিয়ার থেকে শুরু করুন এবং সিস্টেমের জন্য কিছু জায়গা রেখে দিন।

টিয়ার	মেমোরি	কনটেইনারের জন্য যুক্তিসঙ্গত মোট সীমা
VDS-1	2 GB	1.5 GB পর্যন্ত
VDS-2	4 GB	3 GB পর্যন্ত
VDS-3	8 GB	6.5 GB পর্যন্ত
VDS-4	16 GB	14 GB পর্যন্ত
VDS-5	24 GB	21 GB পর্যন্ত
VDS-6	32 GB	29 GB পর্যন্ত

বাকিটা সিস্টেম, ফাইল ক্যাশে এবং 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 যোগ করুন — দেখুন কনটেইনার আপডেট করা।
ডিস্কের কথা ভুলে গেছেন। আপনি মেমোরি সীমিত করেছেন, কিন্তু লেখা একটি সীমায় ঠেকে যাচ্ছে: দেখুন ডিস্কের গতি।