VPS के लिए NVMe बनाम SSD: क्या वास्तव में अंतर है?

क्या VPS पर NVMe मायने रखता है?

जब आपका सॉफ़्टवेयर कई छोटे reads और writes भेजता है और प्रत्येक के पूरा होने की प्रतीक्षा करता है, तब VPS पर NVMe मायने रखता है। जो साइटें cached pages सर्व करती हैं, या जो प्रोग्राम अपना समय नेटवर्क पर प्रतीक्षा करने में बिताते हैं, उनके लिए इससे बहुत कम अंतर पड़ता है। स्टोरेज माध्यम केवल एक कारक है। डिस्क के सामने मौजूद hypervisor और उसी host को साझा करने वाले अन्य guests, उस प्रदर्शन की सीमा तय करते हैं जो आपको वास्तव में प्राप्त होता है।

NVMe क्या बदलता है और क्या नहीं

NVMe (non-volatile memory express) फ्लैश मेमोरी का एक प्रकार नहीं है। यह फ्लैश तक पहुँचने के लिए उपयोग किया जाने वाला प्रोटोकॉल और कनेक्शन है। एक NVMe डिवाइस PCIe (peripheral component interconnect express) लेन्स पर स्थित होता है और NVMe भाषा का उपयोग करता है। एक SATA (serial ATA) SSD, SATA लिंक पर स्थित होता है और AHCI (advanced host controller interface) का उपयोग करता है। आपके डेटा को स्टोर करने वाली मेमोरी चिप्स दोनों में समान हो सकती हैं।

दो चीजें अलग हैं, और दोनों का संबंध स्टोरेज के बजाय कमांड पाथ से है।

Queues (कतारें): AHCI कर्नल को एक कमांड कतार देता है जिसमें 32 कमांड रह सकते हैं। NVMe हजारों कतारों की अनुमति देता है, व्यवहार में प्रति CPU कोर एक कतार, और प्रत्येक कतार 32 से कहीं अधिक गहरी होती है। एक समय में एक ब्लॉक पढ़ने वाली प्रक्रिया इस अंतर को नहीं देख सकती। लेकिन 64 पेंडिंग रीड्स वाला डेटाबेस इसे देख सकता है: SATA पर 33वां अनुरोध कतार में जगह मिलने का इंतजार करता है, जबकि NVMe डिवाइस उन सभी को एक साथ स्वीकार करता है और उन पर काम करता है।

Link width (लिंक की चौड़ाई): एक SATA III लिंक 6 Gbit/s पर चलता है, जो प्रोटोकॉल ओवरहेड के बाद लगभग 550 MB/s वास्तविक डेटा होता है। यह एक निश्चित सीमा है, चाहे उसके पीछे कोई भी फ्लैश लगा हो। चार PCIe लेन्स प्रति सेकंड कई गीगाबाइट डेटा ले जा सकती हैं, इसलिए लिंक अब बाधा (limit) नहीं बनता।

Latency (विलंबता) वह जगह है जहाँ उम्मीदें अक्सर गलत होती हैं। Queue depth 1 पर, यानी एक समय में एक ही अनुरोध होने पर, एक SATA SSD लगभग 100 से 150 माइक्रोसेकंड में 4k रीड का उत्तर देता है। NVMe लगभग 80 से 100 माइक्रोसेकंड में उत्तर देता है। दोनों तेज हैं, और एक अनुरोध पर आप किसी अंतर को महसूस नहीं करेंगे। अंतर concurrency (समवर्तीता) के तहत स्पष्ट होता है। Queue depth, यानी एक साथ चल रहे अनुरोधों की संख्या, वह सेटिंग है जो यह तय करती है कि दोनों मीडिया समान दिखेंगे या बहुत अलग।

Network block storage एक तीसरी श्रेणी है जिसके भौतिक नियम अलग हैं। एक राइट ऑपरेशन नेटवर्क को पार करके स्टोरेज क्लस्टर तक जाता है और तभी स्वीकार किया जाता है जब क्लस्टर उसे सुरक्षित कर लेता है, इसलिए इसकी latency माइक्रोसेकंड के बजाय मिलीसेकंड में मापी जाती है। इस latency के बदले आप durability (स्थायित्व) खरीदते हैं: वॉल्यूम उस होस्ट से अधिक समय तक चलता है जिससे वह जुड़ा है, और इसका स्नैपशॉट लिया जा सकता है या इसे रीसाइज किया जा सकता है।

