VPS-এ CPU steal time ও noisy neighbour চেনার উপায়

CPU steal time আসলে কী মাপে

CPU steal time হলো সেই সময়ের অংশ, যখন আপনার virtual CPU চালানোর জন্য প্রস্তুত ছিল এবং অপেক্ষা করার মতো কিছু ছিল না, কিন্তু hypervisor physical core অন্য guest-কে দিয়েছিল। কাজটি run queue-তে অপেক্ষমাণ ছিল। কিন্তু core অন্য guest-এর কাজে ব্যবহৃত হচ্ছিল। Linux এই cycle-গুলো আলাদাভাবে গণনা করে এবং st হিসেবে দেখায়। এর মাধ্যমে বোঝা যায়, “আমার server ব্যস্ত” আর “আমার server নিজের turn-এর জন্য অপেক্ষা করছে”—এই দুই অবস্থার পার্থক্য।

এই পার্থক্যের কারণেই counter-টি রাখা হয়েছে। আপনার নিজের process CPU-তে যে সময় ব্যয় করে, তা us (user) অথবা sy (system) হিসেবে দেখানো হয়। কোনো task storage-এর জন্য blocked অবস্থায় যে সময় কাটায়, তা wa (I/O wait) হিসেবে দেখানো হয়। একটি vCPU (virtual CPU) runnable অবস্থায় run queue-তে থাকলেও, তার কোনো I/O pending না থাকলে এবং তবু execute না করলে, তা st হিসেবে দেখানো হয়। আপনার server-এর ভেতরের কোনো কিছু এই অবস্থা দূর করতে পারে না, কারণ scheduling decision আপনার এক স্তর নিচে, host-এ নেওয়া হয়।

এটি সরাসরি একটি physical machine কীভাবে অনেক guest-এর মধ্যে ভাগ হয়—তার ফল। সাধারণ কারণ হলো কোনো প্রতিবেশী guest। একই node-এ থাকা অন্য guest অতিরিক্ত CPU ব্যবহার করলে host core-গুলো আপনাদের মধ্যে ভাগ করে দেয়। আরেকটি কারণ প্রায়ই বাদ পড়ে। অনেক provider shared vCPU-র ব্যবহার physical core-এর একটি নির্দিষ্ট fraction-এ সীমাবদ্ধ রাখে। কয়েকটি hypervisor-এ এই enforced cap guest-এর ভেতরে steal হিসেবে গণনা করা হয়। তাই st-এর উচ্চ reading জানায় যে core আপনাকে দেওয়া হয়নি। তবে সব সময় এটি জানায় না যে core কে ব্যবহার করেছে।

Steal সংখ্যাটি কোথা থেকে আসে

আপনার kernel নিজে steal পরিমাপ করতে পারে না, কারণ এটি host দেখতে পায় না। Hypervisor kernel-কে এই তথ্য জানায়। KVM-এ host একটি guest-এর সঙ্গে শেয়ার করা page-এ প্রতিটি vCPU-এর জন্য একটি counter লেখে। Kernel CONFIG_PARAVIRT_TIME_ACCOUNTING দিয়ে build করা হলে guest সেই counter-গুলোর মান যোগ করে; সব distribution kernel-এই এটি থাকে। Xen তার runstate area-এর মাধ্যমে একই তথ্য দেয়। userspace-এ মোট মানটি ঠিক একটি জায়গা থেকে পাওয়া যায়:

head -1 /proc/stat

cpu লাইনটিতে boot হওয়ার পর থেকে USER_HZ tick-এ দশটি counter থাকে। ক্রমটি হলো: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice। label-এর পর steal হলো অষ্টম মান। নিচের প্রতিটি tool, vmstat, top, mpstat এবং যেকোনো Prometheus exporter একই field পড়ে এবং দুটি sample থেকে percentage হিসাব করে।

