NVMe विरुद्ध SSD VPS: फरक पडतो का?

VPS वर NVMe महत्त्वाचे आहे का?

तुमचे सॉफ्टवेअर अनेक लहान read आणि write विनंत्या पाठवते आणि प्रत्येक विनंती पूर्ण होण्याची प्रतीक्षा करते, तेव्हा VPS वर NVMe महत्त्वाचे ठरते. Cached पृष्ठे देणाऱ्या साइटसाठी किंवा नेटवर्कची प्रतीक्षा करण्यात वेळ घालवणाऱ्या प्रोग्रामसाठी त्याचा फारसा फरक पडत नाही. Storage medium हा एक घटक आहे. Disk च्या समोर असलेला hypervisor आणि त्याच host वरची इतर guests यांमुळे तुम्हाला प्रत्यक्षात मिळणारी कमाल कामगिरी निश्चित होते.

NVMe मध्ये काय बदलते आणि काय बदलत नाही

NVMe (non-volatile memory express) हा flash memory चा प्रकार नाही. Flash memory पर्यंत पोहोचण्यासाठी वापरला जाणारा protocol आणि connection म्हणजे NVMe. NVMe device PCIe (peripheral component interconnect express) lanes वर असतो आणि NVMe protocol वापरतो. SATA (serial ATA) SSD SATA link वर असतो आणि AHCI (advanced host controller interface) protocol वापरतो. तुमचा data साठवणाऱ्या memory chips दोन्ही प्रकारांत समान असू शकतात.

दोन गोष्टी वेगळ्या असतात. त्या storage पेक्षा command path शी संबंधित असतात.

Queues. AHCI kernel ला 32 commands ठेवणारी एक command queue देतो. NVMe हजारो queues देतो. प्रत्यक्षात प्रत्येक CPU core साठी एक queue असते आणि प्रत्येक queue ची खोली 32 पेक्षा खूप जास्त असते. एका वेळी एक block वाचणाऱ्या एका process ला हा फरक जाणवत नाही. एकाच वेळी 64 reads प्रलंबित असलेल्या database ला हा फरक जाणवतो. SATA वर 33वी request queue slot मिळेपर्यंत थांबते; device ला ती request दिसण्यापूर्वीच ती प्रतीक्षा करते. NVMe device सर्व requests स्वीकारतो आणि त्यांवर एकाच वेळी काम करतो.

Link width. SATA III link 6 Gbit/s वेगाने चालतो. Protocol overhead वजा केल्यानंतर प्रत्यक्ष data वेग सुमारे 550 MB/s असतो. त्यामागे कोणतीही flash असली तरी ही निश्चित कमाल मर्यादा असते. चार PCIe lanes प्रति सेकंदात अनेक gigabytes वाहून नेतात. त्यामुळे link ही मर्यादा राहत नाही.

Latency बाबत अपेक्षा सहसा चुकीच्या असतात. Queue depth 1 म्हणजे एकच request प्रक्रियेत असताना, SATA SSD 4k read चे उत्तर सुमारे 100 ते 150 microseconds मध्ये देतो. NVMe सुमारे 80 ते 100 microseconds मध्ये उत्तर देतो. दोन्ही वेगवान आहेत. एका request वर तुम्ही चालवलेल्या कोणत्याही कामाला हा फरक जाणवणार नाही. Concurrent requests असताना फरक वाढतो. Queue depth म्हणजे एकाच वेळी प्रक्रियेत असलेल्या requests ची संख्या. ही setting दोन media सारखी दिसतील की खूप वेगळी दिसतील, हे ठरवते.

Network block storage हा वेगळ्या प्रकारचा storage आहे आणि त्याची कार्यपद्धतीही वेगळी आहे. Write network द्वारे storage cluster कडे जाते. Cluster ने ती साठवल्यानंतरच write ला acknowledgement मिळते. त्यामुळे तिची latency microseconds ऐवजी milliseconds मध्ये मोजली जाते. या latency बदल्यात तुम्हाला durability मिळते. Volume ला जोडलेला host बंद पडला तरी volume टिकतो. त्याचा snapshot घेता येतो आणि त्याचा आकार बदलता येतो.

