آیا NVMe برای VPS واقعاً بهتر از SSD است؟

آیا NVMe در یک VPS اهمیت دارد؟

NVMe در یک VPS زمانی اهمیت دارد که نرم‌افزار شما خواندن‌ها و نوشتن‌های کوچک و زیادی ارسال کند و برای تکمیل هرکدام منتظر بماند. برای سایتی که صفحات ذخیره‌شده در cache را ارائه می‌کند، یا برنامه‌ای که زمان خود را در انتظار شبکه می‌گذراند، تفاوت بسیار کمی ایجاد می‌کند. نوع رسانه ذخیره‌سازی تنها یکی از عوامل است. hypervisor قرارگرفته در برابر دیسک و guestهای دیگری که همان host را به‌طور مشترک استفاده می‌کنند، سقف عملکردی را که در عمل دریافت می‌کنید تعیین می‌کنند.

NVMe چه چیزی را تغییر می‌دهد و چه چیزی را تغییر نمی‌دهد

NVMe (non-volatile memory express) نوعی حافظه فلش نیست. NVMe پروتکل و اتصالی است که برای دسترسی به فلش استفاده می‌شود. یک دستگاه NVMe روی مسیرهای PCIe (peripheral component interconnect express) قرار دارد و با NVMe ارتباط برقرار می‌کند. یک SSD مبتنی بر SATA (serial ATA) روی پیوند SATA قرار دارد و با AHCI (advanced host controller interface) ارتباط برقرار می‌کند. تراشه‌های حافظه‌ای که بایت‌های شما را نگه می‌دارند، در هر دو نوع دستگاه می‌توانند یکسان باشند.

دو مورد متفاوت هستند و هر دو به مسیر فرمان مربوط می‌شوند، نه خود فضای ذخیره‌سازی.

صف‌ها. AHCI یک صف فرمان در اختیار هسته قرار می‌دهد که 32 فرمان را نگه می‌دارد. NVMe هزاران صف را امکان‌پذیر می‌کند؛ در عمل، معمولا برای هر هسته CPU یک صف وجود دارد و عمق هر صف بسیار بیشتر از 32 است. یک فرایند که هر بار یک بلوک را می‌خواند، این تفاوت را احساس نمی‌کند. اما یک پایگاه داده با 64 عملیات خواندن هم‌زمان می‌تواند آن را احساس کند: در SATA، درخواست 33ام پیش از آنکه دستگاه حتی آن را ببیند، برای دریافت یک جایگاه در صف منتظر می‌ماند؛ در حالی که دستگاه NVMe همه درخواست‌ها را می‌پذیرد و هم‌زمان روی آن‌ها کار می‌کند.

عرض پیوند. یک پیوند SATA III با سرعت 6 Gbit/s کار می‌کند که پس از کسر سربار پروتکل، معادل حدود 550 MB/s داده واقعی است. این مقدار، صرف‌نظر از نوع فلشی که پشت پیوند قرار دارد، سقف ثابتی ایجاد می‌کند. چهار مسیر PCIe چندین گیگابایت در ثانیه داده منتقل می‌کنند؛ بنابراین پیوند دیگر عامل محدودکننده نیست.

معمولا درباره تأخیر، انتظارها نادرست هستند. در عمق صف 1، یعنی زمانی که فقط یک درخواست در حال اجرا است، یک SSD مبتنی بر SATA یک عملیات خواندن 4k را در حدود 100 تا 150 میکروثانیه پاسخ می‌دهد. NVMe همین کار را در حدود 80 تا 100 میکروثانیه انجام می‌دهد. هر دو سریع هستند و هیچ برنامه‌ای که برای یک درخواست اجرا می‌کنید، این تفاوت را احساس نخواهد کرد. تفاوت در زمان هم‌زمانی آشکار می‌شود. عمق صف، یعنی تعداد درخواست‌هایی که هم‌زمان در حال اجرا هستند، مشخص می‌کند که این دو رسانه مشابه به نظر برسند یا کاملا متفاوت.

