VPS-এ NVMe বনাম SSD: পার্থক্য কি সত্যিই গুরুত্বপূর্ণ?

VPS-এ NVMe কি গুরুত্বপূর্ণ?

আপনার সফটওয়্যার যখন অনেক ছোট আকারের read ও write পাঠায় এবং প্রতিটির শেষ হওয়ার জন্য অপেক্ষা করে, তখন VPS-এ NVMe গুরুত্বপূর্ণ। Cached page সরবরাহ করা সাইটের ক্ষেত্রে, অথবা যে প্রোগ্রামটি network-এর জন্য অপেক্ষা করেই বেশি সময় কাটায়, সেখানে এর প্রভাব খুব কম। Storage medium কেবল একটি কারণ। Disk-এর সামনে থাকা hypervisor এবং একই host ভাগ করে নেওয়া অন্যান্য guest আপনার বাস্তবে পাওয়া সর্বোচ্চ কর্মক্ষমতা নির্ধারণ করে।

NVMe কী পরিবর্তন করে এবং কী পরিবর্তন করে না

NVMe (non-volatile memory express) কোনো ধরনের flash memory নয়। এটি flash-এ পৌঁছানোর protocol এবং connection। একটি NVMe device PCIe (peripheral component interconnect express) lane-এর ওপর সংযুক্ত থাকে এবং NVMe protocol ব্যবহার করে। একটি SATA (serial ATA) SSD SATA link-এর ওপর সংযুক্ত থাকে এবং AHCI (advanced host controller interface) ব্যবহার করে। আপনার byte ধরে রাখা memory chip উভয় ক্ষেত্রেই একই হতে পারে।

দুটি বিষয় ভিন্ন, এবং দুটিই storage নিজে নয়, বরং command path সম্পর্কিত।

Queue। AHCI kernel-কে একটি command queue দেয়, যাতে 32টি command রাখা যায়। NVMe হাজারো queue সমর্থন করে। বাস্তবে প্রতি CPU core-এর জন্য একটি করে queue থাকে, এবং প্রতিটি queue-এর গভীরতা 32-এর চেয়ে অনেক বেশি। একটি process একবারে একটি block পড়লে এই পার্থক্য বোঝা যায় না। কিন্তু 64টি read একসঙ্গে pending থাকা একটি database এই পার্থক্য বুঝতে পারে: SATA-তে 33তম request device দেখার আগেই queue slot-এর জন্য অপেক্ষা করে, আর NVMe device সবগুলো গ্রহণ করে একসঙ্গে প্রক্রিয়া করে।

Link width। একটি SATA III link 6 Gbit/s গতিতে চলে। Protocol overhead বাদ দেওয়ার পর প্রকৃত data rate প্রায় 550 MB/s। এর পেছনে যে flash-ই থাকুক, এটি একটি নির্দিষ্ট সর্বোচ্চ সীমা। চারটি PCIe lane প্রতি সেকেন্ডে কয়েক gigabyte বহন করতে পারে। তাই link আর সীমাবদ্ধতা থাকে না।

Latency নিয়ে প্রত্যাশা সাধারণত ভুল হয়। Queue depth 1, অর্থাৎ একবারে একটি request চলমান থাকা অবস্থায়, একটি SATA SSD প্রায় 100 থেকে 150 microsecond-এ 4k read-এর উত্তর দেয়। NVMe প্রায় 80 থেকে 100 microsecond-এ উত্তর দেয়। দুটিই দ্রুত, এবং একটি request-এর ক্ষেত্রে আপনি চালানো কোনো কাজই এই পার্থক্য বুঝতে পারবে না। Concurrency বাড়লে পার্থক্য দেখা দেয়। Queue depth, অর্থাৎ একই সময়ে চলমান request-এর সংখ্যা, নির্ধারণ করে দুটি medium একই রকম দেখাবে, নাকি খুব আলাদা দেখাবে।

Network block storage একটি তৃতীয় শ্রেণি, যার কার্যপ্রণালি আলাদা। একটি write network-এর মাধ্যমে storage cluster-এ যায় এবং cluster সেটি সংরক্ষণ করার পরেই acknowledgment দেয়। তাই এর latency microsecond-এর বদলে millisecond-এ মাপা হয়। এই latency-এর বিনিময়ে আপনি durability পান: volume-টি যে host-এর সঙ্গে সংযুক্ত, সেই 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; একটি মাত্র AHCI queue এবং 6 Gbit/s link এই মান সীমিত করে। Network block storage সাধারণত hardware-এর পরিবর্তে provider-এর সীমা দ্বারা নিয়ন্ত্রিত হয়, এবং 12,500 একটি প্রচলিত নথিভুক্ত সর্বোচ্চ সীমা।

