मैं इसे REGXA की नकारात्मक समीक्षा के रूप में नहीं लिख रहा हूँ और न ही किसी को यह बताने की कोशिश कर रहा हूँ कि उसे वहाँ VPS खरीदना चाहिए या नहीं। यह बस एक developer के रूप में मेरे काम का एक दिन है।
मैंने 2 vCPU, 2 GB RAM और 60 GB NVMe वाले KVM VPS पर सामान्य workload स्थानांतरित किया। Nginx चल रहा था। Backend भी चल रहा था। फिर भी मशीन ऐसे व्यवहार कर रही थी जैसे वह बुरी तरह overloaded हो: requests जमा हो रहे थे, TLS operations धीमे हो गए थे, connections खुले रह रहे थे और कुछ requests अंत में HTTP 504 लौटाने से पहले दो मिनट से अधिक समय ले रहे थे।
CPU accounting ने जाँच की दिशा बदल दी
मेरी पहली धारणा सीधी थी: VPS के अंदर कोई process 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%अलग-अलग samples में बार-बार लगभग 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 वाली मशीन थी। Linux में runnable processes CPU की प्रतीक्षा कर रहे थे। महत्वपूर्ण metric सामान्य 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 cores किसी और ग्राहक को दे दिए जो विशेष रूप से मेरे लिए reserved थे, और guest metrics से intent साबित नहीं होता। मैं यह साबित कर सकता हूँ कि guest के पास बार-बार runnable work था, लेकिन उसे CPU scheduling time नहीं मिल रहा था।
मैंने पूरा production traffic हटा दिया
एक उचित आपत्ति अभी भी बची थी: शायद मेरा workload ही समस्या पैदा कर रहा था। इसलिए मैंने उस variable को हटा दिया। Active workload दूसरी मशीन पर ले गया, इस VPS पर production traffic बंद किया, queues खाली होने दीं और वही measurement फिर से किया।
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 samples में अब भी 91–98% steal था और अधिकतम 15 runnable processes CPU की प्रतीक्षा कर रहे थे। सबसे महत्वपूर्ण संयोजन था:
user: 1.95%
system: 0.59%
steal: 94.17%मेरे applications अब लगभग कुछ नहीं कर रहे थे, फिर भी VM लगभग पूरा scheduling time खो रहा था। सामान्य production load अब विश्वसनीय explanation नहीं रहा।
यहाँ तक कि localhost भी बेहिसाब धीमा हो गया
मैंने 127.0.0.1 के जरिए HTTPS test किया, जिससे public DNS, मेरा ISP, geographical distance और external network path test से बाहर हो गए।
Traffic के दौरान दस localhost HTTPS attempts में से चार TLS handshake पर fail हुए। सफल requests ने 29.30, 22.77, 12.25, 11.87, 11.12 और 9.40 सेकंड लिए। कुछ TLS handshakes ने अकेले लगभग नौ सेकंड लिए।
Production traffic हटाने के बाद localhost बेहतर हुआ, लेकिन unstable रहा: 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 connections, 122 orphaned connections, 110 FIN-WAIT-1 और 33 CLOSE-WAIT देखे। Local backend की listen queue लगभग 14–15 और HTTPS queue लगभग 40 तक पहुँची।
Nginx ने 142.857, 138.902, 135.064, 129.819 और 128.657 सेकंड बाद HTTP 504 log किए। अन्य requests लगभग 67–130 सेकंड खुले रहे। लगभग 35–41 सेकंड के secure-connect timeouts, database network timeouts और delayed TLS operations भी दिखाई दिए।
अलग-अलग देखने पर ये Nginx, database, networking या backend की अलग समस्याएँ लग सकती थीं। लेकिन timeout बढ़ाने से वह CPU time नहीं बनता जिसे hypervisor schedule ही नहीं कर रहा।
RAM और disk इसका कारण नहीं थे
VPS में अभी भी लगभग 1.0–1.1 GiB RAM available थी, swap लगभग उपयोग नहीं हो रहा था, कोई OOM event या OOM-killer activity नहीं थी। Filesystem केवल लगभग 20% भरा था और लगभग 44 GB खाली था। महत्वपूर्ण CPU measurements के दौरान I/O wait 1% से नीचे था।
Memory खत्म नहीं हुई थी, disk भरी नहीं थी और मेरे applications missing CPU नहीं खा रहे थे। प्रमुख metric अब भी %steal था।
एक स्वस्थ KVM VPS बिल्कुल अलग दिखा
मैंने उसी तरह का diagnostic दूसरे KVM VPS पर चलाया जो सामान्य traffic serve कर रहा था:
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 requests लगभग 37–69 ms में पूरे हुए। बाद में एक सचमुच busy production VPS पर मैंने 61.71% user CPU, 5.08% system CPU, 24.09% idle और केवल 0.13% steal देखा।
अब मेरे लिए यही मुख्य अंतर है। VPS इसलिए busy हो सकता है क्योंकि मेरा software वास्तव में processor उपयोग कर रहा है। यह उस guest से बिल्कुल अलग स्थिति है जो measured CPU time का 90% से अधिक hypervisor की प्रतीक्षा में बिताता है।
आखिरकार REGXA ने infrastructure contention की पुष्टि की
VM के अंदर से मैं guest को माप सकता था, लेकिन physical host, scheduler configuration, CPU quotas या पड़ोसी VMs नहीं देख सकता था। REGXA देख सकता था।
Support ने अंततः बताया कि VPS shared CPU infrastructure पर था, CPU resources कई virtual machines के बीच साझा होते हैं और performance physical node के load पर निर्भर कर सकता है। उन्होंने यह भी कहा कि Frankfurt infrastructure उस समय विशेष रूप से high demand में था और मेरे elevated CPU steal को स्पष्ट रूप से resource contention on the underlying infrastructure का परिणाम बताया।
उन्होंने कहा कि वे मौजूदा infrastructure पर इस shared VPS की CPU quotas या scheduling policies बदल नहीं सकते और अतिरिक्त dedicated CPU resources नहीं दे सकते। प्रस्तावित technical solution था VPS को कम utilization वाली location पर relocate करना।
यह उस language से मेल बैठाना कठिन था जो मैंने dedicated CPU cores और guaranteed resources के बारे में देखी थी। मैं exact host configuration नहीं देख सकता, इसलिए immediate mechanism CPU overcommitment, quotas, scheduler weighting, throttling या इनका combination था—यह नहीं कह सकता। Intent भी साबित नहीं कर सकता। इसकी जरूरत नहीं है: Linux ने लगातार 92–94% steal दिखाया और REGXA ने खुद उस elevated steal को shared infrastructure के contention से जोड़ा।
Refund के लिए भी अलग से जोर लगाना पड़ा
Infrastructure problem साफ होने के बाद मैं VPS को अलग-अलग node पर relocate करके testing जारी नहीं रखना चाहता था। मैं service cancel करके पैसा वापस चाहता था।
शुरुआत में मुझे केवल partial amount का प्रस्ताव मिला और refund मेरे payment card पर लौटाने के बजाय REGXA account balance में देने की बात थी। जब मैं service छोड़ना चाहता हूँ, तो provider credit मेरे लिए refund के बराबर नहीं है।
इसलिए मैंने जवाब देना जारी रखा और 100% payment original payment method पर लौटाने की माँग की। अंततः REGXA सहमत हुआ और पूरा amount original payment method पर लौटाया, full refund को exception बताया गया।
मैं यह मानता हूँ कि अंत में उन्होंने पूरा पैसा लौटा दिया। लेकिन support द्वारा infrastructure contention स्वीकार किए जाने के बाद भी financial resolution के लिए मुझे लगातार दबाव डालना पड़ा—यह भी मेरे अनुभव का हिस्सा है।
इस घटना से मेरा नियम बदल गया
सबसे आसान गलती application optimize करते रहना होती। मैं Nginx settings बदल सकता था, timeouts बढ़ा सकता था, concurrency घटा सकता था, retries जोड़ सकता था, MongoDB जाँच सकता था या backend code दोबारा लिख सकता था। इससे कुछ symptoms बदल सकते थे। लेकिन महत्वपूर्ण प्रश्न का उत्तर नहीं मिलता: CPU steal 90% से अधिक क्यों था?
अब मैं केवल यह नहीं देखता कि SSH चल रहा है, Nginx start होता है और health endpoint 200 लौटाता है। नए VPS पर मैं %user, %system, %iowait, %idle, %steal, CPU PSI, run queue और localhost latency भी देखता हूँ।
और कुछ suspicious लगे तो workload हटाकर फिर मापता हूँ। इस घटना में इसी test ने सबसे स्पष्ट परिणाम दिया:
CPU user: 1.95%
CPU system: 0.59%
CPU steal: 94.17%मैं यह दावा नहीं कर रहा कि हर REGXA VPS ऐसा व्यवहार करता है। मैंने एक VPS test किया और उसी पर जो हुआ उसे document किया। लेकिन उस VPS पर evidence असामान्य रूप से स्पष्ट था: मेरे applications लगभग CPU उपयोग नहीं कर रहे थे, जबकि Linux दिखा रहा था कि virtual CPU time का अधिकांश हिस्सा hypervisor scheduling की प्रतीक्षा में जा रहा था। बाद में REGXA ने इसी व्यवहार को shared infrastructure के resource contention से जोड़ा।
इसीलिए मैं इसे लिख रहा हूँ। किसी score या recommendation के रूप में नहीं, बल्कि एक developer के जीवन के एक दिन के रूप में—और एक ऐसी metric के रूप में जिसे मैं किसी VPS पर फिर कभी नजरअंदाज नहीं करूँगा।