এখানে একটি বিষয় অন্য সব কিছুর চেয়ে গুরুত্বপূর্ণ। Hypervisor counter-টি export না করলে field-টির মান চিরকাল zero থাকে। তখন এর ওপর নির্ভর করা প্রতিটি tool host অতিরিক্ত চাপের মধ্যে থাকলেও শান্ত 0.0 দেখায়। KVM এবং Xen এই counter export করে। VMware এবং Hyper-V-এর guest-এ সাধারণত স্থির zero দেখা যায়। Zero-কে বিশ্বাস করার আগে platform পরীক্ষা করুন:

systemd-detect-virt

এটি platform-এর নাম দেখায়। যেমন kvm, xen, vmware অথবা microsoft। Bare metal-এ এটি none দেখায়। Container-এর ভিতরে এটি পরিবর্তে runtime দেখায়। যেমন lxc, docker অথবা podman। এতে container সম্পর্কে জানা যায়, তার নিচের machine সম্পর্কে নয়। kvm-এ zero পাওয়া host আপনাকে যথেষ্ট resource দিচ্ছে—এর বাস্তব প্রমাণ। যে platform কখনও field-টিতে মান লেখে না, সেখানে zero কোনো প্রমাণই নয়। সে ক্ষেত্রে বাস্তব কাজের timing পরিমাপ করে contention বিচার করতে হবে।

VPS-এ CPU steal time কীভাবে পরীক্ষা করব?

vmstat প্যাকেজটি procps থেকে আসে। এটি প্রায় সব Ubuntu ও Debian VPS image-এ থাকে। কিছু minimal container image-এ এটি থাকে না। তাই এর ওপর নির্ভর করার আগে এটি install করুন।

sudo apt-get update
sudo apt-get install -y procps
vmstat --version
vmstat 1 5

vmstat --version-এর output-এ vmstat from procps-ng 4.0.4-এর মতো একটি line দেখা যায়। এটি দেখা গেলে tool-টি install করা আছে এবং আপনি kernel-এর প্রকৃত counter পড়ছেন। এরপর vmstat 1 5 প্রতি সেকেন্ডে একটি করে মোট পাঁচটি sample নেয়।

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 1  0      0 3216484  98304 1284360    0    0     4    18   62  110  3  1 96  0  0  0
 2  0      0 3216232  98304 1284360    0    0     0     0  248  431  6  2 84  0  8  0

ডান পাশের cpu block-এ st column খুঁজুন। বর্তমান procps-ng build-গুলো KVM guest time-এর জন্য এর পরে gu column দেখায়। তাই st ডান দিক থেকে দ্বিতীয় column, শেষ column নয়। header-এর নাম দেখে column পড়ুন, কারণ release পরিবর্তনের সঙ্গে column-এর অবস্থান বদলেছে।

দুটি অভ্যাস রাখলে reading নির্ভরযোগ্য থাকে। প্রথম data line-টি boot হওয়ার পর থেকে এখন পর্যন্ত average, তাই এটি বাদ দিয়ে পরের line-গুলো পড়ুন। আর একটি sample কোনো measurement নয়, কারণ steal burst আকারে আসে। তাই সিদ্ধান্ত নেওয়ার আগে vmstat 1 60 চালিয়ে পুরো এক মিনিট monitor করুন।

top-এর %Cpu(s) summary line-এ একই number দেখায়। সেখানে এটি st চিহ্নিত field-এ থাকে:

%Cpu(s):  6.2 us,  2.1 sy,  0.0 ni, 83.9 id,  0.0 wa,  0.0 hi,  0.3 si,  7.5 st

প্রতিটি core-এর বিস্তারিত দেখতে sysstat যোগ করুন:

sudo apt-get install -y sysstat
mpstat -P ALL 1 5

mpstat প্রতিটি CPU-এর জন্য একটি row দেখায়। এতে %steal column থাকে, যা দেখায় সব vCPU প্রভাবিত কি না, নাকি শুধু একটি vCPU প্রভাবিত। Support ticket-এর জন্য প্রয়োজনীয় history রাখতে screen থেকে পড়ার পরিবর্তে sample-গুলো সংরক্ষণ করুন:

