দ্বারা VPS-এ CPU steal time ও noisy neighbour বুঝুন
CPU steal time হলো VPS প্রস্তুত থাকা সত্ত্বেও না-পাওয়া CPU সময়। vmstat-এর st column পড়ে noisy neighbour নাকি নিজের overload, তা নির্ণয় করুন।
CPU steal time আসলে কী পরিমাপ করে
CPU steal time হলো সেই সময়ের অংশ, যখন আপনার virtual CPU চালানোর জন্য প্রস্তুত ছিল এবং অপেক্ষা করার মতো কোনো কাজ ছিল না, কিন্তু hypervisor physical core অন্য একটি guest-কে দিয়েছিল। কাজটি run queue-তে অপেক্ষা করছিল। কিন্তু core অন্য guest-এর কাজে ব্যবহৃত হচ্ছিল। Linux এই cycle-গুলো আলাদাভাবে গণনা করে এবং st হিসেবে report করে। এর মাধ্যমে বোঝা যায়, “আমার server ব্যস্ত” নাকি “আমার server নিজের turn-এর জন্য অপেক্ষা করছে”।
এই পার্থক্যের কারণেই counter-টি রয়েছে। আপনার নিজের process CPU-তে যে সময় ব্যবহার করে, তা us (user) অথবা sy (system) হিসেবে report হয়। কোনো task storage-এর জন্য blocked অবস্থায় যে সময় কাটায়, তা wa (I/O wait) হিসেবে report হয়। একটি vCPU (virtual CPU) runnable অবস্থায় run queue-তে থাকলে, তার কোনো I/O outstanding না থাকলে এবং তবু সেটি execute না করলে, সেই সময় st হিসেবে report হয়। আপনার server-এর ভেতরের কোনো কিছু এই state সরাতে পারে না, কারণ 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 আপনাকে দেওয়া হয়নি। তবে কে সেটি ব্যবহার করেছে, তা সব সময় জানায় না।
Steal সংখ্যা কোথা থেকে আসে
আপনার kernel নিজে steal পরিমাপ করতে পারে না, কারণ এটি host দেখতে পায় না। Hypervisor kernel-কে এই তথ্য দেয়। KVM-এ host প্রতি-vCPU counter একটি guest-এর সঙ্গে শেয়ার করা page-এ লেখে। kernel CONFIG_PARAVIRT_TIME_ACCOUNTING দিয়ে build করা হলে guest সেই counter-এর মান যোগ করে। প্রতিটি distribution kernel-এই এটি থাকে। Xen তার runstate area-এর মাধ্যমে একই তথ্য দেয়। userspace-এ মোট মান ঠিক একটি জায়গা দিয়ে পৌঁছায়:
head -1 /proc/statএই cpu line-এ 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 অতিরিক্ত load-এ থাকলেও শান্ত 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 আপনাকে পর্যাপ্ত CPU সময় দিচ্ছে—এটি তার বাস্তব প্রমাণ। যে 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 5vmstat --version-এর আউটপুটে vmstat from procps-ng 4.0.4-এর মতো একটি line দেখা যায়। এই আউটপুট দেখা গেলে tool-টি install করা আছে এবং আপনি প্রকৃত kernel counter পড়ছেন। এরপর vmstat 1 5 প্রতি second-এ একটি করে মোট পাঁচটি 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 হওয়ার পর থেকে গড় মান, তাই এটি উপেক্ষা করে পরের line-গুলো পড়ুন। একটি sample measurement নয়, কারণ steal burst আকারে আসতে পারে। তাই vmstat 1 60 চালিয়ে পুরো এক minute 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 5mpstat প্রতিটি CPU-এর জন্য একটি করে row দেখায়। এতে %steal column থাকে, যা দেখায় সব vCPU প্রভাবিত কি না, নাকি শুধু একটি vCPU প্রভাবিত হয়েছে। Support ticket-এর জন্য প্রয়োজনীয় history সংরক্ষণ করতে screen থেকে পড়ার বদলে sample-গুলো file-এ লিখে রাখুন:
date -u | tee -a ~/steal.log
mpstat -P ALL 1 5 | tee -a ~/steal.logআপনার সন্দেহের সময়জুড়ে cron থেকে এটি চালান। তাহলে file-টি provider-কে শুধু “গত রাতে ধীর মনে হয়েছিল” বলার বদলে ঠিক কোন দশ minute-এ সমস্যা হয়েছে তার প্রমাণ দেবে।
Steal সংখ্যাগুলোর অর্থ কী?
- একটানা
0.0। এটি সুস্থ অবস্থার নির্দেশ করে, অথবা platform মোটেও steal report করে না। উচ্ছ্বসিত হওয়ার আগেsystemd-detect-virtদিয়ে নিশ্চিত করুন। - কয়েক সেকেন্ড স্থায়ী কয়েক শতাংশের spike। যেকোনো shared node-এ এটি স্বাভাবিক। কোনো প্রতিবেশী node-এর build শুরু হতে পারে, অথবা host তার backup চালাতে পারে।
- Shared plan-এ একটানা 1 থেকে 5 শতাংশ। এটি প্রত্যাশিত। দামের মধ্যে shared CPU ব্যবহারের বিষয়টি প্রতিফলিত হয়।
- একটানা 5 থেকে 10 শতাংশ। এটি পরিমাপযোগ্য ধীরগতি। প্রমাণ নথিবদ্ধ করা শুরু করুন এবং কয়েক দিন ধরে একই সময়ের ফলাফল তুলনা করুন।
- একসঙ্গে কয়েক ঘণ্টা 10 শতাংশের বেশি। আপনার workload-এর তুলনায় node-এ অতিরিক্ত workload নির্ধারিত আছে। এই মাত্রায় support ticket খোলা বা অন্য node-এ স্থানান্তর করা যুক্তিসঙ্গত।
এই সীমাগুলো specification হিসেবে নয়, বরং ফলাফল বোঝার নির্দেশিকা হিসেবে ব্যবহার করুন। কারণ কোনো provider shared plan-এ steal-এর নিশ্চয়তা প্রকাশ করে না। আপনি কী চালাচ্ছেন, তার সঙ্গে এই মানগুলো মিলিয়ে দেখুন। একটি overnight batch job 15 শতাংশ steal সামলাতে পারে, কিন্তু কেউ তা টেরও নাও পেতে পারে। একটি latency-sensitive service গড় মান উদ্বেগজনক হওয়ার অনেক আগেই p99-এ এর প্রভাব দেখায়। তাই trading bot-এর মতো latency-sensitive workload dedicated core-এ চালানো উচিত।
Steal time-এর খরচ কত?
হিসাবটি সংক্ষিপ্ত। আপনার CPU time-এর s অংশ কেড়ে নেওয়া হলে, নির্দিষ্ট পরিমাণ CPU প্রয়োজন এমন একটি job ঘড়ির হিসাবে 1 / (1 - s) গুণ বেশি সময় নেয়। 60 seconds CPU প্রয়োজন এমন একটি job-এর ক্ষেত্রে:
The data behind this chart
[
{
"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-এর একটি স্বাভাবিক মান, job-টি 61.9 seconds সময় নেয়, 60.0 seconds-এর পরিবর্তে। এ নিয়ে কেউ ticket খোলে না। 8 percent-এ সময় লাগে 65.2 seconds। 40 percent-এ একই job-এর 100.0 seconds প্রয়োজন হয়, এবং আগে যে queue দ্রুত খালি হতো, সেটি বরং বড় হতে শুরু করে।
এগুলো calculated value, measurement নয়। এই model-এ single runnable thread ধরা হয়েছে এবং interval জুড়ে steal সমানভাবে ছড়িয়ে আছে বলে ধরে নেওয়া হয়েছে। বাস্তব service-এ প্রভাব প্রায়ই এই curve-এর চেয়ে খারাপ মনে হয়। কারণ stolen slice কোনো request-এর মাঝখানে পড়লে, সেই request-এর জন্য অপেক্ষা করা প্রতিটি কাজকেও আবার সেই delay বহন করতে হয়। Formula-এর পরিবর্তে নিজের মান পেতে, শান্ত সময়ে VPS benchmark করুন এবং ব্যস্ত সময়ে আবার benchmark করুন। দুই window-এর জন্য st record করুন।
এটি steal, নাকি অন্য কোনো সমস্যা?
Steal-কে অন্য উপসর্গের সঙ্গে সহজেই গুলিয়ে ফেলা যায়। একই vmstat লাইনে সব counter একসঙ্গে পড়ুন।
stবেশি, কিন্তুrএবংusকম থাকে: host আপনাকে CPU core দিচ্ছে না। এটিই steal।rআপনার vCPU সংখ্যার তুলনায় অনেক বেশি,usবেশি এবংstপ্রায় শূন্য: আপনার নিজের CPU যতটা কাজ নিতে পারে, তার চেয়ে বেশি কাজ চালাচ্ছেন।r-এর সঙ্গেnproc-এর output তুলনা করুন। এটি আপনার নিজের oversubscription, অন্য কোনো প্রতিবেশী tenant-এর সমস্যা নয়।waবেশি এবংstপ্রায় শূন্য: task-গুলো storage-এর কারণে blocked। এটি আলাদা সমস্যা এবং এর সমাধানও আলাদা।- Load average বেশি, কিন্তু
stএবংusদুটিই কম: load figure-এ uninterruptible task-ও গণনা করা হয়। তাই এটি সাধারণত CPU সমস্যার বদলে আটকে থাকা device বা hung network mount নির্দেশ করে।
Burstable plan-এর জন্য আলাদা করে একটি বিষয় মনে রাখুন। আপনি idle থাকলে এই plan credit balance জমায় এবং busy থাকলে তা কমে। credit শেষ হলে provider আপনাকে baseline rate-এ সীমাবদ্ধ রাখে। কিছু platform-এ এই throttle steal হিসেবে report করা হয়। অন্য platform-এ এটি ভেতর থেকে দেখা যায় না; আপনি শুধু প্রতি সেকেন্ডে কম CPU cycle পান। কোনো প্রতিবেশী tenant-কে দায়ী করার আগে plan-এর বিবরণ পড়ুন।
কেন একটি container steal time দেখায় না
Steal time virtual machine-এর বৈশিষ্ট্য, এর ভিতরে চলা container-এর নয়। আপনার নিজের VPS-এ চলা Docker container host-এর /proc শেয়ার করে। তাই এর ভিতরে পড়া st মানটি VPS-এর steal time, এবং এটিই আপনার প্রয়োজনীয় মান। VPS হিসেবে বিক্রি করা container-based virtualisation ভিন্নভাবে কাজ করে। lxcfs সক্রিয় থাকলে container-এর ভিতরের /proc/stat cgroup accounting থেকে তৈরি করা হয়। তাই নির্মাণগতভাবেই steal time শূন্য থাকে। শুধু container-এর ভিতর থেকে metrics সংগ্রহ করা monitoring stack এমন স্থির শূন্য দেখাতে পারে, যখন নিচের physical machine-এ CPU resource-এর তীব্র সংকট চলছে।
Container-এর ভিতরে একই অর্থ বহনকারী counter হলো CPU quota throttling। cgroup v2-এ:
cat /sys/fs/cgroup/cpu.statnr_throttled এমন enforcement period-এর সংখ্যা গোনে, যখন group তার CPU quota-তে পৌঁছেছে। throttled_usec group কত সময় frozen ছিল, তার মোট সময় দেখায়। nr_throttled বাড়ার অর্থ হলো আপনার process runnable ছিল, কিন্তু চলছিল না। অভিজ্ঞতাটি steal time-এর মতো, তবে কারণ হলো আপনি নিজেই নির্ধারণ করা একটি limit। Host-কে দোষ দেওয়ার আগে নিজের limit পরীক্ষা করুন। বিশেষ করে আপনি যদি VPS-এ Docker-এ আপনার service চালান, এবং compose file-এ CPU limit নির্ধারিত থাকে। Layered virtualisation-এ সময় হারিয়ে যাওয়ার আরও একটি স্তর যোগ হয়। কারণ VPS-এর ভিতরের একটি VM-কে আপনার VPS-এর steal time-এর পাশাপাশি নিজের scheduling delay-ও বহন করতে হয়। আপনি যদি VPS-এ nested virtualisation চালান, বিষয়টি মনে রাখুন।
স্থায়ী steal নিয়ে কী করবেন
guest-এর ভেতরের কোনো setting steal ঠিক করতে পারে না, কারণ এই সিদ্ধান্ত নেওয়া scheduler guest-এর বাইরে চলে। kernel upgrade করলেও এটি বদলায় না: Linux kernel 7.2-এ যুক্ত হওয়া cache-aware scheduling আপনার জন্য বরাদ্দ করা core-গুলোর মধ্যে task পুনর্বিন্যাস করে, কিন্তু কোনো প্রতিবেশী আগে নিয়ে নেওয়া CPU cycle ফিরিয়ে আনতে পারে না। কার্যকর পদক্ষেপ 4টি।
আগে প্রমাণ সংগ্রহ করুন। UTC-তে timestamp, প্রতিটি ঘটনার স্থায়িত্ব, কত ঘন ঘন এটি ঘটছে, এবং mpstat-এ একটি vCPU প্রভাবিত হচ্ছে নাকি সবগুলো—এসব record করুন। এক সপ্তাহের logged sample একটি screenshot-এর চেয়ে বেশি কার্যকর।
এই তথ্য দিয়ে ticket খুলুন। দুটি সরাসরি প্রশ্ন করুন: এই সময়সীমাগুলোতে node কি oversubscribed, এবং আমার instance কি অন্য node-এ সরানো যাবে? vmstat-এর output এবং সঠিক সময়গুলো paste করুন। Provider-রা পুনরুৎপাদনযোগ্য সময়সীমার ভিত্তিতে ব্যবস্থা নেয়। শুধু server ধীর—এমন ticket-এর উত্তরে তারা সাধারণত নির্দিষ্ট সময়সীমা চাইবে। এই কাজের কতটা আপনি provider-এর ওপর ছেড়ে দিতে পারেন, সেটি managed ও unmanaged VPS-এর মধ্যে একটি বাস্তব পার্থক্য।
Migration-এর অনুরোধ করুন। guest-কে কম load থাকা node-এ সরানো provider-এর জন্য নিয়মিত কাজ, এবং এতে সাধারণত অল্প সময়ের reboot লাগে। এটি বিনা খরচের সমাধান। একই node-এ একসঙ্গে একাধিক ভারী প্রতিবেশী থাকলে যে সাধারণ সমস্যা হয়, এটি তা সমাধান করে।
Contention এড়াতে বেশি খরচের plan নিন। dedicated vCPU plan আপনার instance-এর জন্য physical core সংরক্ষণ করে। ফলে counter শূন্যে থাকে। এর মাসিক খরচ বেশি। তবে এমন workload-এর জন্য এটিই বাস্তবসম্মত সমাধান, যা এই variance সহ্য করতে পারে না। এটিও যথেষ্ট না হলে, অথবা memory bandwidth-ও নিজের জন্য রাখতে চাইলে, পরবর্তী ধাপ হলো VPS-এর বদলে dedicated server নেওয়া।
এর মধ্যে অপেক্ষা করার সময় steal-এর ক্ষতি কমান। আপনার vCPU যতটি, তার চেয়ে কম worker thread চালান। কারণ core না পাওয়া thread শুধু context switch বাড়ায়। batch কাজ node শান্ত থাকার সময়ে সরান। আপনার 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-এর সঙ্গে মিলিয়ে মানটি বিচার করুন। Overnight batch job যে পরিমাণ steal time সহ্য করতে পারে, latency-sensitive API তা নাও পারতে পারে।
বড় plan নিলে কি high steal time ঠিক হবে?
নিজে থেকে হবে না। একই shared node-এ বেশি vCPU থাকলে একই চাপযুক্ত physical core-এর জন্য প্রতিযোগিতা করা virtual CPU-এর সংখ্যাও বাড়ে। তাই percentage আগের মতোই থাকতে পারে। Dedicated CPU allocation নেওয়া বা কম load থাকা node-এ স্থানান্তরিত হলেই steal কমে। Busy machine-এর বড় অংশও busy machine-এরই একটি অংশ।
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 তুলনা করুন। Container-এর quota throttling দেখতে /sys/fs/cgroup/cpu.stat পড়ুন।
নিজের server-এর ভেতর থেকে কি steal time কমানো যায়?
Guest-এর ভেতর থেকে host-এর scheduling পরিবর্তন করতে পারবেন না। শুধু এর প্রভাব কমাতে পারবেন। আপনার vCPU-এর সংখ্যার চেয়ে কম worker thread চালান। এতে core-এর জন্য অপেক্ষা করা কাজের পরিমাণ কমে। Node-এ load কম থাকার সময় batch job চালান। Result cache করুন, যাতে কম request-এর CPU প্রয়োজন হয়। Steal time সত্যিই দূর করতে হলে node পরিবর্তন বা dedicated core দরকার। এই পরিবর্তন provider-এর দিক থেকেই করতে হবে।