Độ trễ vọt lên do quản lý nguồn điện của server (C-state, điều chỉnh xung nhịp) CPU power management latency (C-states, frequency scaling)

ID nguyên nhân so-cstate · Phụ trách chính Hạ tầng server (Đội hạ tầng)

Mở thẻ gốc có hình minh họa và thí nghiệm →

Core CPU đang rảnh sẽ vào trạng thái tiết kiệm điện sâu (C-state) và hạ xung nhịp để tiết kiệm điện. Khi có gói tin hoặc timer đến, core cần thời gian để thức dậy và nâng xung nhịp, nên việc xử lý gói nhỏ bị cộng thêm độ trễ.

Vì sao Chính sách điều chỉnh xung nhịp (governor) của OS hoặc cấu hình nguồn điện trong BIOS cho phép C-state sâu và xung nhịp thấp → Dẫn đến Mỗi lần thức dậy từ trạng thái tiết kiệm điện sâu, core đang rảnh chậm tối đa vài trăm µs; nếu xung nhịp bị ghim ở mức thấp thì bản thân việc tính tick cũng chậm đi → Trên màn hình Thường khó cảm nhận, nhưng khi có nhiều lời gọi giữa các server, độ trễ cộng dồn thành trễ thao tác, và lúc vắng người phản hồi lại chậm hơn. Nếu xung nhịp bị ghim thấp, lúc đông người tick bị dồn lại, gây quay chậm

Triệu chứng: Trễ thao tác, Quay chậm
Yếu tố: Độ trễ, Jitter, Ngưng trệ
Ai gặp phải: Cả server
Khi nào: Luôn luôn, Thỉnh thoảng bất chợt
Phụ trách: Phụ trách chính Hạ tầng server (Đội hạ tầng)
Việc cần làm (Đội hạ tầng): Chỉnh cấu hình nguồn điện của BIOS sang hướng hiệu năng, đặt governor của OS là performance (scaling_governor của cpufreq), giới hạn C-state sâu trên server nhạy với độ trễ (profile tuned latency-performance, /dev/cpu_dma_latency của PM QoS, tham số kernel intel_idle.max_cstate); sau khi đổi, so sánh cùng lúc thời gian khứ hồi trong trung tâm dữ liệu, jitter của thời gian tick và điện năng tiêu thụ.
Con số tham khảo: Theo bảng của driver intel_idle trong Linux 6.12, CPU server Intel cần 1–2 µs để thức dậy từ C1 (nông) và từ 133 µs (Skylake-SP) đến 290 µs (Sapphire Rapids) từ C6 (sâu). Một lần thì nhỏ, nhưng khi một yêu cầu đi qua nhiều server, độ trễ cộng dồn theo số server đó. Kernel càng dự đoán thời gian rảnh dài thì càng chọn trạng thái sâu, nên hiện tượng này xảy ra thường hơn ở server vắng, nơi gói tin chỉ lác đác đến. Governor powersave của cpufreq chung ghim xung nhịp ở mức thấp nhất trong khoảng cho phép (thuật toán cùng tên của intel_pstate thì điều chỉnh theo tải).
Trên đồ thị: Luôn cao ngay từ đầu · Thời gian khứ hồi trong cùng trung tâm dữ liệu, xung nhịp core
Chỗ cần xem: Tỷ lệ thời gian mỗi core ở từng C-state và xung nhịp thực tế qua cpupower monitor; name, latency (số µs cần để thức dậy) và usage của từng state dưới /sys/devices/system/cpu/cpu0/cpuidle/; scaling_governor của cpufreq; profile hiện tại qua tuned-adm active
Đúng nếu: lúc vắng, core nằm lâu ở C-state sâu nhất hoặc xung nhịp bị ghim gần mức thấp nhất, và khi chuyển sang governor performance cùng C-state nông thì thời gian khứ hồi và jitter của các yêu cầu nhỏ giảm
Loại trừ nếu: sau khi đổi, chênh lệch chỉ trong khoảng vài chục µs → có thể bỏ qua nguyên nhân này. Vọt lên ở mức ms → “CPU steal (máy ảo)” hoặc tầng khác
Cách kiểm tra: Kiểm tra bằng công cụ hạ tầng (không cần code game)
Tìm hiểu thêm: Với server bare-metal trong IDC, hãy xem cấu hình nguồn điện của BIOS (firmware) cùng với cấu hình OS. Trên cloud, chỉ một số loại instance cho phép OS thay đổi C-state và xung nhịp; AWS mặc định ưu tiên hiệu năng tối đa nên phần lớn trường hợp có thể để nguyên. Profile tuned latency-performance trên các bản phân phối họ Red Hat đặt governor là performance và dùng PM QoS để chỉ cho phép C-state nông. Tắt tiết kiệm điện sẽ làm tăng điện năng tiêu thụ, nên chỉ áp dụng cho server nhạy với độ trễ.

Nguồn

CPU Idle Time Management Linux kernel
Mỗi trạng thái tiết kiệm điện có thời gian thức dậy (exit latency) và thời gian lưu lại tối thiểu (target residency), kernel chọn trạng thái sâu theo thời gian rảnh dự đoán; latency, usage và time của từng state trong sysfs; giới hạn trạng thái sâu bằng PM QoS (/dev/cpu_dma_latency) và intel_idle.max_cstate
drivers/idle/intel_idle.c (Linux v6.12) Linux kernel
Thời gian thức dậy theo C-state của CPU server 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
Xem và đổi governor bằng scaling_governor; performance yêu cầu xung nhịp cao nhất trong khoảng cho phép, powersave yêu cầu mức thấp nhất
intel_pstate CPU Performance Scaling Driver Linux kernel
Thuật toán powersave của intel_pstate khác với governor powersave chung: nó điều chỉnh theo tải (tương tự schedutil và ondemand)
Chapter 2. Getting started with TuneD Red Hat
Profile latency-performance tắt các tính năng tiết kiệm điện, đặt governor là performance và dùng PM QoS để chỉ cho phép C-state nông; xem profile hiện tại bằng tuned-adm active
tools/power/cpupower/man/cpupower-monitor.1 (Linux v6.12) Linux kernel
cpupower monitor: thống kê xung nhịp và trạng thái tiết kiệm điện theo từng core
Processor state control for Amazon EC2 Linux instances AWS
Chỉ một số loại instance cho phép OS điều khiển C-state và P-state, và có thể đổi để giảm độ trễ; cấu hình mặc định cho hiệu năng tối đa nên phù hợp với phần lớn khối lượng công việc; Graviton chạy ở xung nhịp cố định nên OS không điều khiển

Nguyên nhân nên xem cùng

Cùng tầng: L7 OS server (kernel)

Nguyên nhân ở tầng khác gây cùng triệu chứng (Trễ thao tác)

Tải render khi đông người L1 Tiến trình game phía client
Nghẽn xử lý gói tin trên main thread L1 Tiến trình game phía client
V-Sync và hàng đợi render L1 Tiến trình game phía client
Chế độ tiết kiệm điện và bóp xung do nhiệt L2 OS và thiết bị phía client
Ứng dụng khác trên cùng thiết bị chiếm giữ băng thông L2 OS và thiết bị phía client
Độ trễ của màn hình, thiết bị nhập và tạo khung hình L2 OS và thiết bị phía client
Kênh Wi-Fi bị nghẽn L3 Mạng gia đình
Bufferbloat (hàng đợi của router) L3 Mạng gia đình

Xem thẻ gốc có hình minh họa và thí nghiệm