सर्वसाधारणपणे प्रकाशित केलेले आकडे: 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 device साठी queue depth 32 असताना सामान्यतः 184,000 random 4k read IOPS (input/output operations per second) असा आकडा दिला जातो. SATA SSD वरील त्याच चाचणीचा आकडा साधारण 90,000 असतो. Single AHCI queue आणि 6 Gbit/s link मुळे हा आकडा मर्यादित राहतो. Network block storage मध्ये मर्यादा सहसा hardware पेक्षा provider ठरवतो आणि 12,500 ही दस्तऐवजीकरणात आढळणारी सामान्य कमाल मर्यादा आहे.

Latency तुमच्या वापरकर्त्यांना जाणवणाऱ्या unit मध्ये हेच स्पष्ट करते. p99 read latency म्हणजे requests मधील सर्वात धीम्या 1 टक्क्यांची latency. स्थानिक NVMe वर ती सुमारे 0.4 ms आणि SATA वर 1.2 ms असते. मार्गामध्ये network जोडल्यास ती 6.5 ms होते. हा NVMe आकड्यापेक्षा दहापटांहून अधिक आहे.

Sequential reads मधील फरक सर्वात मोठा आहे; मात्र हा फरक सर्वात कमी उपयुक्त आहे: 3,400 MB/s विरुद्ध 550 MB/s. Server वरील जवळजवळ कोणतेही काम एक मोठी file पूर्ण वेगाने सुरुवातीपासून शेवटपर्यंत वाचत नाही. Random column आणि latency column database, mail queue किंवा package manager प्रत्यक्षात काय करतात हे दर्शवतात.

डिस्कचा परिणाम जाणवणारी कार्यभार

या सर्वांसाठी एक नियम लागू होतो: कार्यभाराला डिस्कचा परिणाम तेव्हाच जाणवतो, जेव्हा त्याला डिस्कची प्रतीक्षा करावी लागते. Linux अलीकडे वापरलेला फाइल डेटा RAM मधील page cache मध्ये ठेवते. त्यामुळे फाइलचे दुसरे वाचन storage पर्यंत पोहोचत नाही. working set, म्हणजे प्रत्यक्ष वापरात असलेला डेटा, RAM मध्ये मावला तर पहिल्या वाचनानंतरची वाचने memory reads होतात. Writes वेगळे असतात. अनुप्रयोगाने fsync() वापरून flush केलेली कोणतीही write, अनुप्रयोगाला पुढे जाण्याची परवानगी देण्यापूर्वी stable storage वर असणे आवश्यक असते.

Commit करणारे कार्य. PostgreSQL, MySQL आणि SQLite commit वेळी fsync() किंवा fdatasync() कॉल करतात आणि प्रत्येक commit साठी device च्या उत्तराची प्रतीक्षा करतात. त्यामुळे एका connection चा commit rate bandwidth ने नव्हे, तर write latency ने ठरतो. 0.2 ms मध्ये flush करणारे device, 5 ms घेणाऱ्या device पेक्षा प्रति सेकंद खूप अधिक commits करू शकते. Throughput कितीही वाढवला तरी हा फरक बदलत नाही. Flush चा वेग पुरेसा नसल्यास MySQL error log मध्ये हे नमूद करते:

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

PostgreSQL हे checkpoint lines मध्ये नोंदवते. तेथे मोठी sync= value म्हणजे flush स्वतःच धीमा होता:

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

अनेक लहान files हाताळणारे कार्य. एका मोठ्या sequential read च्या तुलनेत प्रत्येक file साठी metadata operations आवश्यक असतात. npm install, मोठ्या repository चे git clone, container images unpack करणे, Maildir mail store आणि मोठ्या tree वरून जाणारे backup हे सर्व लहान random access वर वेळ घालवतात. VPS वरील restic backup job यापूर्वी न पाहिलेली प्रत्येक file वाचते आणि तिचा hash तयार करते. त्यामुळे million files वरील backup चा wall-clock time random read latency शी जवळून संबंधित असतो. du -sh बाबतही हेच लागू होते. ते metadata वाचते आणि इतर काहीही वाचत नाही.

RAM पेक्षा मोठे होणारे databases देखील या वर्गात येतात. Index page cache मध्ये मावत नसल्यावर प्रत्येक lookup random read बनतो आणि disk पुन्हा critical path मध्ये येते.

कोणत्या वर्कलोड्सना डिस्कमधील फरक जाणवत नाही

