NVMe กับ SSD บน VPS ต่างกันแค่ไหน

NVMe มีความสำคัญบน VPS หรือไม่

NVMe มีความสำคัญบน VPS เมื่อซอฟต์แวร์ของคุณดำเนินการอ่านและเขียนข้อมูลขนาดเล็กจำนวนมาก และต้องรอให้แต่ละรายการเสร็จสิ้น ประสิทธิภาพจะแตกต่างเพียงเล็กน้อยสำหรับเว็บไซต์ที่ให้บริการหน้าที่แคชไว้แล้ว หรือโปรแกรมที่ใช้เวลาส่วนใหญ่รอเครือข่าย อุปกรณ์จัดเก็บข้อมูลเป็นเพียงปัจจัยหนึ่งเท่านั้น Hypervisor ที่ทำงานอยู่ด้านหน้าดิสก์ และ guest อื่นที่ใช้โฮสต์เดียวกัน เป็นตัวกำหนดขีดจำกัดประสิทธิภาพที่คุณได้รับจริง

สิ่งที่ NVMe เปลี่ยนแปลง และสิ่งที่ไม่เปลี่ยนแปลง

NVMe (non-volatile memory express) ไม่ใช่หน่วยความจำแฟลชชนิดหนึ่ง แต่เป็นโพรโทคอลและการเชื่อมต่อที่ใช้เข้าถึงหน่วยความจำแฟลช อุปกรณ์ NVMe เชื่อมต่อผ่านเลน PCIe (peripheral component interconnect express) และสื่อสารด้วย NVMe ส่วน SSD แบบ SATA (serial ATA) เชื่อมต่อผ่านลิงก์ SATA และสื่อสารด้วย AHCI (advanced host controller interface) ชิปหน่วยความจำที่เก็บไบต์ของคุณอาจเหมือนกันได้ในอุปกรณ์ทั้งสองแบบ

สิ่งที่แตกต่างกันมี 2 ประการ และทั้งสองประการเกี่ยวข้องกับเส้นทางคำสั่ง ไม่ใช่ตัวสื่อจัดเก็บข้อมูลเอง

คิว AHCI ให้เคอร์เนลมีคิวคำสั่ง 1 คิว ซึ่งรองรับคำสั่งได้ 32 คำสั่ง ส่วน NVMe รองรับคิวได้หลายพันคิว โดยในทางปฏิบัติมักมี 1 คิวต่อ CPU core และแต่ละคิวมีความลึกมากกว่า 32 อย่างมาก กระบวนการเดียวที่อ่านทีละบล็อกจะไม่เห็นความแตกต่างนี้ แต่ฐานข้อมูลที่มีคำขออ่านค้างอยู่ 64 รายการจะเห็นความแตกต่างดังกล่าว บน SATA คำขอรายการที่ 33 ต้องรอช่องว่างในคิวก่อนที่อุปกรณ์จะเห็นคำขอ ขณะที่อุปกรณ์ NVMe รับคำขอทั้งหมดและประมวลผลพร้อมกันได้

ความกว้างของลิงก์ ลิงก์ SATA III ทำงานที่ 6 Gbit/s ซึ่งเทียบเท่าข้อมูลจริงประมาณ 550 MB/s หลังหักโอเวอร์เฮดของโพรโทคอลแล้ว นี่เป็นขีดจำกัดคงที่ ไม่ว่าด้านหลังลิงก์จะใช้หน่วยความจำแฟลชแบบใดก็ตาม เลน PCIe จำนวน 4 เลนรับส่งข้อมูลได้หลาย GB/s ดังนั้นลิงก์จึงไม่ใช่คอขวดอีกต่อไป