सामान्य प्रकाशित आंकड़े: NVMe, SATA SSD और नेटवर्क स्टोरेज

[
  {
    "disk": "Local NVMe SSD",
    "iops_4k_read": "184,000",
    "p99_latency_ms": 0.4,
    "seq_read_mbps": "3,400"
  },
  {
    "disk": "Local SATA SSD",
    "iops_4k_read": "90,000",
    "p99_latency_ms": 1.2,
    "seq_read_mbps": "550"
  },
  {
    "disk": "Network block storage",
    "iops_4k_read": "12,500",
    "p99_latency_ms": 6.5,
    "seq_read_mbps": "250"
  }
]

एक स्थानीय NVMe डिवाइस के लिए आमतौर पर 184,000 रैंडम 4k रीड IOPS (इनपुट/आउटपुट ऑपरेशंस प्रति सेकंड) का उल्लेख किया जाता है, जो 32 की queue depth पर आधारित होता है। SATA SSD पर यही परीक्षण लगभग 90,000 के करीब होता है, जो सिंगल AHCI queue और 6 Gbit/s लिंक के कारण सीमित रहता है। नेटवर्क ब्लॉक स्टोरेज की क्षमता आमतौर पर हार्डवेयर के बजाय प्रदाता द्वारा निर्धारित की जाती है, और 12,500 एक सामान्य प्रलेखित सीमा (documented ceiling) है।

Latency उसी बात को उस इकाई में बताती है जिसे आपके उपयोगकर्ता अनुभव करते हैं। p99 रीड लेटेंसी, जिसका अर्थ है अनुरोधों का सबसे धीमा 1 प्रतिशत हिस्सा, स्थानीय NVMe पर लगभग 0.4 ms और SATA पर 1.2 ms होती है। यदि रास्ते में नेटवर्क शामिल हो, तो यह 6.5 ms हो जाती है, जो NVMe के आंकड़े से दस गुना से भी अधिक है।

Sequential रीड्स में सबसे बड़ा अंतर होता है और यह सबसे कम उपयोगी भी है: 3,400 MB/s बनाम 550 MB/s। सर्वर पर लगभग कोई भी कार्य एक बड़ी फाइल को शुरू से अंत तक पूरी गति से नहीं पढ़ता है। रैंडम और लेटेंसी कॉलम यह बताते हैं कि कोई डेटाबेस, मेल क्यू या पैकेज मैनेजर वास्तव में कैसे काम करता है।

कौन से वर्कलोड डिस्क पर निर्भर करते हैं

एक नियम इन सभी को स्पष्ट करता है: वर्कलोड डिस्क पर तभी निर्भर करता है जब वह डिस्क के लिए प्रतीक्षा करता है। Linux हाल ही में उपयोग किए गए फ़ाइल डेटा को RAM में, page cache के भीतर रखता है, इसलिए किसी फ़ाइल को दूसरी बार पढ़ने पर वह स्टोरेज तक नहीं पहुँचता। यदि वर्किंग सेट, यानी वास्तव में उपयोग में आने वाला डेटा, RAM में समा जाता है, तो पहली बार के बाद सभी रीड ऑपरेशन मेमोरी रीड बन जाते हैं। राइट ऑपरेशन अलग होते हैं। कोई भी राइट जिसे एप्लिकेशन fsync() के साथ फ्लश करता है, उसे एप्लिकेशन के आगे बढ़ने से पहले स्टेबल स्टोरेज पर होना चाहिए।

वह कार्य जो कमिट करता है। PostgreSQL, MySQL और SQLite कमिट पर fsync() या fdatasync() को कॉल करते हैं, और प्रत्येक कमिट डिवाइस से उत्तर मिलने की प्रतीक्षा करता है। इसलिए एक कनेक्शन की कमिट दर बैंडविड्थ से नहीं, बल्कि राइट लेटेंसी (write latency) से निर्धारित होती है। जो डिवाइस 0.2 ms में फ्लश करता है, वह 5 ms लेने वाले डिवाइस की तुलना में प्रति सेकंड कहीं अधिक कमिट की अनुमति देता है, और थ्रूपुट में कितनी भी वृद्धि इसे नहीं बदल सकती। जब फ्लश की गति कम पड़ जाती है, तो MySQL इसे एरर लॉग में इस प्रकार बताता है:

