VPS میں NVMe یا SSD: کیا واقعی فرق پڑتا ہے؟

کیا VPS پر NVMe اہم ہے؟

VPS پر NVMe اس وقت اہم ہوتا ہے جب آپ کا سافٹ ویئر بہت سی چھوٹی read اور write کارروائیاں بھیجے اور ہر کارروائی کے مکمل ہونے کا انتظار کرے۔ ایسی site کے لیے اس کا اثر بہت کم ہوتا ہے جو cached صفحات فراہم کرتی ہو، یا ایسے program کے لیے جو اپنا وقت network پر انتظار کرتے ہوئے گزارتا ہو۔ storage medium صرف ایک عامل ہے۔ disk کے سامنے موجود 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) استعمال کرتی ہے۔ دونوں میں بائٹس محفوظ کرنے والی میموری چپس ایک جیسی ہو سکتی ہیں۔

دو چیزیں مختلف ہوتی ہیں، اور دونوں کا تعلق اسٹوریج کے بجائے کمانڈ کے راستے سے ہے۔

قطاریں۔ AHCI، kernel کو 32 کمانڈز رکھنے والی ایک کمانڈ قطار فراہم کرتا ہے۔ NVMe ہزاروں قطاروں کی اجازت دیتا ہے۔ عملی طور پر ہر CPU core کے لیے ایک قطار ہو سکتی ہے، اور ہر قطار کی گہرائی 32 سے کہیں زیادہ ہوتی ہے۔ ایک وقت میں ایک block پڑھنے والا ایک process یہ فرق محسوس نہیں کر سکتا۔ 64 زیرِ التوا read requests والا database یہ فرق محسوس کر سکتا ہے: SATA پر 33rd request، ڈیوائس تک پہنچنے سے پہلے queue slot کے لیے انتظار کرتی ہے، جبکہ NVMe ڈیوائس تمام requests قبول کر کے ان پر بیک وقت کام کرتی ہے۔

لنک کی چوڑائی۔ SATA III لنک 6 Gbit/s کی رفتار سے چلتا ہے، جو protocol overhead کے بعد حقیقی data کی تقریباً 550 MB/s بنتی ہے۔ اس کے پیچھے کوئی بھی flash موجود ہو، یہ ایک مقررہ حد ہے۔ چار PCIe lanes کئی gigabytes فی سیکنڈ منتقل کرتی ہیں، اس لیے لنک حد نہیں رہتا۔

Latency کے معاملے میں توقعات عموماً درست نہیں ہوتیں۔ Queue depth 1 پر، یعنی جب ایک وقت میں صرف ایک request زیرِ عمل ہو، SATA SSD، 4k read کا جواب تقریباً 100 سے 150 microseconds میں دیتی ہے۔ NVMe تقریباً 80 سے 100 microseconds میں جواب دیتی ہے۔ دونوں تیز ہیں، اور ایک request پر آپ کے چلانے والے کسی بھی کام کو یہ فرق محسوس نہیں ہوگا۔ یہ فرق concurrency بڑھنے پر نمایاں ہوتا ہے۔ Queue depth، یعنی ایک وقت میں زیرِ عمل requests کی تعداد، وہ setting ہے جو طے کرتی ہے کہ دونوں media ایک جیسے دکھائی دیں گے یا بہت مختلف۔

Network block storage تیسری قسم ہے، جس کے اصول مختلف ہیں۔ Write، network کے ذریعے storage cluster تک جاتی ہے اور صرف اس وقت acknowledge ہوتی ہے جب cluster اسے محفوظ کر لیتا ہے، اس لیے اس کی latency microseconds کے بجائے milliseconds میں ناپی جاتی ہے۔ اس latency کے بدلے آپ کو durability ملتی ہے: volume اس host کے ختم ہونے کے بعد بھی موجود رہتا ہے جس سے وہ منسلک ہے، اور اس کا 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 ڈیوائس کے لیے 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 ایک عام documented ceiling ہے۔