date -u | tee -a ~/steal.log
mpstat -P ALL 1 5 | tee -a ~/steal.log

আপনার সন্দেহের সময়জুড়ে cron থেকে এটি চালান। তাহলে file-টি provider-কে “গত রাতে ধীর মনে হয়েছিল” বলার পরিবর্তে সঠিক দশ মিনিটের প্রমাণ দেখানোর সুযোগ দেবে।

steal মানগুলোর অর্থ কী?

• একটি স্থির 0.0। এটি স্বাভাবিক অবস্থা নির্দেশ করে, অথবা platform মোটেই steal রিপোর্ট করে না। উদ্‌যাপন করার আগে systemd-detect-virt দিয়ে নিশ্চিত করুন।
• কয়েক সেকেন্ড স্থায়ী কয়েক শতাংশের spike। যেকোনো shared node-এ এটি স্বাভাবিক। কোনো প্রতিবেশী node-এর build শুরু হতে পারে, অথবা host তার backup চালাতে পারে।
• shared plan-এ 1 থেকে 5 percent পর্যন্ত স্থায়ী মান। এটি প্রত্যাশিত। shared CPU ব্যবহারের প্রতিফলনই মূল্যে থাকে।
• 5 থেকে 10 percent পর্যন্ত স্থায়ী মান। এটি পরিমাপযোগ্য ধীরগতি নির্দেশ করে। প্রমাণ সংগ্রহ শুরু করুন এবং কয়েক দিন ধরে একই সময়ের তথ্য তুলনা করুন।
• একটানা কয়েক ঘণ্টা 10 percent-এর বেশি। আপনার workload-এর জন্য node-এ অতিরিক্ত subscription রয়েছে। এই মাত্রায় support ticket খোলা বা অন্য node-এ স্থানান্তর যুক্তিযুক্ত।

এই সীমাগুলোকে specification হিসেবে নয়, বরং বোঝার নির্দেশিকা হিসেবে ব্যবহার করুন। কারণ কোনো provider shared plan-এ steal-এর নিশ্চয়তা প্রকাশ করে না। আপনি কী চালাচ্ছেন, তার সঙ্গে মিলিয়ে এগুলো মূল্যায়ন করুন। একটি overnight batch job 15 percent steal সহ্য করতে পারে এবং কেউ তা টের নাও পেতে পারে। latency-sensitive service-এ average উদ্বেগজনক হওয়ার অনেক আগেই p99-তে এর প্রভাব দেখা যায়। তাই trading bot-এর মতো latency-sensitive workload dedicated core-এ চালানো উচিত।

আপনার steal time-এর খরচ কত?

হিসাবটি সংক্ষিপ্ত। আপনার CPU time-এর s অংশ নেওয়া হলে, নির্দিষ্ট পরিমাণ CPU প্রয়োজন এমন একটি কাজ সম্পন্ন হতে wall clock-এ 1 / (1 - s) গুণ বেশি সময় লাগে। 60 seconds CPU প্রয়োজন এমন একটি কাজের ক্ষেত্রে:

[
  {
    "steal_percent": 0,
    "wall_clock_seconds": "60.0"
  },
  {
    "steal_percent": 3,
    "wall_clock_seconds": "61.9"
  },
  {
    "steal_percent": 8,
    "wall_clock_seconds": "65.2"
  },
  {
    "steal_percent": 15,
    "wall_clock_seconds": "70.6"
  },
  {
    "steal_percent": 25,
    "wall_clock_seconds": "80.0"
  },
  {
    "steal_percent": 40,
    "wall_clock_seconds": "100.0"
  }
]

