আমি এটি REGXA-এর বিরুদ্ধে নেতিবাচক রিভিউ হিসেবে লিখছি না, এবং কাউকে তাদের VPS কেনা উচিত কি না সেটাও বলছি না। এটি শুধু একজন ডেভেলপার হিসেবে আমার একটি সাধারণ কর্মদিবসের ঘটনা।
আমি 2 vCPU, 2 GB RAM এবং 60 GB NVMe-সহ একটি KVM VPS-এ স্বাভাবিক workload স্থানান্তর করি। Nginx চলছিল, backend-ও চলছিল। কিন্তু সার্ভারটি এমন আচরণ করছিল যেন সেটি প্রচণ্ডভাবে overloaded: রিকোয়েস্ট জমছিল, TLS ধীর হচ্ছিল, কানেকশন খোলা থাকছিল, এবং কিছু রিকোয়েস্ট শেষ পর্যন্ত HTTP 504 ফেরানোর আগে দুই মিনিটেরও বেশি সময় নিচ্ছিল।
CPU accounting তদন্তের দিক বদলে দিল
আমার প্রথম ধারণা ছিল সহজ: VPS-এর ভেতরের কিছু CPU খেয়ে ফেলছে। তারপর আমি mpstat চালাই।
Average CPU steal: 92.58%
CPU 0 steal: 90.62%
CPU 1 steal: 94.57%
CPU user: 4.02%
CPU system: 1.47%
CPU iowait: 0.41%
CPU idle: 0.53%আলাদা sample-এ বারবার প্রায় 89–98% steal দেখা যাচ্ছিল। CPU pressure-ও অত্যন্ত বেশি ছিল:
CPU PSI some avg10: 79.47
CPU PSI some avg60: 75.32
CPU PSI some avg300: 76.31
Load average: 5.85 / 5.75 / 5.73এটি মাত্র দুই vCPU-এর VM। Linux-এ runnable process CPU-এর জন্য অপেক্ষা করছিল। মূল সংখ্যা স্বাভাবিক application CPU usage ছিল না; ছিল %steal।
High CPU usage আর CPU steal একই সমস্যা নয়
আমার application সত্যিই processor ব্যস্ত রাখলে user বা system CPU অনেক বেশি হওয়ার কথা। কিন্তু VPS-এর চিত্র ছিল মোটামুটি এমন:
user: 4%
system: 1%
steal: 93%CPU steal হলো সেই সময়, যখন virtual CPU কাজ চালানোর জন্য প্রস্তুত কিন্তু hypervisor সেটিকে schedule করে না। তাই আমি যখন বলি VPS থেকে CPU time কেড়ে নেওয়া হচ্ছিল, তখন virtualization-এর এই নির্দিষ্ট প্রযুক্তিগত অর্থেই বলি। REGXA ইচ্ছাকৃতভাবে আমার জন্য একচেটিয়া physical core অন্য কাউকে দিয়েছে—এটি আমি প্রমাণ করতে পারি না, এবং guest metric থেকে উদ্দেশ্যও জানা যায় না। আমি যা প্রমাণ করতে পারি তা হলো guest-এর কাজ প্রস্তুত ছিল, কিন্তু সেটি CPU scheduling time পাচ্ছিল না।
আমি সব production traffic সরিয়ে দিলাম
একটি যুক্তিসঙ্গত আপত্তি তখনও ছিল: হয়তো workload-ই সমস্যার কারণ। তাই সেটি বাদ দিলাম। সক্রিয় workload অন্যত্র সরালাম, এই VPS-এ production traffic বন্ধ করলাম, queue খালি হতে দিলাম, তারপর একই CPU test আবার চালালাম।
Average CPU steal: 94.17%
CPU 0 steal: 95.56%
CPU 1 steal: 92.83%
CPU user: 1.95%
CPU system: 0.59%
CPU iowait: 0.59%
CPU idle: 2.18%ফল আরও খারাপ হলো। আলাদা vmstat sample-এ তখনও 91–98% steal ছিল, এবং সর্বোচ্চ 15টি runnable process CPU-এর জন্য অপেক্ষা করছিল। সবচেয়ে গুরুত্বপূর্ণ সমন্বয় ছিল:
user: 1.95%
system: 0.59%
steal: 94.17%আমার application তখন প্রায় কিছুই করছিল না, তবু VM তার প্রায় সব scheduling time হারাচ্ছিল। স্বাভাবিক production load আর বিশ্বাসযোগ্য ব্যাখ্যা ছিল না।
এমনকি localhost-ও অস্বাভাবিক ধীর হয়ে যায়
আমি 127.0.0.1 দিয়ে HTTPS test করি, যাতে public DNS, ISP, ভৌগোলিক দূরত্ব এবং বাইরের network path বাদ যায়।
Traffic থাকা অবস্থায় দশটি localhost HTTPS প্রচেষ্টার চারটি TLS handshake-এর সময় ব্যর্থ হয়। সফল রিকোয়েস্টগুলোর সময় ছিল 29.30, 22.77, 12.25, 11.87, 11.12 এবং 9.40 সেকেন্ড। কিছু TLS handshake একাই প্রায় নয় সেকেন্ড নেয়।
Production traffic সরানোর পর localhost উন্নত হয়, কিন্তু স্থিতিশীল ছিল না: 0.061, 0.745, 0.830, 0.873, 1.010, 1.117, 1.121, 2.188 এবং 3.355 সেকেন্ড। একই local operation একবার প্রায় 61 ms এবং পরেরবার 3.3 সেকেন্ডের বেশি সময় নিচ্ছিল।
পুরো stack-এ তার প্রভাব দেখা যাচ্ছিল
এক পর্যায়ে প্রায় 450টি established connection, 122টি orphaned connection, 110টি FIN-WAIT-1 এবং 33টি CLOSE-WAIT দেখেছি। localhost backend-এর listen queue প্রায় 14–15 এবং HTTPS queue প্রায় 40-এ পৌঁছেছিল।
Nginx 142.857, 138.902, 135.064, 129.819 এবং 128.657 সেকেন্ড পরে HTTP 504 লগ করেছে। অন্য কিছু রিকোয়েস্ট প্রায় 67–130 সেকেন্ড খোলা ছিল। 35–41 সেকেন্ডের secure-connect timeout, database network timeout এবং delayed TLS operation-ও দেখেছি।
এগুলো আলাদা Nginx, database, network বা backend সমস্যা মনে হতে পারত। কিন্তু timeout বাড়ালে hypervisor যে CPU time schedule করছে না, সেটি তৈরি হয় না।
RAM বা disk দিয়ে এটি ব্যাখ্যা করা যায়নি
VPS-এ তখনও প্রায় 1.0–1.1 GiB RAM available ছিল, swap প্রায় ব্যবহারই হচ্ছিল না, OOM event বা OOM-killer activity ছিল না। Filesystem মাত্র প্রায় 20% পূর্ণ ছিল এবং প্রায় 44 GB available ছিল। গুরুত্বপূর্ণ CPU measurement-এর সময় I/O wait 1%-এর নিচে ছিল।
Memory শেষ হয়নি, disk পূর্ণ ছিল না, আর application-ও missing CPU ব্যবহার করছিল না। প্রধান metric ছিল %steal।
একটি healthy KVM VPS সম্পূর্ণ ভিন্ন দেখাচ্ছিল
স্বাভাবিক traffic serve করা আরেকটি KVM VPS-এ একই ধরনের diagnostic চালাই:
Average CPU steal: 0.02%
CPU idle: 87.86%
CPU PSI avg10: 0.29
CPU PSI avg60: 0.63
CPU PSI avg300: 0.49
Load average: 0.47 / 0.33 / 0.14সেখানে দশটি localhost HTTPS request প্রায় 37–69 ms-এ শেষ হয়। পরে সত্যিকারের ব্যস্ত আরেকটি production VPS-এ 61.71% user CPU, 5.08% system CPU, 24.09% idle এবং মাত্র 0.13% steal দেখি।
এখন আমার কাছে এটাই গুরুত্বপূর্ণ পার্থক্য। আমার software processor ব্যবহার করছে বলে VPS ব্যস্ত হতে পারে। কিন্তু guest যদি মাপা CPU time-এর 90%-এর বেশি hypervisor-এর জন্য অপেক্ষা করে, সেটা সম্পূর্ণ আলাদা সমস্যা।
শেষ পর্যন্ত REGXA infrastructure contention নিশ্চিত করে
VM-এর ভেতর থেকে guest-এর অবস্থা দেখা যায়, কিন্তু physical host, scheduler configuration, CPU quota বা পাশের VM দেখা যায় না। REGXA সেগুলো দেখতে পারে।
শেষ পর্যন্ত support জানায় যে VPS-টি shared CPU infrastructure-এ ছিল, CPU resource একাধিক VM-এর মধ্যে ভাগ হয় এবং physical node-এর load অনুযায়ী performance বদলাতে পারে। তারা আরও জানায় Frankfurt infrastructure-এ তখন বিশেষভাবে বেশি demand ছিল এবং আমার elevated CPU steal-কে সরাসরি resource contention on the underlying infrastructure-এর ফল বলে ব্যাখ্যা করে।
তারা জানায় বর্তমান infrastructure-এ ওই shared VPS-এর CPU quota বা scheduling policy বদলানো কিংবা অতিরিক্ত dedicated CPU resource দেওয়া সম্ভব নয়। প্রস্তাবিত technical solution ছিল কম utilization-যুক্ত location-এ VPS relocate করা।
আমি আগে যে dedicated CPU cores ও guaranteed resources ধরনের ভাষা দেখেছিলাম, তার সঙ্গে এই ব্যাখ্যা মেলানো কঠিন ছিল। আমি host-এর exact configuration দেখতে পাই না, তাই immediate mechanism CPU overcommitment, quota, scheduler weighting, throttling নাকি এগুলোর combination—তা বলতে পারি না। Intent-ও প্রমাণ করতে পারি না। দরকারও নেই: Linux ধারাবাহিকভাবে 92–94% steal দেখিয়েছে, আর REGXA নিজেই এটিকে shared infrastructure-এর contention-এর সঙ্গে যুক্ত করেছে।
Refund পেতেও আবার চাপ দিতে হয়েছে
Infrastructure problem পরিষ্কার হওয়ার পর আমি বিভিন্ন node-এ VPS সরিয়ে পরীক্ষা চালিয়ে যেতে চাইনি। Service cancel করে টাকা ফেরত চেয়েছিলাম।
প্রথমে আমাকে শুধু আংশিক amount ফেরতের প্রস্তাব দেওয়া হয়, সেটিও payment card-এ নয়, REGXA account balance-এ। Service ছেড়ে যেতে চাইলে provider credit-কে আমি প্রকৃত refund মনে করি না।
তাই আমি বারবার উত্তর দিয়ে 100% payment original payment method-এ ফেরত চেয়েছি। শেষ পর্যন্ত REGXA রাজি হয় এবং পুরো amount original payment method-এ ফেরত দেয়, full refund-টিকে তারা exception হিসেবে বর্ণনা করে।
শেষ পর্যন্ত পুরো টাকা ফেরত দেওয়াকে আমি স্বীকার করি এবং মূল্য দিই। কিন্তু infrastructure contention support স্বীকার করার পরও financial resolution-এর জন্য আমাকে আলাদা করে চাপ দিতে হয়েছে—এটিও অভিজ্ঞতার অংশ।
এই ঘটনার পর আমার নিয়ম বদলেছে
সবচেয়ে সহজ ভুল হতো application optimize করে যাওয়া। আমি Nginx setting বদলাতে পারতাম, timeout বাড়াতে পারতাম, concurrency কমাতে পারতাম, retry যোগ করতে পারতাম, MongoDB তদন্ত করতে পারতাম বা backend code লিখে ফেলতে পারতাম। এসব কিছু symptom বদলাতে পারত, কিন্তু গুরুত্বপূর্ণ প্রশ্নের উত্তর দিত না: CPU steal কেন 90%-এর বেশি?
এখন আমি শুধু SSH কাজ করছে, Nginx start হচ্ছে এবং health endpoint 200 দিচ্ছে কি না তা দেখি না। নতুন VPS-এ %user, %system, %iowait, %idle, %steal, CPU PSI, run queue এবং localhost latency-ও দেখি।
কিছু সন্দেহজনক লাগলে workload সরিয়ে আবার মাপি। এই ঘটনায় সেটিই সবচেয়ে পরিষ্কার ফল দিয়েছিল:
CPU user: 1.95%
CPU system: 0.59%
CPU steal: 94.17%আমি বলছি না যে প্রত্যেক REGXA VPS এমন আচরণ করে। আমি একটি VPS পরীক্ষা করেছি এবং সেটিতে যা ঘটেছে তা নথিবদ্ধ করেছি। কিন্তু সেই VPS-এ প্রমাণ ছিল অস্বাভাবিকভাবে পরিষ্কার: আমার application প্রায় CPU ব্যবহার করছিল না, অথচ Linux দেখাচ্ছিল virtual CPU time-এর বিশাল অংশ hypervisor scheduling-এর অপেক্ষায় হারিয়ে যাচ্ছে। পরে REGXA একই আচরণকে shared infrastructure-এর resource contention-এর সঙ্গে যুক্ত করে।
এই কারণেই আমি ঘটনাটি লিখে রাখছি। এটি কোনো score বা recommendation নয়; একজন developer হিসেবে আমার আরেকটি কর্মদিবস, এবং VPS-এ এমন একটি metric যা আমি আর কখনও উপেক্ষা করব না।