ब्लॉग किंवा लहान कंपनीची साइट. पृष्ठे लहान असतात. पहिल्या विनंतीनंतर page cache मध्ये ती सर्व पृष्ठे साठतात. Rendering साठी CPU किंवा assets साठी bandwidth ही मर्यादा असते. कमी traffic असलेली साइट देणारा Ubuntu 24.04 वरील LAMP stack warm झाल्यानंतर जवळजवळ कोणतेही disk IO करत नाही.

Media streaming. एक 4K stream 40 Mbit/s वेगाने 5 MB/s वाचवतो. दहा streams 50 MB/s वाचवतात. हा वेग network block storage देखील सहज हाताळते. VPS वरील Jellyfin media server तुमच्या network egress allowance मुळे मर्यादित असतो. तो transcoding करताना CPU मुळेही मर्यादित होतो. Storage medium मुळे तो मर्यादित होत नाही.

Local model inference. LLM स्वतः होस्ट करण्यासाठी VPS वर Ollama चालवणे model file एकदाच वाचते. त्यानंतर ते RAM मध्ये कार्य करते. NVMe मुळे 20 GB model चा load time काही मिनिटांवरून काही सेकंदांपर्यंत कमी होतो. मात्र tokens per second मध्ये बदल होत नाही. ते memory bandwidth आणि CPU मुळे मर्यादित असते.

बाह्य सेवेकडून प्रतिसादाची प्रतीक्षा करणारे कोणतेही काम. प्रत्येक job साठी HTTP request वर 800 ms खर्च करणारा worker चांगल्या disk मुळे अधिक वेगाने चालत नाही.

माध्यमाइतकेच hypervisor महत्त्वाचा का आहे

तुम्ही थेट device शी संवाद साधत नाही. hypervisor सादर करत असलेल्या virtual disk शी संवाद साधता. हे सादरीकरण सामान्यतः virtio द्वारे होते. या स्तरावरील अनेक निर्णयांचा परिणाम NVMe आणि SATA यांमधील फरकापेक्षा अधिक असतो.

guest मधून medium दिसत नाही. lsblk -d -o NAME,ROTA,SIZE,MODEL रिकाम्या model सह vda दाखवते, कारण virtio drive ची ओळख पुढे पाठवत नाही. cat /sys/block/vda/queue/rotational hypervisor जाहीर करत असलेली माहिती दाखवते. त्यामुळे तेथे 0 दिसणे म्हणजे flash असल्याचा पुरावा नाही. nvme-cli package मधील nvme list बहुतेक VPS वर काहीही दाखवत नाही. Host मध्ये NVMe drives असले तरी असे होते, कारण तुमची disk virtio device आहे, NVMe device नाही. NVMe असे नमूद केलेली plan सामान्यतः host मध्ये असलेल्या storage चे वर्णन करते. तुमचा volume तरीही network attached असू शकतो.

Host cache mode चा परिणाम medium पेक्षा benchmark आकड्यांवर अधिक होतो. Host वर writeback caching सुरू असल्यास, guest कडील fsync() host ने data स्वतःच्या RAM मध्ये घेताच पूर्ण झाल्याचे परत सांगू शकते. असा benchmark result कोणतेही physical device देऊ शकत नाही. तसेच host crash झाल्यास database सुरक्षित समजत असलेले writes गमावले जाऊ शकतात. none cache mode वापरल्यास आकडे कमी आणि वास्तवदर्शी असतात.

मर्यादा आणि burst credits. अनेक providers प्रत्येक volume किंवा plan साठी IOPS ची मर्यादा घालतात. अनेक network volumes burst allowance वापरतात. Burst allowance म्हणजे credits चा साठा. Credits उपलब्ध असेपर्यंत volume जलद चालतो. त्यानंतर तो खूपच कमी baseline वेगावर येतो. हे लक्षण सहज ओळखता येते. Import किंवा restore काही मिनिटे जलद चालतो. त्यानंतर तो अचानक मंदावतो आणि configuration मध्ये कोणताही बदल न करता मंदच राहतो. Credits संपलेले असतात.

शेजारील tenants. Shared host वर इतर guests काय करत आहेत त्यानुसार तुमच्या disk ची latency बदलते. म्हणून एकापेक्षा जास्त वेळा मोजमाप करणे आवश्यक आहे. तीच test सकाळी चालवा आणि पुन्हा संध्याकाळी चालवा. त्यांतील फरकाची व्याप्ती तुलना करा. व्यस्त host वर त्याच volume वरील दोन runs मधील फरक अनेकदा दोन media साठी प्रकाशित केलेल्या फरकापेक्षा मोठा असतो.