Latency اسی فرق کو اس unit میں ظاہر کرتی ہے جو users محسوس کرتے ہیں۔ p99 read latency، یعنی requests کے سست ترین 1 فیصد کا وقت، local NVMe پر تقریباً 0.4 ms اور SATA پر 1.2 ms ہوتا ہے۔ اگر path میں network شامل ہو تو یہ 6.5 ms ہو جاتا ہے، جو NVMe کے figure سے دس گنا سے بھی زیادہ ہے۔

Sequential reads میں فرق سب سے زیادہ ہوتا ہے، لیکن یہ سب سے کم مفید پیمانہ ہے: 3,400 MB/s کے مقابلے میں 550 MB/s۔ Server پر تقریباً کوئی بھی کام ایک بڑی file کو ابتدا سے انتہا تک پوری رفتار سے نہیں پڑھتا۔ Random column اور latency column اس عمل کو بیان کرتے ہیں جو database، mail queue یا package manager حقیقت میں انجام دیتا ہے۔

ڈسک کو محسوس کرنے والے ورک لوڈز

ایک اصول ان سب کی وضاحت کرتا ہے: ورک لوڈ ڈسک کو صرف اس وقت محسوس کرتا ہے جب وہ ڈسک کا انتظار کرتا ہے۔ Linux حال ہی میں استعمال ہونے والے فائل ڈیٹا کو RAM میں page cache کے اندر رکھتا ہے، اس لیے فائل کی دوسری read کبھی storage تک نہیں پہنچتی۔ اگر working set، یعنی زیرِ استعمال اصل ڈیٹا، RAM میں سما جائے تو پہلی بار کے بعد reads، memory reads بن جاتی ہیں۔ writes مختلف ہوتی ہیں۔ application جس بھی write کو fsync() کے ذریعے flush کرتی ہے، application کے آگے بڑھنے سے پہلے وہ stable storage پر موجود ہونی چاہیے۔

وہ کام جن میں commit ہوتا ہے۔ PostgreSQL، MySQL اور SQLite، commit کے وقت fsync() یا fdatasync() کو call کرتے ہیں، اور ہر commit device کے جواب کا انتظار کرتا ہے۔ اس لیے ایک connection کی commit rate bandwidth کے بجائے write latency سے متعین ہوتی ہے۔ جو device 0.2 ms میں flush مکمل کرتا ہے، وہ اس device کے مقابلے میں فی سیکنڈ کہیں زیادہ commits کی اجازت دیتا ہے جو 5 ms لیتا ہے، اور 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 استعمال ہوتی ہیں۔ ہر file میں metadata operations شامل ہوتے ہیں، جو ایک بڑی sequential read میں نہیں ہوتے۔ npm install، git clone کسی بڑے repository کے، container images کو unpack کرنا، Maildir mail store، اور بڑے tree پر چلنے والا backup، سب اپنا وقت چھوٹی random access پر صرف کرتے ہیں۔ ایک VPS پر restic backup job ہر اس file کو read اور hash کرتا ہے جسے اس نے پہلے نہیں دیکھا، اس لیے دس لاکھ files کے backup کا wall-clock time random read latency کے ساتھ قریب سے وابستہ ہوتا ہے۔ یہی بات du -sh پر بھی لاگو ہوتی ہے، جو صرف metadata read کرتا ہے۔

وہ databases بھی اسی زمرے میں آتے ہیں جو RAM سے بڑے ہو جائیں۔ جب index page cache میں نہیں سما پاتا تو ہر lookup ایک random read بن جاتا ہے، اور ڈسک دوبارہ critical path میں آ جاتی ہے۔

کون سے ورک لوڈز ڈسک کی کارکردگی سے متاثر نہیں ہوتے