3 percent-এ, যা সাধারণ shared-plan-এর একটি পাঠ, কাজটি 61.9 seconds সময় নেয়, 60.0 seconds নয়। এ নিয়ে কেউ ticket খোলে না। 8 percent-এ সময় লাগে 65.2 seconds। 40 percent-এ একই কাজের জন্য 100.0 seconds প্রয়োজন হয়, এবং আগে যে queue দ্রুত খালি হতো, সেটি উল্টো বাড়তে শুরু করে।

এগুলো calculated value, measurement নয়। এই model-এ একটি runnable thread ধরা হয়েছে এবং interval জুড়ে steal সমানভাবে ছড়িয়ে আছে বলে ধরে নেওয়া হয়েছে। বাস্তব service-এ প্রভাব অনেক সময় এই curve-এর চেয়েও খারাপ মনে হয়, কারণ stolen slice কোনো request-এর মাঝখানে পড়লে সেই বিলম্বের প্রভাব ওই request-এর উপর অপেক্ষমাণ প্রতিটি কাজের ওপরও পড়ে। Formula-এর বদলে নিজের মান পেতে, শান্ত সময়ে এবং আবার ব্যস্ত সময়ে VPS benchmark করুন, উভয় window-র জন্য st record করে।

এটি কি steal, নাকি অন্য কোনো সমস্যা?

Steal-কে অন্যান্য উপসর্গের সঙ্গে সহজেই গুলিয়ে ফেলা যায়। একই vmstat লাইনে কাউন্টারগুলোর মান একসঙ্গে দেখুন।

• st বেশি, কিন্তু r এবং us কম থাকে: host আপনাকে CPU core দিচ্ছে না। এটিই steal।
• r আপনার vCPU সংখ্যার তুলনায় অনেক বেশি, us বেশি এবং st প্রায় শূন্য: আপনার নিজস্ব CPU যতটা কাজ সামলাতে পারে, আপনি তার চেয়ে বেশি কাজ চালাচ্ছেন। r-এর মান nproc-এর output-এর সঙ্গে তুলনা করুন। এটি আপনার নিজস্ব oversubscription, অন্য কোনো প্রতিবেশী instance-এর সমস্যা নয়।
• wa বেশি এবং st প্রায় শূন্য: task-গুলো storage-এর জন্য আটকে আছে। এটি আলাদা সমস্যা এবং এর সমাধানও আলাদা।
• Load average বেশি, কিন্তু st এবং us দুটিই কম: load figure-এ uninterruptible task-ও গণনা করা হয়। তাই এটি সাধারণত CPU সমস্যার বদলে আটকে থাকা device বা সাড়া না দেওয়া network mount নির্দেশ করে।

Burstable plan-এর জন্য আলাদা করে একটি বিষয় মনে রাখা দরকার। আপনি idle থাকলে এই plan-এ credit balance জমে, busy থাকলে তা কমে, এবং credit শেষ হয়ে গেলে provider আপনাকে baseline rate-এ সীমাবদ্ধ করে। কিছু platform-এ এই throttle-কে steal হিসেবে report করা হয়। অন্য platform-এ এটি ভেতর থেকে দেখা যায় না; আপনি শুধু প্রতি সেকেন্ডে কম CPU cycle পান। কোনো প্রতিবেশী instance-কে দায়ী করার আগে plan-এর বিবরণ পড়ুন।

কেন একটি container steal time দেখায় না

Steal একটি virtual machine-এর বৈশিষ্ট্য। এর ভেতরে চলা container-এর বৈশিষ্ট্য নয়। নিজের VPS-এ চলা Docker container host-এর /proc শেয়ার করে। তাই container-এর ভেতরে পড়া st মানটি VPS-এর steal। এই ক্ষেত্রেই সেটিই প্রত্যাশিত ফল। VPS হিসেবে বিক্রি করা container-based virtualisation ভিন্নভাবে কাজ করে। lxcfs চালু থাকলে container-এর ভেতরের /proc/stat cgroup accounting থেকে তৈরি করা হয়। তাই নির্মাণগতভাবেই steal-এর মান শূন্য থাকে। শুধু container-এর ভেতর থেকে metrics সংগ্রহ করা monitoring stack এমন একটি স্থির শূন্য দেখাতে পারে, যখন নিচের physical machine-এ CPU resource-এর তীব্র ঘাটতি চলছে।