तुमच्या VPS मध्ये प्रत्यक्षात असलेली डिस्क कशी मोजावी

मानक IO benchmark असलेले fio install करा आणि मोजमाप घ्या. प्रथम तीन सूचना लक्षात ठेवा. चाचणी एक file तयार करते. त्यामुळे disk space वापरली जाते आणि तुम्हाला बिल आकारल्या जाणाऱ्या कोणत्याही IOPS allowance मध्ये ती गणली जाते. चाचणी लहान ठेवा. live traffic देणाऱ्या volume वर full queue depth सह ती चालवू नका, कारण तुमच्या स्वतःच्या application शी संसाधनांसाठी स्पर्धा निर्माण होईल.

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

Queue depth 32 वर random read करा. Vendors साधारणपणे हाच depth नमूद करतात:

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 guest page cache वगळते. त्यामुळे परिणाम तुमच्या RAM ऐवजी device चे वर्णन करतो. ते वगळल्यास तुम्ही memory मोजता आणि असा आकडा मिळतो जो कोणतीही disk मिळवू शकत नाही. जागा उपलब्ध असल्यास --size=4G किंवा त्याहून मोठी value वापरा, कारण 1G file पूर्णपणे host च्या cache मध्ये राहू शकते आणि परिणाम कृत्रिमरीत्या चांगला दिसू शकतो.

Queue depth 1 मुळे raw latency दिसते. Single-threaded process ला प्रत्यक्ष जाणवणारी हीच latency असते:

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

Commit test database चे वर्तन दर्शवतो. तो 4k लिहितो आणि प्रत्येक write नंतर fdatasync() call करतो. त्यामुळे reported rate मध्ये flush समाविष्ट असतो:

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

या run मधील IOPS figure एका database connection कडून प्रति सेकंद commit करता येणाऱ्या लहान transactions च्या कमाल संख्येच्या जवळ असतो, कारण commit साठी त्याच flush ची प्रतीक्षा करावी लागते.

fio शिवाय जलद sample घेण्यासाठी:

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 value, म्हणजे mean deviation, average इतकीच महत्त्वाची आहे. idle box वर मोठी deviation असल्यास storage backend shared आणि busy आहे, असे सूचित होते.

परिणाम कसा वाचावा

July 2026 पर्यंत, लहान VPS साठी ही मोजमापे वाजवी आहेत. queue depth 32 वर प्रति सेकंद हजारो 4k random read IOPS आणि सुमारे 0.3 ms पेक्षा कमी queue depth 1 latency स्थानिक flash शी सुसंगत आहे. queue depth 1 latency अनेक milliseconds असल्यास, plan चे नाव काहीही असले तरी network path असतो. Sequential reads जवळपास 550 MB/s वर थांबणे हे SATA link चे लक्षण आहे. कोणतेही एक device देऊ शकते त्यापेक्षा खूप मोठी संख्या दिसत असल्यास, path मध्ये caching आहे. हे जवळजवळ नेहमी host वर होते.

तुमच्या सध्या सुरू असलेल्या workload मुळे disk वर काय परिणाम होत आहे हे पाहण्यासाठी:

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

iostat -x output मध्ये r_await आणि w_await वाचा. ही request ने प्रतीक्षा केलेली सरासरी milliseconds आहेत. तसेच aqu-sz वाचा, जी सरासरी queue length आहे. Virtual disk वर %util दुर्लक्षित करा. किमान एक request प्रलंबित असलेल्या वेळेचा वाटा ते दाखवते. एकाच वेळी अनेक requests पूर्ण करणाऱ्या device वरील saturation यावरून समजत नाही. त्यामुळे %util चे मूल्य 100 आणि r_await चे मूल्य 0.2 ms असणे व्यस्त पण निरोगी disk दर्शवते. vmstat मध्ये wa column हा IO साठी प्रतीक्षा करण्यात गेलेल्या CPU time ची टक्केवारी आहे. तुमच्या kernel मध्ये /proc/pressure/io उपलब्ध असल्यास, त्याचे some avg10= मूल्य मागील 10 seconds पैकी किमान एक task IO मुळे अडखळलेला असलेल्या वेळेचा वाटा आहे. Storage तुमचा bottleneck आहे का, या प्रश्नाचे हे सर्वात थेट उत्तर देते.

डिस्कमुळे मर्यादित VPS कसा दिसतो

