การวิเคราะห์ผลกระทบต่อประสิทธิภาพของแหล่งเวลาที่เลือกในระบบ

Brendan Gregg หนึ่งในนักพัฒนาของ DTrace ซึ่งปัจจุบันกำลังพัฒนาเครื่องมือวิเคราะห์ประสิทธิภาพที่ใช้ BPF ในเคอร์เนล Linux ได้สรุปประสบการณ์ที่ได้รับจากการวิเคราะห์ปัญหาด้านประสิทธิภาพที่ Netflix พบเมื่อย้าย Cassandra DBMS จาก CentOS ไปยัง Ubuntu คลาวด์ Amazon EC2 ที่ใช้ Xen หลังจากการโยกย้าย โหลด CPU เพิ่มขึ้น 30% และความล่าช้าระหว่างการดำเนินการเขียนเพิ่มขึ้นประมาณเท่าเดิม ปรากฎว่าประสิทธิภาพของแอปพลิเคชันที่ขอข้อมูลเวลาอย่างเข้มข้นนั้นขึ้นอยู่กับแหล่งเวลาที่แน่นอนที่เลือกในระบบ

ในตอนแรก สาเหตุของประสิทธิภาพที่ลดลงไม่ชัดเจน และการวินิจฉัยเริ่มต้นด้วยการตรวจสอบผลกระทบที่เป็นไปได้ของกระบวนการระบบที่ใช้ทรัพยากรจำนวนมากที่ทำงานอย่างต่อเนื่องหรือเปิดตัวเป็นระยะโดยใช้ยูทิลิตี้ด้านบนและโปรแกรมอรรถประโยชน์ execsnoop แต่ทุกสิ่งบ่งชี้ว่าการใช้ทรัพยากรเพิ่มขึ้นโดยเฉพาะใน Cassandra DBMS ที่เขียนด้วยภาษา Java เมื่อเปรียบเทียบเกณฑ์ชี้วัดโปรไฟล์ของกระบวนการ Cassandra ทั้งสองที่ทำงานพร้อมกันบน CentOS และ Ubuntu การประมวลผลคำสั่งเดียวกัน แสดงให้เห็นว่าประมาณ 32% ของเวลาทั้งหมดถูกใช้ไปกับการเรียก os::javaTimeMillis() ซึ่งใช้เพื่อรับข้อมูลเกี่ยวกับเวลาปัจจุบัน .

หลังจากนั้น ได้ทำการทดลองโดยเขียนแอปพลิเคชัน Java อย่างง่ายที่เรียกว่าเมธอด System.currentTimeMillis() หนึ่งร้อยล้านครั้งในลูป การรันแอปพลิเคชันแสดงให้เห็นว่าใช้เวลา 13 วินาทีในการดำเนินการบน CentOS และประมาณ 68 วินาทีบน Ubuntu เช่น ช้าลง 5 เท่า โปรแกรมที่คล้ายกันนี้เขียนด้วยภาษา C ซึ่งเรียกฟังก์ชัน gettimeofday() กว่าร้อยล้านครั้ง แต่เมื่อดำเนินการ ก็ได้รับผลลัพธ์ที่คล้ายกัน

เนื่องจากเห็นได้ชัดว่าสาเหตุของปัญหาคือหน้าที่ในการส่งคืนเวลาปัจจุบัน ความสนใจจึงหันไปที่การเปลี่ยนแปลงตัวบ่งชี้เมื่อเลือกแหล่งที่มาของเวลาที่แน่นอนในระบบ เมื่อพิจารณาจากเนื้อหาของ “/sys/devices/system/clocksource/clocksource0/current_clocksource” ตัวจับเวลา “xen” ถูกใช้เป็นค่าเริ่มต้นเมื่อรัน Linux ในระบบเกสต์ หลังจากเปลี่ยนแหล่งเวลาเป็น "tsc" เวลาดำเนินการของแอปพลิเคชันทดสอบใน Ubuntu ลดลงจาก 68 เป็น 3.3 วินาที เช่น มันเร็วขึ้น 20 เท่า นอกจากนี้ ยังได้ดำเนินการทดสอบประสิทธิภาพของแหล่งเวลา kvm-clock ซึ่งแสดงให้เห็นความล่าช้าเพิ่มขึ้น 20% เมื่อเทียบกับ TSC $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ เวลา java TimeBench ผู้ใช้จริง 1m8.300s 0m38.337s sys 0m29.875s $ echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ เวลา java TimeBench ผู้ใช้ 0m3.370s จริง 0m3.353s sys 0m0.026s

ในการรับเวลาในการเลือกแหล่ง TSC จะใช้คำสั่งตัวประมวลผล RDTSC ซึ่งการดำเนินการนั้นไม่จำเป็นต้องมีการเรียกระบบ (คำสั่งไม่ต้องการสิทธิ์ระดับสูงและสร้างค่าจากตัวนับเวลาที่สร้างไว้ใน CPU) ตามค่าเริ่มต้น TSC จะไม่เปิดใช้งานเนื่องจากในสมัยก่อนแหล่งข้อมูลนี้ไม่ได้ยกเว้นการเคลื่อนตัวของเวลาแบบค่อยเป็นค่อยไป ซึ่งในโปรเซสเซอร์อื่นๆ จะถูกปรับโดยซอฟต์แวร์เพื่อให้ได้การอ่านที่แม่นยำยิ่งขึ้น ตามที่วิศวกรที่เชี่ยวชาญด้านการพัฒนาโปรเซสเซอร์กล่าวไว้ ความกังวลเกี่ยวกับการเปลี่ยนแปลงเวลาเมื่อใช้ TSC นั้นไม่เป็นความจริงมานานแล้ว และในโปรเซสเซอร์สมัยใหม่ แหล่งข้อมูลนี้สามารถสร้างการอ่านที่เสถียรได้นานหลายปี

การเปลี่ยนเซิร์ฟเวอร์ที่ใช้งานจริงที่ Netflix ไปเป็นแหล่งที่มาของ TSC ส่งผลให้เวลาแฝงในการเขียนลดลง 43% และได้ผลลัพธ์เมื่อใช้ Ubuntu ซึ่งเร็วกว่าการกำหนดค่าที่ใช้ CentOS ด้วยแหล่งเวลา "xen" ถึง 4 เท่า ผลการศึกษาถูกถ่ายโอนไปยัง Amazon ซึ่งได้รับการแนะนำอย่างเป็นทางการโดยใช้แหล่งเวลาเริ่มต้นของ TSC ในสภาพแวดล้อม AWS EC2 ที่ใช้ไฮเปอร์ไวเซอร์ Xen (kvm-clock ยังคงแนะนำให้ใช้ในสภาพแวดล้อมที่ใช้ไนโตรไฮเปอร์ไวเซอร์)

ที่มา: opennet.ru