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

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

NVMe तब मायने रखता है जब आपका software बहुत सारे छोटे reads और writes भेजता है और प्रत्येक के पूरा होने का इंतज़ार करता है। जो साइट cached pages serve करती है, या जो program अपना समय network पर इंतज़ार करने में बिताता है, उसके लिए इसमें बहुत कम बदलाव आता है। storage medium केवल एक कारक है। डिस्क के सामने मौजूद 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 लेन्स प्रति सेकंड कई गीगाबाइट डेटा ले जाती हैं, इसलिए लिंक अब बाधा नहीं बनता।

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

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 के रूप में रखता है, इसलिए किसी फ़ाइल को दूसरी बार पढ़ने पर वह storage तक नहीं पहुँचता। यदि working set, यानी वास्तव में उपयोग में आने वाला डेटा, RAM में समा जाता है, तो पहली बार के बाद reads केवल memory reads बन जाते हैं। Writes अलग होते हैं। कोई भी write जिसे application fsync() के साथ flush करती है, उसे application के आगे बढ़ने से पहले stable storage पर होना चाहिए।

ऐसा कार्य जो commit करता है। PostgreSQL, MySQL और SQLite commit पर fsync() या fdatasync() को कॉल करते हैं, और प्रत्येक commit डिवाइस के उत्तर देने की प्रतीक्षा करता है। इसलिए एक connection की commit दर write latency से निर्धारित होती है, bandwidth से नहीं। जो डिवाइस 0.2 ms में flush करता है, वह 5 ms लेने वाले डिवाइस की तुलना में प्रति सेकंड कहीं अधिक commits की अनुमति देता है, और throughput की कितनी भी मात्रा इसे बदल नहीं सकती। जब flush गति नहीं बना पाता, तो MySQL इसे error log में इस प्रकार बताता है:

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

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

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

ऐसा कार्य जो कई छोटी फ़ाइलों को छूता है। प्रत्येक फ़ाइल में metadata operations होते हैं जो एक बड़े sequential read में नहीं होते। npm install, एक बड़े repository का git clone, container images को unpack करना, Maildir mail store और एक बड़े tree को स्कैन करने वाला backup, ये सभी अपना समय small random access पर व्यतीत करते हैं। एक VPS पर restic backup job हर उस फ़ाइल को पढ़ता और hash करता है जिसे उसने पहले नहीं देखा है, इसलिए दस लाख फ़ाइलों पर backup का wall-clock समय random read latency का बारीकी से अनुसरण करता है। यही बात du -sh के लिए भी सच है, जो केवल metadata पढ़ता है और कुछ नहीं।

जो databases RAM से बड़े हो जाते हैं, वे भी इसी श्रेणी में आते हैं। एक बार जब index page cache में नहीं समाता, तो प्रत्येक lookup एक random read बन जाता है, और डिस्क वापस critical path में आ जाती है।

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

एक ब्लॉग या छोटी कंपनी की साइट। इनके पेज छोटे होते हैं, पहली रिक्वेस्ट के बाद पेज कैश में सभी पेज आ जाते हैं, और यहाँ सीमा रेंडरिंग के लिए CPU या एसेट्स के लिए बैंडविड्थ होती है। कम ट्रैफिक वाली साइट को सर्व करने वाला Ubuntu 24.04 पर LAMP stack एक बार वार्म हो जाने के बाद लगभग कोई डिस्क IO नहीं करता है।

मीडिया स्ट्रीमिंग। 40 Mbit/s पर एक 4K स्ट्रीम 5 MB/s डेटा पढ़ती है। दस स्ट्रीम 50 MB/s पढ़ती हैं, जिसे नेटवर्क ब्लॉक स्टोरेज भी बिना किसी परेशानी के सर्व कर लेता है। VPS पर Jellyfin मीडिया सर्वर की सीमा आपके नेटवर्क इग्रेस अलाउंस और ट्रांसकोडिंग के दौरान CPU द्वारा तय होती है, न कि स्टोरेज माध्यम द्वारा।

