NVMe أم SSD في VPS: هل ستلاحظ فرقًا؟

هل تهم NVMe في خادم VPS؟

تكون NVMe مهمة في خادم VPS عندما يرسل برنامجك عمليات قراءة وكتابة صغيرة كثيرة وينتظر اكتمال كل عملية منها. ولا تُحدث فرقًا كبيرًا لموقع يعرض صفحات مخزنة مؤقتًا، أو لبرنامج يقضي وقته في انتظار الشبكة. وسيط التخزين عامل واحد فقط. أما برنامج مراقبة الأجهزة الافتراضية أمام القرص والضيوف الآخرون الذين يشاركون المضيف نفسه، فيحددون الحد الأقصى للأداء الذي تحصل عليه فعليًا.

ما الذي يغيّره NVMe وما الذي لا يغيّره

إن NVMe ‏(non-volatile memory express) ليس نوعًا من ذاكرة flash. بل هو البروتوكول والوصلة المستخدمان للوصول إلى flash. يتصل جهاز NVMe بمسارات PCIe ‏(peripheral component interconnect express) ويتخاطب باستخدام NVMe. أما قرص SSD ‏(solid-state drive) من نوع 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 من البيانات الفعلية بعد احتساب النفقات الإضافية للبروتوكول. وهذا حد أقصى ثابت، بغض النظر عن نوع flash المتصل بها. تنقل 4 مسارات PCIe عدة gigabytes في الثانية، لذلك لا تعود الوصلة هي العامل المحدِّد.

غالبًا ما تكون التوقعات غير دقيقة بشأن زمن الاستجابة. عند عمق قائمة انتظار يساوي 1، أي عند وجود طلب واحد قيد التنفيذ، يستجيب SSD من نوع SATA لقراءة بحجم 4k خلال نحو 100 إلى 150 microseconds. أما NVMe فيستجيب خلال نحو 80 إلى 100. كلاهما سريع، ولن تلاحظ أي عملية تشغّلها الفرق عند تنفيذ طلب واحد. يظهر الفرق عند زيادة التزامن. وعمق قائمة الانتظار، أي عدد الطلبات قيد التنفيذ في الوقت نفسه، هو الإعداد الذي يحدد ما إذا كانت وسيلتا التخزين تبدوان متشابهتين أو مختلفتين جدًا.

تُعدّ وحدة تخزين الكتل عبر الشبكة فئة ثالثة ذات خصائص فيزيائية مختلفة. تعبر عملية الكتابة الشبكة إلى عنقود تخزين، ولا يُؤكَّد استلامها إلا بعد أن يحتفظ العنقود بها، لذلك يُقاس زمن استجابتها بالـ milliseconds بدلًا من microseconds. وما تحصل عليه مقابل هذا التأخير هو المتانة: إذ يبقى المجلد موجودًا بعد زوال المضيف المتصل به، ويمكن إنشاء 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 من عمليات الإدخال/الإخراج العشوائية للقراءة بحجم 4k في الثانية، عند عمق قائمة انتظار قدره 32. ويُقدَّر الاختبار نفسه على SATA SSD بنحو 90,000، بسبب تقييده بقائمة انتظار AHCI واحدة وبوصلة بسرعة 6 Gbit/s. ويكون التخزين الكتلي الشبكي مقيدًا عادةً بحدود يفرضها موفر الخدمة، لا بمواصفات العتاد، ويُعد 12,500 حدًا أقصى شائعًا وموثقًا.

يوضح زمن الاستجابة الأمر نفسه بالوحدة التي يشعر بها المستخدمون. ويبلغ زمن استجابة القراءة عند p99، أي أبطأ 1 بالمئة من الطلبات، نحو 0.4 ms على NVMe المحلي، ونحو 1.2 ms على SATA. وعند وضع شبكة في مسار البيانات، يرتفع إلى 6.5 ms، أي أكثر من عشرة أضعاف قيمة NVMe.

