“Guaranteed Resources — No Sharing” के बावजूद मेरे AVA Hosting VPS पर औसत CPU Steal 32.73% था

मैं इसे AVA Hosting की नकारात्मक review के रूप में नहीं लिख रहा हूँ।

यह बस एक developer के रूप में मेरे सामान्य कामकाजी दिनों में से एक की कहानी है: एक server खराब व्यवहार कर रहा था, सामान्य कारण फिट नहीं हो रहे थे, और आखिर में Linux ने दिखाया कि वास्तव में क्या हो रहा था।

मेरे पास AVA Hosting का एक छोटा KVM VPS था:

1 vCPU
2 GB RAM
25 GB NVMe

उस पर सामान्य production workload चल रहा था। Nginx चल रहा था। backend चल रहा था। memory उपलब्ध थी। disk भरी हुई नहीं थी।

फिर भी server workload के साथ बने नहीं रह पा रहा था।

इसलिए मैंने सामान्य production traffic के दौरान 60 सेकंड की passive diagnostic observation की। कोई 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” कहकर advertise करता है। उसकी VPS pages fixed या dedicated vCPU allocation की बात भी करती हैं और कहती हैं कि दूसरे customers की वजह से performance प्रभावित नहीं होना चाहिए। Linux VPS से जुड़ी सामग्री में AVA इससे भी आगे जाकर कहता है कि उसी host पर किसी दूसरे tenant का CPU-intensive workload आपके instance में steal time पैदा नहीं कर सकता। एक दूसरी page कहती है कि CPU steal hypervisor level पर ही eliminate कर दिया जाता है।

ये बहुत specific claims हैं। यह केवल ऐसी page नहीं थी जहाँ 1 vCPU लिखा हो और CPU allocation model के बारे में कुछ न बताया गया हो। AVA साफ तौर पर उसी तरह की CPU contention से सुरक्षा advertise कर रहा था जिसे Linux मेरी VM के अंदर report कर रहा था।

CPU steal का मतलब क्या है

steal virtualized environments में Linux का एक सामान्य CPU metric है। यह उस समय को दर्शाता है जब guest के पास runnable work होता है लेकिन virtual CPU वास्तव में run नहीं कर रहा होता।

यह उस स्थिति से अलग है जिसमें मेरी application उपलब्ध CPU को पूरी तरह इस्तेमाल कर रही हो। अगर मैं लगभग 100% user/system CPU, 0% steal और 0% idle देखता, तो मैं मानता कि workload को बस अधिक processing power चाहिए।

लेकिन यहाँ CPU accounting का लगभग एक-तिहाई हिस्सा steal था।

guest के अंदर से मैं AVA का hypervisor नहीं देख सकता। physical node का load, neighboring VMs की संख्या, CPU pinning policy या overcommit ratio मुझे पता नहीं हो सकता। लेकिन मैं यह देख सकता हूँ कि Linux मेरी VM को क्या बता रहा था: काम इंतजार कर रहा था, फिर भी vCPU बार-बार run नहीं कर रहा था।

यह एक सेकंड का spike नहीं था

एक खराब CPU sample मुझे ज्यादा आश्वस्त नहीं करता, इसलिए मैंने machine को लगातार 60 सेकंड मापा। मैंने जानबूझकर कोई stress test, synthetic HTTP flood या disk benchmark नहीं चलाया।

हर सेकंड के samples बार-बार ऐसे दिख रहे थे:

%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

Observation के अंत के करीब भी 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 न होने वाले छोटे-छोटे intervals मिलकर लगभग इतने समय के बराबर बने।

backend backlog खत्म नहीं कर पा रहा था

CPU समस्या application level पर भी दिखाई दे रही थी। monitoring से पहले backend listen queue थी:

Recv-Q: 168
Send-Q: 511

60 सेकंड बाद:

Recv-Q: 166
Send-Q: 511

Exact numbers महत्वपूर्ण नहीं हैं। महत्वपूर्ण यह है कि queue लगभग drain ही नहीं हुई। application के पास एक पूरा मिनट था catch up करने के लिए, लेकिन वह पीछे ही रही।

काफी CLOSE-WAIT connections भी थे। केवल इस state के लिए मैं host को जिम्मेदार नहीं मानूँगा, क्योंकि application-side connection handling भी इसका कारण हो सकती है। लेकिन overall picture consistent थी:

1 vCPU
32.73% steal
0% idle
~99% CPU pressure
elevated runnable queue
backend queue not draining

Server चालू था, लेकिन healthy नहीं था।

RAM और disk स्पष्ट bottleneck नहीं थे

मैंने सामान्य alternatives भी check किए। Memory:

