คู่มือเกมแลค › L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)
ความหน่วงพุ่งจากการจัดการพลังงานของเซิร์ฟเวอร์ (C-state/การปรับความถี่) CPU power management latency (C-states, frequency scaling)
ID สาเหตุ so-cstate · ผู้รับผิดชอบหลัก อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
คอร์ CPU ที่ว่างจะเข้าโหมดประหยัดพลังงานระดับลึก (C-state) และลดความถี่ลงเพื่อประหยัดไฟ เมื่อแพ็กเก็ตหรือตัวจับเวลามาถึง ต้องใช้เวลาตื่นและเพิ่มความถี่ การประมวลผลแพ็กเก็ตเล็ก ๆ จึงมีดีเลย์เพิ่มขึ้น
ทำไม นโยบายปรับความถี่ของ OS (governor) หรือการตั้งค่าพลังงานใน BIOS ยอมให้ใช้ C-state ระดับลึกและความถี่ต่ำ → ผลคือ คอร์ที่ว่างอยู่ตื่นช้าสูงสุดหลายร้อย µs ทุกครั้งที่ออกจากโหมดประหยัดพลังงานระดับลึก และถ้าความถี่ถูกตรึงไว้ต่ำ การคำนวณทิกเองก็ช้าลง → บนหน้าจอ ปกติรู้สึกได้ยาก แต่ถ้าเรียกกันระหว่างเซิร์ฟเวอร์บ่อย ดีเลย์จะสะสมเป็นอินพุตดีเลย์ที่กลับหนักขึ้นตอนเซิร์ฟเวอร์ว่าง ถ้าความถี่ถูกตรึงไว้ต่ำ ตอนคนแห่มารวมกันทิกจะตามไม่ทันจนเป็นสโลว์โมชั่น
อาการ อินพุตดีเลย์ , สโลว์โมชั่น ปัจจัย ความหน่วง, จิตเตอร์, การหยุดชะงัก
ใครเจอ ทั้งเซิร์ฟเวอร์
เกิดเมื่อไร ตลอดเวลา, สุ่มเป็นครั้งคราว
ผู้รับผิดชอบ ผู้รับผิดชอบหลัก อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา)
งานฝั่งทีมอินฟรา ตั้งค่าพลังงานใน BIOS ไปทางประสิทธิภาพ, ตั้ง governor ของ OS เป็น performance (scaling_governor ของ cpufreq), จำกัด C-state ระดับลึกบนเซิร์ฟเวอร์ที่ไวต่อความหน่วง (โปรไฟล์ tuned latency-performance, /dev/cpu_dma_latency ของ PM QoS, พารามิเตอร์เคอร์เนล intel_idle.max_cstate), หลังเปลี่ยนให้เทียบเวลาไปกลับภายในดาต้าเซ็นเตอร์เดียวกัน จิตเตอร์ของเวลาต่อทิก และการใช้พลังงานไปพร้อมกัน
ตัวเลขที่ควรรู้ ตารางของไดรเวอร์ intel_idle ใน Linux 6.12 ระบุว่า CPU เซิร์ฟเวอร์ของ Intel ใช้เวลาตื่นจาก C1 (ระดับตื้น) 1–2 µs และจาก C6 (ระดับลึก) 133 µs (Skylake-SP) ถึง 290 µs (Sapphire Rapids) ครั้งเดียวถือว่าน้อย แต่ถ้าคำขอหนึ่งต้องผ่านเซิร์ฟเวอร์หลายเครื่อง ดีเลย์ก็สะสมตามจำนวนนั้น เคอร์เนลจะเลือกสถานะที่ลึกขึ้นเมื่อคาดว่าจะว่างนานขึ้น อาการนี้จึงพบบ่อยกว่าบนเซิร์ฟเวอร์ที่ว่างซึ่งแพ็กเก็ตมาห่าง ๆ governor แบบ powersave ของ cpufreq ทั่วไปจะตรึงความถี่ไว้ที่ค่าต่ำสุดในช่วงที่อนุญาต (ส่วนอัลกอริทึมชื่อเดียวกันของ intel_pstate จะปรับตามโหลด)
บนกราฟ จุดที่ต้องดู สัดส่วนเวลาที่แต่ละคอร์อยู่ในแต่ละ C-state และความถี่จริงจาก cpupower monitor, name, latency (µs ที่ใช้ตื่น) และ usage ของแต่ละ state ใต้ /sys/devices/system/cpu/cpu0/cpuidle/, scaling_governor ของ cpufreq และโปรไฟล์ปัจจุบันจาก tuned-adm active สัญญาณว่าใช่ ตอนว่าง คอร์อยู่ใน C-state ลึกสุดเป็นเวลานาน หรือความถี่ถูกตรึงไว้ใกล้ค่าต่ำสุด และเมื่อเปลี่ยนเป็น performance governor กับ C-state ระดับตื้น เวลาไปกลับและจิตเตอร์ของคำขอเล็ก ๆ ลดลง สัญญาณว่าไม่ใช่ เปลี่ยนแล้วต่างกันไม่เกินหลักสิบ µs: ข้ามสาเหตุนี้ได้ ถ้าพุ่งในระดับ ms ให้ดู “CPU steal (VM)” หรือชั้นอื่น วิธีตรวจ ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
รายละเอียดเพิ่มเติม เซิร์ฟเวอร์ bare-metal ใน IDC ต้องดูการตั้งค่าพลังงานใน BIOS (เฟิร์มแวร์) ควบคู่กับการตั้งค่าของ OS ส่วนบนคลาวด์ มีเพียงอินสแตนซ์บางประเภทที่ OS เปลี่ยน C-state และความถี่ได้ และ AWS ตั้งค่าเริ่มต้นไว้ทางประสิทธิภาพสูงสุด ส่วนใหญ่จึงปล่อยไว้ตามเดิมได้ โปรไฟล์ tuned latency-performance ของตระกูล Red Hat ตั้ง governor เป็น performance และใช้ PM QoS ให้ใช้เฉพาะ C-state ระดับตื้น การปิดโหมดประหยัดพลังงานทำให้ใช้ไฟมากขึ้น จึงควรใช้เฉพาะกับเซิร์ฟเวอร์ที่ไวต่อความหน่วง
แหล่งอ้างอิง CPU Idle Time Management Linux kernel โหมดประหยัดพลังงานแต่ละระดับมีเวลาตื่น (exit latency) และเวลาอยู่ขั้นต่ำ (target residency) และจะเลือกสถานะลึกตามเวลาว่างที่คาดไว้, latency, usage และ time ของแต่ละ state ใน sysfs, จำกัดสถานะลึกด้วย PM QoS (/dev/cpu_dma_latency) และ intel_idle.max_cstate drivers/idle/intel_idle.c (Linux v6.12) Linux kernel เวลาตื่นของแต่ละ C-state บน CPU เซิร์ฟเวอร์ของ Intel: Skylake-SP (C1 2 µs, C1E 10 µs, C6 133 µs), Ice Lake (C6 170 µs), Sapphire Rapids (C1 1 µs, C6 290 µs) CPU Performance Scaling Linux kernel ตรวจและเปลี่ยน governor ด้วย scaling_governor, performance จะขอความถี่สูงสุดในช่วงที่อนุญาต, powersave ขอความถี่ต่ำสุด intel_pstate CPU Performance Scaling Driver Linux kernel อัลกอริทึม powersave ของ intel_pstate ต่างจาก powersave governor ทั่วไป คือปรับตามโหลด (คล้าย schedutil และ ondemand) Chapter 2. Getting started with TuneD Red Hat โปรไฟล์ latency-performance ปิดฟีเจอร์ประหยัดพลังงาน ตั้ง governor เป็น performance และใช้ PM QoS ให้ใช้เฉพาะ C-state ระดับตื้น, ตรวจโปรไฟล์ปัจจุบันด้วย tuned-adm active tools/power/cpupower/man/cpupower-monitor.1 (Linux v6.12) Linux kernel cpupower monitor: สถิติความถี่และโหมดประหยัดพลังงานแยกตามคอร์ Processor state control for Amazon EC2 Linux instances AWS มีเพียงอินสแตนซ์บางประเภทที่ OS ควบคุม C-state และ P-state ได้ และปรับเพื่อลดความหน่วงได้, ค่าเริ่มต้นเป็นประสิทธิภาพสูงสุดซึ่งเหมาะกับงานส่วนใหญ่, Graviton ใช้ความถี่คงที่ OS จึงไม่ได้ควบคุม สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (อินพุตดีเลย์)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง