VPS का आकार कैसे तय करें: CPU, RAM, डिस्क और बैंडविड्थ गाइड

VPS को सही आकार देने की एक व्यावहारिक गाइड — वास्तविक वर्कलोड के लिए vCPU, RAM, डिस्क प्रकार/क्षमता और मासिक बैंडविड्थ का अनुमान कैसे लगाएं, साथ में वे Linux कमांड जिनकी आपको अपने चुनाव को मापने और सत्यापित करने के लिए ज़रूरत होगी।

VPS का आकार कैसे तय करें: CPU, RAM, डिस्क और बैंडविड्थ

VPS प्लान चुनना एक संतुलन साधने जैसा काम है। ज़रूरत से ज़्यादा संसाधन ले लें, तो आप हर महीने उन कोर और मेमोरी के लिए भुगतान करते रहते हैं जो बेकार पड़ी रहती हैं। ज़रूरत से कम लें, तो लोड के समय आपका ऐप अटक जाता है, डिस्क पर स्वैप करने लगता है, या बैंडविड्थ कोटा खत्म होने पर बंद हो जाता है। यह गाइड बताती है कि अपने वास्तविक वर्कलोड के आधार पर हर संसाधन — vCPU, RAM, डिस्क और बैंडविड्थ — का आकार कैसे तय करें, और अनुमान लगाने के बजाय अपने चुनाव को सत्यापित करने के लिए ज़रूरी Linux कमांड भी देती है।

अगर आप साझा होस्टिंग या किसी दूसरे प्रदाता से माइग्रेट कर रहे हैं, तो सबसे भरोसेमंद तरीका है पहले मापें, फिर उन आँकड़ों को किसी प्लान पर मैप करें।

प्लान से नहीं, वर्कलोड से शुरुआत करें

किसी भी मूल्य-निर्धारण पृष्ठ को देखने से पहले, लिखें कि सर्वर वास्तव में क्या चलाएगा। चार सबसे आम स्वरूप ये हैं:

• एक ही बॉक्स पर वेब ऐप + डेटाबेस (WordPress, Laravel, Node): उतार-चढ़ाव भरा CPU, मध्यम RAM, पढ़ने-केंद्रित (read-heavy) डिस्क।
• डेटाबेस सर्वर: RAM की भूखी (वर्किंग सेट को मेमोरी में समाना चाहिए), डिस्क IOPS सबसे ज़्यादा मायने रखती है।
• बैकग्राउंड/बैच या बिल्ड वर्कर्स: निरंतर CPU, पूर्वानुमेय RAM।
• स्टैटिक/एज या प्रॉक्सी: कम CPU/RAM, असली अड़चन बैंडविड्थ होती है।

हर स्वरूप किसी अलग संसाधन पर दबाव डालता है। उसी के लिए आकार तय करें जो सबसे पहले संतृप्त (saturate) होता है — वही आपकी अड़चन (bottleneck) है — और बाकी पर थोड़ी गुंजाइश छोड़ दें।

CPU: vCPU कोई भौतिक कोर नहीं है

एक vCPU किसी साझा भौतिक कोर का एक थ्रेड होता है, जिसे हाइपरवाइज़र शेड्यूल करता है। स्थिर वर्कलोड के लिए यह एक समर्पित कोर की तरह व्यवहार करता है; उतार-चढ़ाव भरे वर्कलोड के लिए, "शेयर्ड" प्लान आपको कुछ समय के लिए बेसलाइन से ऊपर उछाल लेने देते हैं, जबकि "डेडिकेटेड vCPU" प्लान पूर्णकालिक पहुँच की गारंटी देते हैं।

मोटे तौर पर नियम:

• एक छोटी WordPress या व्यावसायिक साइट: 1–2 vCPU।
• एक व्यस्त CMS, ऐप सर्वर, या मध्यम समवर्तीता (concurrency) वाला डेटाबेस: 2–4 vCPU।
• CI बिल्ड, वीडियो ट्रांसकोडिंग, या निरंतर कंप्यूट: शेयर्ड नहीं, बल्कि डेडिकेटेड vCPU चुनें।

किसी मौजूदा बॉक्स पर CPU दबाव मापें:

# 1-minute, 5-minute, 15-minute load average vs core count
uptime
nproc          # number of vCPUs available

# per-core utilization, refreshed every 2s
mpstat -P ALL 2

अगर आपका 5-मिनट का लोड एवरेज लगातार आपके nproc गिनती से ऊपर रहता है, या mpstat में %idle शून्य के आसपास रहता है, तो आप CPU-बाउंड हैं — कोर जोड़ें। अगर लोड कोर गिनती से काफी नीचे रहता है, तो आप बेकार पड़े vCPU के लिए भुगतान कर रहे हैं।

RAM: वर्किंग सेट का आकार तय करें, फिर गुंजाइश छोड़ें

RAM आमतौर पर पहली दीवार होती है जिससे आप टकराते हैं। लक्ष्य है अपने एप्लिकेशन के हॉट डेटा और OS पेज कैश को मेमोरी में रखना ताकि सर्वर को पढ़ने के लिए डिस्क को शायद ही कभी छूना पड़े।

डरावने "total used" आँकड़े को नहीं, असली उपयोग को देखें:

free -h
# Look at the "available" column, not "free".
# Linux uses spare RAM for buffers/cache and releases it on demand.

दो व्यावहारिक नियम:

