डिस्क स्पीड: बेसलाइन और बर्स्ट
टियर के अनुसार डिस्क स्पीड सीमा कैसे निकलती है, 30-सेकंड का बर्स्ट क्यों ज़रूरी है, असली स्पीड कैसे मापें, और सीमा छू जाने पर क्या करें।
23 अगस्त 2026 को अपडेट किया गया
VPS पर डिस्क NVMe होती है, लेकिन स्पीड टियर से सीमित रहती है ताकि कोई एक मशीन नोड के साझा रिसोर्स को न खा जाए। इन आंकड़ों को समझने से आपको "CPU खाली है तो डेटाबेस धीमा क्यों है" जैसे सवालों का जवाब मिल जाता है।
गणना कैसे होती है
राइट बेसलाइन प्रति कोर 60 MB/s है, लेकिन 60 से कम और 400 MB/s से ज़्यादा नहीं। रीड राइट बेसलाइन का दोगुना होता है। बेसलाइन से ऊपर, उसकी तीन गुना वैल्यू का बर्स्ट 30 सेकंड के लिए उपलब्ध रहता है।
| टियर | कोर | राइट बेसलाइन | रीड बेसलाइन | राइट बर्स्ट (30 सेकंड) |
|---|---|---|---|---|
| VDS-1 | 1 | 60 MB/s | 120 MB/s | 180 MB/s |
| VDS-2 | 2 | 120 MB/s | 240 MB/s | 360 MB/s |
| VDS-3 | 4 | 240 MB/s | 480 MB/s | 720 MB/s |
| VDS-4 | 6 | 360 MB/s | 720 MB/s | 1080 MB/s |
| VDS-5 | 8 | 400 MB/s | 800 MB/s | 1200 MB/s |
| VDS-6 | 10 | 400 MB/s | 800 MB/s | 1200 MB/s |
बर्स्ट उन्हीं कामों के लिए है जिनके लिए होना चाहिए: एप्लिकेशन स्टार्टअप, आर्काइव एक्सट्रैक्शन, माइग्रेशन लगाना। लगातार चलने वाली राइट स्ट्रीम — गीगाबाइट्स कॉपी करना, बिल्ड, बड़े डेटाबेस को स्कैन करना — बेसलाइन पर ही चलती है।
माप कैसे करें
sudo apt install -y fio
fio --name=w --rw=write --bs=1M --size=2G --numjobs=1 \
--runtime=60 --time_based --end_fsync=1 --directory=/var/tmp
पहले कुछ सेकंड बर्स्ट दिखाएंगे, फिर स्पीड बेसलाइन पर गिर जाएगी — यह सामान्य और अपेक्षित तस्वीर है, कोई खराबी नहीं।
पैकेज इंस्टॉल किए बिना एक त्वरित मोटा-मोटी जांच:
dd if=/dev/zero of=/var/tmp/testfile bs=1M count=2048 oflag=direct
rm /var/tmp/testfile
काम के घंटों में प्रोडक्शन मशीन पर डिस्क टेस्ट न चलाएं। टेस्ट वाकई पूरी उपलब्ध बैंडविड्थ खा जाएगा, और उन मिनटों में आपकी साइट को जवाब देने में सेकंडों लगेंगे। और टेस्ट फ़ाइलें पीछे न छोड़ें: 40 GB की डिस्क पर दो गीगाबाइट एक बड़ा हिस्सा है, देखें डिस्क स्पेस।
कैसे पता करें कि डिस्क बॉटलनेक है
sudo apt install -y sysstat
iostat -x 2 5
vmstat 2 5
दो मेट्रिक्स देखें: %util 100 के करीब और await दसियों मिलीसेकंड में — यह डिस्क क्यू दर्शाता है। vmstat में भी संकेत वही है — बढ़ता b कॉलम (इंतज़ार करती प्रोसेस) और CPU यूटिलाइज़ेशन का कम प्रतिशत।
एक और लक्षण: लगभग खाली CPU के साथ ऊंचा load average। Linux का load average डिस्क का इंतज़ार करती प्रोसेस को भी गिनता है।
कौन लिख रहा है:
sudo iotop -o -b -n 3
अगर बॉटलनेक से टकरा गए हैं तो क्या करें
- समय में अलग-अलग करें। कॉपी, रजिस्ट्री बिल्ड, रिपोर्ट — रात में और एक साथ नहीं। देखें शेड्यूल किए गए जॉब।
- बैकग्राउंड टास्क सीमित करें। जो भी ज़रूरी नहीं है उसके लिए
rsync --bwlimit,nice -n 19 ionice -c3 <command>। - राइट कम करें। लॉग का साइज़ सीमित करें, एप्लिकेशन में ज़रूरत से ज़्यादा वर्बोसिटी बंद करें, कैश को मेमोरी (
tmpfs) में ले जाएं अगर वह रीबूट के बाद बचा रहे। - डेटाबेस ट्यून करें। PostgreSQL और MySQL में राइट का बड़ा हिस्सा ट्रांज़ैक्शन लॉग होता है। बफ़र के लिए ज़्यादा मेमोरी का मतलब कम डिस्क एक्सेस।
- ऊपर के टियर में जाएं। बेसलाइन कोर के साथ बढ़ती है: VDS-1 से VDS-2 तक यह दोगुनी हो जाती है। अपग्रेड सिर्फ़ ऊपर की ओर संभव है, पेड टर्म के बचे दिनों के लिए अतिरिक्त भुगतान के साथ।
आम गलतियां
oflag=directके बिनाddसे स्पीड मापना। डेटा पेज कैश में बैठ जाता है, और आंकड़े बढ़े-चढ़े आते हैं।- बर्स्ट को लगातार स्पीड मान लेना। पहले 30 सेकंड तेज़ हैं, फिर बेसलाइन — यह डिज़ाइन के मुताबिक है।
- स्वैप को एक्टिव डिस्क पर रखना और उसमें स्वैप करना। जब मेमोरी कम हो, स्वैप डिस्क को बॉटलनेक बना देता है: बेहतर है कंटेनर सीमित करें, देखें रिसोर्स लिमिट।