Latency আপনার ব্যবহারকারীরা যে এককে অনুভব করেন, সেই এককেই একই বিষয়টি বোঝায়। p99 read latency, অর্থাৎ সবচেয়ে ধীর 1 শতাংশ request-এর latency, স্থানীয় NVMe-তে প্রায় 0.4 ms এবং SATA-তে 1.2 ms। পথের মধ্যে network যুক্ত হলে এটি 6.5 ms হয়, যা NVMe-এর মানের দশ গুণেরও বেশি।

Sequential read-এ পার্থক্য সবচেয়ে বেশি, তবে এটি সবচেয়ে কম কার্যকর মাপ: 3,400 MB/s-এর বিপরীতে 550 MB/s। কোনো server-ই প্রায় কখনো একটি বড় file শুরু থেকে শেষ পর্যন্ত পূর্ণ গতিতে পড়ে না। random মান এবং latency মান একটি database, mail queue বা package manager বাস্তবে কীভাবে কাজ করে, তা বোঝায়।

কোন কাজের চাপ ডিস্কের কর্মক্ষমতা বুঝতে পারে

একটি নিয়ম সব ক্ষেত্রেই প্রযোজ্য: কোনো কাজের চাপ কেবল তখনই ডিস্কের কর্মক্ষমতা বুঝতে পারে, যখন সেটিকে ডিস্কের জন্য অপেক্ষা করতে হয়। Linux সম্প্রতি ব্যবহৃত ফাইলের ডেটা RAM-এ, page cache-এ রাখে। তাই কোনো ফাইলের দ্বিতীয়বার পড়ার সময় storage-এ আর অনুরোধ যায় না। working set, অর্থাৎ বর্তমানে ব্যবহৃত ডেটা, যদি RAM-এ ধরে যায়, তাহলে প্রথমবার পড়ার পর পরবর্তী read-গুলো memory read হয়ে যায়। Write-এর ক্ষেত্রে নিয়ম আলাদা। অ্যাপ্লিকেশন fsync() দিয়ে যে write flush করে, অ্যাপ্লিকেশনকে চালিয়ে যাওয়ার অনুমতি দেওয়ার আগে সেটি 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-এর তুলনায় অনেক বেশি commit সম্পন্ন করতে পারে। কোনো পরিমাণ throughput এই সীমাবদ্ধতা পরিবর্তন করতে পারে না। Flush কাজের চাপ সামলাতে না পারলে MySQL error log-এ তা জানায়:

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

PostgreSQL তার checkpoint lines-এ বিষয়টি জানায়। সেখানে বড় sync= মানের অর্থ হলো flush নিজেই ধীর ছিল:

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

যে কাজ অনেক ছোট ফাইল ব্যবহার করে। একটি বড় sequential read-এর তুলনায় প্রতিটি ফাইলের ক্ষেত্রে metadata operation থাকে। npm install, বড় repository-এর git clone, container image unpack করা, Maildir mail store এবং বড় tree-এর মধ্য দিয়ে চলা backup—সবকিছুই ছোট random access-এ সময় ব্যয় করে। একটি VPS-এ restic backup job আগে দেখা হয়নি এমন প্রতিটি ফাইল পড়ে এবং hash গণনা করে। তাই এক মিলিয়ন ফাইলের backup সম্পন্ন করতে wall-clock time random read latency-এর সঙ্গে ঘনিষ্ঠভাবে সম্পর্কিত। du -sh-এর ক্ষেত্রেও একই কথা প্রযোজ্য। এটি কেবল metadata পড়ে, অন্য কিছু নয়।

যে database-এর আকার RAM-এর সীমা ছাড়িয়ে যায়, সেগুলিও এই শ্রেণির অন্তর্ভুক্ত। Index page cache-এ আর ধরে না গেলে প্রতিটি lookup একটি random read হয়ে যায় এবং ডিস্ক আবার critical path-এর অংশ হয়ে দাঁড়ায়।

কোন কাজগুলোর ক্ষেত্রে ডিস্কের পারফরম্যান্সের প্রভাব বোঝা যায় না