[Note] InnoDB: page_cleaner: 1000ms intended loop took 4589ms. The settings might not be optimal.

PostgreSQL इसे अपनी चेकपॉइंट लाइनों में रिपोर्ट करता है, जहाँ एक बड़ा sync= मान यह दर्शाता है कि फ्लश प्रक्रिया धीमी थी:

LOG:  checkpoint complete: wrote 8192 buffers (25.0%); write=27.694 s, sync=11.207 s, total=39.001 s

वह कार्य जो कई छोटी फ़ाइलों को छूता है। प्रत्येक फ़ाइल के साथ मेटाडेटा ऑपरेशन जुड़े होते हैं जो एक बड़े सीक्वेंशियल रीड में नहीं होते। npm install, एक बड़े रिपॉजिटरी का git clone, कंटेनर इमेज को अनपैक करना, Maildir मेल स्टोर और एक बड़े ट्री को स्कैन करने वाला बैकअप, ये सभी अपना समय छोटे रैंडम एक्सेस में बिताते हैं। एक VPS पर restic बैकअप जॉब हर उस फ़ाइल को पढ़ता है और उसका हैश बनाता है जिसे उसने पहले नहीं देखा है, इसलिए दस लाख फ़ाइलों के बैकअप का वास्तविक समय रैंडम रीड लेटेंसी का बारीकी से अनुसरण करता है। यही बात du -sh के लिए भी सच है, जो केवल मेटाडेटा पढ़ता है और कुछ नहीं।

जो डेटाबेस RAM से बड़े हो जाते हैं, वे भी इसी श्रेणी में आते हैं। एक बार जब इंडेक्स page cache में नहीं समाता, तो प्रत्येक लुकअप एक रैंडम रीड बन जाता है, और डिस्क वापस क्रिटिकल पाथ में आ जाती है।

Which workloads do not notice the disk

A blog or a small company site. The pages are small, the page cache holds all of them after the first request, and the limit is CPU for rendering or bandwidth for assets. A LAMP stack on Ubuntu 24.04 serving a low-traffic site does almost no disk IO once it is warm.

Media streaming. One 4K stream at 40 Mbit/s reads 5 MB/s. Ten of them read 50 MB/s, which even network block storage serves without effort. A Jellyfin media server on a VPS is limited by your network egress allowance, and by CPU when it transcodes, not by the storage medium.

Local model inference. Running Ollama on a VPS to self-host an LLM reads the model file once, then works in RAM. NVMe cuts the load time of a 20 GB model from minutes to seconds. It does not change tokens per second, which is bound by memory bandwidth and CPU.

Anything waiting on an external service. A worker that spends 800 ms per job on an HTTP request will not go faster on a better disk.

हाइपरवाइजर माध्यम (medium) जितना ही महत्वपूर्ण क्यों है

आप कभी सीधे डिवाइस से बात नहीं करते हैं। आप एक वर्चुअल डिस्क से बात करते हैं जिसे हाइपरवाइजर प्रस्तुत करता है, आमतौर पर virtio के माध्यम से, और उस लेयर में लिए गए कई निर्णय NVMe बनाम SATA की तुलना में अधिक मायने रखते हैं।

आप गेस्ट के अंदर से माध्यम को नहीं देख सकते। lsblk -d -o NAME,ROTA,SIZE,MODEL एक खाली मॉडल के साथ vda दिखाता है, क्योंकि virtio ड्राइव की पहचान को पास नहीं करता है। cat /sys/block/vda/queue/rotational वही रिपोर्ट करता है जो हाइपरवाइजर विज्ञापित करता है, इसलिए वहां 0 होना फ्लैश का प्रमाण नहीं है। nvme-cli पैकेज से nvme list, अधिकांश VPS पर कुछ भी सूचीबद्ध नहीं करता है, भले ही होस्ट NVMe ड्राइव से भरा हो, क्योंकि आपकी डिस्क एक virtio डिवाइस है न कि NVMe डिवाइस। जो प्लान NVMe का दावा करता है, वह आमतौर पर यह बता रहा होता है कि होस्ट में क्या है। आपका वॉल्यूम अभी भी नेटवर्क से जुड़ा हो सकता है।