وتظهر أكبر فجوة في القراءات التسلسلية، لكنها الأقل فائدة: 3,400 MB/s مقابل 550 MB/s. لا يقرأ أي شيء تقريبًا على الخادم ملفًا كبيرًا واحدًا من بدايته إلى نهايته بأقصى سرعة. يصف عمود الوصول العشوائي وعمود زمن الاستجابة ما تفعله قاعدة البيانات أو قائمة انتظار البريد أو مدير الحزم فعليًا.

أحمال العمل التي تلاحظ القرص

تفسر قاعدة واحدة جميع هذه الحالات: يلاحظ حمل العمل القرص فقط عندما ينتظر القرص. يحتفظ Linux ببيانات الملفات المستخدمة حديثًا في ذاكرة RAM، في ذاكرة التخزين المؤقت للصفحات، لذلك لا تصل القراءة الثانية للملف إلى وحدة التخزين. إذا كانت مجموعة العمل، أي البيانات المستخدمة فعليًا، تتسع في ذاكرة RAM، تصبح القراءات قراءات من الذاكرة بعد المرور الأول. تختلف عمليات الكتابة. يجب أن تكون أي كتابة يفرغها التطبيق باستخدام fsync() على وحدة تخزين مستقرة قبل السماح للتطبيق بالمتابعة.

العمل الذي ينفذ عمليات الإيداع. يستدعي PostgreSQL وMySQL وSQLite الدالتين fsync() أو fdatasync() عند تنفيذ عملية الإيداع، وتنتظر كل عملية إيداع استجابة الجهاز. لذلك يحدد زمن كتابة الجهاز معدل عمليات الإيداع لاتصال واحد، وليس عرض النطاق الترددي. يتيح جهاز يفرغ البيانات خلال 0.2 ms عمليات إيداع أكثر بكثير في الثانية من جهاز يستغرق 5 ms، ولا يغير أي مقدار من معدل النقل ذلك. يوضح MySQL ذلك في سجل الأخطاء عندما يتعذر على التفريغ مواكبة الحمل:

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

يبلغ PostgreSQL عن ذلك في أسطر نقاط التحقق الخاصة به، حيث تعني قيمة sync= الكبيرة أن عملية التفريغ نفسها كانت بطيئة:

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

العمل الذي يتعامل مع ملفات صغيرة كثيرة. يتضمن كل ملف عمليات على البيانات الوصفية لا تتضمنها قراءة تسلسلية كبيرة واحدة. تستخدم npm install وgit clone لمستودع كبير، وفك صور الحاويات، ومخزن بريد Maildir، ونسخة احتياطية تتنقل عبر شجرة كبيرة معظم وقتها في الوصول العشوائي الصغير. تقرأ مهمة نسخ احتياطي restic على VPS كل ملف لم تره من قبل وتحسب تجزئته، لذلك يرتبط الزمن الفعلي لنسخة احتياطية تضم مليون ملف ارتباطًا وثيقًا بزمن استجابة القراءة العشوائية. وينطبق الأمر نفسه على du -sh، الذي يقرأ البيانات الوصفية ولا يقرأ شيئًا آخر.

تنتمي قواعد البيانات التي يتجاوز حجمها سعة RAM إلى هذه الفئة أيضًا. عندما لا يعود الفهرس يتسع في ذاكرة التخزين المؤقت للصفحات، تصبح كل عملية بحث قراءة عشوائية، ويعود القرص إلى المسار الحرج.

أحمال العمل التي لا تلاحظ القرص

مدونة أو موقع شركة صغيرة. تكون الصفحات صغيرة، وتحتفظ ذاكرة التخزين المؤقت للصفحات بها كلها بعد الطلب الأول، ويكون الحد الأقصى هو وحدة المعالجة المركزية اللازمة للعرض أو النطاق الترددي للملفات الثابتة. لا ينفذ مكدس LAMP على Ubuntu 24.04 يخدم موقعًا منخفض الزيارات عمليات إدخال وإخراج كثيرة على القرص بعد امتلاء الذاكرة المؤقتة.