একটি ব্লগ বা ছোট কোম্পানির সাইট। পেজগুলো ছোট। প্রথম অনুরোধের পর page cache সব পেজ ধরে রাখে। তাই সীমাবদ্ধতা থাকে rendering-এর CPU অথবা asset-এর bandwidth-এ। কম traffic-এর একটি Ubuntu 24.04-এ LAMP stack চালিত সাইট চালু হওয়ার পর প্রায় কোনো disk IO করে না।

Media streaming। একটি 4K stream 40 Mbit/s হারে 5 MB/s পড়ে। দশটি stream 50 MB/s পড়ে। Network block storage-ও এটি অনায়াসে সরবরাহ করতে পারে। VPS-এ Jellyfin media server আপনার network egress allowance এবং transcoding-এর সময় CPU দ্বারা সীমাবদ্ধ হয়, storage medium দ্বারা নয়।

Local model inference। নিজে LLM host করতে VPS-এ Ollama চালানো model file একবার পড়ে, তারপর RAM-এ কাজ করে। NVMe একটি 20 GB model-এর load time কয়েক মিনিট থেকে কয়েক সেকেন্ডে কমিয়ে দেয়। তবে এটি প্রতি সেকেন্ডে tokens-এর সংখ্যা পরিবর্তন করে না। এই গতি memory bandwidth এবং CPU দ্বারা নির্ধারিত হয়।

যে কোনো কাজ যা external service-এর জন্য অপেক্ষা করে। কোনো worker যদি প্রতি job-এ HTTP request-এর জন্য 800 ms ব্যয় করে, তাহলে উন্নত disk ব্যবহার করলেও এটি দ্রুত কাজ করবে না।

হাইপারভাইজার কেন স্টোরেজ মাধ্যমের মতোই গুরুত্বপূর্ণ

আপনি সরাসরি ডিভাইসের সঙ্গে যোগাযোগ করেন না। আপনি হাইপারভাইজার উপস্থাপিত একটি ভার্চুয়াল ডিস্কের সঙ্গে যোগাযোগ করেন, সাধারণত virtio-এর মাধ্যমে। এই স্তরের কয়েকটি সিদ্ধান্ত NVMe ও SATA-এর পার্থক্যের চেয়েও বেশি গুরুত্বপূর্ণ।

গেস্টের ভেতর থেকে স্টোরেজ মাধ্যম দেখা যায় না। lsblk -d -o NAME,ROTA,SIZE,MODEL, খালি মডেলসহ vda দেখায়, কারণ virtio ড্রাইভের পরিচয় গেস্টে পাঠায় না। cat /sys/block/vda/queue/rotational হাইপারভাইজার যে তথ্য প্রকাশ করে তা জানায়। তাই সেখানে 0 দেখা গেলে সেটি flash থাকার প্রমাণ নয়। nvme-cli package-এর nvme list অধিকাংশ VPS-এ কিছুই দেখায় না, host-এ NVMe drive থাকলেও। কারণ আপনার disk হলো virtio device, NVMe device নয়। কোনো plan-এ NVMe লেখা থাকলে সাধারণত host-এ কী আছে তা বোঝানো হয়। আপনার volume এখনও network attached হতে পারে।

Host cache mode স্টোরেজ মাধ্যমের চেয়েও বেশি পরিমাণে ফলাফল বদলে দেয়। Host-এ writeback caching চালু থাকলে, গেস্টের fsync() host-এর নিজস্ব RAM-এ data পৌঁছানোর সঙ্গে সঙ্গেই সফলভাবে শেষ হতে পারে। এতে এমন benchmark ফলাফল পাওয়া যায়, যা কোনো physical device দিতে পারে না। এর অর্থ হলো host crash হলে আপনার database যে write-গুলো নিরাপদ মনে করছে, সেগুলো হারিয়ে যেতে পারে। none cache mode ব্যবহার করলে ফলাফল কম হবে এবং বাস্তব পরিস্থিতি দেখাবে।

সীমা এবং burst credit। অনেক provider প্রতি volume বা plan অনুযায়ী IOPS সীমাবদ্ধ করে। অনেক network volume burst allowance ব্যবহার করে। Burst allowance হলো credit-এর একটি সঞ্চয়। Credit থাকা পর্যন্ত volume দ্রুত চলে। এরপর এটি অনেক কম baseline গতিতে নেমে যায়। লক্ষণটি সহজে চেনা যায়। Import বা restore কয়েক মিনিট দ্রুত চলে, তারপর হঠাৎ ধীর হয়ে যায় এবং ধীরই থাকে, configuration-এ কোনো পরিবর্তন না করলেও। আপনি credit ব্যবহার করে ফেলেছেন।