होस्ट कैश मोड माध्यम की तुलना में आंकड़ों को अधिक प्रभावित करता है। होस्ट पर writeback कैशिंग के साथ, एक गेस्ट fsync() जैसे ही होस्ट के पास अपना डेटा RAM में होता है, वापस आ सकता है। यह एक ऐसा बेंचमार्क परिणाम देता है जिसे कोई भी भौतिक डिवाइस नहीं दे सकता। इसका मतलब यह भी है कि होस्ट क्रैश होने पर वे राइट्स (writes) खो सकते हैं जिन्हें आपका डेटाबेस सुरक्षित मानता है। कैश मोड none के साथ, आंकड़े कम और सटीक होते हैं।

कैप्स और बर्स्ट क्रेडिट्स। कई प्रदाता प्रति वॉल्यूम या प्रति प्लान IOPS को सीमित (cap) करते हैं, और कई नेटवर्क वॉल्यूम बर्स्ट अलाउंस का उपयोग करते हैं। बर्स्ट अलाउंस क्रेडिट्स का एक पूल है: जब तक क्रेडिट्स रहते हैं तब तक वॉल्यूम तेज चलता है, फिर एक बहुत निचले बेसलाइन पर आ जाता है। इसके लक्षण को पहचानना आसान है। एक इम्पोर्ट या रिस्टोर कई मिनटों तक तेजी से चलता है, फिर अचानक धीमा हो जाता है और धीमा ही रहता है, जबकि आपके कॉन्फ़िगरेशन में कुछ भी नहीं बदला होता है। आपने क्रेडिट्स खर्च कर दिए हैं।

पड़ोसी (Neighbours)। एक साझा होस्ट पर, आपकी डिस्क लेटेंसी इस आधार पर बदलती है कि अन्य गेस्ट क्या कर रहे हैं। यही कारण है कि एक से अधिक बार माप (measure) करना चाहिए। सुबह और शाम को एक ही टेस्ट चलाएं और अंतर की तुलना करें। एक व्यस्त होस्ट पर, एक ही वॉल्यूम पर दो रन के बीच का अंतर अक्सर दो माध्यमों के बीच प्रकाशित अंतर से बड़ा होता है।

अपने VPS पर उपलब्ध डिस्क की वास्तविक क्षमता कैसे मापें

fio इंस्टॉल करें, जो कि मानक IO बेंचमार्क है, और मापें। पहले तीन सावधानियां बरतें। यह टेस्ट एक फाइल बनाता है, इसलिए यह डिस्क स्पेस का उपयोग करता है और आपकी बिलिंग में शामिल IOPS सीमा में गिना जाता है। रन को छोटा रखें। इसे लाइव ट्रैफिक सर्व कर रहे वॉल्यूम पर फुल क्यू डेप्थ (queue depth) के साथ न चलाएं, क्योंकि आप अपने स्वयं के एप्लिकेशन के साथ प्रतिस्पर्धा करेंगे।

sudo apt update && sudo apt install -y fio ioping sysstat
cd /var/tmp

क्यू डेप्थ 32 पर रैंडम रीड, जो कि वह डेप्थ है जिसे वेंडर उद्धृत करते हैं:

fio --name=randread --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 \
  --runtime=30 --time_based --group_reporting

जो लाइन महत्वपूर्ण है वह read: से शुरू होती है।

  read: IOPS=184k, BW=719MiB/s (754MB/s)(21.1GiB/30001msec)

--direct=1 गेस्ट पेज कैश को बायपास करता है, इसलिए परिणाम आपकी RAM के बजाय डिवाइस का विवरण देता है। इसे हटा देने पर आप मेमोरी को मापेंगे, जो ऐसी संख्या लौटाएगी जिसे कोई भी डिस्क प्राप्त नहीं कर सकती। यदि आपके पास जगह है तो --size=4G या उससे बड़ी फाइल का उपयोग करें, क्योंकि 1G की फाइल पूरी तरह से होस्ट के कैश में रह सकती है और परिणाम को बढ़ा-चढ़ाकर दिखा सकती है।

क्यू डेप्थ 1 रॉ लेटेंसी (raw latency) दिखाती है, जो वह है जिसे एक सिंगल-थ्रेडेड प्रोसेस महसूस करती है:

fio --name=lat --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based