بلاگ یا چھوٹی کمپنی کی ویب سائٹ۔ صفحات چھوٹے ہوتے ہیں، اور پہلی درخواست کے بعد page cache ان سب کو محفوظ کر لیتا ہے۔ اس کے بعد حد rendering کے لیے CPU یا assets کے لیے bandwidth ہوتی ہے۔ کم ٹریفک والی سائٹ پیش کرنے والا Ubuntu 24.04 پر LAMP stack گرم ہونے کے بعد تقریباً کوئی 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 مقرر کرتے ہیں۔

ہر وہ کام جو کسی بیرونی سروس کا منتظر ہو۔ جو worker ہر job پر HTTP request کے لیے 800 ms صرف کرتا ہے، وہ بہتر disk کے ساتھ زیادہ تیزی سے کام نہیں کرے گا۔

ہائپر وائزر اتنا ہی اہم کیوں ہے جتنا اسٹوریج میڈیا

آپ براہِ راست ڈیوائس سے رابطہ نہیں کرتے۔ آپ ایک ورچوئل ڈسک سے رابطہ کرتے ہیں جسے ہائپر وائزر عموماً virtio کے ذریعے پیش کرتا ہے، اور اس تہہ کے کئی فیصلے NVMe اور SATA کے فرق سے زیادہ اہم ہوتے ہیں۔

آپ guest کے اندر سے اسٹوریج میڈیا نہیں دیکھ سکتے۔ lsblk -d -o NAME,ROTA,SIZE,MODEL، خالی model کے ساتھ vda دکھاتا ہے، کیونکہ virtio ڈرائیو کی شناخت آگے منتقل نہیں کرتا۔ cat /sys/block/vda/queue/rotational وہ معلومات رپورٹ کرتا ہے جو ہائپر وائزر فراہم کرتا ہے، اس لیے وہاں 0 ہونا flash ہونے کا ثبوت نہیں ہے۔ nvme list، جو nvme-cli package کا حصہ ہے، زیادہ تر VPS پر کچھ بھی ظاہر نہیں کرتا، چاہے host میں NVMe drives لگی ہوں، کیونکہ آپ کی disk ایک virtio device ہے، NVMe device نہیں۔ جس plan میں NVMe لکھا ہو، وہ عموماً host میں موجود hardware کی وضاحت کرتا ہے۔ آپ کا volume پھر بھی network attached ہو سکتا ہے۔

Host کا cache mode، اسٹوریج میڈیا کے مقابلے میں اعداد کو زیادہ بدل دیتا ہے۔ Host پر writeback caching فعال ہو تو guest کا fsync() اسی وقت واپس آ سکتا ہے جب host نے data اپنی RAM میں رکھ لیا ہو۔ اس سے ایسا benchmark result حاصل ہوتا ہے جو کوئی physical device فراہم نہیں کر سکتی۔ اس کا مطلب یہ بھی ہے کہ host crash ہونے پر وہ writes ضائع ہو سکتی ہیں جنہیں آپ کا database محفوظ سمجھتا ہے۔ none cache mode میں اعداد کم اور حقیقت کے زیادہ قریب ہوتے ہیں۔

Limits اور burst credits۔ بہت سے providers ہر volume یا plan کے لیے IOPS محدود کرتے ہیں، اور بہت سے network volumes burst allowance استعمال کرتے ہیں۔ Burst allowance credits کا ایک ذخیرہ ہوتا ہے۔ Volume، credits باقی رہنے تک تیزی سے چلتا ہے، پھر بہت کم baseline پر آ جاتا ہے۔ اس کی علامت آسانی سے پہچانی جا سکتی ہے۔ Import یا restore کئی منٹ تک تیزی سے چلتا ہے، پھر اچانک بہت سست ہو جاتا ہے اور سست ہی رہتا ہے، حالانکہ آپ کی configuration میں کچھ تبدیل نہیں ہوا۔ آپ کے credits ختم ہو گئے۔