CPU निष्क्रिय असताना load average जास्त असणे आणि wa मध्ये मोठे vmstat असणे म्हणजे प्रक्रिया डिस्कच्या मागे रांगेत थांबल्या आहेत. कर्नलचा सर्वात स्पष्ट संकेत dmesg -T मधील हा संदेश आहे:

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

हा संदेश दिसतो कारण स्टोरेजकडून प्रतिसाद मिळण्यासाठी कर्नल थ्रेडने दोन मिनिटांहून अधिक वेळ प्रतीक्षा केली. त्यामुळे hung task watchdog ने त्याची नोंद केली. jbd2 हा ext4 journal thread आहे. याचा अर्थ एखादा चुकीच्या पद्धतीने चालणारा प्रोग्राम नव्हे, तर संपूर्ण filesystem प्रतीक्षा करत होता. VPS वर याचा संबंध सहसा storage backend किंवा संपलेल्या IOPS allowance शी असतो.

Application symptoms देखील हाच नमुना दर्शवतात. Median response time स्वीकारार्ह राहतो, पण सर्वात धीम्या requests साठी दीर्घ tail दिसतो, कारण डिस्कवर प्रवेश करणाऱ्या requests वरच हा विलंब होतो. apt upgrade अनेक मिनिटे Unpacking स्थितीत राहतो, कारण dpkg लिहिताना flush करतो. मोठ्या repository मधील git status पूर्ण होण्यासाठी काही सेकंद लागतात. हे metadata आणि flush costs आहेत. त्यामुळे अधिक bandwidth उपलब्ध करून दिल्याने मदत होणार नाही.

डिस्क मर्यादा ठरत असताना काय करावे

IOPS घेण्यापूर्वी RAM वाढवा. कार्यरत संच page cache मध्ये बसत असेल, तर वाचन disk पर्यंत पोहोचतच नाही. Memory दुप्पट करणे अनेकदा अधिक जलद storage class वर स्थलांतर करण्यापेक्षा परिणामकारक ठरते आणि त्याची किंमतही सहसा कमी असते.

डेटा परवानगी देत असेल, तर flush ची संख्या कमी करा. PostgreSQL मध्ये, synchronous_commit = off मुळे write disk वर होण्यापूर्वी commit परत येऊ शकतो. Server बंद पडल्यास व्यवहारांमधील शेवटचा fraction of a second गमावला जाऊ शकतो. Database corrupt होत नाही, कारण write-ahead log अद्याप क्रमाने लिहिला जातो. Analytics copy साठी हा व्यवहार योग्य आहे, पण payments साठी अयोग्य आहे. MySQL मधील innodb_flush_log_at_trx_commit = 2 हाच व्यवहार करतो.

लहान files चे batch तयार करा. दहा लाख लहान files चे transfer किंवा backup करताना प्रत्येक file चा स्वतंत्र खर्च प्रमुख ठरतो. त्यामुळे आधी archive तयार करून एकच stream हलवणे, उच्च-latency storage वर tree मधील files एकेक करून copy करण्यापेक्षा जलद असते.

Thin volumes वर discard कार्यरत ठेवा. Thin provisioned storage मध्ये filesystem ने block मोकळा असल्याचे सांगितल्याशिवाय backend ला तो मोकळा आहे हे कळत नाही. तसेच, volume वर कधीही trim न केल्यास write performance हळूहळू कमी होते. Ubuntu यासाठी साप्ताहिक timer देते:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av प्रत्येक mount point साठी trim केलेले bytes दाखवते. Discard operation समर्थित नसल्याचा संदेश दिसल्यास virtual disk discard host पर्यंत पोहोचवत नाही. त्यामुळे तुमच्याकडून दुरुस्त करण्यासारखे काही नाही.

IO scheduler चे tuning टाळा. virtio disk वर cat /sys/block/vda/queue/scheduler सहसा none आधीच दाखवते. प्रत्यक्ष scheduling host वर होते आणि त्यावर तुम्हाला प्रवेश नसतो. noatime देखील टाळा. Ubuntu default ने relatime सह mount करते, त्यामुळे जवळजवळ प्रत्येक atime write आधीच टाळला जातो.

योजना निवडणे

