Diagnosa Anomali: Utilisasi CPU Rendah, Latensi Melonjak

Pola insiden pasca-deployment yang sering membingungkan engineer adalah lonjakan p99 latency HTTP/gRPC tanpa kenaikan utilisasi CPU yang sepadan. Dasbor monitoring APM (Application Performance Monitoring) mungkin menunjukkan utilisasi CPU container hanya berada di kisaran 30% hingga 40%, tetapi thread aplikasi tertahan hingga ratusan milidetik.

Akar masalah kasus ini umumnya berada di Linux kernel scheduler, khususnya Completely Fair Scheduler (CFS) quota throttling pada Linux Control Groups (cgroups). Metrik utilisasi CPU standar menghitung rata-rata penggunaan komputasi dalam jendela waktu relatif besar (misalnya 15-60 detik). Sebaliknya, CFS enforcement bekerja dalam rentang mikro-periode (default 100ms). Ketika thread aplikasi menggunakan jatah kuotanya terlalu cepat di awal periode, Linux scheduler memutus akses CPU hingga periode berikutnya dimulai, menciptakan runqueue starvation.

Mengapa Metrik Rata-Rata CPU Menyesatkan

CFS quota bekerja menggunakan dua parameter utama:

  • cpu.cfs_period_us: Jendela siklus enforcement (umumnya 100.000 µs atau 100 ms).
  • cpu.cfs_quota_us: Alokasi total waktu eksekusi CPU yang diizinkan untuk grup thread per periode.

Jika sebuah container memiliki alokasi 2.0 CPU, kernel menetapkan quota = 200ms per period = 100ms. Apabila aplikasi backend multithreaded (misalnya runtime Go, Java, atau Node.js worker pool) menjalankan 8 thread konkuren secara intensif, alokasi 200ms tersebut habis hanya dalam 25ms pertama (8 thread * 25ms = 200ms).

Dampaknya, seluruh 8 thread dibekukan (throttled) selama sisa 75ms siklus tersebut. Dalam rentang pemantauan 1 menit, konsumsi CPU hanya terlihat 25% hingga 33%, tetapi transaksi HTTP mengalami jeda paksa 75ms berulang kali di layer OS scheduler.

Observasi Lapangan: Membaca Metrik Scheduler Linux

Untuk memverifikasi hipotesis throttling tanpa bergantung pada metrik APM level tinggi, gunakan interface Linux cgroup dan tool diagnostik performa kernel langsung dari host atau container shell.

1. Cgroup CPU Stat Interface

Pada cgroup v2 (standar modern Kubernetes/containerd), baca metrik langsung dari pseudo-filesystem:

cat /sys/fs/cgroup/cpu.stat
# Output:
# usage_usec 184520392
# user_usec 142103902
# system_usec 42416490
# nr_periods 12450
# nr_throttled 4310
# throttled_usec 928340120

Jika persentase nr_throttled / nr_periods melebihi 5-10%, container mengalami degradasi performa aktif akibat batas scheduler.

Untuk cgroup v1 legasi:

cat /sys/fs/cgroup/cpu/cpu.stat
# Periksa field: nr_periods, nr_throttled, throttled_time

2. Runqueue Latency via /proc/schedstat

File /proc/schedstat mencatat counter scheduler kernel secara mendalam. Tiga nilai penting per core CPU mencakup:

  1. Waktu menjalankan task (cpu execution time).
  2. Waktu task menunggu di runqueue sebelum dieksekusi (runqueue latency / wait time).
  3. Jumlah time-slices yang dijalankan kernel.

Pemeriksaan cepat lonjakan waktu tunggu antrean thread:

awk '{print "CPU: " $1, "Wait time (ns): " $8, "Run slices: " $9}' /proc/schedstat

Alternatif lebih mudah adalah menggunakan pidstat dari package sysstat untuk melihat metrik penundaan scheduling (%wait):

pidstat -u -w -p <PID> 1 5

Bila kolom %wait bernilai tinggi sementara %CPU di bawah batas kapasitas prosesor, thread aplikasi tertahan di runqueue menunggu giliran eksekusi yang ditahan oleh quota policy atau CPU saturasi di tingkat node.

Canary Mitigation: Alur Safe Rollback Berbasis Latensi Scheduler

Saat deployment baru masuk fase canary (misalnya 10% traffic), integrasikan metrik scheduler ke dalam automated rollback pipeline. Metrik latensi HTTP p99 sering kali terlambat mendeteksi jika threshold monitoring terlalu longgar.

# Contoh Prometheus alert rule untuk deteksi throttling canary
- alert: ContainerCPUThrottlingHigh
  expr: (
      rate(container_cpu_cfs_throttled_periods_total{namespace="production", stage="canary"}[2m])
      /
      rate(container_cpu_cfs_periods_total{namespace="production", stage="canary"}[2m])
    ) * 100 > 15
  for: 1m
  labels:
    severity: critical
  annotations:
    summary: "Canary instance CPU throttling melebihi 15%"

SOP Rollback Otomatis di Canary Stage

  1. Evaluasi Threshold: Monitor metrik container_cpu_cfs_throttled_periods_total dan delta p99 HTTP latency selama 5 menit pertama canary traffic injection.
  2. Drain Traffic: Turunkan routing weight canary ke 0% secara instan via Service Mesh (Istio/Envoy) atau Ingress Controller jika throttling ratio > 15% atau p99 melonjak > 2x baseline.
  3. Ekstraksi State: Jalankan dump thread pool dan salin isi /sys/fs/cgroup/cpu.stat canary pod sebelum pod dimatikan untuk analisis root cause pasca-insiden.
  4. Rollback Workload: Hentikan rollout Deployment controller dan pertahankan replicaset versi stabil.

Pencegahan: Tuning CPU Period dan Quota Limits

Solusi jangka panjang memerlukan kalibrasi tepat antara konfigurasi container limits dan karakteristik concurrency aplikasi runtime.

1. Penyesuaian Quota pada Container Spec

Jika aplikasi membutuhkan konkurensi thread tinggi (misal thread pool worker berukuran 16), jangan batasi pod dengan CPU limit yang terlalu ketat jika period masih default (100ms).

resources:
  requests:
    cpu: "2000m"
    memory: "4Gi"
  limits:
    # Naikkan batas quota atau hapus jika cluster menerapkan policy burstable
    cpu: "4000m"
    memory: "4Gi"

2. Tuning CFS Period untuk Aplikasi Latency-Sensitive

Pada node Kubernetes modern yang mengaktifkan feature gate CustomCPUCFSQuotaPeriod, perpendek periode scheduler dari 100ms menjadi 10ms (10.000 µs). Period yang lebih pendek mengurangi durasi sleep paksa saat kuota terlampaui.

# /var/lib/kubelet/config.yaml
cpuCFSQuota: true
cpuCFSQuotaPeriod: "10ms"

Dampaknya: alokasi CPU didistribusikan ke jendela-jendela mikro yang jauh lebih rapat, menekan jitter runqueue latency dari orde 70ms ke skala sub-5ms tanpa menonaktifkan mekanisme proteksi multi-tenant di host.