ความหน่วงเป็นจุดที่มักมีความคาดหวังไม่ตรงกับความเป็นจริง เมื่อ queue depth เท่ากับ 1 ซึ่งหมายถึงมีคำขออยู่ระหว่างดำเนินการเพียง 1 รายการ SSD แบบ SATA จะตอบคำขออ่านขนาด 4k ภายในเวลาประมาณ 100 ถึง 150 ไมโครวินาที ส่วน NVMe ตอบภายในเวลาประมาณ 80 ถึง 100 ไมโครวินาที ทั้งสองแบบทำงานได้รวดเร็ว และไม่มีสิ่งใดที่คุณเรียกใช้จะสังเกตเห็นความแตกต่างจากคำขอเดียว ความแตกต่างจะชัดเจนเมื่อมีการทำงานพร้อมกัน queue depth ซึ่งเป็นจำนวนคำขอที่อยู่ระหว่างดำเนินการในเวลาเดียวกัน เป็นค่าที่กำหนดว่าสื่อจัดเก็บข้อมูลทั้งสองแบบจะมีลักษณะใกล้เคียงกันหรือแตกต่างกันอย่างมาก

พื้นที่จัดเก็บข้อมูลแบบบล็อกผ่านเครือข่ายเป็นประเภทที่ 3 ซึ่งมีคุณสมบัติทางกายภาพแตกต่างกัน การเขียนข้อมูลจะส่งผ่านเครือข่ายไปยังคลัสเตอร์จัดเก็บข้อมูล และจะได้รับการยืนยันก็ต่อเมื่อคลัสเตอร์จัดเก็บข้อมูลนั้นไว้แล้ว ดังนั้นจึงวัดความหน่วงเป็นมิลลิวินาทีแทนไมโครวินาที สิ่งที่คุณได้รับเพื่อแลกกับความหน่วงดังกล่าวคือความทนทานของข้อมูล: 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 ภายในเครื่องมักมีค่าที่ระบุไว้ที่ 184,000 IOPS การอ่านแบบสุ่มขนาด 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 กว่า 10 เท่า

การอ่านแบบลำดับมีช่องว่างมากที่สุดและมีประโยชน์น้อยที่สุด: 3,400 MB/s เทียบกับ 550 MB/s แทบไม่มีงานใดบนเซิร์ฟเวอร์ที่อ่านไฟล์ขนาดใหญ่เพียงไฟล์เดียวตั้งแต่ต้นจนจบด้วยความเร็วเต็มที่ คอลัมน์การอ่านแบบสุ่มและคอลัมน์ความหน่วงอธิบายลักษณะการทำงานจริงของฐานข้อมูล คิวเมล หรือ package manager ได้ดีกว่า

เวิร์กโหลดที่สังเกตเห็นดิสก์

มีกฎข้อเดียวที่อธิบายได้ทั้งหมด: เวิร์กโหลดจะสังเกตเห็นดิสก์ก็ต่อเมื่อเวิร์กโหลดต้องรอดิสก์ Linux เก็บข้อมูลไฟล์ที่เพิ่งถูกใช้งานไว้ใน RAM หรือ page cache ดังนั้นการอ่านไฟล์ครั้งที่สองจะไม่ไปถึง storage หาก working set ซึ่งหมายถึงข้อมูลที่กำลังใช้งานจริง มีขนาดพอดีกับ RAM การอ่านจะกลายเป็นการอ่านจากหน่วยความจำหลังจากการอ่านรอบแรก การเขียนแตกต่างออกไป การเขียนใดก็ตามที่แอปพลิเคชันสั่ง flush ด้วย fsync() ต้องอยู่บน stable storage ก่อนที่แอปพลิเคชันจะทำงานต่อได้