একটি container-এর ভেতরে একই অর্থ বহনকারী counter হলো CPU quota throttling। cgroup v2-এ:

cat /sys/fs/cgroup/cpu.stat

nr_throttled সেই enforcement period-এর সংখ্যা গণনা করে, যেগুলোতে group তার CPU quota-এ পৌঁছেছে। throttled_usec group কত সময় frozen ছিল, তার মোট সময় দেখায়। nr_throttled বাড়ার অর্থ হলো আপনার process runnable ছিল, কিন্তু চলছিল না। Steal-এর অভিজ্ঞতাও একই রকম। তবে এখানে কারণ হলো আপনার নির্ধারিত limit। host-কে দোষ দেওয়ার আগে নিজের limit পরীক্ষা করুন। বিশেষ করে compose file-এ CPU limit দিয়ে VPS-এ Docker-এ আপনার service চালালে এটি করুন। Layered virtualisation-এ সময় হারানোর আরও একটি স্তর যুক্ত হয়। কারণ আপনার VPS-এর ভেতরের একটি VM-কে VPS-এর steal-এর পাশাপাশি নিজের scheduling delay-ও বহন করতে হয়। VPS-এ nested virtualisation চালালে বিষয়টি মনে রাখুন।

sustained steal হলে কী করবেন

Guest-এর ভেতরের কোনো setting steal ঠিক করতে পারে না, কারণ সিদ্ধান্ত নেওয়া scheduler guest-এর বাইরে চলে। বাস্তবসম্মত চারটি পদক্ষেপ আছে।

প্রথমে প্রমাণ সংগ্রহ করুন। UTC-তে timestamp, প্রতিটি episode-এর সময়কাল, কত ঘন ঘন এটি পুনরাবৃত্তি হয়, এবং mpstat-এ একটি vCPU প্রভাবিত হচ্ছে নাকি সবগুলো হচ্ছে—এসব নথিবদ্ধ করুন। এক সপ্তাহের log করা sample একটি screenshot-এর চেয়ে বেশি কার্যকর।

এই তথ্য দিয়ে ticket খুলুন। দুটি সরাসরি প্রশ্ন করুন: এই সময়সীমাগুলোতে node কি oversubscribed থাকে, এবং আপনার instance কি অন্য node-এ সরানো যাবে? vmstat-এর output এবং সঠিক সময়গুলো যুক্ত করুন। Provider পুনরুৎপাদন করা যায় এমন সময়সীমার ভিত্তিতে ব্যবস্থা নেয়। শুধু server ধীর—এমন ticket-এর উত্তরে তারা সাধারণত সঠিক সময় জানতে চায়। এই কাজের কতটা আপনি provider-এর ওপর ছেড়ে দিতে পারেন, তা managed ও unmanaged VPS-এর মধ্যে একটি বাস্তব পার্থক্য।

Migration-এর অনুরোধ করুন। Guest-কে কম load থাকা node-এ সরানো provider-এর জন্য নিয়মিত কাজ, এবং সাধারণত এর জন্য অল্প সময়ের reboot লাগে। এটি এমন একটি সমাধান যার জন্য অতিরিক্ত খরচ হয় না। একই node-এ একসঙ্গে একাধিক ভারী neighbour থাকাই সাধারণ সমস্যার কারণ।

Contention এড়াতে অর্থ ব্যয় করুন। Dedicated vCPU plan আপনার instance-এর জন্য physical core সংরক্ষণ করে। ফলে counter শূন্যে থাকে এবং সেখানেই থাকে। প্রতি মাসে এর খরচ বেশি। যে workload variance সহ্য করতে পারে না, তার জন্য এটিই সৎ সমাধান। এটিও যথেষ্ট না হলে, অথবা memory bandwidth-ও নিজে ব্যবহার করতে চাইলে, পরবর্তী ধাপ হলো VPS-এর বদলে একটি dedicated server।