• स्वैप पर नज़र रखें। अगर सामान्य लोड पर free -h में स्वैप सक्रिय रूप से उपयोग होता दिखे, तो आपके पास RAM कम है और आप एक भारी लेटेंसी दंड चुका रहे हैं।
• अपनी सेवाओं का सही आकार तय करें। गलत तरीके से कॉन्फ़िगर किया गया MySQL innodb_buffer_pool_size या बहुत ज़्यादा PHP-FPM वर्कर्स प्लान के आकार की परवाह किए बिना RAM खत्म कर सकते हैं। बड़ा बॉक्स खरीदने से पहले ऐप को ट्यून करें।

डिस्क: क्षमता और गति दो अलग-अलग निर्णय हैं

दो सवाल: कितनी जगह, और कितनी तेज़।

क्षमता — OS (~3–10 GB), आपके एप्लिकेशन, डेटाबेस, लॉग और अपलोड का योग करें, फिर बढ़ने के लिए जगह जोड़ें। कम से कम 20–30% खाली रखें; पूरी भरी डिस्क पर डेटाबेस और लॉग रोटेशन बुरी तरह व्यवहार करते हैं।

df -h          # space used/free per filesystem
du -sh /var/* | sort -h   # find what is actually consuming space

गति — NVMe SSD को प्राथमिकता दें, जिसका Skyline Cloud VPS प्लान डिफ़ॉल्ट रूप से उपयोग करते हैं। घूमने वाली (spinning) डिस्क और यहाँ तक कि SATA SSD भी डेटाबेस के लिए अड़चन बन जाती हैं। जाँचें कि कहीं आप I/O-बाउंड तो नहीं:

# %iowait high = CPU waiting on disk
iostat -x 2

# %util near 100% on your disk device = saturated I/O

अगर iowait ज़्यादा है जबकि CPU %idle भी ज़्यादा है, तो आपकी सीमा डिस्क है — प्रोसेसर नहीं — और तेज़ स्टोरेज (या कैशिंग के लिए ज़्यादा RAM) ज़्यादा कोर की तुलना में अधिक मदद करता है।

बैंडविड्थ: कोटा और थ्रूपुट

दो अलग-अलग आँकड़ों को "बैंडविड्थ" कहा जाता है:

1. मासिक ट्रांसफर कोटा (उदा. 2 TB/माह) — अंदर/बाहर कुल डेटा। इसे पार करें तो आपको थ्रॉटल किया जाता है या ओवरेज के लिए बिल भेजा जाता है।
2. पोर्ट स्पीड / थ्रूपुट (उदा. 1 Gbps) — एक अकेला ट्रांसफर कितनी तेज़ी से चल सकता है।

वास्तविक ट्रैफ़िक से मासिक ट्रांसफर का अनुमान लगाएं: औसत पेज वज़न × पेज व्यू × ~1.3 (रीट्राई, एसेट और API कॉल के लिए)। ~2 MB के पेज के 100,000 मासिक व्यू देने वाली एक साइट को लगभग 260 GB/माह आउटबाउंड की ज़रूरत होती है — जो एक सामान्य 1–2 TB भत्ते के भीतर आराम से समा जाता है, लेकिन मीडिया या डाउनलोड-भारी साइटें इससे आगे निकल सकती हैं।

किसी चालू सर्वर पर मौजूदा उपयोग जाँचें:

# install with: apt install vnstat  (Debian/Ubuntu)
vnstat -m      # monthly totals, in and out

सऊदी अरब और GCC के भीतर के उपयोगकर्ताओं और ट्रैफ़िक के लिए, किंगडम के भीतर होस्टिंग राउंड-ट्रिप लेटेंसी को भी कम करती है और डेटा को PDPL तथा NCA आवश्यकताओं के अधीन रखती है — एक ऐसा आकार-निर्धारण निर्णय जो जितना कच्ची क्षमता के बारे में है उतना ही स्थान के बारे में भी। किंगडम के भीतर विकल्पों के लिए Skyline Cloud होस्टिंग और VPS व क्लाउड सर्वर हब देखें।

सब मिलाकर: एक आकार-निर्धारण चेकलिस्ट

1. वर्कलोड स्वरूप और उसके संभावित अड़चन वाले संसाधन की पहचान करें।
2. mpstat, free -h, iostat -x, और vnstat से मौजूदा उपयोग मापें।
3. अड़चन वाले संसाधन का आकार ~30% गुंजाइश के साथ तय करें; बाकी का सही आकार रखें।
4. निरंतर कंप्यूट के लिए NVMe स्टोरेज और डेडिकेटेड vCPU को प्राथमिकता दें।
5. ऐसा प्लान चुनें जिसे आप बाद में स्केल अप कर सकें — कम से शुरू करें और जब मेट्रिक्स कहें तभी आकार बदलें।

क्लाउड VPS का सबसे बड़ा फ़ायदा यह है कि आकार-निर्धारण स्थायी नहीं होता। एक रूढ़िवादी (conservative) प्लान से शुरू करें, ऊपर बताए मेट्रिक्स को एक-दो सप्ताह देखें, और जब वास्तविक डेटा — न कि घबराहट — कहे तभी आकार बदलें। अगर आप मेल भी चलाते हैं, तो उसे ऐप सर्वर से अलग रखें; समर्पित बिज़नेस ईमेल होस्टिंग सस्ती होती है और आपके VPS संसाधनों को एप्लिकेशन के लिए मुक्त कर देती है।

शुरुआत करें

पारदर्शी मूल्य-निर्धारण और स्थानीय अरबी समर्थन के साथ एक NVMe-समर्थित, किंगडम के भीतर का VPS प्रोविज़न करें, और बढ़ने के साथ कभी भी आकार बदलें। अपना Skyline Cloud खाता बनाएं और मिनटों में अपना सर्वर लॉन्च करें।