งานที่ทำการ commit PostgreSQL, MySQL และ SQLite เรียกใช้ fsync() หรือ fdatasync() เมื่อทำการ commit และแต่ละ commit ต้องรอให้อุปกรณ์ตอบกลับ ดังนั้นอัตรา commit ของการเชื่อมต่อหนึ่งรายการจึงถูกกำหนดโดยเวลาแฝงในการเขียน ไม่ใช่ bandwidth อุปกรณ์ที่ flush เสร็จใน 0.2 ms รองรับ commit ต่อวินาทีได้มากกว่าอุปกรณ์ที่ใช้เวลา 5 ms อย่างมาก และ throughput ไม่ว่าระดับใดก็ไม่สามารถเปลี่ยนแปลงข้อเท็จจริงนี้ได้ MySQL ระบุเรื่องนี้ใน error log เมื่อการ flush ทำไม่ทัน:

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

PostgreSQL รายงานเรื่องนี้ในบรรทัด checkpoint โดยค่า 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 ขนาดใหญ่ การแตกไฟล์อิมเมจคอนเทนเนอร์ Maildir mail store และการสำรองข้อมูลที่ไล่ดู tree ขนาดใหญ่ ล้วนใช้เวลากับการเข้าถึงแบบสุ่มขนาดเล็กเป็นหลัก งานสำรองข้อมูล restic บน VPS จะอ่านและคำนวณ hash ของทุกไฟล์ที่ยังไม่เคยพบ ดังนั้นเวลารวมของการสำรองข้อมูลที่มีไฟล์ 1 ล้านไฟล์จึงใกล้เคียงกับเวลาแฝงของการอ่านแบบสุ่ม เช่นเดียวกันกับ du -sh ซึ่งอ่านเฉพาะ metadata และไม่อ่านข้อมูลอื่น

ฐานข้อมูลที่มีขนาดใหญ่เกิน RAM ก็อยู่ในกลุ่มนี้เช่นกัน เมื่อ index ไม่สามารถอยู่ใน page cache ได้ทั้งหมดอีกต่อไป การค้นหาแต่ละครั้งจะกลายเป็นการอ่านแบบสุ่ม และดิสก์จะกลับมาเป็นส่วนสำคัญของเส้นทางการทำงาน:VEVENT

เวิร์กโหลดใดไม่สังเกตเห็นข้อจำกัดของดิสก์

บล็อกหรือเว็บไซต์ของบริษัทขนาดเล็ก หน้าเว็บมีขนาดเล็ก แคชหน้าสามารถเก็บหน้าเว็บทั้งหมดได้หลังจากคำขอแรก และคอขวดอยู่ที่ CPU สำหรับการเรนเดอร์หรือแบนด์วิดท์สำหรับไฟล์ประกอบ เมื่อระบบทำงานจนแคชพร้อมแล้ว LAMP stack บน Ubuntu 24.04 ที่ให้บริการเว็บไซต์ที่มีทราฟฟิกต่ำแทบไม่ทำ disk IO

การสตรีมสื่อ สตรีม 4K หนึ่งรายการที่ความเร็ว 40 Mbit/s อ่านข้อมูลที่ 5 MB/s หากมี 10 รายการ จะอ่านข้อมูลที่ 50 MB/s ซึ่ง network block storage ก็ให้บริการได้โดยไม่มีปัญหา เซิร์ฟเวอร์สื่อ Jellyfin บน VPS ถูกจำกัดโดยโควตา network egress ของคุณ และโดย CPU เมื่อทำ transcoding ไม่ใช่โดยสื่อจัดเก็บข้อมูล

การอนุมานโมเดลภายในเครื่อง การรัน Ollama บน VPS เพื่อโฮสต์ LLM ด้วยตนเอง จะอ่านไฟล์โมเดลหนึ่งครั้ง จากนั้นจึงทำงานใน RAM NVMe ลดเวลาโหลดโมเดลขนาด 20 GB จากระดับนาทีเหลือระดับวินาที แต่ไม่เปลี่ยนจำนวนโทเค็นต่อวินาที เนื่องจากค่านี้ขึ้นอยู่กับ memory bandwidth และ CPU