ذخیره‌سازی بلوکی شبکه‌ای، به دلیل ماهیت متفاوت خود، در رده دیگری قرار می‌گیرد. یک عملیات نوشتن از طریق شبکه به یک کلاستر ذخیره‌سازی ارسال می‌شود و فقط زمانی تأیید می‌شود که کلاستر آن را نگه داشته باشد؛ بنابراین تأخیر آن به‌جای میکروثانیه، برحسب میلی‌ثانیه اندازه‌گیری می‌شود. مزیتی که در ازای این تأخیر دریافت می‌کنید، دوام داده است: حجم ذخیره‌سازی پس از میزبان متصل به آن نیز باقی می‌ماند و می‌توان از آن 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 محلی، معمولاً مقدار 184,000 IOPS خواندن تصادفی 4k (عملیات ورودی/خروجی در ثانیه) در عمق صف 32 اعلام می‌شود. همین آزمون روی یک SATA SSD معمولاً نزدیک به 90,000 اعلام می‌شود؛ زیرا یک صف AHCI و پیوند 6 Gbit/s آن را محدود می‌کنند. ذخیره‌سازی بلوکی شبکه‌ای معمولاً به‌جای سخت‌افزار، توسط ارائه‌دهنده محدود می‌شود و 12,500 سقف مستند رایجی است.

تأخیر نیز همین تفاوت را با واحدی نشان می‌دهد که کاربران آن را احساس می‌کنند. تأخیر خواندن p99، یعنی تأخیر کندترین 1 درصد درخواست‌ها، در NVMe محلی حدود 0.4 ms و در SATA حدود 1.2 ms است. اگر شبکه در مسیر قرار بگیرد، این مقدار به 6.5 ms می‌رسد که بیش از 10 برابر مقدار NVMe است.

خواندن ترتیبی بزرگ‌ترین اختلاف را نشان می‌دهد، اما کم‌کاربردترین معیار است: 3,400 MB/s در برابر 550 MB/s. تقریباً هیچ فرایندی روی یک سرور، یک فایل بزرگ را از ابتدا تا انتها با حداکثر سرعت نمی‌خواند. ستون خواندن تصادفی و ستون تأخیر، عملکرد واقعی یک پایگاه داده، صف ایمیل یا مدیر بسته را بهتر توصیف می‌کنند.

کدام بارهای کاری متوجه دیسک می‌شوند

یک قاعده همه آن‌ها را توضیح می‌دهد: بار کاری فقط زمانی متوجه دیسک می‌شود که منتظر دیسک بماند. Linux داده‌های فایل‌هایی را که اخیراً استفاده شده‌اند در RAM و در page cache نگه می‌دارد؛ بنابراین خواندن دوم یک فایل هرگز به storage نمی‌رسد. اگر working set، یعنی داده‌ای که واقعاً در حال استفاده است، در RAM جا شود، خواندن‌ها پس از گذر اول به خواندن از حافظه تبدیل می‌شوند. نوشتن متفاوت است. هر نوشتنی که برنامه با fsync() flush می‌کند، باید پیش از ادامه اجرای برنامه روی stable storage قرار گرفته باشد.

کارهایی که commit انجام می‌دهند. PostgreSQL، MySQL و SQLite هنگام commit، fsync() یا fdatasync() را فراخوانی می‌کنند و هر commit منتظر پاسخ device می‌ماند. بنابراین نرخ commit یک connection را write latency تعیین می‌کند، نه bandwidth. دستگاهی که در 0.2 ms flush می‌کند، در مقایسه با دستگاهی که 5 ms زمان می‌برد، commitهای بسیار بیشتری را در هر ثانیه امکان‌پذیر می‌کند و هیچ مقدار throughput این تفاوت را تغییر نمی‌دهد. MySQL زمانی که flush نمی‌تواند همگام بماند، این موضوع را در error log اعلام می‌کند:

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

PostgreSQL این موضوع را در checkpoint lineهای خود گزارش می‌کند؛ در این خطوط، مقدار بزرگ sync= یعنی خود flush کند بوده است:

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