कमिट टेस्ट डेटाबेस के व्यवहार का अनुमान लगाता है। यह 4k लिखता है और हर राइट के बाद fdatasync() को कॉल करता है, इसलिए रिपोर्ट की गई दर में फ्लश शामिल होता है:

fio --name=commit --filename=fio.test --size=1G --bs=4k --rw=randwrite \
  --ioengine=psync --fdatasync=1 --runtime=30 --time_based
rm -f fio.test

उस रन से प्राप्त IOPS का आंकड़ा प्रति सेकंड छोटे ट्रांजेक्शन की उस अधिकतम संख्या के करीब है जिसे एक डेटाबेस कनेक्शन कमिट कर सकता है, क्योंकि कमिट उसी फ्लश की प्रतीक्षा करता है।

fio के बिना त्वरित नमूने के लिए:

ioping -c 20 .

--- . (ext4 /dev/vda1) ioping statistics ---
19 requests completed in 4.13 ms, 76 KiB read, 4.60 k iops, 17.9 MiB/s
min/avg/max/mdev = 174.2 us / 217.6 us / 386.1 us / 51.3 us

mdev मान, यानी माध्य विचलन (mean deviation), औसत के जितना ही महत्वपूर्ण है। एक आइडल बॉक्स पर बड़ा विचलन यह दर्शाता है कि स्टोरेज बैकएंड साझा है और व्यस्त है।

परिणामों को कैसे पढ़ें

जुलाई 2026 तक, एक छोटे VPS के लिए ये उचित रीडिंग हैं। queue depth 32 पर हजारों 4k random read IOPS, और 0.3 ms से कम की queue depth 1 latency, local flash के अनुरूप है। कई milliseconds की queue depth 1 latency का अर्थ है कि यह एक network path है, चाहे plan का नाम कुछ भी हो। 550 MB/s के आसपास रुकने वाले sequential reads, SATA link की पहचान हैं। कोई भी संख्या जो किसी एक device की क्षमता से कहीं अधिक है, उसका अर्थ है कि path में caching मौजूद है, जो लगभग हमेशा host पर होती है।

यह देखने के लिए कि आपका live workload डिस्क पर क्या कर रहा है:

iostat -x 1 3
vmstat 1 5
cat /proc/pressure/io

iostat -x आउटपुट में, r_await और w_await को पढ़ें, जो कि एक request द्वारा प्रतीक्षा किए गए औसत milliseconds हैं, और aqu-sz, जो औसत queue length है। virtual disk पर %util को अनदेखा करें। यह उस समय के हिस्से को दर्शाता है जब कम से कम एक request लंबित थी, जो ऐसे device पर saturation के बारे में कुछ नहीं बताता जो एक साथ कई requests को पूरा करता है, इसलिए 0.2 ms के r_await के साथ %util का 100 होना एक स्वस्थ व्यस्त डिस्क का संकेत है। vmstat में, wa कॉलम IO पर प्रतीक्षा में व्यतीत CPU समय का प्रतिशत है। यदि आपके kernel पर /proc/pressure/io मौजूद है, तो इसका some avg10= मान पिछले 10 seconds का वह हिस्सा है जिसमें कम से कम एक task IO पर रुका हुआ था, जो इस प्रश्न का सबसे सीधा उत्तर है कि क्या storage आपका bottleneck है।

डिस्क-बाउंड VPS कैसा दिखता है

यदि CPU खाली है लेकिन load average अधिक है और wa में vmstat की संख्या बड़ी है, तो इसका अर्थ है कि processes डिस्क के कारण कतार में हैं। kernel का सबसे स्पष्ट संकेत dmesg -T में यह संदेश है:

INFO: task jbd2/vda1-8:194 blocked for more than 120 seconds.

यह लाइन इसलिए दिखाई देती है क्योंकि एक kernel thread ने स्टोरेज से प्रतिक्रिया के लिए दो मिनट से अधिक प्रतीक्षा की, जिसे hung task watchdog ने लॉग कर दिया। jbd2 एक ext4 journal thread है, जिसका अर्थ है कि पूरा filesystem प्रतीक्षा कर रहा था, न कि कोई एक खराब प्रोग्राम। VPS पर यह आमतौर पर स्टोरेज बैकएंड या समाप्त हो चुके IOPS allowance की ओर इशारा करता है।

