NVMe vs SSD บน VPS เลือกแบบไหนให้คุ้มค่าและเร็วที่สุด

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

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

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

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

มีสองสิ่งที่แตกต่างกัน และทั้งสองอย่างเกี่ยวข้องกับเส้นทางการส่งคำสั่งมากกว่าตัวสื่อบันทึกข้อมูลเอง

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

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

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

Network block storage เป็นประเภทที่สามที่มีคุณสมบัติทางกายภาพต่างออกไป การเขียนข้อมูลหนึ่งครั้งจะต้องข้ามเครือข่ายไปยังคลัสเตอร์จัดเก็บข้อมูลและจะได้รับการยืนยันก็ต่อเมื่อคลัสเตอร์ได้รับข้อมูลนั้นแล้ว ดังนั้นความหน่วงจึงวัดเป็นมิลลิวินาทีแทนที่จะเป็นไมโครวินาที สิ่งที่คุณได้รับแลกกับความหน่วงนี้คือความทนทาน (durability): โวลุ่มข้อมูลจะยังคงอยู่แม้โฮสต์ที่เชื่อมต่ออยู่จะเสียหาย และยังสามารถทำ snapshot หรือปรับขนาดได้

ตัวเลขประสิทธิภาพทั่วไป: NVMe, SATA SSD และ network storage