کارهایی که به فایل‌های کوچک زیادی دسترسی دارند. هر فایل عملیات metadata دارد که یک خواندن ترتیبی بزرگ چنین عملیاتی ندارد. npm install، git clone از یک repository بزرگ، باز کردن container imageها، یک Maildir mail store و backupای که یک درخت بزرگ را پیمایش می‌کند، زمان خود را صرف دسترسی تصادفی کوچک می‌کنند. یک job پشتیبان‌گیری restic روی VPS هر فایلی را که قبلاً ندیده است می‌خواند و hash می‌کند؛ بنابراین زمان سپری‌شده برای backup از یک میلیون فایل، ارتباط نزدیکی با random read latency دارد. همین موضوع درباره du -sh نیز صدق می‌کند که فقط metadata را می‌خواند.

Databaseهایی که از ظرفیت RAM بیشتر می‌شوند نیز در همین دسته قرار می‌گیرند. وقتی index دیگر در page cache جا نشود، هر lookup به یک random read تبدیل می‌شود و دیسک دوباره در مسیر حیاتی قرار می‌گیرد.

کدام بارهای کاری متوجه دیسک نمی‌شوند

یک وبلاگ یا سایت شرکتی کوچک. صفحه‌ها کوچک هستند، حافظه نهان صفحه پس از نخستین درخواست همه آن‌ها را در خود نگه می‌دارد و عامل محدودکننده، CPU برای رندر کردن یا پهنای‌باند برای دارایی‌ها است. یک پشته LAMP روی Ubuntu 24.04 که سایتی کم‌ترافیک را ارائه می‌کند، پس از گرم شدن تقریباً هیچ disk IO انجام نمی‌دهد.

پخش رسانه‌ای. یک جریان 4K با سرعت 40 Mbit/s، برابر با 5 MB/s داده می‌خواند. 10 جریان، 50 MB/s داده می‌خوانند؛ مقداری که حتی فضای ذخیره‌سازی بلوکی شبکه نیز بدون مشکل ارائه می‌کند. یک سرور رسانه‌ای Jellyfin روی VPS به‌وسیله سهمیه خروجی شبکه شما محدود می‌شود و هنگام تبدیل کدک، به‌وسیله CPU محدود است، نه رسانه ذخیره‌سازی.

استنتاج مدل محلی. اجرای Ollama روی VPS برای میزبانی شخصی یک LLM فایل مدل را یک‌بار می‌خواند و سپس در RAM کار می‌کند. NVMe زمان بارگیری یک مدل 20 GB را از چند دقیقه به چند ثانیه کاهش می‌دهد. اما تعداد توکن در ثانیه را تغییر نمی‌دهد؛ این مقدار به پهنای‌باند حافظه و CPU وابسته است.

هر کاری که منتظر یک سرویس خارجی است. کارگری که برای هر کار 800 ms را صرف یک درخواست HTTP می‌کند، با دیسک بهتر سریع‌تر نمی‌شود.

چرا hypervisor به اندازه رسانه اهمیت دارد

شما مستقیماً با دستگاه ارتباط ندارید. شما با یک دیسک مجازی ارتباط دارید که hypervisor آن را، معمولاً از طریق virtio، ارائه می‌کند. چند تصمیم در این لایه، بیش از تفاوت NVMe و SATA اهمیت دارند.

از داخل guest نمی‌توانید رسانه را ببینید. lsblk -d -o NAME,ROTA,SIZE,MODEL، vda را با مدل خالی نمایش می‌دهد، زیرا virtio هویت درایو را منتقل نمی‌کند. cat /sys/block/vda/queue/rotational چیزی را گزارش می‌کند که hypervisor اعلام می‌کند؛ بنابراین مقدار 0 در آن، اثبات استفاده از flash نیست. nvme list از بسته nvme-cli، در بیشتر VPSها چیزی فهرست نمی‌کند؛ حتی زمانی که میزبان پر از درایوهای NVMe است، زیرا دیسک شما یک دستگاه virtio است، نه یک دستگاه NVMe. وقتی در مشخصات یک طرح نوشته می‌شود NVMe، معمولاً منظور محتوای میزبان است. ممکن است volume شما همچنان به شبکه متصل باشد.