এর মধ্যে অপেক্ষা করার সময় steal-এর প্রভাব কমান। আপনার vCPU যতগুলো, তার চেয়ে কম worker thread চালান। কারণ core না পাওয়া thread শুধু context switch বাড়ায়। Batch work এমন সময়ে চালান, যখন node-এ কম load থাকে; আপনার log এখন সেই সময় জানিয়ে দিচ্ছে। এরপর একই command দিয়ে একই সময়সীমা জুড়ে আবার measure করুন। এতে অনুমান না করে বলা যাবে পরিবর্তনটি কাজ করেছে কি না।

FAQ

VPS-এ স্বাভাবিক CPU steal time কত?

Shared plan-এ অল্প সময়ের spike এবং প্রায় 5 percent-এর নিচে স্থিতিশীল মান স্বাভাবিক। কারণ shared CPU-তে host physical core-গুলো guest-দের মধ্যে ভাগ করে। কয়েক ঘণ্টা ধরে স্থিতিশীলভাবে double-digit মান স্বাভাবিক নয়; এ ক্ষেত্রে support ticket খোলা উচিত। Dedicated vCPU plan-এ প্রত্যাশিত reading হলো 0.0। তাই এর বাইরে কোনো মান দেখা গেলে তা report করার মতো fault। নিজের workload-এর সঙ্গে মিলিয়ে মানটি বিচার করুন। যে steal একটি overnight batch job সামলে নিতে পারে, latency-sensitive API-এর ক্ষেত্রে তা গ্রহণযোগ্য নাও হতে পারে।

বড় plan নিলে কি high steal time ঠিক হবে?

নিজে থেকে হবে না। একই shared node-এ বেশি vCPU নিলে একই প্রতিযোগিতাপূর্ণ physical core-গুলোর জন্য আরও virtual CPU প্রতিদ্বন্দ্বিতা করে। ফলে percentage আগের মতোই থাকতে পারে। Steal কমানোর কার্যকর উপায় হলো dedicated CPU allocation নেওয়া অথবা কম load থাকা node-এ স্থানান্তর করা। ব্যস্ত machine-এর বড় share নিলেও সেটি ব্যস্ত machine-এরই একটি share থাকে।

VPS ধীর হলেও 0 steal time দেখায় কেন?

এর দুটি সাধারণ কারণ আছে। Hypervisor হয়তো counter-টি export করে না। VMware এবং Hyper-V platform-এ এটি সাধারণ। তাই host-এ যা-ই ঘটুক, field-টি zero থাকে। আপনি কোন platform-এ আছেন তা দেখতে systemd-detect-virt চালান। অন্যথায় bottleneck অন্যত্র রয়েছে। Storage wait দেখতে wa পরীক্ষা করুন, নিজের overload যাচাই করতে r-এর সঙ্গে nproc তুলনা করুন, এবং quota throttling দেখতে container-এর ভেতরে /sys/fs/cgroup/cpu.stat পড়ুন।

আমার server-এর ভেতর থেকে কি steal time কমানো যায়?

Guest-এর ভেতর থেকে host-এর scheduling পরিবর্তন করা যায় না। শুধু এর প্রভাব কমানো যায়। আপনার vCPU-এর চেয়ে কম worker thread চালান, যাতে core পাওয়ার অপেক্ষায় run queue-তে কম কাজ জমে থাকে। Node-এ load কম থাকা সময়ে batch job চালান। Cache ব্যবহার করুন, যাতে কম সংখ্যক request-এর জন্য CPU প্রয়োজন হয়। Steal time প্রকৃতপক্ষে সরাতে যে পরিবর্তনগুলো দরকার, অর্থাৎ অন্য node-এ migration বা dedicated core নেওয়া, সেগুলো provider-এর দিক থেকেই করতে হবে।