আমি এটি AVA Hosting-এর নেতিবাচক রিভিউ হিসেবে লিখছি না।
এটি একজন ডেভেলপার হিসেবে আমার একটি সাধারণ কর্মদিবসের গল্প: একটি সার্ভার খারাপ আচরণ করছিল, সাধারণ ব্যাখ্যাগুলো মেলেনি, এবং শেষ পর্যন্ত Linux দেখিয়েছে আসলে কী ঘটছিল।
আমার একটি ছোট AVA Hosting KVM VPS ছিল:
1 vCPU
2 GB RAM
25 GB NVMeসেখানে স্বাভাবিক প্রোডাকশন workload চলছিল। Nginx চালু ছিল। backend চালু ছিল। পর্যাপ্ত memory ছিল। disk পূর্ণ ছিল না।
তবু সার্ভার কাজের সঙ্গে তাল রাখতে পারছিল না।
তাই স্বাভাবিক প্রোডাকশন ট্রাফিকের মধ্যে আমি 60 সেকেন্ডের একটি passive diagnostic চালাই। কোনো stress test, synthetic HTTP flood বা disk benchmark ছিল না।
ফলাফল:
vCPU count: 1
Average CPU user: 52.52%
Average CPU system: 8.07%
Average CPU softirq: 6.69%
Average CPU steal: 32.73%
Average CPU iowait: 0.00%
Average CPU idle: 0.00%
Maximum runnable queue: 11সবচেয়ে গুরুত্বপূর্ণ সংখ্যা ছিল 32.73% CPU steal। এখানেই পুরো diagnosis বদলে গেল।
এটি আমাকে কেন অবাক করেছিল
AVA Hosting বর্তমানে তাদের VPS পণ্যে “Guaranteed resources — no sharing” বলে বিজ্ঞাপন দেয়। তাদের VPS পেজগুলো fixed বা dedicated vCPU allocation-এর কথাও বলে এবং জানায় যে অন্য গ্রাহকের কারণে performance প্রভাবিত হওয়ার কথা নয়। Linux VPS সম্পর্কিত উপকরণে AVA আরও স্পষ্টভাবে বলে যে একই হোস্টের অন্য tenant-এর CPU-intensive workload আপনার instance-এ steal time তৈরি করতে পারে না। আরেকটি পেজে বলা হয়েছে CPU steal hypervisor স্তরেই দূর করা হয়।
এগুলো খুব নির্দিষ্ট দাবি। এটি শুধু এমন কোনো VPS পেজ ছিল না যেখানে 1 vCPU লেখা আছে কিন্তু CPU allocation model নিয়ে কিছু বলা হয়নি। AVA সরাসরি সেই ধরনের CPU contention থেকে সুরক্ষার কথা বলছিল, যেটিই আমার VM-এর ভেতরে Linux রিপোর্ট করছিল।
CPU steal আসলে কী
steal হলো virtualized environment-এ ব্যবহৃত Linux-এর একটি স্বাভাবিক CPU metric। guest-এর runnable কাজ থাকা সত্ত্বেও virtual CPU যখন বাস্তবে চালানো হয় না, সেই সময়টি এটি নির্দেশ করে।
এটি আমার application তার পুরো CPU ব্যবহার করার বিষয় থেকে আলাদা। যদি আমি প্রায় 100% user/system CPU, 0% steal এবং 0% idle দেখতাম, তাহলে ধরে নিতাম workload-এর আরও processing power দরকার।
কিন্তু এখানে CPU accounting-এর প্রায় এক-তৃতীয়াংশ ছিল steal।
guest-এর ভেতর থেকে আমি AVA-এর hypervisor দেখতে পারি না। physical node-এর load, neighboring VM-এর সংখ্যা, CPU pinning policy বা overcommit ratio-ও জানতে পারি না। আমি যা দেখতে পারি তা হলো Linux আমার VM-কে কী বলেছে: কাজ অপেক্ষা করছিল, অথচ vCPU বারবার চলছিল না।
এটি এক সেকেন্ডের spike ছিল না
একটি খারাপ CPU sample আমাকে খুব বেশি কিছু বিশ্বাস করাতে পারত না। তাই আমি টানা 60 সেকেন্ড মাপি। কোনো stress test, synthetic HTTP flood বা disk benchmark চালাইনি।
প্রতি সেকেন্ডের sample বারবার এমন ছিল:
%usr %sys %soft %steal %idle
53.54 10.10 5.05 31.31 0.00
56.44 6.93 5.94 30.69 0.00
51.52 7.07 6.06 35.35 0.00
55.45 6.93 5.94 31.68 0.00
51.49 8.91 5.94 33.66 0.00
52.53 7.07 7.07 33.33 0.00
52.48 6.93 7.92 32.67 0.00পর্যবেক্ষণের শেষের দিকেও একই pattern ছিল:
50.98 10.78 6.86 31.37 0.00
48.48 8.08 9.09 34.34 0.00
55.00 5.00 7.00 33.00 0.00সম্পূর্ণ average:
user: 52.52%
system: 8.07%
softirq: 6.69%
steal: 32.73%
iowait: 0.00%
idle: 0.00%অর্থাৎ এটি অল্প সময়ের scheduling anomaly ছিল না। মিনিটের অধিকাংশ সময় steal প্রায় 30% বা তার বেশি ছিল এবং CPU idle ছিল শূন্য।
বোঝার সুবিধায়, এক মিনিটের 32.73% প্রায় 19.64 সেকেন্ড। এর মানে VPS টানা 19.64 সেকেন্ড freeze করেছিল এমন নয়; বরং vCPU schedule না হওয়ার ছোট ছোট interval মিলিয়ে প্রায় এত সময় হয়েছিল।
backend আর backlog কমাতে পারছিল না
CPU সমস্যা application level-এও দেখা যাচ্ছিল। পর্যবেক্ষণের আগে backend listen queue ছিল:
Recv-Q: 168
Send-Q: 51160 সেকেন্ড পরে:
Recv-Q: 166
Send-Q: 511ঠিক কত ছিল সেটি মূল বিষয় নয়। গুরুত্বপূর্ণ হলো queue কার্যত drain হয়নি। application-এর কাছে পুরো এক মিনিট সময় ছিল catch up করার, কিন্তু সে পিছিয়েই ছিল।
অনেক CLOSE-WAIT connection-ও ছিল। শুধু এটি দেখে host-কে দায়ী করব না, কারণ application-side connection handling থেকেও এই state আসতে পারে। কিন্তু সামগ্রিক ছবিটি একই কথা বলছিল:
1 vCPU
32.73% steal
0% idle
~99% CPU pressure
elevated runnable queue
backend queue not drainingসার্ভার চলছিল, কিন্তু healthy ছিল না।
RAM বা disk স্পষ্ট bottleneck ছিল না
আমি সাধারণ বিকল্প কারণগুলোও পরীক্ষা করেছি। Memory ছিল:
RAM total: ~1.9 GiB
RAM available: ~959 MiB
Swap total: 2 GiB
Swap used: ~33 MiBঅর্থাৎ উল্লেখযোগ্য পরিমাণ memory এখনও available ছিল এবং আচরণটি ব্যাখ্যা করার মতো কোনো পরিষ্কার OOM event ছিল না।
Filesystem:
24 GB total
14 GB used
9.4 GB available
60% usedAverage CPU I/O wait ছিল 0.00%। অন্যদিকে CPU pressure প্রায় 99%-এর কাছাকাছি ছিল, এক-vCPU VM-এ load average ছিল প্রায় 3.5–4 এবং runnable queue 11 পর্যন্ত উঠেছিল।
সব measurement একই দিকে ইঙ্গিত করছিল: machine CPU-starved ছিল; RAM বা storage-এর পরিষ্কার bottleneck দেখা যাচ্ছিল না।
AVA-এর ভাষার সঙ্গে বিরোধ
এটাই আমার কাছে সবচেয়ে আকর্ষণীয় অংশ।
AVA বলে “Guaranteed resources — no sharing”। তারা বলে অন্য customer-এর কারণে performance প্রভাবিত হওয়ার কথা নয়। তাদের Linux VPS material বলে co-hosted tenant steal time তৈরি করতে পারে না, আর অন্য একটি page বলে CPU steal hypervisor level-এ eliminate করা হয়।
আমার AVA VPS দেখিয়েছিল:
Average CPU steal: 32.73%VM-এর ভেতর থেকে এর সঠিক কারণ প্রমাণ করা আমার পক্ষে সম্ভব নয়। ইচ্ছাকৃত overselling, কোনো নির্দিষ্ট neighboring workload, বা AVA host-এর CPU configuration আমি প্রমাণ করতে পারি না।
আমি এটাও বলছি না যে প্রতিটি AVA Hosting VPS এমন আচরণ করে। আমি একটি VPS পরীক্ষা করেছি।
তবে আমি বলতে পারি, আমি যে behavior মেপেছি তা তাদের এই নির্দিষ্ট CPU-isolation দাবিগুলোর সঙ্গে মেলানো খুব কঠিন। এই লেখার জন্য এটুকুই যথেষ্ট।
আমি কেন upgrade করিনি
স্বাভাবিক প্রতিক্রিয়া হতে পারত আরও vCPU কেনা।
যদি steal প্রায় শূন্য হতো এবং আমার application সত্যিই পুরো core ব্যবহার করত, upgrade করা যুক্তিসঙ্গত হতো। কিন্তু observed CPU accounting-এর প্রায় এক-তৃতীয়াংশই ছিল steal।
প্রথম vCPU-এর এত বড় অংশ কেন unavailable হিসেবে রিপোর্ট হচ্ছিল, তা না বুঝে আমি অতিরিক্ত virtual CPU-এর জন্য টাকা দিতে চাইনি। তাই VPS বাতিল করে refund চেয়েছি।
AVA দ্রুত পুরো টাকা ফেরত দিয়েছে
এই অংশের অভিজ্ঞতা ভালো ছিল।
AVA Hosting পুরো অর্থ ফেরত দিয়েছে। refund দ্রুত হয়েছে এবং CPU measurement নিয়ে তারা দিনের পর দিন আমার সঙ্গে তর্ক করেনি। আমি সমস্যা ব্যাখ্যা করেছি, টাকা ফেরত চেয়েছি, তারা ফেরত দিয়েছে।
এটি আমি মূল্য দিই।
তাই আমার অভিজ্ঞতা থেকে দুটি আলাদা সিদ্ধান্ত আছে: আমি যে VPS পেয়েছিলাম তাতে CPU availability-এর গুরুতর সমস্যা ছিল, এবং AVA আমার refund সঠিকভাবে handle করেছে। দুটোই সত্য।
আমি কী শিখেছি
এখন আর আমি শুধু 1 vCPU / 2 GB RAM / NVMe / KVM দেখে VPS বিচার করি না। এগুলো provision করা resource-এর specification, বাস্তব workload-এ CPU কতটা predictably পাওয়া যাবে তার প্রমাণ নয়।
নতুন virtual machine-এ এখন প্রথম দিকেই আমি চালাই:
mpstat 1 60
vmstat 1 60
cat /proc/pressure/cpu
ss -ltnp
free -h
df -h
iostat -xz 1 60AVA Hosting-এর এই অভিজ্ঞতা থেকে আমার সবচেয়ে গুরুত্বপূর্ণ শিক্ষা এই নয় যে এক vCPU খুব ছোট। শিক্ষা হলো, চলমান process, available RAM এবং দেখতে healthy disk-এর নিচে একেবারে অন্য ধরনের সমস্যা লুকিয়ে থাকতে পারে।
আমার ক্ষেত্রে Linux সেটি খুব পরিষ্কারভাবে দেখিয়েছিল:
CPU steal: 32.73%
CPU idle: 0.00%
CPU pressure: ~99%AVA Hosting CPU resource sharing ছাড়া দেওয়ার কথা বলে এবং neighbouring workload থেকে steal হওয়ার কথা নয় বলে দাবি করে। আমার VPS অন্য কিছু রিপোর্ট করেছে।
আমি VPS বাতিল করেছি। AVA দ্রুত এবং কোনো তর্ক ছাড়াই পুরো টাকা ফেরত দিয়েছে।
এই debugging দিনের গল্প সেখানেই শেষ।