- โดยทั่วไปมักใช้ % การใช้งาน CPU จากเครื่องมือติดตามอย่าง
top เพื่อตัดสินขีดจำกัดด้านประสิทธิภาพของเซิร์ฟเวอร์ แต่ในความเป็นจริง ตัวชี้วัดนี้ ไม่ได้สะท้อนประสิทธิภาพแบบเชิงเส้น
- ผลการทดสอบด้วย stress-ng บนเครื่อง Ryzen 9 5900X พบว่า เมื่อ การใช้งานอยู่ที่ 50% ภาระงานจริงกลับอยู่ที่ 60~100% ซึ่งแตกต่างจากตัวเลขที่รายงานอย่างมาก
- สาเหตุหลักคือ Hyper-Threading และ Turbo Boost ซึ่งทำให้การแชร์ทรัพยากรระหว่างคอร์เชิงตรรกะและการเปลี่ยนแปลงความถี่สัญญาณนาฬิกาบิดเบือนตัวชี้วัดนี้
- ดังนั้น แทนที่จะดูเพียงการใช้งาน CPU ควรใช้ เบนช์มาร์กของปริมาณงานที่ประมวลผลได้จริง และเปรียบเทียบกับ throughput ปัจจุบัน ซึ่งแม่นยำกว่า
- หากตีความการใช้งาน CPU แบบเชิงเส้น จะทำให้เกิด ความคลาดเคลื่อนอย่างมากในการประเมินประสิทธิภาพ ดังนั้นการวางแผนระบบจึงควรใช้ แนวทางที่อิงเบนช์มาร์ก
ความไม่สอดคล้องกันระหว่างตัวเลขการใช้งาน CPU ของเซิร์ฟเวอร์กับ throughput จริง
- ระหว่างการดูแลเซิร์ฟเวอร์ หลายคนต้องการรู้ว่าระบบเข้าใกล้การใช้งานสูงสุดหรือยัง
- โดยทั่วไปมักอ้างอิงค่าที่สูงที่สุดในบรรดาการใช้งานเครือข่าย หน่วยความจำ และ CPU ผ่านเครื่องมือติดตามอย่าง
top
- แต่ในทางปฏิบัติ มีปัญหาที่ตัวเลขการใช้งาน CPU กับปริมาณงานที่ประมวลผลได้จริงไม่ได้เพิ่มขึ้นแบบเชิงเส้น
สภาพแวดล้อมและวิธีการทดสอบ
- การทดลองบน Ubuntu เดสก์ท็อป + Ryzen 9 5900X (12 คอร์/24 เธรด)
- เปิดใช้งาน Precision Boost Overdrive (Turbo)
- ใช้ stress-ng จำลองโหลดหลายรูปแบบ (1~24 worker, การใช้งาน 1~100%)
- ตัวชี้วัดที่วัด: การใช้งาน CPU ที่ระบบรายงาน และปริมาณการคำนวณจริง (Bogo ops)
สรุปผลลัพธ์
- โหลด CPU ทั่วไป: ที่การใช้งาน 50% ได้ throughput จริง 60~65%
- การคำนวณจำนวนเต็ม 64 บิต: ที่การใช้งาน 50% ได้ throughput 65~85%
- การคำนวณเมทริกซ์ (Matrix math): ที่การใช้งาน 50% ได้ throughput 80~100%
- ในความเป็นจริง แม้ worker เพิ่มเติมจะไม่ช่วยเพิ่มประสิทธิภาพ การใช้งาน CPU ก็ยังสูงขึ้น
การวิเคราะห์สาเหตุ
-
Hyper-Threading
- โครงสร้างประกอบด้วย 12 คอร์จริง + 12 คอร์เชิงตรรกะ
- เมื่อมี worker ไม่เกิน 12 ตัว จะถูกจัดลงคอร์จริงได้อย่างเหมาะสม แต่เมื่อเกินจากนั้นจะเกิด การแชร์คอร์เชิงตรรกะ ทำให้ประสิทธิภาพลดลง
- โดยเฉพาะใน การคำนวณ SIMD (การคำนวณเมทริกซ์) จะไม่มีทรัพยากรที่แชร์แล้วช่วยเพิ่มประสิทธิภาพได้
-
Turbo Boost
- เมื่อโหลดต่ำ ความถี่อยู่ที่ 4.9GHz → เมื่อโหลดเต็มลดลงเหลือ 4.3GHz ทำให้ ความถี่ลดลง 15%
- ทำให้เกิดความบิดเบือนในสูตรคำนวณการใช้งาน CPU (= busy cycles / total cycles)
- เมื่อส่วนหาร (จำนวน cycle ทั้งหมด) ลดลง อัตราการใช้งานที่เพิ่มขึ้นจึงถูกประเมินสูงเกินจริงเมื่อเทียบกับปริมาณงานจริง
ข้อสังเกตสำคัญ
- การใช้งาน CPU ไม่ใช่ตัวชี้วัดประสิทธิภาพแบบสัมบูรณ์
- เมื่อต้องประเมินขนาดระบบและคาดการณ์ประสิทธิภาพของเซิร์ฟเวอร์:
- 1. วัด throughput สูงสุดด้วยเบนช์มาร์ก
- 2. ติดตาม throughput แบบเรียลไทม์
- 3. เปรียบเทียบสองค่านี้เพื่อ ตัดสินว่าระบบเข้าใกล้ขีดจำกัดประสิทธิภาพหรือไม่
- เนื่องจาก สถาปัตยกรรม CPU (AMD vs Intel), ประสิทธิภาพของ Hyper-Threading และรูปแบบการทำงานของ Turbo แตกต่างกันมาก จึงจำเป็นต้องวิเคราะห์แยกตามโปรเซสเซอร์
บทสรุป
- การใช้งาน CPU เป็นเพียง สัดส่วนของ cycle ที่กำลังทำงานอยู่ เท่านั้น ไม่ได้สะท้อนสมรรถนะการประมวลผลจริงอย่างแม่นยำ
- หากใช้งานได้อย่างมีประสิทธิภาพ ต่อให้แสดงว่า "ใช้งาน 50%" ก็อาจหมายถึง ถึงระดับ 80~100% ของประสิทธิภาพสูงสุดแล้ว
- ดังนั้น การติดตามประสิทธิภาพและการวางแผนระบบ ควรยึด throughput ของงานที่อิงเบนช์มาร์ก เป็นหลัก แทนการดูการใช้งาน CPU เพียงอย่างเดียว
ยังไม่มีความคิดเห็น