한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Buku Putih Lag Game › L7 OS server (kernel)

Lonjakan latensi akibat manajemen daya server (C-state, pengaturan frekuensi) CPU power management latency (C-states, frequency scaling)

ID penyebab so-cstate · Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)

Buka kartu interaktif dengan gambar dan simulasi →

Core CPU yang sedang menganggur masuk ke mode hemat daya yang dalam (C-state) dan menurunkan frekuensinya untuk menghemat listrik. Saat paket atau timer datang, core butuh waktu untuk bangun dan menaikkan frekuensi, sehingga pemrosesan paket kecil mendapat tambahan latensi.

Mengapa Kebijakan pengaturan frekuensi OS (governor) atau pengaturan daya BIOS mengizinkan C-state yang dalam dan frekuensi rendah → Akibatnya Setiap kali core yang menganggur bangun dari mode hemat daya yang dalam, ada keterlambatan hingga ratusan µs; jika frekuensi tertahan rendah, perhitungan tick itu sendiri menjadi lambat → Di layar Biasanya sulit dirasakan, tetapi jika pemanggilan antarserver banyak, keterlambatan menumpuk dan muncul input lag yang justru terjadi saat server sepi. Jika frekuensi tertahan rendah, tick tertinggal saat pemain ramai dan terjadi slow motion

Gejala
Input lag, Slow motion
Faktor
Latensi, Jitter, Stall
Siapa yang mengalami
Seluruh server
Kapan
Selalu, Sesekali secara acak
Penanggung jawab
Penanggung jawab utama Infrastruktur server (Tim Infrastruktur)
Tugas Tim Infrastruktur
Atur daya BIOS ke mode performa, set governor OS ke performance (scaling_governor di cpufreq), batasi C-state yang dalam pada server yang peka latensi (profil tuned latency-performance, /dev/cpu_dma_latency di PM QoS, parameter kernel intel_idle.max_cstate), setelah diubah bandingkan waktu pulang-pergi di dalam data center yang sama, jitter waktu tick, dan pemakaian daya.
Kisaran angka
Menurut tabel driver intel_idle di Linux 6.12, C1 yang dangkal pada CPU server Intel butuh 1–2 µs untuk bangun, sedangkan C6 yang dalam butuh 133 µs (Skylake-SP) hingga 290 µs (Sapphire Rapids). Sekali saja memang kecil, tetapi jika satu permintaan melewati beberapa server, keterlambatan itu menumpuk sebanyak jumlah servernya. Kernel memilih state yang makin dalam jika waktu idle yang diperkirakan makin panjang, jadi gejala ini lebih sering muncul di server sepi yang paketnya datang jarang-jarang. Governor powersave pada cpufreq umum mengunci frekuensi di nilai terendah dalam rentang yang diizinkan (algoritma intel_pstate dengan nama yang sama mengatur frekuensi sesuai beban).
Di grafik
Selalu tinggi sejak awal · Waktu pulang-pergi di dalam data center yang sama, frekuensi core
Yang diperiksa
Periksa persentase waktu di setiap C-state per core dan frekuensi sebenarnya dengan cpupower monitor, lalu periksa name, latency (µs yang dibutuhkan untuk bangun), dan usage tiap state di bawah /sys/devices/system/cpu/cpu0/cpuidle/, scaling_governor di cpufreq, serta profil aktif dengan tuned-adm active
Cocok jika
Saat sepi, core lama berada di C-state terdalam atau frekuensinya tertahan di dekat nilai terendah, dan setelah diganti ke governor performance dan C-state dangkal, waktu pulang-pergi dan jitter permintaan kecil berkurang
Tidak cocok jika
Setelah diubah selisihnya hanya puluhan µs atau kurang: penyebab ini bisa diabaikan. Melonjak dalam satuan ms: lebih mungkin “CPU steal (virtual machine)” atau lapisan lain
Sarana pemeriksaan
Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut
Untuk server bare metal di data center, periksa pengaturan daya BIOS (firmware) bersama pengaturan OS. Di cloud, hanya sebagian jenis instance yang mengizinkan OS mengubah C-state dan frekuensi; di AWS, pengaturan default mengutamakan performa maksimum, jadi sebagian besar bisa dibiarkan apa adanya. Profil tuned latency-performance di keluarga Red Hat menetapkan governor ke performance dan memakai PM QoS agar hanya C-state dangkal yang dipakai. Mematikan fitur hemat daya menaikkan konsumsi listrik, jadi terapkan hanya pada server yang peka terhadap latensi.

Sumber

  1. CPU Idle Time Management Linux kernel
    Setiap mode hemat daya punya waktu bangun (exit latency) dan waktu tinggal minimum (target residency), dan state yang dalam dipilih sesuai waktu idle yang diperkirakan; latency, usage, dan time per state ada di sysfs; state yang dalam dibatasi dengan PM QoS (/dev/cpu_dma_latency) dan intel_idle.max_cstate
  2. drivers/idle/intel_idle.c (Linux v6.12) Linux kernel
    Waktu bangun per C-state pada 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
  3. CPU Performance Scaling Linux kernel
    Periksa dan ubah governor dengan scaling_governor; performance meminta frekuensi tertinggi dalam rentang yang diizinkan, powersave meminta frekuensi terendah
  4. intel_pstate CPU Performance Scaling Driver Linux kernel
    Algoritma powersave pada intel_pstate berbeda dari governor powersave umum karena mengatur frekuensi sesuai beban (mirip schedutil dan ondemand)
  5. Chapter 2. Getting started with TuneD Red Hat
    Profil latency-performance mematikan fitur hemat daya, menetapkan governor ke performance, dan memakai PM QoS agar hanya C-state dangkal yang dipakai; profil aktif diperiksa dengan tuned-adm active
  6. tools/power/cpupower/man/cpupower-monitor.1 (Linux v6.12) Linux kernel
    cpupower monitor: statistik frekuensi dan mode hemat daya per core
  7. Processor state control for Amazon EC2 Linux instances AWS
    Hanya sebagian jenis instance yang mengizinkan OS mengontrol C-state dan P-state, dan keduanya bisa diubah untuk menurunkan latensi; pengaturan default adalah performa maksimum sehingga cocok untuk sebagian besar beban kerja; Graviton memakai frekuensi tetap sehingga OS tidak mengontrolnya

Lihat juga

Lapisan yang sama: L7 OS server (kernel)

Penyebab di lapisan lain dengan gejala yang sama (Input lag)

Lihat kartu interaktif dengan gambar dan simulasi