بث الوسائط. يقرأ بث واحد بدقة 4K بسرعة 40 Mbit/s، أي 5 MB/s. وتقرأ 10 تدفقات بسرعة 50 MB/s، وهي سرعة تستطيع وحدات التخزين الكتلية عبر الشبكة توفيرها بسهولة. يتحدد أداء خادم وسائط Jellyfin على VPS بحد النطاق الترددي المسموح به للخروج عبر الشبكة، وبوحدة المعالجة المركزية عند تحويل الترميز، وليس بوسيط التخزين.

الاستدلال المحلي على النماذج. يقرأ تشغيل Ollama على VPS لاستضافة LLM ذاتيًا ملف النموذج مرة واحدة، ثم يعمل في الذاكرة RAM. يقلل NVMe مدة تحميل نموذج حجمه 20 GB من دقائق إلى ثوانٍ. لكنه لا يغير عدد الرموز في الثانية، لأن هذا العدد تحدده سرعة نقل الذاكرة ووحدة المعالجة المركزية.

أي مهمة تنتظر خدمة خارجية. لن يعمل عامل يقضي 800 ms لكل مهمة في طلب HTTP بسرعة أكبر عند استخدام قرص أفضل.

لماذا يهم برنامج مراقبة الأجهزة الافتراضية بقدر أهمية وسيط التخزين

أنت لا تتعامل مع الجهاز مباشرة. بل تتعامل مع قرص افتراضي يقدمه برنامج مراقبة الأجهزة الافتراضية، عادةً عبر 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 ما يحتويه المضيف. وقد يظل مجلدك متصلًا عبر الشبكة.

يؤثر وضع التخزين المؤقت على المضيف في الأرقام أكثر من وسيط التخزين. عند تفعيل التخزين المؤقت للكتابة على المضيف، يمكن أن تعود عملية fsync() في النظام الضيف فورًا، بمجرد أن يخزن المضيف البيانات في ذاكرته RAM. وينتج عن ذلك قياس أداء لا يستطيع أي جهاز فعلي تقديمه. ويعني ذلك أيضًا أن تعطل المضيف قد يؤدي إلى فقدان عمليات الكتابة التي يعتقد برنامج قاعدة البيانات أنها آمنة. مع وضع التخزين المؤقت none، تكون الأرقام أقل وأكثر دقة.

الحدود وائتمانات الزيادة المؤقتة. يفرض كثير من موفري الخدمة حدًا على IOPS لكل مجلد أو لكل خطة، وتستخدم أحجام التخزين الشبكية الكثيرة سماحًا بالزيادة المؤقتة. وسماح الزيادة المؤقتة هو مجموعة من الائتمانات: يعمل المجلد بسرعة ما دامت الائتمانات متاحة، ثم ينخفض إلى مستوى أساسي أقل بكثير. ويسهل تمييز هذا العَرَض. تعمل عملية استيراد أو استعادة بسرعة لعدة دقائق، ثم تتباطأ بشدة وتبقى بطيئة، من دون تغيير في إعداداتك. لقد استهلكت الائتمانات.

الأجهزة المجاورة. على مضيف مشترك، يتغير زمن استجابة القرص وفقًا لما تفعله الأنظمة الضيفة الأخرى. ولهذا يجب إجراء القياس أكثر من مرة. نفّذ الاختبار نفسه في الصباح، ثم أعده في المساء، وقارن مدى التفاوت. على مضيف مشغول، يكون الفرق بين تشغيلين على المجلد نفسه أكبر غالبًا من الفرق المنشور بين وسيطين مختلفين.

كيفية قياس القرص المتاح فعليًا لخادم VPS لديك