งานใดก็ตามที่รอบริการภายนอก Worker ที่ใช้เวลา 800 ms ต่อ job กับคำขอ 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 ของคุณอาจยังเชื่อมต่อผ่านเครือข่าย

โหมดแคชของโฮสต์มีผลต่อตัวเลขมากกว่าชนิดสื่อจัดเก็บข้อมูล เมื่อโฮสต์เปิดใช้แคชแบบ writeback คำสั่ง fsync() ของ guest อาจส่งคืนผลทันทีที่โฮสต์เก็บข้อมูลไว้ใน RAM ของตนเองแล้ว ผลการทดสอบจึงอาจสูงกว่าความเร็วที่อุปกรณ์จริงใดๆ จะทำได้ นอกจากนี้ หากโฮสต์ขัดข้อง การเขียนข้อมูลที่ฐานข้อมูลเชื่อว่าปลอดภัยแล้วอาจสูญหายได้ เมื่อใช้โหมดแคช none ตัวเลขจะต่ำลงและสะท้อนความเป็นจริง

ข้อจำกัดและเครดิตสำหรับการใช้งานแบบ burst ผู้ให้บริการหลายรายจำกัด IOPS ต่อ volume หรือต่อแผนบริการ และ volume บนเครือข่ายจำนวนมากใช้สิทธิ์การทำงานแบบ burst สิทธิ์ดังกล่าวเป็นกลุ่มเครดิต volume จะทำงานด้วยความเร็วสูงตราบเท่าที่ยังมีเครดิต จากนั้นจะลดลงสู่ระดับพื้นฐานที่ต่ำกว่ามาก อาการนี้สังเกตได้ง่าย การนำเข้าข้อมูลหรือการกู้คืนข้อมูลจะทำงานอย่างรวดเร็วเป็นเวลาหลายนาที จากนั้นจะช้าลงอย่างมากและยังคงช้า โดยที่คุณไม่ได้เปลี่ยนแปลงการกำหนดค่าใดๆ แสดงว่าคุณใช้เครดิตหมดแล้ว

ผู้ใช้งานรายอื่นบนโฮสต์เดียวกัน ในโฮสต์ที่ใช้ร่วมกัน เวลาแฝงของดิสก์จะเปลี่ยนแปลงตามกิจกรรมของ guest รายอื่น นี่คือเหตุผลที่ควรทำการวัดมากกว่า 1 ครั้ง ให้ทดสอบเดียวกันในตอนเช้าและอีกครั้งในตอนเย็น แล้วเปรียบเทียบช่วงการกระจายของผลลัพธ์ บนโฮสต์ที่มีภาระงานสูง ความแตกต่างระหว่างการทดสอบ 2 ครั้งบน volume เดียวกันมักมากกว่าความแตกต่างที่ประกาศไว้ระหว่างสื่อจัดเก็บข้อมูล 2 ชนิด

วิธีวัดดิสก์ที่ VPS ของคุณมีอยู่จริง

ติดตั้ง fio ซึ่งเป็นเครื่องมือมาตรฐานสำหรับทดสอบประสิทธิภาพ IO แล้วจึงทำการวัด ก่อนเริ่ม มีข้อควรระวัง 3 ประการ การทดสอบจะสร้างไฟล์ จึงใช้พื้นที่ดิสก์และนับรวมในโควตา IOPS ที่คุณถูกเรียกเก็บเงิน ใช้เวลาทดสอบแต่ละรอบให้สั้น อย่าเรียกใช้ที่ queue depth สูงสุดกับ volume ที่กำลังให้บริการ network traffic อยู่ เพราะจะต้องแย่งทรัพยากรกับแอปพลิเคชันของคุณเอง

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