حالت cache میزبان، اعداد را بیش از خود رسانه جابه‌جا می‌کند. با فعال بودن writeback caching در میزبان، یک fsync() در guest می‌تواند به‌محض قرار گرفتن داده در RAM خود میزبان، بازگردد. این وضعیت نتیجه‌ای در benchmark ایجاد می‌کند که هیچ دستگاه فیزیکی نمی‌تواند ارائه دهد. همچنین ممکن است در اثر خرابی میزبان، writeهایی از بین بروند که database شما آن‌ها را ایمن می‌داند. با حالت cache یعنی none، اعداد پایین‌تر و واقعی‌تر هستند.

محدودیت‌ها و اعتبارهای burst. بسیاری از providerها، IOPS را برای هر volume یا هر طرح محدود می‌کنند و بسیاری از volumeهای شبکه‌ای از سهمیه burst استفاده می‌کنند. سهمیه burst، مجموعه‌ای از اعتبارهاست: volume تا زمانی که اعتبارها باقی بمانند با سرعت بالا اجرا می‌شود، سپس به baseline بسیار پایین‌تری کاهش می‌یابد. تشخیص این وضعیت آسان است. یک import یا restore چند دقیقه با سرعت بالا اجرا می‌شود، سپس به‌طور محسوسی کند می‌شود و کند باقی می‌ماند، بدون اینکه چیزی در پیکربندی شما تغییر کرده باشد. اعتبارها را مصرف کرده‌اید.

همسایه‌ها. در یک میزبان اشتراکی، latency دیسک شما با فعالیت guestهای دیگر تغییر می‌کند. به همین دلیل باید بیش از یک بار اندازه‌گیری کنید. همان آزمایش را صبح و دوباره عصر اجرا کنید و دامنه تغییرات را مقایسه کنید. در یک میزبان شلوغ، تفاوت بین دو اجرا روی یک volume یکسان، اغلب از تفاوت اعلام‌شده بین دو رسانه بیشتر است.

چگونه دیسکی را که VPS شما واقعاً در اختیار دارد اندازه‌گیری کنیم

fio، ابزار استاندارد سنجش IO، را نصب و اندازه‌گیری کنید. ابتدا به 3 نکته توجه کنید. این آزمون یک فایل ایجاد می‌کند؛ بنابراین از فضای دیسک استفاده می‌کند و در هر سهمیه IOPS که بابت آن هزینه می‌پردازید، محاسبه می‌شود. مدت اجرای آزمون‌ها را کوتاه نگه دارید. آزمون را با عمق صف کامل روی volumeای که در حال ارائه ترافیک زنده است اجرا نکنید، زیرا برنامه خودتان برای منابع با آن رقابت می‌کند.

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 cache صفحات guest را دور می‌زند؛ بنابراین نتیجه، مشخصات device را نشان می‌دهد، نه RAM شما را. اگر آن را حذف کنید، حافظه را اندازه‌گیری می‌کنید و عددی به دست می‌آورید که هیچ دیسکی نمی‌تواند به آن برسد. اگر فضای کافی دارید، از --size=4G یا مقدار بزرگ‌تر استفاده کنید، زیرا یک فایل 1G ممکن است کاملاً داخل cache میزبان قرار بگیرد و نتیجه را بهتر از واقعیت نشان دهد.

عمق صف 1 تأخیر خام را نشان می‌دهد؛ یعنی همان چیزی که یک فرایند تک‌رشته‌ای تجربه می‌کند:

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

آزمون commit رفتار پایگاه داده را پیش‌بینی می‌کند. این آزمون در هر بار نوشتن 4k، پس از نوشتن، fdatasync() را فراخوانی می‌کند؛ بنابراین نرخ گزارش‌شده شامل 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 این اجرا به بیشترین تعداد تراکنش‌های کوچک در ثانیه که یک اتصال پایگاه داده می‌تواند 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، یعنی انحراف میانگین، به اندازه میانگین اهمیت دارد. انحراف زیاد روی یک سیستم idle نشان می‌دهد که backend ذخیره‌سازی اشتراکی و شلوغ است.

نحوه خواندن نتیجه