लोकल मॉडल इन्फरेंस। LLM को सेल्फ-होस्ट करने के लिए VPS पर Ollama चलाना मॉडल फाइल को एक बार पढ़ता है, और फिर RAM में काम करता है। NVMe 20 GB मॉडल के लोड होने के समय को मिनटों से घटाकर सेकंड में कर देता है। यह टोकन प्रति सेकंड की गति को नहीं बदलता, जो मेमोरी बैंडविड्थ और CPU द्वारा सीमित होती है।

कोई भी कार्य जो बाहरी सर्विस पर निर्भर हो। एक वर्कर जो प्रति जॉब HTTP रिक्वेस्ट पर 800 ms खर्च करता है, वह बेहतर डिस्क पर तेज नहीं चलेगा।

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

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

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

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

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

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

अपने VPS पर उपलब्ध डिस्क को कैसे मापें

मानक IO बेंचमार्क, fio को इंस्टॉल करें और मापें। पहले तीन सावधानियां बरतें। यह टेस्ट एक फाइल बनाता है, इसलिए यह डिस्क स्पेस का उपयोग करता है और आपकी बिलिंग में शामिल 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 है, चाहे प्लान का नाम कुछ भी हो। 550 MB/s के आसपास रुकने वाले sequential reads, SATA link की पहचान हैं। किसी भी एकल डिवाइस की क्षमता से कहीं अधिक संख्या का अर्थ है कि 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 लंबित थी, जो एक ऐसे डिवाइस पर saturation के बारे में कुछ नहीं बताता जो एक साथ कई requests को पूरा करता है, इसलिए r_await के 0.2 ms के साथ %util का 100 होना एक स्वस्थ व्यस्त डिस्क का संकेत है। vmstat में, wa कॉलम IO पर प्रतीक्षा में व्यतीत CPU समय का प्रतिशत है। यदि आपके kernel पर /proc/pressure/io मौजूद है, तो इसका some avg10= मान पिछले 10 seconds का वह हिस्सा है जिसमें कम से कम एक task IO पर रुका हुआ था, जो इस प्रश्न का सबसे सीधा उत्तर है कि क्या storage आपका bottleneck है।

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

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

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

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

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

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

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

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

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

थिन वॉल्यूम पर डिस्कॉर्ड (discard) को काम करने दें। थिन प्रोविज़न्ड स्टोरेज पर बैकएंड को तब तक पता नहीं चलता कि कोई ब्लॉक खाली है जब तक कि फाइलसिस्टम ऐसा न कहे। जो वॉल्यूम कभी ट्रिम (trim) नहीं होता, उसकी राइट परफॉरमेंस धीरे-धीरे कम हो जाती है। 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 के लिए प्रीमियम न दें जिसका समय बाहरी calls में व्यतीत होता है। यदि आप सुनिश्चित नहीं हैं, तो disk संभवतः आपकी सीमा नहीं है, क्योंकि अधिकांश छोटे VPS workloads में पहले RAM या bandwidth समाप्त हो जाती है।

पहले दिन ही मापें, जब आप नए VPS पर पहले दस मिनट के दौरान काम कर रहे हों, और output को एक file में रखें। एक baseline ही वह तरीका है जिससे आप बाद में यह साबित कर सकते हैं कि host धीमा हुआ है, न कि आपका code। ऐसे प्रदाताओं को प्राथमिकता दें जो 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 flight में हों, क्योंकि AHCI 32 commands गहरी एक queue प्रदान करता है जबकि NVMe हज़ारों गहरी queues प्रदान करता है। एक shared host पर, अन्य guests का load medium की तुलना में आपकी latency को अधिक प्रभावित कर सकता है, इसलिए plan का नाम पढ़ने के बजाय fio के साथ अपने volume को मापें।

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

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

क्या NVMe मेरी website को तेज़ी से load होने में मदद करता है?

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

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

July 2026 तक, local flash पर एक छोटा VPS आमतौर पर queue depth 32 पर हज़ारों की संख्या में (tens of thousands) 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 हो सकें।