การอ่านแบบสุ่มที่ queue depth 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 จะข้าม guest page cache ดังนั้นผลลัพธ์จะแสดงลักษณะของอุปกรณ์แทน RAM ของคุณ หากไม่ระบุ ผลการวัดจะเป็นการวัดหน่วยความจำ ซึ่งให้ค่าที่ดิสก์ไม่สามารถทำได้ ใช้ --size=4G หรือค่าที่สูงกว่า หากคุณมีพื้นที่เพียงพอ เพราะไฟล์ขนาด 1G อาจอยู่ภายใน cache ของ host ได้ทั้งหมดและทำให้ผลลัพธ์ดูสูงเกินจริง

queue depth 1 แสดง latency ดิบ ซึ่งเป็นค่าที่โพรเซสแบบ single-threaded สัมผัสได้:

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 จากการทดสอบนี้ใกล้เคียงกับจำนวนสูงสุดของธุรกรรมขนาดเล็กต่อวินาทีที่ database connection เดียวสามารถ 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 ซึ่งเป็นค่าเบี่ยงเบนเฉลี่ย มีความสำคัญเทียบเท่ากับค่าเฉลี่ย หากค่าเบี่ยงเบนสูงบนเครื่องที่ไม่มีภาระงาน แสดงว่า storage backend ถูกใช้งานร่วมกับผู้อื่นและกำลังมีภาระสูง

วิธีอ่านผลลัพธ์

ณ เดือน July 2026 ค่าต่อไปนี้ถือว่าสมเหตุสมผลสำหรับ VPS ขนาดเล็ก ค่า IOPS สำหรับการอ่านแบบสุ่มขนาด 4k ที่ระดับคิว 32 อยู่ในหลักหมื่น และเวลาแฝงที่ระดับคิว 1 ต่ำกว่าประมาณ 0.3 ms สอดคล้องกับอุปกรณ์ flash ในเครื่อง หากเวลาแฝงที่ระดับคิว 1 อยู่ที่หลาย ms แสดงว่าเป็นเส้นทางเครือข่าย ไม่ว่าแพ็กเกจนั้นจะเรียกว่าอะไรก็ตาม การอ่านแบบลำดับที่หยุดใกล้ 550 MB/s เป็นลักษณะของลิงก์ SATA หากตัวเลขสูงกว่าความสามารถของอุปกรณ์เดี่ยวใด ๆ มาก แสดงว่ามี caching อยู่ในเส้นทาง ซึ่งเกือบทุกครั้งเกิดขึ้นบน host

หากต้องการดูว่า workload ที่กำลังทำงานอยู่ส่งผลต่อ disk อย่างไร:

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

ในผลลัพธ์ของ iostat -x ให้อ่านค่า r_await และ w_await ซึ่งเป็นค่าเฉลี่ยหน่วยเป็น ms ที่ request รอ และ aqu-sz ซึ่งเป็นความยาวคิวเฉลี่ย ไม่ต้องสนใจ %util บน virtual disk ค่านี้รายงานสัดส่วนเวลาที่มี request ค้างอยู่อย่างน้อย 1 รายการ แต่ไม่ได้บอกอะไรเกี่ยวกับ saturation บนอุปกรณ์ที่ให้บริการ request ได้หลายรายการพร้อมกัน ดังนั้นค่า %util ที่ 100 ร่วมกับค่า r_await ที่ 0.2 ms จึงหมายถึง disk ที่มีงานอยู่ในระดับปกติ ใน vmstat คอลัมน์ wa คือเปอร์เซ็นต์ของเวลา CPU ที่ใช้รอ IO หากมี /proc/pressure/io อยู่ใน kernel ของคุณ ค่า some avg10= คือสัดส่วนของช่วง 10 วินาทีล่าสุดที่มี task อย่างน้อย 1 รายการหยุดรอ IO ซึ่งเป็นคำตอบโดยตรงที่สุดว่าพื้นที่จัดเก็บข้อมูลเป็น bottleneck ของคุณหรือไม่

ลักษณะของ VPS ที่ถูกจำกัดด้วยดิสก์