تا ژوئیه 2026، این اعداد برای یک VPS کوچک معقول هستند. ده‌ها هزار IOPS خواندن تصادفی 4k در عمق صف 32، همراه با تأخیر کمتر از حدود 0.3 ms در عمق صف 1، با فلش محلی سازگار است. تأخیر چند میلی‌ثانیه‌ای در عمق صف 1، صرف‌نظر از نام طرح، به معنای وجود یک مسیر شبکه است. خواندن ترتیبی که نزدیک 550 MB/s متوقف می‌شود، مشخصه یک پیوند SATA است. عددی که بسیار بیشتر از توان هر دستگاه منفرد است، نشان می‌دهد که caching در مسیر قرار دارد؛ این caching تقریباً همیشه روی میزبان انجام می‌شود.

برای مشاهده تأثیر بار کاری فعلی شما بر دیسک:

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

در خروجی iostat -x، r_await و w_await را بخوانید؛ این دو مقدار میانگین میلی‌ثانیه‌هایی هستند که یک درخواست منتظر مانده است. aqu-sz میانگین طول صف است. %util را روی دیسک مجازی نادیده بگیرید. این مقدار سهم زمانی را گزارش می‌کند که حداقل یک درخواست در حال انتظار بوده است. بنابراین درباره اشباع دستگاهی که می‌تواند چندین درخواست را هم‌زمان پاسخ دهد، اطلاعاتی ارائه نمی‌کند. در نتیجه، مقدار %util برابر 100 همراه با مقدار r_await برابر 0.2 ms نشان‌دهنده یک دیسک سالم و در حال فعالیت است. در vmstat، ستون wa درصد زمان CPU را نشان می‌دهد که صرف انتظار برای IO شده است. اگر /proc/pressure/io در kernel شما وجود داشته باشد، مقدار some avg10= آن سهمی از 10 ثانیه اخیر است که در آن حداقل یک task به دلیل IO متوقف بوده است. این مستقیم‌ترین پاسخ به این پرسش است که آیا storage گلوگاه شماست یا نه.

یک VPS محدودشده توسط دیسک چگونه به نظر می‌رسد

میانگین بار بالا، همراه با CPU بیکار و مقدار زیاد wa در vmstat، نشان می‌دهد که پردازه‌ها پشت دیسک در صف قرار گرفته‌اند. واضح‌ترین سیگنال هسته این پیام در dmesg -T است:

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

این خط ظاهر می‌شود، زیرا یک ریسمان هسته بیش از 2 دقیقه منتظر پاسخ storage مانده است؛ بنابراین watchdog مربوط به hung task آن را ثبت کرده است. jbd2 ریسمان journal مربوط به ext4 است؛ بنابراین کل filesystem منتظر بوده است، نه یک برنامه با عملکرد نامناسب. در یک VPS، این وضعیت معمولاً به backend مربوط به storage یا تمام‌شدن سهمیه IOPS اشاره دارد.

نشانه‌های برنامه نیز همین الگو را نشان می‌دهند. زمان پاسخ میانه همچنان قابل‌قبول می‌ماند، اما طولانی‌ترین درخواست‌ها دنباله‌ای طولانی ایجاد می‌کنند، زیرا فقط درخواست‌هایی که به دیسک دسترسی دارند این تأخیر را متحمل می‌شوند. apt upgrade برای چند دقیقه در وضعیت Unpacking می‌ماند، زیرا dpkg هنگام نوشتن، داده‌ها را flush می‌کند. git status در یک repository بزرگ چند ثانیه طول می‌کشد. این‌ها هزینه‌های metadata و flush هستند؛ بنابراین bandwidth بیشتر کمکی نمی‌کند.

وقتی دیسک عامل محدودکننده است چه باید کرد

پیش از خرید IOPS، RAM بخرید. اگر مجموعه کاری در page cache جا بگیرد، خواندن‌ها دیگر اصلاً به دیسک نمی‌رسند. دو برابر کردن حافظه اغلب از انتقال به یک کلاس ذخیره‌سازی سریع‌تر مؤثرتر است و معمولاً هزینه کمتری دارد.