প্রতিবেশী workload। Shared host-এ অন্য guest-রা কী করছে তার ওপর আপনার disk latency পরিবর্তিত হয়। এ কারণেই একাধিকবার মাপা দরকার। একই test সকালে একবার এবং সন্ধ্যায় আবার চালান। এরপর ফলাফলের পার্থক্য তুলনা করুন। ব্যস্ত host-এ একই volume-এ দুটি run-এর পার্থক্য প্রায়ই দুটি storage medium-এর প্রকাশিত পার্থক্যের চেয়েও বেশি হয়।

আপনার VPS-এ আসলে থাকা ডিস্ক কীভাবে পরিমাপ করবেন

স্ট্যান্ডার্ড IO বেঞ্চমার্ক fio ইনস্টল করে পরিমাপ করুন। প্রথমে তিনটি সতর্কতা মনে রাখুন। পরীক্ষা একটি ফাইল তৈরি করে, তাই এটি ডিস্কের স্থান ব্যবহার করে এবং আপনার বিলিংয়ে থাকা যেকোনো IOPS সীমার হিসাবে গণনা হয়। রানগুলো সংক্ষিপ্ত রাখুন। লাইভ ট্র্যাফিক পরিবেশন করছে এমন ভলিউমে পূর্ণ queue depth ব্যবহার করে এটি চালাবেন না, কারণ এতে আপনার নিজের অ্যাপ্লিকেশনের সঙ্গে প্রতিযোগিতা হবে।

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

queue depth 32-এ random read করুন। বিক্রেতারা সাধারণত এই 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-এর পরিবর্তে ডিভাইসের কার্যক্ষমতা বর্ণনা করে। এটি বাদ দিলে আপনি মেমরি পরিমাপ করবেন, যা এমন একটি সংখ্যা ফেরত দেয় যা কোনো ডিস্ক অর্জন করতে পারে না। স্থান থাকলে --size=4G বা তার চেয়ে বড় মান ব্যবহার করুন, কারণ একটি 1G ফাইল সম্পূর্ণভাবে host-এর cache-এ থাকতে পারে এবং ফলাফলকে কৃত্রিমভাবে ভালো দেখাতে পারে।

queue depth 1 কাঁচা latency দেখায়। একক-থ্রেডের প্রক্রিয়া যে latency অনুভব করে, এটি সেটিই:

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

commit পরীক্ষা database-এর আচরণ পূর্বাভাস দেয়। এটি 4k লেখে এবং প্রতিটি লেখার পরে 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 সংখ্যা প্রতি সেকেন্ডে একটি database connection যে ছোট transaction-এর সর্বোচ্চ সংখ্যাটি commit করতে পারে, তার কাছাকাছি। কারণ commit একই flush সম্পন্ন হওয়ার জন্য অপেক্ষা করে।

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, average-এর মতোই গুরুত্বপূর্ণ। নিষ্ক্রিয় server-এ বড় deviation থাকলে বোঝা যায় storage backend shared এবং ব্যস্ত।

ফলাফল কীভাবে পড়বেন

July 2026 অনুযায়ী, ছোট VPS-এর জন্য এগুলো যুক্তিসংগত ব্যাখ্যা। queue depth 32-এ কয়েক দশ হাজার 4k random read IOPS এবং queue depth 1-এ প্রায় 0.3 ms-এর কম latency local flash-এর সঙ্গে সামঞ্জস্যপূর্ণ। queue depth 1-এ কয়েক মিলিসেকেন্ড latency থাকলে, plan-এর নাম যা-ই হোক, সেটি network path নির্দেশ করে। প্রায় 550 MB/s-এ থেমে যাওয়া sequential read 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 অপেক্ষা করার গড় সময়, মিলিসেকেন্ডে। aqu-sz হলো গড় queue length। virtual disk-এ %util উপেক্ষা করুন। এটি জানায়, অন্তত একটি request outstanding থাকা অবস্থায় মোট সময়ের কত অংশ কেটেছে। একসঙ্গে অনেক request পরিবেশন করতে পারে এমন device-এ এটি saturation সম্পর্কে কিছু জানায় না। তাই 100-এর মধ্যে %util এবং 0.2 ms-এর r_await থাকলে disk ব্যস্ত হলেও সেটি সুস্থ অবস্থায় আছে। vmstat-এ wa column হলো IO-এর জন্য অপেক্ষায় CPU time-এর শতাংশ। আপনার kernel-এ /proc/pressure/io থাকলে, এর some avg10= value হলো শেষ 10 সেকেন্ডের কত অংশে অন্তত একটি task IO-তে stalled ছিল। Storage আপনার bottleneck কি না, এর সবচেয়ে সরাসরি উত্তর এটি দেয়।