ค่า load average สูง ขณะที่ CPU ว่าง และมีค่า wa ใน vmstat สูง หมายความว่ากระบวนการต่าง ๆ กำลังรอคิวการทำงานของดิสก์ สัญญาณจากเคอร์เนลที่ชัดเจนที่สุดคือข้อความนี้ใน dmesg -T:

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

บรรทัดนี้ปรากฏขึ้นเนื่องจากเธรดของเคอร์เนลรอให้ storage ตอบสนองนานกว่า 2 นาที ดังนั้น hung task watchdog จึงบันทึกข้อความดังกล่าว jbd2 คือเธรด journal ของ ext4 ซึ่งหมายความว่าระบบไฟล์ทั้งหมดกำลังรอ ไม่ใช่เพียงโปรแกรมใดโปรแกรมหนึ่งที่ทำงานผิดปกติ บน VPS สาเหตุนี้มักชี้ไปที่ storage backend หรือโควตา IOPS ที่ถูกใช้จนหมด

อาการของแอปพลิเคชันเป็นไปในรูปแบบเดียวกัน เวลาในการตอบสนองค่ามัธยฐานยังอยู่ในระดับที่ยอมรับได้ ขณะที่คำขอที่ใช้เวลานานที่สุดมีหางการกระจายที่ยาวขึ้น เนื่องจากมีเพียงคำขอที่เข้าถึงดิสก์เท่านั้นที่ได้รับผลกระทบ apt upgrade ค้างอยู่ที่ Unpacking เป็นเวลาหลายนาที เนื่องจาก dpkg ดำเนินการ flush ขณะเขียน git status ใน repository ขนาดใหญ่ใช้เวลาหลายวินาที ปัญหาเหล่านี้เกิดจากต้นทุนของ metadata และการ flush ดังนั้นการเพิ่ม bandwidth จึงไม่ช่วยแก้ปัญหา

เมื่อดิสก์เป็นข้อจำกัด

เพิ่ม RAM ก่อนเพิ่ม IOPS หาก working set อยู่ใน page cache ได้ทั้งหมด การอ่านจะไม่ต้องไปถึงดิสก์เลย การเพิ่มหน่วยความจำเป็น 2 เท่ามักให้ผลดีกว่าการย้ายไปใช้ storage class ที่เร็วกว่า และโดยทั่วไปมีค่าใช้จ่ายน้อยกว่า

ลดจำนวนครั้งของการ flush เมื่อข้อมูลยอมรับได้ ใน PostgreSQL, synchronous_commit = off อนุญาตให้ commit ตอบกลับก่อนที่ข้อมูลจะถูกเขียนลงดิสก์ หากเซิร์ฟเวอร์ล่ม คุณอาจสูญเสียธุรกรรมในช่วงเสี้ยววินาทีสุดท้าย ฐานข้อมูลจะไม่เสียหาย เพราะ write-ahead log ยังคงถูกเขียนตามลำดับ การแลกเปลี่ยนนี้เหมาะกับสำเนาสำหรับ analytics แต่ไม่เหมาะกับระบบชำระเงิน innodb_flush_log_at_trx_commit = 2 ใน MySQL ให้ผลในลักษณะเดียวกัน

รวมไฟล์ขนาดเล็กเป็นชุด การถ่ายโอนหรือสำรองข้อมูลไฟล์ขนาดเล็กจำนวน 1 ล้านไฟล์มีต้นทุนต่อไฟล์เป็นปัจจัยหลัก ดังนั้นการ archive ก่อนแล้วจึงย้ายเป็น stream เดียวจึงเร็วกว่าเมื่อใช้ storage ที่มี latency สูง แทนการคัดลอกโครงสร้างไดเรกทอรีทีละไฟล์