در صورت امکان، تعداد flushها را کاهش دهید. در PostgreSQL، synchronous_commit = off اجازه می‌دهد commit پیش از نوشته شدن داده روی دیسک برگردد. اگر سرور از کار بیفتد، ممکن است آخرین کسری از ثانیه تراکنش‌ها را از دست بدهید. پایگاه داده خراب نمی‌شود، زیرا write-ahead log همچنان به‌ترتیب نوشته می‌شود. این مصالحه برای یک نسخه تحلیلی مناسب است، اما برای پرداخت‌ها مناسب نیست. innodb_flush_log_at_trx_commit = 2 در MySQL نیز همین مصالحه را ایجاد می‌کند.

فایل‌های کوچک را دسته‌بندی کنید. انتقال یا پشتیبان‌گیری از یک میلیون فایل کوچک، بیشتر تحت تأثیر هزینه هر فایل است. بنابراین، در فضای ذخیره‌سازی با latency بالا، آرشیو کردن فایل‌ها و انتقال یک stream واحد از کپی کردن درخت فایل، فایل‌به‌فایل، سریع‌تر است.

discard را روی volumeهای thin فعال نگه دارید. در فضای ذخیره‌سازی thin provisioned، backend تا زمانی که filesystem آزاد بودن یک block را اعلام نکند از آن مطلع نمی‌شود. volumeای که هرگز trim نمی‌شود، به‌تدریج عملکرد نوشتن خود را از دست می‌دهد. Ubuntu برای این کار یک timer هفتگی ارائه می‌کند:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av تعداد بایت‌های trim‌شده برای هر mount point را چاپ می‌کند. اگر پیامی مبنی بر پشتیبانی نشدن discard نمایش داده شود، یعنی virtual disk این قابلیت را به host منتقل نمی‌کند؛ بنابراین کاری برای اصلاح آن از طرف شما وجود ندارد.

از تنظیم scheduler مربوط به IO صرف‌نظر کنید. در یک دیسک virtio، cat /sys/block/vda/queue/scheduler معمولاً از قبل none را نشان می‌دهد و زمان‌بندی واقعی روی host انجام می‌شود؛ جایی که شما دسترسی ندارید. از noatime نیز صرف‌نظر کنید: Ubuntu به‌صورت پیش‌فرض با relatime mount می‌کند و همین کار تقریباً از همه writeهای atime جلوگیری می‌کند.

انتخاب یک طرح

برای NVMe هزینه کنید اگر پایگاه داده، mail server، CI runner یا ساختی با وابستگی‌های متعدد روی سرور اجرا می‌شود. برای وب‌سایتی که از cache استفاده می‌کند یا برنامه‌ای که بیشتر زمانش صرف فراخوانی‌های خارجی می‌شود، هزینه اضافی نپردازید. اگر مطمئن نیستید، احتمالاً دیسک محدودیت شما نیست؛ زیرا بیشتر workloadهای کوچک VPS ابتدا با کمبود RAM یا پهنای باند مواجه می‌شوند.

از روز اول، هنگام انجام ده دقیقه اول روی یک VPS جدید، اندازه‌گیری کنید و خروجی را در یک فایل نگه دارید. baseline به شما امکان می‌دهد بعداً ثابت کنید که سرعت host کاهش یافته است، نه اینکه کد شما کندتر شده باشد. ارائه‌دهندگانی را ترجیح دهید که نوع storage و هرگونه محدودیت IOPS را به‌صورت مکتوب اعلام می‌کنند. اگر یک طرح، NVMe را اعلام کند اما خواندن با queue depth برابر 1، 4 ms طول بکشد، شما از network storage روی یک host مجهز به NVMe استفاده می‌کنید. فروش چنین چیزی منصفانه است، اما چیزی که خریداری می‌کنید متفاوت است.

FAQ

آیا NVMe همیشه در یک VPS سریع‌تر از یک SSD از نوع SATA است؟

