ผมไม่ได้เขียนเรื่องนี้เพื่อเป็นรีวิวเชิงลบของ AVA Hosting
มันเป็นเพียงวันทำงานวันหนึ่งของผมในฐานะนักพัฒนา: เซิร์ฟเวอร์ทำงานผิดปกติ สาเหตุที่ดูน่าจะเป็นไปได้กลับอธิบายไม่ได้ และสุดท้าย Linux ก็แสดงให้เห็นว่าเกิดอะไรขึ้น
ผมใช้ KVM VPS ขนาดเล็กจาก AVA Hosting ที่มี:
1 vCPU
2 GB RAM
25 GB NVMeบนเครื่องมี workload production ตามปกติ Nginx ทำงานอยู่ backend ทำงานอยู่ หน่วยความจำยังเหลือ และดิสก์ก็ไม่ได้เต็ม
แต่เซิร์ฟเวอร์กลับตามงานไม่ทัน
ผมจึงเก็บข้อมูลแบบ passive เป็นเวลา 60 วินาทีภายใต้ทราฟฟิก production ปกติ โดยไม่รัน stress test, HTTP flood แบบสังเคราะห์ หรือ disk benchmark
ผลที่ได้:
vCPU count: 1
Average CPU user: 52.52%
Average CPU system: 8.07%
Average CPU softirq: 6.69%
Average CPU steal: 32.73%
Average CPU iowait: 0.00%
Average CPU idle: 0.00%
Maximum runnable queue: 11ตัวเลขที่สำคัญที่สุดคือ CPU steal 32.73% ตรงนี้ทำให้แนวทางการวิเคราะห์เปลี่ยนไปทั้งหมด
ทำไมผลนี้ถึงทำให้ผมแปลกใจ
ปัจจุบัน AVA Hosting โฆษณา VPS ด้วยข้อความ “Guaranteed resources — no sharing” หน้า VPS ของบริษัทอธิบายการจัดสรร vCPU ว่าเป็นแบบ fixed หรือ dedicated และระบุว่าประสิทธิภาพไม่ควรได้รับผลกระทบจากลูกค้ารายอื่น ในข้อมูลเกี่ยวกับ Linux VPS ทาง AVA ระบุชัดกว่านั้นอีกว่า workload ที่ใช้ CPU หนักของ tenant อื่นบน host เดียวกันไม่สามารถสร้าง steal time ให้กับ instance ของคุณได้ และอีกหน้าหนึ่งระบุว่า CPU steal ถูกกำจัดในระดับ hypervisor
นี่เป็นคำกล่าวที่เฉพาะเจาะจงมาก ไม่ใช่แค่หน้า VPS ที่เขียนว่า 1 vCPU แล้วไม่บอกว่า CPU ถูกจัดสรรอย่างไร AVA กำลังโฆษณาการป้องกันจาก CPU contention แบบเดียวกับที่ Linux ดูเหมือนจะรายงานอยู่ภายใน VM ของผม
CPU steal หมายถึงอะไร
steal เป็น metric ของ CPU ตามปกติใน Linux สำหรับสภาพแวดล้อม virtualized โดยหมายถึงช่วงเวลาที่ guest มีงานพร้อมรัน แต่ virtual CPU ไม่ได้ทำงานจริง
มันต่างจากกรณีที่แอปของผมใช้ CPU เต็มเอง หากผมเห็น user/system ประมาณ 100%, steal 0% และ idle 0% ผมก็คงสรุปว่า workload ต้องการพลังประมวลผลเพิ่ม
แต่ในกรณีนี้ ประมาณหนึ่งในสามของเวลาที่ระบบบันทึกเกี่ยวกับ CPU เป็น steal
จากภายใน guest ผมมองไม่เห็น hypervisor ของ AVA ผมไม่รู้ load ของ physical node จำนวน VM ข้างเคียง นโยบาย CPU pinning หรือสัดส่วน overcommit สิ่งที่ผมเห็นได้คือสิ่งที่ Linux รายงานต่อ VM: vCPU ไม่ได้ทำงานซ้ำ ๆ ทั้งที่มีงานกำลังรอการประมวลผล
นี่ไม่ใช่ spike แค่หนึ่งวินาที
ตัวอย่าง CPU ที่แย่เพียงครั้งเดียวไม่เพียงพอให้ผมสรุปอะไร ผมจึงวัดต่อเนื่องเป็นเวลา 60 วินาที โดยตั้งใจไม่รัน stress test, HTTP flood แบบสังเคราะห์ หรือ disk benchmark
ค่าที่ได้ในแต่ละวินาทีเกิดซ้ำในลักษณะนี้:
%usr %sys %soft %steal %idle
53.54 10.10 5.05 31.31 0.00
56.44 6.93 5.94 30.69 0.00
51.52 7.07 6.06 35.35 0.00
55.45 6.93 5.94 31.68 0.00
51.49 8.91 5.94 33.66 0.00
52.53 7.07 7.07 33.33 0.00
52.48 6.93 7.92 32.67 0.00ใกล้จบการสังเกต รูปแบบเดิมก็ยังอยู่:
50.98 10.78 6.86 31.37 0.00
48.48 8.08 9.09 34.34 0.00
55.00 5.00 7.00 33.00 0.00ค่าเฉลี่ยทั้งหมด:
user: 52.52%
system: 8.07%
softirq: 6.69%
steal: 32.73%
iowait: 0.00%
idle: 0.00%ดังนั้นนี่ไม่ใช่ scheduling anomaly ชั่วครู่ ในช่วงส่วนใหญ่ของหนึ่งนาที steal อยู่ราว 30% หรือสูงกว่า ขณะที่ CPU idle ยังคงเป็นศูนย์
เพื่อให้เห็นภาพ 32.73% ของหนึ่งนาทีเท่ากับประมาณ 19.64 วินาที ไม่ได้หมายความว่า VPS ค้างต่อเนื่อง 19.64 วินาที แต่หมายความว่าช่วงเวลาสั้น ๆ ที่ vCPU ไม่ได้ถูก schedule เมื่อนำมารวมกันแล้วมีเวลาประมาณเท่านี้
backend ไล่ตามงานไม่ทัน
ปัญหา CPU เห็นได้ในระดับแอปด้วย ก่อนเริ่มวัด listen queue ของ backend คือ:
Recv-Q: 168
Send-Q: 511หลังผ่านไป 60 วินาที:
Recv-Q: 166
Send-Q: 511ตัวเลขที่แน่นอนไม่ใช่ประเด็นสำคัญ สิ่งสำคัญคือ queue แทบไม่ลดลง แอปมีเวลาหนึ่งนาทีเต็มในการตามงานให้ทัน แต่ก็ยังตามหลังอยู่
ยังมี connection สถานะ CLOSE-WAIT จำนวนมากด้วย ผมจะไม่โทษ host จากสถานะนี้เพียงอย่างเดียว เพราะอาจเกี่ยวข้องกับการจัดการ connection ในตัวแอปเองได้เช่นกัน แต่ภาพรวมสอดคล้องกัน:
1 vCPU
32.73% steal
0% idle
~99% CPU pressure
elevated runnable queue
backend queue not drainingเซิร์ฟเวอร์ยังมีชีวิต แต่ไม่อยู่ในสภาพที่ปกติ
RAM และดิสก์ไม่ใช่ bottleneck ที่เห็นชัด
ผมตรวจสาเหตุทั่วไปด้วย สถานะหน่วยความจำ:
RAM total: ~1.9 GiB
RAM available: ~959 MiB
Swap total: 2 GiB
Swap used: ~33 MiBยังมีหน่วยความจำเหลือพอสมควร และไม่มี OOM event ที่ชัดเจนพอจะอธิบายอาการนี้
ระบบไฟล์:
24 GB total
14 GB used
9.4 GB available
60% usedค่า CPU I/O wait เฉลี่ยอยู่ที่ 0.00% ขณะที่ CPU pressure อยู่ใกล้ 99%, load average ของ VM ที่มีหนึ่ง vCPU อยู่ราว 3.5–4 และ runnable queue ขึ้นไปถึง 11
ทุก metric ชี้ไปทางเดียวกัน: เครื่องขาดเวลาประมวลผล CPU ไม่ได้ติดอย่างชัดเจนที่ RAM หรือ storage
ความขัดแย้งกับข้อความของ AVA
นี่เป็นส่วนที่ผมสนใจที่สุด
AVA ระบุว่า “Guaranteed resources — no sharing” และบอกว่าประสิทธิภาพไม่ควรได้รับผลจากลูกค้ารายอื่น ข้อมูล Linux VPS ระบุว่า tenant อื่นไม่สามารถสร้าง steal time ได้ และอีกหน้าระบุว่า CPU steal ถูกกำจัดในระดับ hypervisor
แต่ VPS ของ AVA ที่ผมใช้รายงานว่า:
Average CPU steal: 32.73%จากภายใน VM ผมพิสูจน์ไม่ได้ว่าเกิดจากอะไรอย่างแน่นอน ผมพิสูจน์ไม่ได้ว่ามีการ overselling โดยเจตนา ระบุ workload ของเพื่อนบ้านรายใดรายหนึ่งไม่ได้ และไม่สามารถสร้างภาพ configuration CPU ฝั่ง host ของ AVA ขึ้นมาใหม่ได้
ผมก็ไม่ได้อ้างว่า VPS ทุกเครื่องของ AVA Hosting ทำงานแบบนี้ ผมทดสอบเพียงหนึ่งเครื่อง
แต่ผมพูดได้ว่าพฤติกรรมที่วัดได้นั้นเข้ากันได้ยากมากกับคำกล่าวเฉพาะเหล่านี้เรื่องการแยก CPU สำหรับบทความนี้ แค่นั้นก็เพียงพอแล้ว
ทำไมผมไม่อัปเกรด
ทางเลือกที่ดูตรงที่สุดคือซื้อ vCPU เพิ่ม
ถ้า VPS แทบไม่มี steal และแอปของผมใช้หนึ่ง core เต็มจริง การอัปเกรดก็คงสมเหตุสมผล แต่ประมาณหนึ่งในสามของ CPU accounting ที่สังเกตได้เป็น steal
ผมไม่ต้องการจ่ายเงินเพิ่มสำหรับ virtual CPU ก่อนจะเข้าใจว่าทำไม execution time ของ vCPU ตัวแรกจำนวนมากจึงถูกบันทึกว่าไม่พร้อมใช้งานอยู่แล้ว ดังนั้นผมจึงยกเลิก VPS และขอ refund
AVA คืนเงินทั้งหมดอย่างรวดเร็ว
ส่วนนี้ของประสบการณ์ถือว่าดี
AVA Hosting คืนเงินเต็มจำนวน การ refund ดำเนินการเร็ว และไม่ได้ใช้เวลาหลายวันเถียงกับผมเรื่องค่า CPU ผมอธิบายปัญหา ขอเงินคืน และพวกเขาคืนให้
ผมขอบคุณตรงนี้
ดังนั้นประสบการณ์ของผมมีข้อสรุปสองข้อที่แยกจากกัน: VPS ที่ผมได้รับมีปัญหาร้ายแรงเรื่องการเข้าถึง CPU และ AVA จัดการ refund ของผมได้ดี ทั้งสองอย่างเป็นความจริง
สิ่งที่ผมได้จากเรื่องนี้
ตอนนี้ผมไม่ตัดสิน VPS จากสเปกอย่าง 1 vCPU / 2 GB RAM / NVMe / KVM เพียงอย่างเดียว ตัวเลขเหล่านั้นบอกว่า provision อะไรไว้ แต่ไม่ได้บอกว่า CPU จะพร้อมใช้งานอย่างคาดเดาได้แค่ไหนเมื่อเจอ workload จริง
หนึ่งในสิ่งแรกที่ผมตรวจบน VM ใหม่ตอนนี้คือ:
mpstat 1 60
vmstat 1 60
cat /proc/pressure/cpu
ss -ltnp
free -h
df -h
iostat -xz 1 60บทเรียนสำคัญที่สุดจากประสบการณ์กับ AVA Hosting ไม่ใช่ว่าหนึ่ง vCPU น้อยเกินไป แต่คือ process ที่ยังทำงาน RAM ที่ยังเหลือ และดิสก์ที่ดูปกติ อาจซ่อนปัญหาอีกชนิดหนึ่งไว้ด้านล่าง
ในกรณีของผม Linux แสดงปัญหานั้นอย่างชัดเจนมาก:
CPU steal: 32.73%
CPU idle: 0.00%
CPU pressure: ~99%AVA Hosting โฆษณา CPU resource แบบไม่แชร์และบอกว่า workload ของเพื่อนบ้านไม่ควรทำให้เกิด steal แต่ VPS ของผมรายงานอย่างอื่น
ผมยกเลิกมัน AVA คืนเงินทั้งหมดอย่างรวดเร็วและไม่โต้เถียง
และวัน debugging ครั้งนี้ก็จบลงตรงนั้น