ทำให้ discard ทำงานบน thin volume สำหรับ storage ที่จัดสรรพื้นที่แบบ thin provisioned backend จะไม่ทราบว่าบล็อกใดว่างจนกว่า filesystem จะแจ้ง และ volume ที่ไม่เคย trim จะสูญเสียประสิทธิภาพการเขียนอย่างช้าๆ Ubuntu มี timer รายสัปดาห์ให้ใช้งานดังนี้:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av แสดงจำนวนไบต์ที่ trim แล้วต่อจุด mount ข้อความที่ระบุว่าไม่รองรับ discard operation หมายความว่า virtual disk ไม่ส่งต่อ discard ไปยัง host ดังนั้นคุณไม่จำเป็นต้องแก้ไขอะไร

ไม่ต้องปรับแต่ง IO scheduler บน virtio disk, cat /sys/block/vda/queue/scheduler มักแสดง none อยู่แล้ว และการจัดตารางจริงเกิดขึ้นบน host ซึ่งคุณไม่มีสิทธิ์เข้าถึง ไม่ต้องปรับ noatime เช่นกัน: Ubuntu mount ด้วย relatime เป็นค่าเริ่มต้น ซึ่งหลีกเลี่ยงการเขียน atime ได้เกือบทั้งหมดอยู่แล้ว】【。

การเลือกแผน

เลือกจ่ายสำหรับ NVMe เมื่อมีฐานข้อมูล mail server CI runner หรือกระบวนการ build ที่ใช้แพ็กเกจจำนวนมากทำงานอยู่บนเครื่อง หากเป็นเว็บไซต์ที่ใช้แคชหรือแอปที่ใช้เวลาส่วนใหญ่ไปกับการเรียกบริการภายนอก ไม่ควรจ่ายส่วนเพิ่ม หากไม่แน่ใจ ดิสก์อาจไม่ใช่ข้อจำกัดของคุณ เพราะเวิร์กโหลด VPS ขนาดเล็กส่วนใหญ่มักใช้ RAM หรือแบนด์วิดท์จนหมดก่อน

วัดผลตั้งแต่วันแรก ระหว่างที่ดำเนินการตาม สิบห้านาทีแรกบน VPS ใหม่ และเก็บผลลัพธ์ไว้ในไฟล์ ค่า baseline ช่วยให้คุณพิสูจน์ภายหลังได้ว่าโฮสต์ทำงานช้าลง ไม่ใช่โค้ดของคุณ เลือกผู้ให้บริการที่ระบุคลาสของพื้นที่จัดเก็บและขีดจำกัด IOPS ไว้อย่างชัดเจน หากแผนระบุว่าเป็น NVMe แต่การอ่านที่ queue depth 1 ใช้เวลา 4 ms แสดงว่าคุณกำลังใช้พื้นที่จัดเก็บบนเครือข่ายบนโฮสต์ที่ติดตั้ง NVMe นั่นเป็นบริการที่สามารถจำหน่ายได้อย่างสมเหตุสมผล แต่เป็นสิ่งที่แตกต่างจากสิ่งที่คุณกำลังซื้อ

FAQ

NVMe เร็วกว่า SATA SSD บน VPS เสมอหรือไม่

ไม่เสมอไป เมื่อ queue depth เท่ากับ 1 อุปกรณ์ทั้งสองมีประสิทธิภาพใกล้เคียงกัน โดยการอ่านขนาด 4k ใช้เวลาประมาณ 80 ถึง 150 microseconds และโปรแกรมที่ทำงานแบบ single-threaded ไม่สามารถแยกความแตกต่างได้ NVMe จะมีประสิทธิภาพเหนือกว่าเมื่อมีคำขอจำนวนมากกำลังประมวลผลอยู่ เนื่องจาก AHCI มีคิวเดียวที่รองรับคำสั่งได้ลึก 32 รายการ ขณะที่ NVMe มีหลายคิวที่รองรับความลึกได้มากกว่าหลายพันรายการ บน host ที่ใช้ทรัพยากรร่วมกัน โหลดจาก guest อื่นอาจทำให้ latency เปลี่ยนแปลงมากกว่าความแตกต่างของอุปกรณ์จัดเก็บข้อมูล ดังนั้นให้วัด volume ของคุณเองด้วย fio แทนการดูจากชื่อแพ็กเกจ