[
  {
    "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 ในเครื่องมักมีตัวเลข IOPS (จำนวนการอ่าน/เขียนต่อวินาที) สำหรับการอ่านแบบสุ่มขนาด 4k อยู่ที่ 184,000 ที่ queue depth 32 การทดสอบเดียวกันบน SATA SSD จะอยู่ที่ประมาณ 90,000 ซึ่งถูกจำกัดด้วยคิว AHCI แบบเดี่ยวและลิงก์ความเร็ว 6 Gbit/s ส่วน network block storage มักถูกจำกัดด้วยผู้ให้บริการมากกว่าตัวฮาร์ดแวร์เอง โดยมีเพดานที่ระบุไว้ทั่วไปอยู่ที่ 12,500

ค่า latency อธิบายสิ่งเดียวกันในหน่วยที่ผู้ใช้งานสัมผัสได้ ค่า p99 read latency ซึ่งหมายถึงคำขอที่ช้าที่สุด 1 เปอร์เซ็นต์ จะอยู่ที่ประมาณ 0.4 ms บน NVMe ในเครื่อง และ 1.2 ms บน SATA หากมีเครือข่ายเข้ามาเกี่ยวข้องในเส้นทาง ค่านี้จะกลายเป็น 6.5 ms ซึ่งมากกว่าค่าของ NVMe ถึงสิบเท่า

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

Workload ประเภทใดบ้างที่ส่งผลต่อดิสก์

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

งานที่ต้องมีการ commit
PostgreSQL, MySQL และ SQLite จะเรียกใช้ fsync() หรือ fdatasync() เมื่อมีการ commit และทุกการ commit จะต้องรอการตอบกลับจากอุปกรณ์ ดังนั้นอัตราการ commit ของการเชื่อมต่อหนึ่งๆ จึงถูกกำหนดโดย write latency ไม่ใช่ 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 ขนาดใหญ่, การแตกไฟล์ container image, การเก็บอีเมลแบบ Maildir และการสำรวจโครงสร้างไฟล์ขนาดใหญ่เพื่อทำ backup ล้วนใช้เวลาไปกับการเข้าถึงข้อมูลแบบสุ่มขนาดเล็ก งาน restic backup บน VPS จะอ่านและทำ hash ทุกไฟล์ที่ไม่เคยเห็นมาก่อน ดังนั้นเวลาที่ใช้จริงในการ backup ไฟล์จำนวนหนึ่งล้านไฟล์จึงขึ้นอยู่กับ random read latency เป็นหลัก เช่นเดียวกับ du -sh ซึ่งอ่านเฉพาะ metadata เท่านั้น

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

ภาระงานประเภทใดที่ไม่ได้รับผลกระทบจากดิสก์

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

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

การประมวลผลโมเดลในเครื่อง การรัน Ollama บน VPS เพื่อ self-host LLM จะอ่านไฟล์โมเดลเพียงครั้งเดียว จากนั้นจะทำงานใน RAM การใช้ NVMe จะช่วยลดเวลาในการโหลดโมเดลขนาด 20 GB จากหลักนาทีเหลือเพียงหลักวินาที แต่จะไม่ส่งผลต่อความเร็วในการสร้างโทเค็นต่อวินาที (tokens per second) ซึ่งถูกจำกัดด้วยแบนด์วิดท์ของหน่วยความจำและ CPU

งานใดก็ตามที่รอการตอบสนองจากบริการภายนอก เวิร์กเกอร์ที่ใช้เวลา 800 ms ต่อหนึ่งงานในการรอ HTTP request จะไม่ทำงานเร็วขึ้นแม้จะใช้ดิสก์ที่มีประสิทธิภาพดีกว่าก็ตาม

เหตุใด Hypervisor จึงมีความสำคัญไม่น้อยไปกว่าสื่อบันทึกข้อมูล

คุณไม่ได้สื่อสารกับอุปกรณ์โดยตรง แต่คุณสื่อสารกับดิสก์เสมือนที่ Hypervisor นำเสนอให้ ซึ่งมักจะผ่าน virtio และการตัดสินใจหลายอย่างในเลเยอร์นั้นมีความสำคัญมากกว่าการเลือกระหว่าง NVMe กับ SATA

คุณไม่สามารถมองเห็นสื่อบันทึกข้อมูลจากภายใน Guest ได้ lsblk -d -o NAME,ROTA,SIZE,MODEL จะแสดง vda โดยไม่มีข้อมูลรุ่น (model) เนื่องจาก virtio ไม่ได้ส่งผ่านข้อมูลระบุตัวตนของไดรฟ์ออกมา cat /sys/block/vda/queue/rotational จะรายงานสิ่งที่ Hypervisor ประกาศไว้ ดังนั้นค่า 0 ที่ปรากฏจึงไม่ใช่หลักฐานยืนยันว่าเป็น Flash storage ส่วน nvme list จากแพ็กเกจ nvme-cli จะไม่แสดงรายการใดๆ บน VPS ส่วนใหญ่ แม้ว่าโฮสต์จะเต็มไปด้วยไดรฟ์ NVMe ก็ตาม เนื่องจากดิสก์ของคุณเป็นอุปกรณ์ virtio ไม่ใช่อุปกรณ์ NVMe แผนบริการที่ระบุว่าเป็น NVMe มักจะอธิบายถึงสิ่งที่โฮสต์มีอยู่จริง แต่ Volume ของคุณอาจยังคงเชื่อมต่อผ่านเครือข่ายอยู่

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

การจำกัดปริมาณงาน (Caps) และเครดิตสำหรับการเร่งความเร็ว (Burst credits) ผู้ให้บริการหลายรายจำกัดค่า IOPS ต่อ Volume หรือต่อแผนบริการ และ Volume บนเครือข่ายจำนวนมากใช้ระบบเครดิตสำหรับการเร่งความเร็ว (burst allowance) ซึ่งเป็นกลุ่มของเครดิตที่อนุญาตให้ Volume ทำงานด้วยความเร็วสูงในขณะที่ยังมีเครดิตเหลืออยู่ จากนั้นจะลดลงมาอยู่ที่ระดับพื้นฐานที่ต่ำกว่ามาก อาการนี้สังเกตได้ง่าย คือการนำเข้าข้อมูล (import) หรือการกู้คืนข้อมูล (restore) จะทำงานได้อย่างรวดเร็วในช่วงไม่กี่นาทีแรก จากนั้นจะช้าลงอย่างเห็นได้ชัดและคงความช้าไว้อย่างนั้น โดยที่คุณไม่ได้เปลี่ยนแปลงการตั้งค่าใดๆ นั่นเป็นเพราะคุณใช้เครดิตจนหมดแล้ว

เพื่อนบ้าน (Neighbours) บนโฮสต์ที่ใช้งานร่วมกัน ค่าความหน่วง (latency) ของดิสก์จะเปลี่ยนแปลงไปตามสิ่งที่ Guest รายอื่นกำลังทำอยู่ นี่คือเหตุผลที่ควรทำการวัดผลมากกว่าหนึ่งครั้ง ให้รันการทดสอบเดิมในช่วงเช้าและอีกครั้งในช่วงเย็น แล้วเปรียบเทียบความแตกต่างที่เกิดขึ้น บนโฮสต์ที่มีการใช้งานหนาแน่น ความแตกต่างระหว่างการทดสอบสองครั้งบน Volume เดียวกันมักจะมีค่ามากกว่าความแตกต่างระหว่างสื่อบันทึกข้อมูลสองประเภทที่ผู้ให้บริการระบุไว้เสียอีก

วิธีวัดพื้นที่จัดเก็บข้อมูลบน VPS ของคุณ

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

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

การอ่านแบบสุ่ม (Random read) ที่ 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 ของโฮสต์ทั้งหมดและทำให้ผลลัพธ์สูงเกินจริง

Queue depth 1 จะแสดงค่า latency ดิบ ซึ่งเป็นสิ่งที่ process แบบ 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 จากการทดสอบนี้จะใกล้เคียงกับจำนวนธุรกรรมขนาดเล็กสูงสุดต่อวินาทีที่การเชื่อมต่อฐานข้อมูลหนึ่งรายการสามารถ 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 ที่คุณใช้งานอยู่นั้นมีการแชร์ทรัพยากรและกำลังทำงานหนัก

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

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

หากต้องการดูว่า workload ปัจจุบันของคุณส่งผลต่อดิสก์อย่างไร:

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

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

ลักษณะของ VPS ที่มีปัญหาคอขวดที่ดิสก์

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

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

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

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

สิ่งที่ควรทำเมื่อพื้นที่จัดเก็บข้อมูลถึงขีดจำกัด

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

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

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

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

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av จะแสดงจำนวนไบต์ที่ถูก trim ต่อ mount point หากมีข้อความแจ้งว่าไม่รองรับการทำงานแบบ discard หมายความว่า virtual disk ไม่ส่งคำสั่ง discard ไปยัง host ดังนั้นจึงไม่มีสิ่งใดที่คุณต้องแก้ไข

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

การเลือกแผนบริการ

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

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

FAQ

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

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

ฉันจะตรวจสอบได้อย่างไรว่า VPS ของฉันใช้ NVMe จริงหรือไม่?

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

NVMe ช่วยให้เว็บไซต์ของฉันโหลดเร็วขึ้นหรือไม่?

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

ผลลัพธ์ fio ที่ดีสำหรับ VPS ควรเป็นอย่างไร?

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

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

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