ডিস্ক-নির্ভর VPS কেমন দেখায়

CPU idle থাকা অবস্থায় load average বেশি এবং wa-এ বড় vmstat থাকার অর্থ হলো প্রসেসগুলো ডিস্কের পিছনে সারিবদ্ধ হয়ে অপেক্ষা করছে। কার্নেলের সবচেয়ে স্পষ্ট সংকেত হলো dmesg -T-এ থাকা এই বার্তাটি:

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

এই লাইনটি দেখা যায় কারণ কোনো কার্নেল থ্রেড স্টোরেজের উত্তরের জন্য 2 মিনিটের বেশি অপেক্ষা করেছে। তাই hung task watchdog এটি লগ করেছে। jbd2 হলো ext4 journal থ্রেড। এর অর্থ, শুধু কোনো একটি ত্রুটিপূর্ণ প্রোগ্রাম নয়, পুরো filesystem অপেক্ষা করছিল। VPS-এ এটি সাধারণত storage backend বা শেষ হয়ে যাওয়া IOPS বরাদ্দের দিকে ইঙ্গিত করে।

অ্যাপ্লিকেশনের লক্ষণগুলোও একই ধরন অনুসরণ করে। Median response time গ্রহণযোগ্য থাকে, কিন্তু সবচেয়ে ধীর request-গুলোর সময় দীর্ঘ tail তৈরি করে। কারণ শুধু ডিস্কে পৌঁছানো request-গুলোই এই বিলম্বের শিকার হয়। apt upgrade কয়েক মিনিট ধরে Unpacking অবস্থায় থাকে, কারণ লেখার সময় dpkg flush করে। বড় repository-তে git status সম্পন্ন হতে কয়েক সেকেন্ড লাগে। এগুলো metadata এবং flush-এর খরচ। তাই বেশি bandwidth এতে সাহায্য করবে না।

ডিস্ক সীমাবদ্ধতা হয়ে দাঁড়ালে কী করবেন

IOPS কেনার আগে RAM কিনুন। Working set যদি page cache-এ ধরে, তাহলে read আর ডিস্কে পৌঁছায় না। Memory দ্বিগুণ করা প্রায়ই দ্রুততর storage class-এ যাওয়ার চেয়ে বেশি কার্যকর হয় এবং সাধারণত খরচও কম।

যেখানে ডেটা তা অনুমোদন করে, সেখানে flush-এর সংখ্যা কমান। PostgreSQL-এ synchronous_commit = off ব্যবহার করলে write ডিস্কে যাওয়ার আগেই commit return করতে পারে। Server বন্ধ হয়ে গেলে শেষ fraction-of-a-second-এর transaction হারাতে পারেন। Database corrupted হয় না, কারণ write-ahead log এখনও ক্রম অনুযায়ী লেখা হয়। এই trade analytics copy-এর জন্য উপযুক্ত, কিন্তু payments-এর জন্য নয়। MySQL-এর innodb_flush_log_at_trx_commit = 2 একই trade।

ছোট file একত্রে batch করুন। এক million ছোট file transfer বা backup করার সময় প্রতি-file cost-ই প্রধান হয়ে দাঁড়ায়। তাই আগে archive করে একটি stream সরানো, high-latency storage-এ tree-এর প্রতিটি file আলাদাভাবে copy করার চেয়ে দ্রুত।

Thin volume-এ discard চালু রাখুন। Thin provisioned storage-এ filesystem তা না জানানো পর্যন্ত backend বুঝতে পারে না যে কোনো block free হয়েছে। Trim না করা volume ধীরে ধীরে write performance হারায়। Ubuntu এ জন্য একটি weekly timer সরবরাহ করে:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av প্রতিটি mount point-এ trim করা bytes-এর পরিমাণ দেখায়। Discard operation supported নয়—এমন message-এর অর্থ virtual disk discard host-এ pass through করে না। তাই আপনার ঠিক করার মতো কিছু নেই।