एप्लिकेशन के लक्षण भी इसी पैटर्न का पालन करते हैं। median response time स्वीकार्य रहता है जबकि सबसे धीमी requests का समय बढ़ता जाता है, क्योंकि केवल वही requests प्रभावित होती हैं जो डिस्क का उपयोग करती हैं। apt upgrade मिनटों तक Unpacking पर अटका रहता है, क्योंकि dpkg लिखते समय डेटा को फ्लश करता है। एक बड़े repository में git status में सेकंडों का समय लगता है। ये metadata और flush की लागत हैं, इसलिए अधिक bandwidth से कोई मदद नहीं मिलेगी।

जब डिस्क की सीमा समाप्त हो जाए तो क्या करें

IOPS खरीदने से पहले RAM खरीदें। यदि वर्किंग सेट पेज कैश में फिट हो जाता है, तो रीड ऑपरेशंस डिस्क तक पहुँचते ही नहीं हैं। मेमोरी को दोगुना करना अक्सर तेज़ स्टोरेज क्लास में जाने से बेहतर होता है, और यह आमतौर पर सस्ता भी पड़ता है।

जहाँ डेटा अनुमति दे, वहां फ्लश की संख्या कम करें। PostgreSQL में, synchronous_commit = off एक कमिट को डिस्क पर लिखे जाने से पहले ही रिटर्न करने की अनुमति देता है। यदि सर्वर क्रैश हो जाता है, तो आप अंतिम क्षण के कुछ ट्रांजेक्शन खो सकते हैं। डेटाबेस करप्ट नहीं होता है, क्योंकि राइट-अहेड लॉग अभी भी क्रम में लिखा जाता है। यह समझौता एनालिटिक्स कॉपी के लिए सही है, लेकिन भुगतान (पेमेंट्स) के लिए गलत है। MySQL में innodb_flush_log_at_trx_commit = 2 भी यही समझौता है।

छोटी फाइलों को बैच में रखें। दस लाख छोटी फाइलों का ट्रांसफर या बैकअप प्रति-फाइल लागत से प्रभावित होता है। इसलिए, हाई-लेटेंसी स्टोरेज पर फाइल-दर-फाइल कॉपी करने के बजाय, पहले आर्काइव बनाना और एक स्ट्रीम में मूव करना अधिक तेज़ होता है।

थिन वॉल्यूम पर डिस्कॉर्ड (discard) को काम करने दें। थिन प्रोविज़न्ड स्टोरेज पर, बैकएंड को तब तक पता नहीं चलता कि कोई ब्लॉक खाली है जब तक कि फाइलसिस्टम ऐसा न कहे। जो वॉल्यूम कभी ट्रिम नहीं होता, उसकी राइट परफॉरमेंस धीरे-धीरे कम हो जाती है। Ubuntu इसके लिए एक साप्ताहिक टाइमर प्रदान करता है:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av प्रत्येक माउंट पॉइंट के लिए ट्रिम किए गए बाइट्स को प्रिंट करता है। यदि यह संदेश आता है कि डिस्कॉर्ड ऑपरेशन समर्थित नहीं है, तो इसका मतलब है कि वर्चुअल डिस्क होस्ट तक डिस्कॉर्ड पास नहीं करती है, इसलिए आपके पास ठीक करने के लिए कुछ भी नहीं है।

IO शेड्यूलर ट्यूनिंग को छोड़ दें। virtio डिस्क पर, cat /sys/block/vda/queue/scheduler आमतौर पर पहले से ही none दिखाता है, और वास्तविक शेड्यूलिंग होस्ट पर होती है, जहाँ आपकी पहुँच नहीं है। noatime को भी छोड़ दें: Ubuntu डिफ़ॉल्ट रूप से relatime के साथ माउंट होता है, जो लगभग हर atime राइट को पहले ही रोक देता है।

प्लान का चयन

यदि सर्वर पर कोई database, mail server, CI runner या package-heavy build चल रहा हो, तो ही NVMe के लिए भुगतान करें। किसी cached website या ऐसे app के लिए अतिरिक्त शुल्क न दें जिसका अधिकांश समय external calls में व्यतीत होता है। यदि आप सुनिश्चित नहीं हैं, तो disk संभवतः आपकी सीमा नहीं है, क्योंकि अधिकांश छोटे VPS workloads में सबसे पहले RAM या bandwidth समाप्त होती है।