پڑوسی workloads۔ Shared host پر آپ کی disk latency، دوسرے guests کی سرگرمی کے مطابق بدلتی رہتی ہے۔ اسی لیے ایک سے زیادہ مرتبہ پیمائش کرنا ضروری ہے۔ ایک ہی test صبح چلائیں، پھر شام کو دوبارہ چلائیں، اور دونوں نتائج کے فرق کا موازنہ کریں۔ مصروف host پر ایک ہی volume کے دو runs کا فرق اکثر دو مختلف میڈیا کے شائع شدہ فرق سے بھی زیادہ ہوتا ہے۔

آپ کے VPS میں موجود اصل ڈسک کی پیمائش کیسے کریں

معیاری IO بینچ مارک fio انسٹال کریں اور پیمائش کریں۔ پہلے 3 احتیاطیں ضروری ہیں۔ یہ ٹیسٹ ایک فائل بناتا ہے، اس لیے ڈسک کی جگہ استعمال ہوتی ہے اور آپ کے بل میں شامل کسی بھی IOPS allowance کے خلاف شمار ہوتی ہے۔ رنز مختصر رکھیں۔ جس volume پر live traffic چل رہا ہو، اس کے خلاف اسے 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 کو bypass کرتا ہے، اس لیے نتیجہ آپ کی RAM کے بجائے device کی کارکردگی بیان کرتا ہے۔ اسے چھوڑنے پر آپ memory کی پیمائش کریں گے، جو ایسی قدر واپس کرتی ہے جس تک کوئی disk نہیں پہنچ سکتی۔ اگر جگہ موجود ہو تو --size=4G یا اس سے بڑی قدر استعمال کریں، کیونکہ 1G فائل مکمل طور پر host کے cache میں رہ سکتی ہے اور نتیجہ مصنوعی طور پر بہتر دکھا سکتی ہے۔

queue depth 1 خام latency دکھاتا ہے، جو single-threaded process کو محسوس ہوتی ہے:

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() کال کرتا ہے، اس لیے رپورٹ کی گئی 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

اس رن سے حاصل ہونے والا IOPS figure تقریباً اتنی چھوٹی transactions فی سیکنڈ کی زیادہ سے زیادہ تعداد کے برابر ہے جسے ایک database connection commit کر سکتا ہے، کیونکہ 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 اور مصروف ہے۔

نتیجہ کیسے پڑھیں

July 2026 تک، چھوٹے VPS کے لیے یہ نتائج قابلِ قبول ہیں۔ queue depth 32 پر 4k کے random read IOPS کی تعداد دسیوں ہزار ہو، اور queue depth 1 پر latency تقریباً 0.3 ms سے کم ہو، تو یہ local flash کے مطابق ہے۔ queue depth 1 پر کئی milliseconds کی latency کا مطلب network path ہے، چاہے plan کا نام کچھ بھی ہو۔ Sequential reads اگر تقریباً 550 MB/s پر رک جائیں تو یہ SATA link کی علامت ہے۔ اگر کوئی number کسی ایک device کی ممکنہ کارکردگی سے بہت زیادہ ہو، تو path میں caching موجود ہے، اور تقریباً ہمیشہ یہ host پر ہوتی ہے۔

یہ دیکھنے کے لیے کہ آپ کا live workload disk پر کیا اثر ڈال رہا ہے:

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

iostat -x کے output میں r_await اور w_await پڑھیں۔ یہ وہ اوسط milliseconds ہیں جن تک request نے انتظار کیا۔ aqu-sz اوسط queue length ہے۔ Virtual disk پر %util کو نظرانداز کریں۔ یہ اس وقت کا تناسب بتاتا ہے جب کم از کم ایک request زیرِ التوا تھی۔ اس سے ایسے device پر saturation کے بارے میں کچھ معلوم نہیں ہوتا جو بیک وقت بہت سی requests پوری کرتا ہے۔ اس لیے %util کا 100 ہونا، اور r_await کا 0.2 ms ہونا، ایک مصروف مگر صحت مند disk کی علامت ہے۔ vmstat میں wa column CPU time کے اس percentage کو دکھاتا ہے جو IO کے انتظار میں صرف ہوا۔ اگر آپ کے kernel میں /proc/pressure/io موجود ہو، تو اس کی some avg10= value گزشتہ 10 seconds میں اس حصے کو دکھاتی ہے جس دوران کم از کم ایک task IO پر stalled تھا۔ یہ اس سوال کا storage bottleneck ہونے یا نہ ہونے کے بارے میں سب سے براہِ راست جواب ہے۔