ثبّت fio، وهو أداة قياس أداء IO القياسية، ثم أجرِ القياس. انتبه إلى 3 أمور أولًا. ينشئ الاختبار ملفًا، لذلك يستهلك مساحة من القرص ويُحتسب ضمن حد IOPS الذي تدفع مقابله. اجعل عمليات التشغيل قصيرة. لا تشغّله بأقصى عمق لقائمة الانتظار على وحدة تخزين تخدم حركة مرور مباشرة، لأن ذلك سيتنافس مع تطبيقك نفسه.

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 زمن الاستجابة الخام، وهو ما يشعر به البرنامج ذو الخيط الواحد:

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، أي الانحراف المتوسط، القدر نفسه من الاهتمام الذي يستحقه المتوسط. يشير الانحراف الكبير في خادم خامل إلى أن الواجهة الخلفية للتخزين مشتركة ومشغولة.

كيفية قراءة النتيجة

اعتبارًا من يوليو 2026، تُعد هذه القراءات معقولة لخادم VPS صغير. إن تحقيق عشرات الآلاف من عمليات الإدخال والإخراج العشوائية بحجم 4k عند عمق قائمة انتظار يبلغ 32، مع زمن استجابة عند عمق قائمة انتظار يبلغ 1 أقل من نحو 0.3 ms، يتوافق مع وحدة تخزين فلاش محلية. أما زمن الاستجابة عند عمق قائمة انتظار يبلغ 1، إذا بلغ عدة ميليثوانٍ، فيعني وجود مسار عبر الشبكة، مهما كان اسم الخطة. وتُعد القراءات التسلسلية التي تتوقف قرب 550 MB/s علامة مميزة لوصلة SATA. أما الرقم الذي يتجاوز بكثير ما يمكن لأي جهاز واحد تحقيقه، فيعني أن التخزين المؤقت موجود ضمن المسار، ويكون ذلك دائمًا تقريبًا على المضيف.

لمعرفة تأثير حمل العمل الحالي على القرص:

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= فيه هي نسبة الثواني العشر الأخيرة التي تعطل فيها مهمة واحدة على الأقل بسبب IO. وهذه هي الإجابة الأكثر مباشرة عن سؤال ما إذا كان التخزين يمثل عنق الزجاجة لديك.

كيف يبدو VPS مقيّدًا بالقرص

يعني ارتفاع متوسط الحمل مع خمول وحدة المعالجة المركزية وارتفاع wa في vmstat أن العمليات تنتظر خلف القرص. أوضح إشارة من النواة هي هذه الرسالة في dmesg -T:

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

يظهر هذا السطر لأن خيطًا من النواة انتظر أكثر من دقيقتين للحصول على استجابة من وحدة التخزين، ولذلك سجّلها مراقب المهام العالقة. يمثّل jbd2 خيط سجل ext4، ما يعني أن نظام الملفات بأكمله كان ينتظر، وليس برنامجًا واحدًا سيئ السلوك. في VPS، يشير ذلك عادةً إلى الواجهة الخلفية لوحدة التخزين أو إلى استنفاد حد IOPS المسموح به.

تتبع أعراض التطبيق النمط نفسه. يظل زمن الاستجابة الوسيط مقبولًا، بينما يزداد الذيل الطويل للطلبات الأبطأ، لأن الطلبات التي تصل إلى القرص فقط تتحمل هذا التأخير. يبقى apt upgrade عند مرحلة Unpacking لدقائق، لأن dpkg يفرغ البيانات إلى القرص أثناء الكتابة. يستغرق git status في مستودع كبير ثوانٍ. هذه تكاليف بيانات وصفية وتفريغ، ولذلك لن يساعد توفير نطاق ترددي أكبر.

ما يجب فعله عندما يكون القرص هو العامل المحدِّد

اشترِ RAM قبل شراء IOPS. إذا كانت مجموعة العمل تتسع في ذاكرة التخزين المؤقت للصفحات، فلن تصل عمليات القراءة إلى القرص إطلاقًا. غالبًا ما يتفوق مضاعفة الذاكرة على الانتقال إلى فئة تخزين أسرع، وعادةً ما تكون تكلفته أقل.