IO scheduler tuning বাদ দিন। virtio disk-এ cat /sys/block/vda/queue/scheduler সাধারণত ইতিমধ্যেই none দেখায়। প্রকৃত scheduling host-এ হয়, যেখানে আপনার access নেই। noatime-ও বাদ দিন। Ubuntu default হিসেবে relatime দিয়ে mount করে, যা প্রায় সব atime write আগেই এড়িয়ে যায়।

একটি প্ল্যান নির্বাচন

কোনো database, mail server, CI runner বা package-heavy build সার্ভারে চললে NVMe-এর জন্য অর্থ দিন। cached website বা যেসব app-এর সময় external call-এ ব্যয় হয়, সেগুলোর জন্য অতিরিক্ত মূল্য দেবেন না। নিশ্চিত না হলে ধরে নিতে পারেন, disk আপনার সীমাবদ্ধতা নয়। কারণ বেশিরভাগ ছোট VPS workload-এ আগে RAM বা bandwidth শেষ হয়ে যায়।

প্রথম দিনেই মাপ নিন, যখন আপনি নতুন VPS-এ প্রথম দশ মিনিটের কাজ সম্পন্ন করছেন, এবং output একটি file-এ সংরক্ষণ করুন। পরে host ধীর হয়েছে, নাকি আপনার code-এর সমস্যা—তা প্রমাণ করার জন্য baseline প্রয়োজন। যেসব provider 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 program পার্থক্য বুঝতে পারে না। অনেক request একসঙ্গে চললে NVMe এগিয়ে যায়। কারণ AHCI-তে 32 commands গভীরতার একটি queue থাকে, আর NVMe-তে আরও গভীরতার হাজারো queue থাকে। একটি shared host-এ অন্য guest-দের load storage medium-এর চেয়ে latency-তে বেশি পরিবর্তন আনতে পারে। তাই plan-এর নাম দেখে সিদ্ধান্ত না নিয়ে fio দিয়ে আপনার নিজের volume মাপুন।

আমার VPS সত্যিই NVMe ব্যবহার করছে কি না কীভাবে পরীক্ষা করব?

আপনি এটি সরাসরি পরীক্ষা করতে পারবেন না। কারণ virtio physical device-এর তথ্য আড়াল করে। lsblk কোনো model string ছাড়া vda দেখায়। nvme list কিছু ফেরত দেয় না। /sys/block/vda/queue/rotational শুধু hypervisor যে তথ্য প্রকাশ করে তা জানায়। তাই আচরণ মাপুন। queue depth 1-এ random 4k read-এর latency প্রায় 0.3 ms-এর কম হলে সেটি local flash নির্দেশ করে। কয়েক milliseconds হলে path-এ একটি network hop আছে। Sequential read প্রায় 550 MB/s-এ থেমে গেলে SATA link থাকার সম্ভাবনা বেশি।

NVMe কি আমার website দ্রুত load করাবে?

সাধারণত না। প্রথম request-এর পর Linux file-গুলো RAM-এর page cache থেকে সরবরাহ করে। তাই disk আর সক্রিয় থাকে না। ছোট 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। ভিন্ন সময়ে তিনবার পরীক্ষা চালান। পরীক্ষাগুলোর ফলাফলের মধ্যে বড় পার্থক্য থাকলে average-এর চেয়ে সেটিই বেশি তথ্য দেয়। কারণ এতে বোঝা যায় host-এর অন্য guest-রা আপনার ওপর কতটা প্রভাব ফেলছে।

আমার database কি network block storage-এ রাখা উচিত?

আপনি রাখতে পারেন। অনেক managed service-ও তা করে। তবে এতে commit path-এর জন্য অতিরিক্ত সময় লাগে। প্রতিটি flush network-এর মধ্য দিয়ে যায়। তাই local flash-এর তুলনায় একটি single connection প্রতি সেকেন্ডে কম small transaction commit করতে পারে। এর বিনিময়ে আপনি এমন durability পান যা host নষ্ট হলেও টিকে থাকে। Write-heavy database-এর জন্য network storage বেছে নিলে কাজগুলো বড় transaction-এ একত্র করুন। এতে কম flush-এ বেশি row লেখা যায়।