ڈسک سے محدود VPS کی صورتِ حال

زیادہ load average، idle CPU، اور vmstat میں بڑا wa اس بات کی نشاندہی کرتے ہیں کہ عمل ڈسک کے پیچھے قطار میں ہیں۔ کرنل کا سب سے واضح اشارہ dmesg -T میں موجود یہ پیغام ہے:

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

یہ سطر اس لیے ظاہر ہوتی ہے کہ ایک kernel thread نے storage کے جواب کا انتظار دو منٹ سے زیادہ کیا، اس لیے hung task watchdog نے اسے لاگ کیا۔ jbd2 ext4 کا journal thread ہے۔ اس کا مطلب ہے کہ پورا filesystem انتظار کر رہا تھا، نہ کہ صرف کوئی ایک نامناسب طریقے سے چلنے والا پروگرام۔ VPS میں یہ عموماً storage backend یا ختم ہو چکے IOPS allowance کی طرف اشارہ کرتا ہے۔

Application کی علامات بھی اسی صورتِ حال کی پیروی کرتی ہیں۔ درمیانی response time قابلِ قبول رہتا ہے، جبکہ سب سے سست requests میں طویل tail پیدا ہو جاتی ہے، کیونکہ صرف وہی requests ڈسک تک پہنچنے کی قیمت ادا کرتی ہیں۔ apt upgrade کئی منٹ تک Unpacking پر رہتا ہے، کیونکہ dpkg لکھتے وقت flush کرتا ہے۔ بڑے repository میں git status کو مکمل ہونے میں کئی seconds لگتے ہیں۔ یہ metadata اور flush کے اخراجات ہیں، اس لیے زیادہ bandwidth سے مسئلہ حل نہیں ہوگا۔

جب ڈسک حد بن جائے تو کیا کریں

IOPS خریدنے سے پہلے RAM خریدیں۔ اگر working set page cache میں سما جائے تو read operations ڈسک تک پہنچتے ہی نہیں۔ میموری کو دوگنا کرنا اکثر تیز تر storage class پر منتقل ہونے سے زیادہ مؤثر ہوتا ہے، اور عموماً اس کی لاگت بھی کم ہوتی ہے۔

جہاں ڈیٹا اجازت دے، flush operations کی تعداد کم کریں۔ PostgreSQL میں synchronous_commit = off کے ذریعے commit ڈسک پر write مکمل ہونے سے پہلے واپس آ سکتا ہے۔ اگر server بند ہو جائے تو آپ آخری fraction of a second کی transactions کھو سکتے ہیں۔ database corrupt نہیں ہوتا، کیونکہ write-ahead log اب بھی ترتیب کے ساتھ لکھا جاتا ہے۔ یہ سمجھوتا analytics copy کے لیے موزوں ہے، مگر payments کے لیے نہیں۔ MySQL میں innodb_flush_log_at_trx_commit = 2 بھی یہی سمجھوتا ہے۔

چھوٹی files کو batch کریں۔ ایک million چھوٹی files کی transfer یا backup میں فی file لاگت غالب ہوتی ہے۔ اس لیے پہلے archive بنانا اور ایک stream منتقل کرنا، high-latency storage پر tree کو file بہ file copy کرنے سے زیادہ تیز ہوتا ہے۔