จะตรวจสอบได้อย่างไรว่า VPS ใช้ NVMe จริง

คุณไม่สามารถตรวจสอบได้โดยตรง เนื่องจาก virtio ซ่อนอุปกรณ์จริงไว้ lsblk แสดง vda โดยไม่มี model string, nvme list ไม่ส่งคืนข้อมูลใด ๆ และ /sys/block/vda/queue/rotational รายงานเฉพาะข้อมูลที่ hypervisor ประกาศไว้ ให้ใช้การวัดพฤติกรรมแทน การอ่านแบบสุ่มขนาด 4k ที่ queue depth เท่ากับ 1 และมี latency ต่ำกว่าประมาณ 0.3 ms หมายถึงใช้ local flash หากใช้เวลาหลาย milliseconds แสดงว่ามี network hop อยู่ในเส้นทาง การอ่านแบบต่อเนื่องที่หยุดใกล้ 550 MB/s บ่งชี้ว่าใช้ลิงก์ SATA

NVMe ทำให้เว็บไซต์โหลดเร็วขึ้นหรือไม่

โดยทั่วไปไม่ หลังจากคำขอแรก Linux จะให้บริการไฟล์จาก page cache ใน RAM ทำให้ disk ไม่ต้องทำงานต่อ ความเร็วของหน้าเว็บบน VPS ขนาดเล็กโดยปกติขึ้นอยู่กับเวลาประมวลผลของ application CPU และ bandwidth disk จะกลับมาอยู่ใน critical path หากเว็บไซต์เขียนข้อมูลในทุกคำขอ เช่น cart ที่ใช้ฐานข้อมูลและทำการ commit บ่อยครั้ง เนื่องจากแต่ละ commit ต้องรอให้การ flush เสร็จสมบูรณ์

ผลลัพธ์ fio แบบใดจึงถือว่าดีสำหรับ VPS

ณ July 2026 VPS ขนาดเล็กที่ใช้ local flash โดยทั่วไปให้ผลลัพธ์การอ่านแบบสุ่มขนาด 4k ที่ queue depth เท่ากับ 32 ได้หลายหมื่น IOPS และมี latency ที่ queue depth เท่ากับ 1 ต่ำกว่า 0.3 ms ส่วน network block storage โดยทั่วไปให้ผลลัพธ์ไม่กี่พัน IOPS โดยมี latency หลาย milliseconds ให้ทดสอบ 3 ครั้งในช่วงเวลาที่แตกต่างกัน ผลลัพธ์ที่แตกต่างกันมากระหว่างการทดสอบมีข้อมูลมากกว่าค่าเฉลี่ย เนื่องจากแสดงให้เห็นว่า guest อื่นบน host ส่งผลกระทบต่อคุณมากเพียงใด

ควรวางฐานข้อมูลไว้บน network block storage หรือไม่

ทำได้ และ managed services จำนวนมากก็ใช้วิธีนี้ แต่ commit path จะมีต้นทุนเพิ่มขึ้น การ flush ทุกครั้งต้องส่งผ่าน network ดังนั้น connection เดียวจะทำการ commit ธุรกรรมขนาดเล็กต่อวินาทีได้น้อยกว่าการใช้ local flash ข้อแลกเปลี่ยนคือคุณจะได้รับ durability ที่ยังคงอยู่แม้ host จะขัดข้อง หากเลือกใช้ network storage สำหรับฐานข้อมูลที่มีการเขียนข้อมูลมาก ให้รวมงานเป็นธุรกรรมที่มีขนาดใหญ่ขึ้น เพื่อให้การ flush จำนวนน้อยครั้งสามารถรองรับ rows ได้มากขึ้น