قلّل عدد عمليات التفريغ عندما تسمح البيانات بذلك. في PostgreSQL، يتيح synchronous_commit = off إرجاع نتيجة commit قبل كتابة البيانات على القرص. قد تفقد آخر جزء من الثانية من المعاملات إذا تعطل الخادم. لن تتلف قاعدة البيانات، لأن سجل الكتابة المسبقة يُكتب بالترتيب نفسه. هذا الخيار مناسب لنسخة التحليلات، وغير مناسب للمدفوعات. يطبّق innodb_flush_log_at_trx_commit = 2 في MySQL المقايضة نفسها.

اجمع الملفات الصغيرة في أرشيفات. تهيمن تكلفة كل ملف على نقل أو نسخ احتياطي لمليون ملف صغير، لذلك يكون إنشاء أرشيف أولًا ونقل دفق واحد أسرع على وحدات التخزين ذات زمن الاستجابة المرتفع من نسخ شجرة الملفات ملفًا تلو الآخر.

حافظ على عمل discard في وحدات التخزين الرقيقة. في وحدات التخزين ذات التخصيص الرقيق، لا تعرف الواجهة الخلفية أن الكتلة أصبحت حرة حتى يخبرها نظام الملفات بذلك، كما أن وحدة التخزين التي لا تنفذ trim تفقد أداء الكتابة تدريجيًا. يوفّر Ubuntu مؤقتًا أسبوعيًا لهذا الغرض:

systemctl status fstrim.timer
sudo fstrim -av

يطبع fstrim -av عدد البايتات التي جرى تشذيبها لكل نقطة تحميل. تعني رسالة تفيد بأن عملية discard غير مدعومة أن القرص الافتراضي لا يمرر discard إلى المضيف، ولذلك لا يوجد ما يمكنك إصلاحه.

تجاوز ضبط جدولة IO. في قرص virtio، يعرض cat /sys/block/vda/queue/scheduler عادةً none مسبقًا، كما تحدث الجدولة الفعلية على المضيف، حيث لا تملك صلاحية الوصول. تجاوز noatime أيضًا: يحمّل Ubuntu أنظمة الملفات باستخدام relatime افتراضيًا، ما يتجنب بالفعل معظم عمليات الكتابة الخاصة بـ atime.

اختيار خطة

ادفع مقابل NVMe عندما تكون قاعدة بيانات أو خادم بريد أو مشغّل CI أو عملية بناء تعتمد على حزم كثيرة موجودة على الخادم. لا تدفع تكلفة إضافية لموقع ويب مخزّن مؤقتًا أو لتطبيق يقضي معظم وقته في إجراء استدعاءات خارجية. إذا لم تكن متأكدًا، فغالبًا لا يكون القرص هو العامل المحدِّد لديك، لأن معظم أحمال VPS الصغيرة تستنفد RAM أو سعة النطاق أولًا.

أجرِ القياس في اليوم الأول، أثناء تنفيذ الدقائق العشر الأولى على VPS جديد، واحتفظ بالمخرجات في ملف. يتيح لك خط الأساس إثبات أن المضيف أصبح أبطأ، بدلًا من افتراض أن السبب هو التعليمات البرمجية لديك. فضّل موفّري الخدمة الذين يذكرون فئة التخزين وأي حد أقصى لـ IOPS كتابةً. إذا ذكرت الخطة NVMe واستغرأت قراءة بعمق طابور 1 مدة 4 ms، فهذا يعني أنك تستخدم تخزينًا عبر الشبكة على مضيف مزود بأقراص NVMe. هذا منتج مشروع للبيع، لكنه يختلف عما تشتريه.

FAQ

هل يكون NVMe أسرع دائمًا من SSD SATA على VPS؟