خیر. در عمق صف 1، عملکرد این دو به هم نزدیک است و زمان خواندن یک بلوک 4k تقریباً 80 تا 150 میکروثانیه است؛ بنابراین یک برنامه تک‌رشته‌ای نمی‌تواند تفاوت آن‌ها را تشخیص دهد. NVMe زمانی برتری خود را نشان می‌دهد که درخواست‌های زیادی هم‌زمان در حال اجرا باشند، زیرا AHCI یک صف با ظرفیت 32 فرمان دارد، درحالی‌که NVMe هزاران صف عمیق‌تر ارائه می‌کند. در یک میزبان اشتراکی، بار کاری سایر guestها می‌تواند تأخیر شما را بیشتر از نوع رسانه تغییر دهد. بنابراین به‌جای توجه به نام پلن، حجم ذخیره‌سازی خود را با fio اندازه‌گیری کنید.

چگونه بررسی کنم که VPS من واقعاً از NVMe استفاده می‌کند؟

نمی‌توانید این موضوع را مستقیماً بررسی کنید، زیرا virtio دستگاه فیزیکی را پنهان می‌کند. lsblk، vda را بدون رشته مدل نمایش می‌دهد؛ nvme list چیزی برنمی‌گرداند؛ و /sys/block/vda/queue/rotational فقط اطلاعاتی را گزارش می‌کند که hypervisor اعلام می‌کند. در عوض، رفتار دستگاه را اندازه‌گیری کنید. خواندن تصادفی 4k با عمق صف 1 و تأخیر کمتر از حدود 0.3 ms نشان‌دهنده flash محلی است. تأخیر چندمیلی‌ثانیه‌ای نشان می‌دهد که یک گام شبکه در مسیر قرار دارد. خواندن ترتیبی که نزدیک 550 MB/s متوقف می‌شود، نشان‌دهنده یک پیوند SATA است.

آیا NVMe باعث می‌شود وب‌سایت من سریع‌تر بارگذاری شود؟

معمولاً خیر. پس از درخواست اول، Linux فایل‌ها را از page cache در RAM ارائه می‌کند؛ بنابراین دیسک بیکار می‌ماند. سرعت صفحه در یک VPS کوچک معمولاً به زمان CPU برنامه و پهنای‌باند محدود می‌شود. اگر سایت در هر درخواست عملیات نوشتن انجام دهد، دیسک دوباره در مسیر بحرانی قرار می‌گیرد؛ برای مثال، یک سبد خرید مبتنی بر پایگاه‌داده که مرتب commit انجام می‌دهد، زیرا هر commit باید تا تکمیل flush منتظر بماند.

نتیجه مناسب fio برای یک VPS چیست؟

در ژوئیه 2026، یک VPS کوچک روی flash محلی معمولاً در عمق صف 32، ده‌ها هزار IOPS خواندن تصادفی 4k ارائه می‌کند و تأخیر آن در عمق صف 1 کمتر از 0.3 ms است. ذخیره‌سازی بلوکی شبکه معمولاً چند هزار IOPS با تأخیر چندمیلی‌ثانیه‌ای ارائه می‌کند. آزمایش را 3 بار و در ساعت‌های متفاوت اجرا کنید. اختلاف زیاد بین نتایج اجراها اطلاعاتی مهم‌تر از میانگین ارائه می‌دهد، زیرا نشان می‌دهد guestهای دیگر روی میزبان تا چه اندازه بر عملکرد شما اثر می‌گذارند.

آیا باید پایگاه‌داده‌ام را روی ذخیره‌سازی بلوکی شبکه قرار دهم؟

می‌توانید این کار را انجام دهید و بسیاری از سرویس‌های مدیریت‌شده نیز چنین می‌کنند، اما مسیر commit هزینه آن را تحمیل می‌کند. هر flush از شبکه عبور می‌کند؛ بنابراین یک اتصال منفرد، در مقایسه با flash محلی، تعداد کمتری تراکنش کوچک را در هر ثانیه commit می‌کند. در مقابل، دوام داده‌ای دریافت می‌کنید که پس از خرابی میزبان نیز حفظ می‌شود. اگر برای یک پایگاه‌داده با نوشتن سنگین، ذخیره‌سازی شبکه را انتخاب می‌کنید، عملیات را در تراکنش‌های بزرگ‌تر گروه‌بندی کنید تا flushهای کمتری تعداد ردیف‌های بیشتری را منتقل کنند.