Thin volumes پر discard کو فعال رکھیں۔ Thin provisioned storage میں backend کو اس وقت تک معلوم نہیں ہوتا کہ کوئی block خالی ہے جب تک filesystem اسے نہ بتائے۔ جو volume کبھی trim نہیں ہوتا، اس کی write performance آہستہ آہستہ کم ہو جاتی ہے۔ Ubuntu اس مقصد کے لیے weekly timer فراہم کرتا ہے:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av ہر mount point کے لیے trim کیے گئے bytes دکھاتا ہے۔ اگر پیغام آئے کہ discard operation supported نہیں ہے، تو اس کا مطلب ہے کہ 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 سے پہلے ہی بچاتا ہے۔

منصوبے کا انتخاب

NVMe کے لیے اس وقت ادائیگی کریں جب سرور پر database، mail server، CI runner یا packages پر مبنی build چل رہی ہو۔ 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 سے لیس host پر network storage ہے۔ یہ فروخت کرنے کے لیے ایک مناسب چیز ہے، مگر خریدنے کے لیے ایک مختلف چیز ہے۔

FAQ

کیا VPS پر NVMe ہمیشہ SATA SSD سے تیز ہوتا ہے؟

نہیں۔ queue depth 1 پر دونوں کی کارکردگی قریب قریب ہوتی ہے؛ 4k read کے لیے تاخیر عموماً 80 سے 150 microseconds ہوتی ہے، اور single-threaded پروگرام دونوں میں فرق محسوس نہیں کر سکتا۔ NVMe اس وقت آگے نکلتا ہے جب بہت سی requests زیرِ تکمیل ہوں، کیونکہ AHCI میں 32 commands گہری ایک queue ہوتی ہے، جبکہ NVMe میں زیادہ گہری ہزاروں queues ہوتی ہیں۔ shared host پر دوسرے guests کا load آپ کی latency کو storage medium سے زیادہ بدل سکتا ہے۔ اس لیے plan name دیکھنے کے بجائے اپنے volume کو fio سے ناپیں۔

میں کیسے جانچوں کہ میرا VPS واقعی NVMe استعمال کرتا ہے؟

آپ اسے براہِ راست نہیں جانچ سکتے، کیونکہ virtio physical device کو چھپا دیتا ہے۔ lsblk، vda کو model string کے بغیر دکھاتا ہے، nvme list کچھ واپس نہیں کرتا، اور /sys/block/vda/queue/rotational صرف وہی رپورٹ کرتا ہے جو hypervisor ظاہر کرتا ہے۔ اس کے بجائے کارکردگی ناپیں۔ queue depth 1 پر random 4k read کی latency تقریباً 0.3 ms سے کم ہو تو اس کا مطلب local flash ہے۔ کئی milliseconds کی latency کا مطلب ہے کہ راستے میں 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 سے محدود ہوتی ہے۔ اگر site ہر request پر write کرے تو 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 عموماً چند ہزار IOPS فراہم کرتا ہے، جس کی latency چند milliseconds ہوتی ہے۔ test کو مختلف اوقات میں تین بار چلائیں۔ runs کے درمیان وسیع فرق average سے زیادہ معلومات فراہم کرتا ہے، کیونکہ اس سے ظاہر ہوتا ہے کہ host پر موجود دوسرے guests آپ کو کس حد تک متاثر کرتے ہیں۔

کیا مجھے اپنا database network block storage پر رکھنا چاہیے؟

آپ ایسا کر سکتے ہیں، اور بہت سی managed services ایسا کرتی ہیں، لیکن commit path کی اس کی قیمت ادا کرنا پڑتی ہے۔ ہر flush network سے گزرتا ہے، اس لیے single connection پر مقامی flash کے مقابلے میں فی second کم چھوٹی transactions commit ہوتی ہیں۔ اس کے بدلے آپ کو ایسی durability ملتی ہے جو host کے ناکام ہونے کے بعد بھی برقرار رہتی ہے۔ اگر آپ write-heavy database کے لیے network storage منتخب کریں تو کام کو بڑی transactions میں جمع کریں، تاکہ کم flushes میں زیادہ rows شامل ہوں۔