วิธีอ่านสเปก VPS ราคาถูกก่อนตัดสินใจซื้อให้คุ้มค่า
วิเคราะห์รายละเอียด VPS ราคาถูกแบบบรรทัดต่อบรรทัด ทั้งเรื่องการ oversell vCPU ข้อจำกัดแบนด์วิดท์ ราคาต่ออายุ และการทดสอบเซิร์ฟเวอร์ภายใน 30 นาทีเพื่อป้องกันปัญหาการใช้งาน
สิ่งที่ข้อเสนอ VPS ราคาถูกไม่ได้บอกไว้
ให้อ่านข้อเสนอ VPS ราคาถูกแบบย้อนกลับ เพราะราคาเป็นตัวเลขที่มีประโยชน์น้อยที่สุดในหน้านั้น สิ่งที่ตัดสินว่าเซิร์ฟเวอร์นั้นใช้งานได้ดีหรือไม่คือส่วนที่รายการไม่ได้ระบุไว้ ได้แก่ อัตราการขายเกินขีดจำกัด (oversell ratio) ที่อยู่เบื้องหลังจำนวน vCPU, ข้อกำหนดการใช้งานอย่างเป็นธรรม (fair use clause) ที่อยู่เบื้องหลังคำว่า "ไม่จำกัด", ราคาต่ออายุหลังจากครบกำหนดรอบแรก และการที่ค่าสำรองข้อมูล (backups) กับหมายเลข IPv4 ถูกเรียกเก็บเงินเพิ่มหรือไม่ คู่มือนี้จะวิเคราะห์รายการทีละบรรทัด จากนั้นจะให้การทดสอบเพื่อยอมรับ (acceptance test) ที่คุณสามารถรันบนเซิร์ฟเวอร์ได้ในขณะที่ยังอยู่ในช่วงเวลาที่ขอคืนเงินได้
ไม่มีสิ่งใดที่กล่าวมานี้หมายความว่าราคาต่ำเป็นกลอุบาย ฮาร์ดแวร์ที่เก่ากว่า การอัดแน่นของเซิร์ฟเวอร์ที่มากกว่า การสนับสนุนแบบบริการตนเอง และความซ้ำซ้อนของแพลตฟอร์มที่น้อยกว่า คือวิธีที่ทำให้ราคาต่ำเป็นไปได้ หน้าที่ของคุณคือต้องทราบว่าคุณยอมรับการแลกเปลี่ยนใดก่อนที่ผู้ใช้งานของคุณจะเป็นคนพบมัน ทุกอย่างด้านล่างนี้รันบน Ubuntu 24.04 ด้วยแพ็กเกจที่มีให้ใช้งานในเดือนสิงหาคม 2026
vCPU ไม่ใช่ core
vCPU เป็นเพียงช่องสำหรับการจัดตารางเวลา (scheduling slot) ไม่ใช่ชิ้นส่วนของซิลิคอน ใน KVM (kernel-based virtual machine) vCPU แต่ละตัวคือ thread หนึ่งบนโฮสต์ และตัวจัดตารางเวลาของโฮสต์จะนำ thread นั้นไปวางบน physical core เมื่อถึงคิว โฮสต์สามารถขาย vCPU ได้ถึงสี่ตัวต่อหนึ่ง physical core และ guest ทุกตัวยังคงรายงานจำนวน vCPU เต็มตามที่ได้รับใน nproc ตัวเลขที่ระบุในรายการเป็นเพียงเพดานสูงสุดที่คุณสามารถเรียกใช้ได้ และไม่ได้บ่งบอกว่ามีการสำรองทรัพยากรไว้ให้คุณจริงเท่าใด
อัตราส่วนการขายเกิน (oversell ratio) คือจำนวน vCPU ที่โฮสต์ขายต่อหนึ่ง physical core หากเป็น 1:1 แสดงว่า core นั้นเป็นของคุณเพียงผู้เดียว แผนราคาประหยัดมักมีอัตราส่วนที่สูงกว่า และแทบไม่มีการเปิดเผยอัตราส่วนนี้ ดังนั้นให้ถือว่ารายการใดก็ตามที่ไม่ได้ระบุว่า "dedicated core" หรือ "dedicated vCPU" เป็นแบบ shared ทั้งสิ้น การใช้งานแบบ shared เพียงพอสำหรับงานส่วนใหญ่ เนื่องจากเซิร์ฟเวอร์ส่วนใหญ่มักจะว่างงานในเวลาส่วนใหญ่ แต่จะเริ่มมีปัญหาเมื่อช่วงเวลาที่คุณใช้งานหนักตรงกับช่วงเวลาที่คนอื่นใช้งานหนักเช่นกัน
คุณสามารถวัดผลกระทบได้จากภายใน guest เมื่อ vCPU ของคุณพร้อมทำงานแต่โฮสต์นำ physical core ไปให้ guest อื่นใช้งาน การรอคอยนั้นจะถูกนับเป็น steal time ซึ่งแสดงอยู่ในคอลัมน์ st ใน vmstat และ %st ใน top Steal time คือวิธีที่ noisy neighbour ปรากฏในเมตริกของคุณ และเป็นตัวเลขที่มีประโยชน์ที่สุดในคู่มือนี้ เพราะรายการขายไม่สามารถปลอมแปลงค่านี้ได้
แม้จะเป็น dedicated core ก็ยังมีการแชร์ทรัพยากรในด้านอื่นอยู่ดี เช่น memory bandwidth, last level cache และเส้นทางจัดเก็บข้อมูล (storage path) ซึ่งเป็นของโฮสต์ทั้งเครื่อง การใช้ "dedicated vCPU" ช่วยลดความแปรปรวนที่ใหญ่ที่สุดออกไปได้ แต่ไม่ได้กำจัดความแปรปรวนทั้งหมด
ตรวจสอบรุ่นของ CPU ด้วย lscpu แผนบริการสองแผนอาจระบุว่า "4 vCPU" เหมือนกัน แต่ความเร็วต่อหนึ่ง thread อาจต่างกันถึงสองเท่า เนื่องจากโฮสต์หนึ่งอาจใช้ CPU ที่เก่ากว่าหลายรุ่น ซิลิคอนรุ่นเก่าในราคาต่ำเป็นการแลกเปลี่ยนที่ยุติธรรมสำหรับ build agent แต่เป็นตัวเลือกที่ไม่ดีสำหรับหน้า checkout ของเว็บไซต์
"Unlimited bandwidth" เป็นชื่อเรียกของผลิตภัณฑ์อย่างน้อย 4 รูปแบบ
การจราจรข้อมูล (traffic) ถูกอธิบายไว้ 4 ลักษณะ ซึ่งไม่สามารถใช้แทนกันได้
- การจำกัดปริมาณการใช้งาน (metered allowance): รายการระบุตัวเลขชัดเจน เช่น "2 TB ต่อเดือน" สิ่งที่ต้องพิจารณาคือสิ่งที่เกิดขึ้นหลังจากนั้น ไม่ว่าจะเป็นการคิดค่าบริการส่วนเกินต่อ TB หรือการลดความเร็วลงจนช้ามากจนกว่าจะถึงรอบเดือนถัดไป ควรตรวจสอบเงื่อนไขนี้ก่อนที่จะถึงเวลาที่ต้องใช้งานจริง
- แผนแบบไม่จำกัดปริมาณ (unmetered) ที่มีเงื่อนไขการใช้งานอย่างเป็นธรรม (fair use clause): ไม่มีการนับปริมาณการใช้งาน แต่ข้อกำหนดการใช้งานที่ยอมรับได้ (acceptable use policy) จะกำหนดขีดจำกัดไว้เป็นตัวอักษรแทนตัวเลข ให้ค้นหาคำว่า "fair use", "sustained", "excessive" และ "abuse" ในเอกสารดังกล่าว
- การจำกัดความเร็วพอร์ต (port speed cap): พอร์ตขนาด 100 Mbit/s จะจำกัดคุณด้วยข้อจำกัดทางกายภาพ ไม่ว่านโยบายการใช้งานจะระบุไว้อย่างไรก็ตาม
- การผสมผสานระหว่างสองข้อหลัง: การใช้งานแบบไม่จำกัดปริมาณบนพอร์ตความเร็วต่ำ นี่เป็นรูปแบบที่พบบ่อยที่สุดในแผนราคาประหยัด และถือเป็นข้อเสนอที่ตรงไปตรงมาตราบใดที่คุณอ่านค่าความเร็วพอร์ตให้ชัดเจน
The data behind this chart
[
{
"label": "100 Mbit/s",
"tb_ceiling_30d": 32,
"hours_per_tb": 22.2
},
{
"label": "200 Mbit/s",
"tb_ceiling_30d": 65,
"hours_per_tb": 11.1
},
{
"label": "500 Mbit/s",
"tb_ceiling_30d": 162,
"hours_per_tb": 4.4
},
{
"label": "1 Gbit/s",
"tb_ceiling_30d": 324,
"hours_per_tb": 2.2
}
]ความเร็วพอร์ตคือเพดานสูงสุดที่แท้จริง และการคำนวณนั้นง่ายมาก พอร์ต 100 Mbit/s เท่ากับ 12.5 เมกะไบต์ต่อวินาที ดังนั้นการใช้งานพอร์ตนี้เต็มประสิทธิภาพเป็นเวลา 30 วัน จะรับส่งข้อมูลได้ประมาณ 32 TB ส่วน 30 วันบนพอร์ต 1 Gbit/s จะได้ 324 TB ในที่นี้ TB หมายถึง 10^12 ไบต์ ซึ่งเป็นหน่วยที่ผู้ให้บริการใช้เรียกเก็บเงิน นี่เป็นการคำนวณทางคณิตศาสตร์ไม่ใช่การวัดผลจริง และไม่มีเซิร์ฟเวอร์ใดที่ใช้งานพอร์ตเต็มประสิทธิภาพตลอดทั้งเดือน
คอลัมน์ที่สองคือสิ่งที่ทำให้แผนแตกต่างกัน การย้ายข้อมูล 1 เทราไบต์ใช้เวลาประมาณ 22.2 ชั่วโมงบนพอร์ต 100 Mbit/s และ 2.2 ชั่วโมงบนพอร์ตระดับกิกะบิต หากแผนการกู้คืนข้อมูลของคุณคือ "ดึงข้อมูลสำรองลงมาแล้วเริ่มใหม่" ตัวเลขนี้คือเวลาในการกู้คืนของคุณ
ยังมีรายละเอียดอีกสองประการที่ซ่อนอยู่ในข้อมูลจำเพาะนี้ "1 Gbit/s shared" หมายความว่าพอร์ตถูกแชร์ร่วมกับผู้ใช้อื่น ดังนั้นเพดานข้างต้นจึงเป็นกรณีที่ดีที่สุดไม่ใช่คำสัญญา และผู้ให้บริการบางรายเรียกเก็บค่าบริการตามอัตราการใช้งานสูงสุดที่ 95 เปอร์เซ็นไทล์ (95th percentile) แทนที่จะคิดตามปริมาณรวม ซึ่งทำให้การใช้งานที่คงที่ต่อเนื่องมีราคาถูกกว่าการใช้งานที่พุ่งสูงเป็นช่วงๆ
ไม่ว่าแผนจะระบุไว้อย่างไร ให้วัดการใช้งานของคุณเอง vnstat จะอ่านค่าจากตัวนับอินเทอร์เฟซและเก็บประวัติไว้
sudo apt install -y vnstat
sudo systemctl enable --now vnstat
vnstat -d
vnstat -mทันทีหลังจากติดตั้ง vnstat จะแสดงผล Not enough data available yet. เนื่องจากฐานข้อมูลยังไม่มีตัวอย่างข้อมูล ให้กลับมาดูในวันถัดไป แล้ว vnstat -m จะแสดงยอดรวมรายเดือนเพื่อให้คุณนำไปเปรียบเทียบกับปริมาณที่ได้รับอนุญาตตามแผนที่คุณจ่ายอยู่
การอ้างสิทธิ์เรื่อง NVMe เป็นเรื่องจริงหรือไม่ และคุณจะตรวจสอบได้อย่างไร
lsblk -d -o NAME,ROTA,SIZE,MODELค่า ROTA ที่เป็น 0 หมายความว่า guest ได้รับแจ้งว่าอุปกรณ์ไม่ใช่แบบหมุน (rotational) ค่านี้มาจาก hypervisor จึงเป็นการอธิบายสิ่งที่ host ประกาศออกมามากกว่าจะเป็นตัวสื่อบันทึกข้อมูลที่อยู่เบื้องล่าง คอลัมน์ MODEL มักจะว่างเปล่าสำหรับดิสก์ประเภท virtio เช่น /dev/vda และจะแสดงค่าทั่วไปเป็น QEMU HARDDISK สำหรับดิสก์ที่เชื่อมต่อผ่าน SCSI คุณกำลังดูดิสก์เสมือน ดังนั้นป้ายกำกับของมันจึงไม่ได้พิสูจน์อะไรเลย
คุณสมบัติที่ควรตรวจสอบคือ latency และความแตกต่างที่แท้จริงอยู่ที่ระหว่าง NVMe ในเครื่องกับ volume ที่เชื่อมต่อผ่านเครือข่าย volume บนเครือข่ายสามารถแสดงตัวเลข throughput แบบ sequential ที่สูงได้ แต่ก็ยังรู้สึกช้า เพราะ throughput ถูกวัดด้วยการส่งคำขอจำนวนมากพร้อมกัน ในขณะที่ฐานข้อมูลรอการเขียนขนาดเล็กทีละรายการ ให้วัดที่ queue depth 1 เพื่อดู latency จากนั้นวัดที่ queue ที่ลึกขึ้นเพื่อดู IOPS (input/output operations per second)
sudo apt install -y fio
fio --name=lat --filename=fiotest --size=1G --direct=1 --ioengine=libaio --rw=randread --bs=4k --iodepth=1 --numjobs=1 --runtime=60 --time_based --group_reporting
fio --name=iops --filename=fiotest --size=1G --direct=1 --ioengine=libaio --rw=randread --bs=4k --iodepth=32 --numjobs=1 --runtime=60 --time_based --group_reporting
rm -f fiotestให้อ่านบล็อก clat percentiles โดยเฉพาะบรรทัดที่ 99.00th นั่นคือ completion latency ที่คำขอที่ช้าที่สุดหนึ่งเปอร์เซ็นต์ของคุณได้รับ และเป็นสิ่งที่ผู้ใช้รู้สึกว่าเป็นอาการค้าง ในฐานะแนวทางคร่าวๆ NVMe ในเครื่องที่ queue depth 1 จะตอบสนองในระดับหลายร้อยไมโครวินาที ส่วน volume ที่เชื่อมต่อผ่านเครือข่ายจะตอบสนองในระดับมิลลิวินาที ให้เปรียบเทียบผลการทดสอบสองครั้งของคุณเองแทนที่จะเชื่อตัวเลขที่เผยแพร่เพียงตัวเลขเดียว และให้รันการทดสอบทั้งสองครั้งซ้ำสามรอบตลอดทั้งวัน เพราะดิสก์ที่แชร์ร่วมกับผู้เช่ารายอื่นจะมีพฤติกรรมที่แตกต่างกันในช่วงเวลา 03:00 น. และ 20:00 น.
fio จะสร้างไฟล์ขนาด 1 GB ขึ้นมาก่อน ดังนั้นควรเหลือพื้นที่ว่างบนดิสก์ไว้ และจำไว้ว่าการทดสอบจะใช้โควตา IOPS ที่แผนของคุณกำหนดไว้ หากคุณต้องการเพียงค่าอ่านแบบรวดเร็ว ioping -c 20 . จะให้ค่า latency แก่คุณในบรรทัดเดียว การทดสอบประสิทธิภาพจะมีค่าก็ต่อเมื่อคุณสามารถทำซ้ำได้ ดังนั้นให้บันทึกคำสั่งและผลลัพธ์ที่ได้พร้อมระบุวันที่ไว้ด้วย
สิ่งที่รวมอยู่และสิ่งที่ต้องชำระเงินเพิ่ม
- IPv4: โดยปกติจะรวมที่อยู่ 1 หมายเลขไว้ให้ แผนราคาประหยัดบางแห่งอาจให้ที่อยู่แบบแชร์ผ่าน NAT (network address translation) ซึ่งมีการส่งต่อพอร์ตเพียงไม่กี่พอร์ต ทำให้คุณไม่สามารถรันบริการใดๆ บนพอร์ต 443 ของตนเองได้ ให้ตรวจสอบด้วย
ip -4 addr show scope globalและcurl -4 https://icanhazip.comหากได้ผลลัพธ์ที่แตกต่างกัน แสดงว่าคุณอยู่หลัง NAT - IPv6: การกำหนดเส้นทางแบบ /64 ช่วยให้คุณมีที่อยู่สำหรับคอนเทนเนอร์และบริการทุกอย่างที่ต้องการให้เข้าถึงได้จากภายนอก ส่วน /128 เพียงหมายเลขเดียวจะครอบคลุมเฉพาะการรับส่งข้อมูลขาออกเท่านั้น
- การสำรองข้อมูล: การสำรองข้อมูลอัตโนมัติมักเป็นบริการเสริมที่ต้องชำระเงินเพิ่ม ส่วน Snapshot มักไม่มีค่าใช้จ่าย แต่ Snapshot จะเก็บอยู่บนโครงสร้างพื้นฐานเดียวกับดิสก์ที่คัดลอกมา จึงช่วยป้องกันความผิดพลาดจากตัวคุณเองเท่านั้น ไม่ได้ป้องกันกรณีโฮสต์สูญหาย ควรเก็บสำเนาไว้นอกเซิร์ฟเวอร์เสมอไม่ว่าแผนบริการจะรวมอะไรไว้ให้บ้างก็ตาม
- การจัดการ DDoS: ผู้ให้บริการหลายรายรับมือกับการโจมตีแบบ volumetric (distributed denial of service) ด้วยการทำ null routing ที่ IP ของคุณเป็นระยะเวลาที่กำหนด เซิร์ฟเวอร์จะยังคงทำงานปกติ แต่จะไม่สามารถเข้าถึงได้จากอินเทอร์เน็ต ให้สอบถามเกณฑ์การเริ่มทำงาน (trigger threshold) และระยะเวลาที่ null route จะคงอยู่
- ขอบเขตการสนับสนุน: ในแผนแบบ unmanaged คุณคือผู้ดูแลระบบ และความรับผิดชอบของผู้ให้บริการจะสิ้นสุดที่ระดับ hypervisor และเครือข่ายเท่านั้น นี่คือความแตกต่างด้านต้นทุนที่แท้จริงที่ใหญ่ที่สุดระหว่างสองแผนที่มีสเปกเหมือนกัน
- ใบอนุญาตและแผงควบคุม: แผงควบคุม (control panel), ระบบปฏิบัติการเชิงพาณิชย์ หรือบริการเสริมสำหรับอีเมล อาจมีค่าใช้จ่ายรายเดือนสูงกว่าค่าเช่าเซิร์ฟเวอร์เสียอีก
คุณกำลังซื้อระบบเสมือนประเภทใด?
systemd-detect-virtkvm หรือ qemu หมายถึงการทำ virtualization เต็มรูปแบบ ซึ่งคุณสามารถใช้ kernel ของตนเองและเลือกโหลดโมดูลที่ต้องการได้ ส่วน lxc, lxc-libvirt หรือ openvz หมายถึง container ที่ใช้ kernel ร่วมกับโฮสต์ และ none หมายถึง bare metal
ความแตกต่างนี้จะส่งผลกระทบเมื่อมีการใช้ kernel ร่วมกัน โดย sudo modprobe wireguard จะล้มเหลว และ ip link add dev wg0 type wireguard จะส่งค่า RTNETLINK answers: Operation not supported กลับมา เนื่องจาก container ไม่สามารถโหลด kernel module ที่โฮสต์ไม่ได้โหลดไว้ได้ ส่วน free -h อาจรายงานหน่วยความจำของโฮสต์แทนที่จะเป็นของคุณหากไม่มี lxcfs ทำให้การตรวจสอบระบบอ่านค่าที่ไม่ใช่ของเซิร์ฟเวอร์คุณ นอกจากนี้ swap มักถูกใช้ร่วมกับ container อื่น และการ รัน virtual machine ภายใน VPS ของคุณ นั้นไม่สามารถทำได้เลย แผนบริการแบบ container มีราคาถูกกว่าด้วยเหตุผลนี้ และสำหรับเว็บไซต์แบบ static หรือแอปพลิเคชันขนาดเล็ก มันยังคงเป็นตัวเลือกที่เหมาะสม
ราคาต่ออายุคือเท่าไร
ราคาที่โฆษณามักครอบคลุมเฉพาะรอบบิลแรกเท่านั้น ให้มองหาข้อความที่ระบุว่า "renews at" ในหน้าสั่งซื้อ และตรวจสอบระยะเวลาของสัญญาที่ผูกกับส่วนลดนั้น ส่วนลดที่ใช้ได้หนึ่งปีกับส่วนลดที่คงอยู่ตลอดอายุการใช้งานของแผนเป็นผลิตภัณฑ์ที่แตกต่างกัน แม้จะปรากฏในใบแจ้งหนี้แรกเหมือนกันก็ตาม
โปรดอ่านเงื่อนไขการคืนเงินด้วยความระมัดระวังเช่นเดียวกัน ให้สังเกตว่าระยะเวลาการรับประกันคืนเงินมีผลนานเท่าใด เริ่มนับตั้งแต่วันที่สั่งซื้อหรือวันที่เริ่มให้บริการ ส่วนเสริมอย่างเช่น IP address เพิ่มเติมสามารถขอคืนเงินได้หรือไม่ และการชำระเงินล่วงหน้าแบบรายปีจะได้รับเงินคืนตามสัดส่วนหรือไม่ จากนั้นให้ตั้งการแจ้งเตือนในปฏิทินของคุณล่วงหน้าหนึ่งสัปดาห์ก่อนถึงวันต่ออายุ เพราะช่วงเวลาที่ประหยัดที่สุดในการย้ายออกคือช่วงเวลาก่อนที่ใบแจ้งหนี้จะออก
การย้ายบริการในภายหลังนั้นไม่มีค่าใช้จ่ายก็จริง แต่มีต้นทุนแฝง การย้ายข้อมูลขนาดหลายร้อยกิกะไบต์ การตั้งค่าระบบใหม่ การรอค่า time to live ของ DNS (domain name system) และสำหรับ mail server การสร้างชื่อเสียงของ IP ขึ้นมาใหม่ อาจทำให้คุณต้องเสียเวลาทั้งสุดสัปดาห์ ให้คำนวณเวลาของสุดสัปดาห์นั้นรวมไปด้วยเมื่อเห็นตัวเลขส่วนลดที่น่าสนใจ ต้นทุนที่แท้จริงของ VPS ในหนึ่งปี คือตัวเลขที่คุณควรนำมาเปรียบเทียบ ไม่ใช่ราคาของเดือนแรก
การทดสอบการยอมรับระบบภายใน 30 นาที
ให้รันการทดสอบนี้บนเซิร์ฟเวอร์เครื่องใหม่ก่อนที่คุณจะย้ายข้อมูลใดๆ และในขณะที่ยังอยู่ในช่วงเวลาที่สามารถขอคืนเงินได้ เริ่มจากการรักษาความปลอดภัยก่อน: สิบนาทีแรกบน VPS เครื่องใหม่ ครอบคลุมเรื่องบัญชีผู้ใช้, กุญแจเข้ารหัส และไฟร์วอลล์ จากนั้นจึงติดตั้งเครื่องมือที่จำเป็น
sudo apt update
sudo apt install -y sysbench fio ioping sysstat stress-ng vnstat mtr-tiny curlตรวจสอบที่ 1: สิ่งที่ผู้ให้บริการให้มาจริงคืออะไร?
systemd-detect-virt
nproc
lscpu | grep -E 'Model name|MHz|Hypervisor'
free -h
lsblk -d -o NAME,ROTA,SIZE,MODEL
ip -4 addr show scope global
curl -4 -s https://icanhazip.comคุณควรเห็นประเภทของ virtualization, รุ่นของ CPU และตัวเลขหน่วยความจำที่ใกล้เคียงกับที่คุณซื้อไว้ภายในค่าความคลาดเคลื่อนเพียงเล็กน้อย หาก free -h รายงานค่า RAM มากกว่าแพ็กเกจที่ซื้อไว้มาก นั่นอาจเป็น container ที่ไม่มี lxcfs ไม่ใช่โบนัสแต่อย่างใด หากที่อยู่สาธารณะจาก curl ไม่ปรากฏใน ip -4 addr แสดงว่าที่อยู่ IPv4 นั้นเป็นการใช้งานร่วมกับผู้อื่น
ตรวจสอบที่ 2: ความเร็วของหนึ่งเธรดเป็นอย่างไร และมีการแย่งชิงทรัพยากร (steal) มากน้อยเพียงใดภายใต้ภาระงาน?
sysbench cpu --cpu-max-prime=20000 --threads=1 runบันทึกบรรทัด events per second ไว้ ความเร็วของเธรดเดี่ยวเป็นตัวตัดสินว่าหน้าเว็บจะแสดงผลเร็วแค่ไหนและใช้เวลา build นานเท่าใด ซึ่งเป็นตัวเลขที่แพ็กเกจราคาถูกมักจะแตกต่างกันมากที่สุด ตอนนี้ให้เพิ่มภาระงานให้เต็มทุก vCPU และดูว่าตัวจัดตารางเวลา (scheduler) จัดสรรทรัพยากรให้คุณอย่างไร
stress-ng --cpu 0 --timeout 300s &
vmstat 1 30
mpstat -P ALL 1 10--cpu 0 จะเริ่ม worker หนึ่งตัวต่อหนึ่ง CPU ที่ออนไลน์อยู่ ให้สังเกตคอลัมน์ st ใน vmstat และค่า %steal ใน mpstat การมีค่า steal เป็นเลขหลักเดียวเป็นครั้งคราวบนแพ็กเกจแบบแชร์ถือเป็นเรื่องปกติ แต่หากค่า steal อยู่ในระดับเลขสองหลักต่อเนื่องกันหลายนาที แสดงว่า physical core ถูกใช้งานเกินขีดจำกัด ทำให้งานของคุณต้องรอคิวอยู่หลังผู้เช่ารายอื่น ให้รัน sysbench อีกครั้งในขณะที่มีภาระงาน หากคะแนนเธรดเดี่ยวลดลงอย่างมาก แสดงว่า vCPU ของคุณกำลังแย่งชิงทรัพยากรกันเอง ซึ่งมักหมายความว่าเป็นเธรดพี่น้องกันบน core เดียวกันแทนที่จะเป็นคนละ core กรณีที่คะแนนต่ำแต่ค่า steal ใกล้ศูนย์คืออีกกรณีหนึ่ง ซึ่งเกิดจากการจำกัด CPU โดยโฮสต์ที่คุณไม่สามารถมองเห็นได้โดยตรงจากภายใน guest
ตรวจสอบที่ 3: ดิสก์ทำงานอย่างไรที่ queue depth 1?
ให้รันคำสั่ง fio สองคำสั่งจากส่วน NVMe และเก็บผลลัพธ์ไว้ทั้งสองค่า คือค่า latency ที่เปอร์เซ็นไทล์ที่ 99 ณ queue depth 1 และค่า IOPS ที่ depth 32 จากนั้นให้ตรวจสอบการเขียนข้อมูล เนื่องจาก volume หลายแห่งมีความเร็วในทิศทางนั้นช้ากว่ามาก
fio --name=wlat --filename=fiotest --size=1G --direct=1 --ioengine=libaio --rw=randwrite --bs=4k --iodepth=1 --numjobs=1 --runtime=30 --time_based --group_reporting
rm -f fiotestตัวเลข sequential จาก dd คือตัวเลขที่โฆษณามักจะนำมาอ้างอิง และเป็นตัวเลขที่มีประโยชน์น้อยที่สุดที่คุณจะเก็บได้ เนื่องจากการสตรีมข้อมูลแบบต่อเนื่องไม่ใช่สิ่งที่ฐานข้อมูลหรือเว็บแอปพลิเคชันที่มีการใช้งานสูงทำเป็นปกติ ให้เก็บค่านี้ไว้หากคุณต้องการเปรียบเทียบ แต่ให้ตัดสินใจจากค่า latency เป็นหลัก
ตรวจสอบที่ 4: เครือข่ายมีสภาพเป็นอย่างไรจากจุดที่ผู้ใช้งานของคุณอยู่?
ขั้นแรก ให้ดึงไฟล์ขนาดใหญ่ลงมาที่ VPS
curl -o /dev/null -w 'in: %{speed_download} bytes/s\n' https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.6.tar.xzนั่นเป็นการทดสอบเส้นทางเดียวเข้าสู่เซิร์ฟเวอร์ของคุณและไม่ได้ทดสอบอย่างอื่น ทิศทางที่สำคัญคือทิศทางที่ผู้ใช้งานของคุณใช้งานจริง ดังนั้นให้เปิดไฟล์และดึงข้อมูลจากเครื่องที่อยู่ใกล้กับผู้ใช้งานของคุณ
fallocate -l 100M /var/tmp/100mb.bin
python3 -m http.server 8080 --directory /var/tmpจากนั้น จากแล็ปท็อปหรือเซิร์ฟเวอร์ที่อยู่ใกล้กับกลุ่มเป้าหมายของคุณ:
curl -o /dev/null -w 'down: %{speed_download} bytes/s\n' http://YOUR_SERVER_IP:8080/100mb.bin
mtr --report --report-cycles 50 YOUR_SERVER_IPพอร์ต 8080 จะต้องเปิดอยู่ในไฟร์วอลล์ในขณะที่คุณทำขั้นตอนนี้ ดังนั้นให้ปิดพอร์ตและลบไฟล์ทิ้งหลังจากเสร็จสิ้น รวมถึงหยุดการทำงานของ Python server ด้วย Ctrl+C ในผลลัพธ์ของ mtr ให้ดูที่คอลัมน์ loss ในบรรทัดสุดท้าย การสูญเสียข้อมูลที่ hop ระหว่างทางโดยไม่มีการสูญเสียที่ปลายทางถือเป็นเรื่องปกติ เนื่องจากเราเตอร์จะตอบกลับ ICMP (internet control message protocol) ที่ mtr นับด้วยลำดับความสำคัญต่ำ ซึ่งนั่นไม่ใช่การสูญเสียข้อมูลในทราฟฟิกของคุณ การสูญเสียข้อมูลในบรรทัดสุดท้ายคือการสูญเสียจริง
ให้ทดสอบเครือข่ายซ้ำในช่วงเวลาที่มีผู้ใช้งานสูงสุด ตัวอย่างข้อมูลเพียงชุดเดียวตอนเวลา 02:00 น. จะบอกคุณได้เพียงสภาพเครือข่ายในช่วงที่เงียบเหงาเท่านั้น
บันทึกผลลัพธ์ทั้งสี่รายการลงในไฟล์พร้อมระบุวันที่ แล้วรันซ้ำอีกครั้งในอีกหนึ่งเดือนถัดไป แพ็กเกจที่ใช้งานได้ดีในวันแรกแต่ช้าในสัปดาห์ที่หก คือแพ็กเกจที่โฮสต์มีการใช้งานเต็มขีดจำกัด และการมีตัวเลขของวันแรกไว้คือความแตกต่างระหว่างการรู้ความจริงกับการคาดเดา
เมื่อใดที่ VPS ราคาประหยัดเป็นตัวเลือกที่เหมาะสม
ราคาที่ต่ำแลกมาด้วยข้อจำกัดบางประการและทรัพยากรที่จำกัด CPU รุ่นเก่า อัตราการขายทรัพยากรเกิน (oversell ratio) ที่สูงกว่า พื้นที่จัดเก็บข้อมูลบนเครือข่ายที่ช้ากว่า การสนับสนุนแบบบริการตนเอง และความซ้ำซ้อนของระบบที่น้อยกว่า คือปัจจัยที่ทำให้ราคาถูกลง คุณควรเลือกใช้ให้เหมาะสมกับงาน
VPS ราคาประหยัดเหมาะสำหรับใช้เป็นเครื่องพัฒนา (development box), CI runner, VPN endpoint, โหนดสำหรับตรวจสอบระบบ (monitoring node), ปลายทางสำหรับสำรองข้อมูล (backup target) หรือโฮสต์เว็บไซต์แบบ static ซึ่งงานเหล่านี้สามารถทนต่อความล่าช้าได้ แต่การใช้ VPS ราคาประหยัดเป็นทางเลือกที่ไม่ดีหากความหน่วง (latency) คือหัวใจสำคัญของบริการ เช่น หน้าชำระเงิน, API แบบโต้ตอบ, เซิร์ฟเวอร์เกม หรือฐานข้อมูลที่บริการอื่นต้องรอการตอบสนอง การทดสอบข้างต้นจะช่วยให้คุณทราบว่าคุณได้ทรัพยากรประเภทใดมา และช่วยให้คุณตัดสินใจได้ในขณะที่ยังไม่มีค่าใช้จ่ายเกิดขึ้น
FAQ
vCPU ในข้อเสนอ VPS ราคาประหยัดหมายถึงอะไร
vCPU คือหน่วยประมวลผลเสมือนหนึ่งหน่วยที่แสดงผลต่อระบบปฏิบัติการ guest ของคุณ โดยจะจับคู่กับ thread ที่ตัวจัดตารางเวลาของ host ทำงานบน physical core เมื่อมีทรัพยากรว่าง มันเป็นเพียงสิทธิ์ในการขอเวลาใช้งาน CPU ไม่ใช่ฮาร์ดแวร์ที่จองไว้ให้คุณโดยเฉพาะ เว้นแต่ในรายการระบุว่า "dedicated core" หรือ "dedicated vCPU" ผู้ให้บริการมักขาย vCPU จำนวนมากกว่าจำนวน core ที่มีจริง และอัตราส่วนนี้มักไม่ถูกเปิดเผย ดังนั้นคุณควรวัดผลด้วยตนเอง ให้รัน stress-ng --cpu 0 --timeout 300s แล้วสังเกตคอลัมน์ st ใน vmstat 1 หากค่า steal มีตัวเลขสองหลัก หมายความว่าคุณกำลังรอคิวใช้งาน core ที่ guest อื่นกำลังใช้งานอยู่
"unlimited bandwidth" หมายความว่าไม่จำกัดจริงหรือไม่
ไม่จริง และขีดจำกัดมักจะซ่อนอยู่ในสองส่วนนอกเหนือจากคำอธิบายแผนบริการ นโยบายการใช้งานที่ยอมรับได้ (acceptable use policy) จะกำหนดขีดจำกัดการใช้งานอย่างเป็นธรรมไว้เป็นลายลักษณ์อักษร และความเร็วพอร์ต (port speed) จะเป็นตัวกำหนดเพดานสูงสุดของข้อมูล พอร์ตขนาด 100 Mbit/s ไม่สามารถส่งข้อมูลได้เกินประมาณ 32 TB ใน 30 วัน แม้จะใช้งานเต็มสปีดตลอดเวลาก็ตาม ดังนั้นให้สอบถามความเร็วพอร์ตและอ่านนโยบายเพื่อหาคำว่า "fair use" และ "sustained" จากนั้นให้ติดตามปริมาณการรับส่งข้อมูลจริงด้วย vnstat -m แล้วเปรียบเทียบกับสิทธิ์ที่คุณได้รับ
ฉันจะทราบได้อย่างไรว่า VPS ของฉันใช้ NVMe จริงหรือไม่
คุณไม่สามารถยืนยันสื่อบันทึกข้อมูลทางกายภาพจากภายใน guest ได้ เพราะ lsblk จะรายงานเฉพาะสิ่งที่ hypervisor แจ้งไว้เท่านั้น เช่น ROTA ที่เป็น 0 และชื่อรุ่นที่เป็นค่าว่างหรือชื่อทั่วไป สิ่งที่คุณวัดได้คือพฤติกรรมการทำงาน ให้รัน fio ด้วย --direct=1 ที่ --iodepth=1 แล้วอ่านค่า completion latency ที่เปอร์เซ็นไทล์ 99.00th หากเป็น NVMe ในเครื่องจริง ค่าตอบสนองจะอยู่ในระดับหลักร้อยไมโครวินาที แต่หากเป็น volume ที่เชื่อมต่อผ่านเครือข่าย ค่าตอบสนองจะอยู่ในระดับมิลลิวินาที แม้ว่า throughput แบบต่อเนื่องจะดูสูงก็ตาม ให้ทดสอบซ้ำหลายครั้งตลอดทั้งวัน เนื่องจากประสิทธิภาพของดิสก์ที่ใช้ร่วมกันในช่วงเวลา 03:00 น. และ 20:00 น. นั้นไม่เท่ากัน
ฉันควรทดสอบอะไรบ้างก่อนที่ช่วงเวลาขอคืนเงินจะสิ้นสุดลง
มีสี่สิ่งที่ควรทำตามลำดับนี้ ตรวจสอบว่าเครื่องที่คุณได้รับคืออะไรจาก systemd-detect-virt, lscpu และ free -h ทดสอบความเร็ว single thread จาก sysbench cpu --cpu-max-prime=20000 --threads=1 run ตรวจสอบค่า steal time ภายใต้ภาระงานเต็มที่จาก stress-ng --cpu 0 โดยเฝ้าสังเกตด้วย vmstat 1 และทดสอบ disk latency จาก fio ที่ queue depth 1 จากนั้นให้วัดประสิทธิภาพเครือข่ายจากเครื่องที่อยู่ใกล้กลุ่มผู้ใช้งานของคุณด้วย mtr และทำการดาวน์โหลดไฟล์ที่คุณให้บริการจากเครื่องนั้น การทดสอบทั้งหมดนี้ใช้เวลาไม่เกิน 30 นาที และการทำก่อนย้ายข้อมูลใดๆ จะช่วยให้คุณใช้สิทธิ์ขอคืนเงินได้อย่างมั่นใจ