पहले दिन ही मापें, जब आप नए VPS पर शुरुआती दस मिनट की प्रक्रिया पूरी कर रहे हों, और output को एक file में सुरक्षित रखें। baseline ही वह तरीका है जिससे आप बाद में यह सिद्ध कर सकते हैं कि host धीमा हुआ है, न कि आपका code। ऐसे providers को प्राथमिकता दें जो storage class और किसी भी IOPS cap का लिखित उल्लेख करते हों। यदि किसी plan में NVMe लिखा है और queue depth 1 read में 4 ms का समय लगता है, तो आप NVMe-equipped host पर network storage का उपयोग कर रहे हैं। यह बेचने के लिए एक उचित उत्पाद है, लेकिन खरीदने के लिए एक अलग वस्तु।

FAQ

क्या VPS पर NVMe हमेशा SATA SSD से तेज़ होता है?

नहीं। Queue depth 1 पर दोनों का प्रदर्शन लगभग समान होता है, 4k read के लिए लगभग 80 से 150 microseconds, और एक single-threaded program इनके बीच अंतर नहीं कर पाता। NVMe तब बेहतर प्रदर्शन करता है जब एक साथ कई requests process हो रही हों, क्योंकि AHCI में 32 commands की एक ही queue होती है, जबकि NVMe में हजारों गहरी queues उपलब्ध होती हैं। एक shared host पर, अन्य guests का load आपके latency को medium के प्रकार से कहीं अधिक प्रभावित कर सकता है, इसलिए plan के नाम पर भरोसा करने के बजाय fio का उपयोग करके अपने volume को स्वयं मापें।

मैं यह कैसे जाँचूँ कि मेरा VPS वास्तव में NVMe का उपयोग कर रहा है?

आप इसे सीधे नहीं जाँच सकते, क्योंकि virtio physical device को छिपा देता है। lsblk में vda बिना किसी model string के दिखाई देता है, nvme list कुछ भी return नहीं करता, और /sys/block/vda/queue/rotational केवल वही रिपोर्ट करता है जो hypervisor बताता है। इसके बजाय व्यवहार को मापें। 0.3 ms से कम की queue depth 1 random 4k read का मतलब है कि यह local flash है। यदि इसमें कई milliseconds का समय लगता है, तो इसका मतलब है कि path में network hop शामिल है। 550 MB/s के आसपास रुकने वाली sequential reads SATA link का संकेत देती हैं।

क्या NVMe से मेरी वेबसाइट तेज़ी से लोड होती है?

आमतौर पर नहीं। पहली request के बाद, Linux फाइलों को RAM में page cache से serve करता है, इसलिए disk idle हो जाती है। एक छोटे VPS पर page speed सामान्यतः application CPU time और bandwidth द्वारा सीमित होती है। यदि साइट हर request पर लिखती है, तो disk critical path में वापस आ जाती है, उदाहरण के लिए database-backed cart जो अक्सर commit करती है, क्योंकि प्रत्येक commit को flush पूरा होने का इंतज़ार करना पड़ता है।

VPS के लिए एक अच्छा fio परिणाम क्या है?

July 2026 तक, local flash पर एक छोटा VPS आमतौर पर queue depth 32 पर हज़ारों की संख्या में 4k random read IOPS देता है, जिसकी queue depth 1 latency 0.3 ms से कम होती है। Network block storage आमतौर पर कुछ milliseconds की latency पर कुछ हज़ार IOPS देता है। इस test को अलग-अलग समय पर तीन बार चलाएँ। अलग-अलग runs के बीच का बड़ा अंतर औसत से अधिक जानकारी देता है, क्योंकि यह दर्शाता है कि host पर मौजूद अन्य guests आपको कितना प्रभावित कर रहे हैं।

क्या मुझे अपना database network block storage पर रखना चाहिए?

आप ऐसा कर सकते हैं, और कई managed services ऐसा करती भी हैं, लेकिन commit path के लिए इसकी कीमत चुकानी पड़ती है। प्रत्येक flush network से होकर गुज़रता है, इसलिए एक single connection local flash की तुलना में प्रति सेकंड कम small transactions ही commit कर पाता है। इसके बदले आपको ऐसी durability मिलती है जो host के खराब होने पर भी सुरक्षित रहती है। यदि आप write-heavy database के लिए network storage चुनते हैं, तो काम को बड़े transactions में group करें ताकि कम flushes में अधिक rows process हो सकें।