RAM total:      ~1.9 GiB
RAM available:  ~959 MiB
Swap total:     2 GiB
Swap used:      ~33 MiB

अभी भी पर्याप्त memory उपलब्ध थी और behavior को समझाने वाला कोई स्पष्ट OOM event नहीं था।

Filesystem:

24 GB total
14 GB used
9.4 GB available
60% used

Average CPU I/O wait 0.00% था। दूसरी तरफ CPU pressure लगभग 99% बना रहा, एक-vCPU VM पर load average करीब 3.5–4 था और runnable queue 11 तक पहुँची।

सभी measurements एक ही दिशा में इशारा कर रहे थे: machine CPU-starved थी, RAM या storage में स्पष्ट रूप से फँसी हुई नहीं थी।

AVA की wording के साथ विरोध

मेरे लिए यही सबसे दिलचस्प हिस्सा है।

AVA कहता है “Guaranteed resources — no sharing”। वह कहता है कि दूसरे customers से performance प्रभावित नहीं होना चाहिए। उसका Linux VPS material कहता है कि co-hosted tenant steal time introduce नहीं कर सकता, और दूसरी page कहती है कि CPU steal hypervisor level पर eliminate होता है।

मेरे AVA VPS ने दिखाया:

Average CPU steal: 32.73%

VM के अंदर से मैं यह साबित नहीं कर सकता कि ऐसा ठीक क्यों हुआ। मैं malicious overselling साबित नहीं कर सकता, किसी specific neighboring workload को identify नहीं कर सकता और AVA की host-side CPU configuration reconstruct नहीं कर सकता।

मैं यह भी नहीं कह रहा कि हर AVA Hosting VPS ऐसा behave करता है। मैंने एक VPS test किया।

लेकिन इतना कह सकता हूँ कि मैंने जो behavior मापा, उसे इन specific CPU-isolation claims के साथ reconcile करना बहुत मुश्किल है। इस article के लिए इतना पर्याप्त है।

मैंने upgrade क्यों नहीं किया

सीधा जवाब होता कि और vCPU खरीद लिए जाएँ।

अगर VPS पर steal लगभग zero होता और मेरी application बस पूरा core consume कर रही होती, तो upgrade समझ में आता। लेकिन observed CPU accounting का लगभग एक-तिहाई हिस्सा steal था।

पहले vCPU की इतनी execution time पहले ही unavailable क्यों report हो रही थी, यह समझे बिना मैं additional virtual CPUs के लिए पैसा नहीं देना चाहता था। इसलिए मैंने VPS cancel किया और refund माँगा।

AVA ने पूरा पैसा जल्दी वापस कर दिया

Experience का यह हिस्सा अच्छा था।

AVA Hosting ने पूरी रकम वापस की। Refund जल्दी process हुआ और CPU measurements को लेकर उन्होंने कई दिनों तक बहस नहीं की। मैंने समस्या समझाई, पैसा वापस माँगा और उन्होंने refund कर दिया।

मैं इसकी सराहना करता हूँ।

इसलिए मेरे experience से दो अलग conclusions निकलते हैं: मुझे मिला VPS गंभीर CPU-availability problem से जूझ रहा था, और AVA ने मेरा refund सही तरीके से handle किया। दोनों बातें सच हैं।

मैंने इससे क्या सीखा

अब मैं VPS को सिर्फ 1 vCPU / 2 GB RAM / NVMe / KVM जैसी specification से judge नहीं करता। ये numbers बताते हैं कि क्या provision हुआ है; वे यह नहीं बताते कि real workload के नीचे CPU कितना predictably मिलेगा।

अब नई VM पर शुरुआती checks में मैं चलाता हूँ:

mpstat 1 60
vmstat 1 60
cat /proc/pressure/cpu
ss -ltnp
free -h
df -h
iostat -xz 1 60

AVA Hosting के इस experience से मेरी सबसे उपयोगी सीख यह नहीं थी कि एक vCPU बहुत छोटा है। असली सीख यह थी कि running process, available RAM और healthy दिखने वाला disk भी नीचे छिपी बिल्कुल अलग समस्या को छुपा सकते हैं।

मेरे मामले में Linux ने इसे बहुत स्पष्ट कर दिया:

CPU steal:    32.73%
CPU idle:      0.00%
CPU pressure: ~99%

AVA Hosting CPU resources को बिना sharing के advertise करता है और कहता है कि neighboring workload से steal नहीं होना चाहिए। मेरे VPS ने कुछ और report किया।

मैंने उसे cancel किया। AVA ने पूरा पैसा जल्दी और बिना बहस के वापस कर दिया।

और यह debugging day वहीं खत्म हो गया।