डेटाबेस, mail server, CI runner किंवा package-heavy build त्या सर्व्हरवर चालत असल्यास NVMe साठी पैसे द्या. Cached website किंवा ज्याचा बहुतांश वेळ external calls मध्ये जातो अशा app साठी अतिरिक्त शुल्क देऊ नका. खात्री नसल्यास disk ही तुमची मर्यादा नसण्याची शक्यता आहे, कारण बहुतेक लहान VPS workloads मध्ये आधी RAM किंवा bandwidth संपते.

पहिल्याच दिवशी मोजमाप करा, आणि नवीन VPS वरील पहिल्या दहा मिनिटांत काम करत असताना त्याचे output एका file मध्ये जतन करा. Host मंद झाला आहे की तुमच्या code मुळे समस्या निर्माण झाली आहे, हे नंतर सिद्ध करण्यासाठी baseline उपयोगी ठरतो. Storage class आणि कोणतीही IOPS cap लेखी नमूद करणाऱ्या providers ना प्राधान्य द्या. एखाद्या plan मध्ये NVMe नमूद असून queue depth 1 read ला 4 ms लागत असल्यास, NVMe असलेल्या host वर network storage वापरले जात आहे. अशी सेवा विकणे योग्य आहे, पण ती वेगळी गोष्ट खरेदी करणे आहे.

FAQ

VPS वरील NVMe नेहमी SATA SSD पेक्षा जलद असतो का?

नाही. queue depth 1 वर दोन्हींची कामगिरी जवळपास सारखी असते. 4k read साठी विलंब साधारण 80 ते 150 microseconds असतो. single-threaded प्रोग्रामला दोन्हींमधील फरक जाणवत नाही. अनेक requests एकाच वेळी प्रलंबित असताना NVMe पुढे असतो. याचे कारण म्हणजे AHCI मध्ये 32 commands खोलीची एक queue असते, तर NVMe मध्ये अधिक खोली असलेल्या हजारो queues असतात. shared host वर इतर guests चा load storage medium पेक्षा तुमच्या latency मध्ये अधिक बदल करू शकतो. त्यामुळे plan name पाहण्याऐवजी fio वापरून तुमच्या volume ची मोजणी करा.

माझा VPS प्रत्यक्षात NVMe वापरतो की नाही हे कसे तपासावे?

तुम्ही हे थेट तपासू शकत नाही, कारण virtio भौतिक device लपवते. lsblk हे vda model string शिवाय दाखवते, nvme list काहीही परत करत नाही आणि /sys/block/vda/queue/rotational hypervisor ज्या माहितीची जाहिरात करतो तेवढेच अहवालात देते. त्याऐवजी प्रत्यक्ष कामगिरी मोजा. queue depth 1 वरील random 4k read चा विलंब साधारण 0.3 ms पेक्षा कमी असल्यास तो local flash असण्याची शक्यता असते. काही milliseconds लागत असल्यास मार्गामध्ये network hop आहे. Sequential reads साधारण 550 MB/s जवळ थांबत असल्यास SATA link असल्याचे सूचित होते.

NVMe मुळे माझी website जलद load होईल का?

सामान्यतः नाही. पहिल्या request नंतर Linux files RAM मधील page cache मधून पुरवते, त्यामुळे disk idle होते. लहान VPS वरील page speed साधारणपणे application CPU time आणि bandwidth यांमुळे मर्यादित असते. Website प्रत्येक request वर write करत असल्यास disk पुन्हा critical path मध्ये येते. उदाहरणार्थ, वारंवार commit करणारा database-backed cart प्रत्येक 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 साधारणपणे काही हजार IOPS देते आणि latency काही milliseconds असते. वेगवेगळ्या वेळांमध्ये ही चाचणी तीन वेळा चालवा. चाचण्यांमधील मोठा फरक सरासरीपेक्षा अधिक माहिती देतो, कारण त्यामुळे host वरील इतर guests तुमच्यावर किती परिणाम करतात हे दिसते.

माझा database network block storage वर ठेवावा का?

तुम्ही ठेवू शकता आणि अनेक managed services असे करतात. परंतु commit path वर त्याचा परिणाम होतो. प्रत्येक flush network मधून जातो. त्यामुळे local flash च्या तुलनेत एक connection दर सेकंदाला कमी small transactions commit करू शकतो. त्याच्या बदल्यात host निकामी झाल्यानंतरही टिकणारी durability मिळते. Write-heavy database साठी network storage निवडल्यास काम मोठ्या transactions मध्ये गटबद्ध करा. त्यामुळे कमी flushes मध्ये अधिक rows लिहिता येतात.