لا. عند عمق قائمة انتظار يساوي 1، يكون الفرق بينهما صغيرًا، إذ تبلغ المدة تقريبًا من 80 إلى 150 ميكروثانية لقراءة بحجم 4k، ولا يستطيع برنامج أحادي الخيط تمييز الفرق. يتفوق NVMe عند وجود طلبات كثيرة قيد التنفيذ، لأن AHCI يوفر قائمة انتظار واحدة بعمق 32 أمرًا، بينما يوفر NVMe آلاف قوائم الانتظار الأعمق. على مضيف مشترك، قد يؤثر الحمل الناتج عن الضيوف الآخرين في زمن الاستجابة أكثر مما يؤثر نوع وسيط التخزين، لذلك قِس وحدة التخزين الخاصة بك باستخدام fio بدلًا من الاعتماد على اسم الخطة.

كيف أتحقق من أن VPS الخاص بي يستخدم NVMe فعلًا؟

لا يمكنك التحقق من ذلك مباشرة، لأن virtio يخفي الجهاز الفعلي. يعرض lsblk قيمة vda من دون سلسلة طراز، ولا يعيد nvme list أي نتيجة، بينما يعرض /sys/block/vda/queue/rotational فقط ما يعلنه برنامج مراقبة الأجهزة الافتراضية. قِس السلوك بدلًا من ذلك. تعني قراءة عشوائية بحجم 4k عند عمق قائمة انتظار يساوي 1، بزمن استجابة أقل من نحو 0.3 ms، وجود وحدة تخزين فلاش محلية. ويعني زمن استجابة يبلغ عدة ميليثوانٍ أن المسار يتضمن قفزة عبر الشبكة. وتشير القراءات التسلسلية التي تتوقف قرب 550 MB/s إلى وجود وصلة SATA.

هل يجعل NVMe موقعي يُحمّل بسرعة أكبر؟

عادةً لا. بعد الطلب الأول، يعرض Linux الملفات من ذاكرة التخزين المؤقت للصفحات في RAM، ولذلك يتوقف نشاط القرص. تعتمد سرعة الصفحة في VPS صغير عادةً على وقت وحدة المعالجة المركزية الذي يحتاج إليه التطبيق وعلى عرض النطاق الترددي. يعود القرص إلى المسار الحرج إذا كان الموقع يكتب في كل طلب، مثل سلة مشتريات مرتبطة بقاعدة بيانات تنفذ عمليات تثبيت متكررة، لأن كل عملية تثبيت تنتظر اكتمال عملية التفريغ.

ما نتيجة fio الجيدة على VPS؟

اعتبارًا من July 2026، يعيد VPS صغير يستخدم وحدة تخزين فلاش محلية عادةً عشرات الآلاف من عمليات الإدخال والإخراج في الثانية لقراءات عشوائية بحجم 4k عند عمق قائمة انتظار يساوي 32، مع زمن استجابة أقل من 0.3 ms عند عمق قائمة انتظار يساوي 1. ويعيد تخزين الكتل عبر الشبكة عادةً بضعة آلاف من عمليات الإدخال والإخراج في الثانية، مع زمن استجابة يبلغ عدة ميليثوانٍ. شغّل الاختبار 3 مرات في ساعات مختلفة. ويكشف التفاوت الكبير بين النتائج معلومات أكثر من المتوسط، لأنه يوضح مدى تأثير الضيوف الآخرين على المضيف في أدائك.

هل ينبغي أن أضع قاعدة بياناتي على تخزين الكتل عبر الشبكة؟

يمكنك ذلك، وتستخدمه خدمات مُدارة كثيرة، لكن مسار تثبيت المعاملات يتكبد تكلفته. تعبر كل عملية تفريغ الشبكة، لذلك تنفذ وصلة واحدة عددًا أقل من المعاملات الصغيرة في الثانية مقارنةً بما تنفذه على وحدة تخزين فلاش محلية. وفي المقابل، تحصل على متانة تستمر حتى بعد تعطل المضيف. إذا اخترت تخزينًا عبر الشبكة لقاعدة بيانات كثيفة الكتابة، فجمّع العمل في معاملات أكبر حتى تحمل عمليات تفريغ أقل عددًا أكبر من الصفوف.