Cara Troubleshoot High Context Switches di Linux: Diagnosa Sampai Fix untuk Production Server

Skip basa-basi. Kalau server kamu tiba-tiba lemot, load average naik ke langit, tapi semua proses kelihatan biasa-biasa aja di daftar CPU — besar kemungkinan biang keroknya adalah context switches yang gila-gilaan. Cek dulu pake satu perintah ini: vmstat 1, terus perhatiin kolom cs. Kalau angkanya ratusan ribu per detik, ya itu dia masalahnya.

Gak bakal aku perpanjang dengan teori yang bikin pusing. Artikel ini berisi langkah diagnosa paling cepet sampai fix yang biasanya aku pakai di lapangan buat troubleshoot high context switches linux. Ikutin urut ya, biar gak bolak-balik.

Kenapa Context Switches Tinggi Jadi Masalah Serius di Production?

Masalah utama dari high context switches bukan cuma server yang terasa lambat. Di environment production, dampaknya berantai: latensi request naik, response time membengkak, aplikasi yang sensitif kayak database atau API mulai timeout, dan kalau dibiarkan lama, uptime jadi taruhan. Aku pernah pegang server 16 core yang keload-nya cuma 30 persen, tapi request-nya ngos-ngosan banget. Lucunya, pas dicek, CPU masih banyak idle. Nah, pola kayak gini hampir selalu tanda context switches, bukan CPU exhaustion beneran. Jadi kalau ada yang bilang “server gak dipake tapi lemot”, jangan langsung percaya — cek dulu angkanya.

Kenapa bisa begini? Karena CPU-nya sibuk pindah-pindah tugas ketimbang ngerjain tugas. Ibaratnya admin yang tiap 5 menit ganti pekerjaan — muter terus, gak ada yang kelar. Nah.

Penyebabnya macam-macam. Paling sering: proses sleep-wake yang hiperaktif (kayak worker PHP-FPM atau connection handler), banyak thread yang rebutan lock, interrupt network yang deras (apalagi kalau banyak koneksi pendek kayak short-lived connections), terus setting scheduler yang gak pas kayak sched_autogroup dimatiin, atau cgroup CPU quota yang terlalu ketat. Jangan buru-buru nyalahin kernel. Seringkali musuhnya ada di config aplikasi yang melahirkan thread pendek terus-terusan. Makanya diagnosa dulu, jangan asal reboot. Kalau kamu butuh pijakan dasar soal baca resource server, baca dulu artikel cara troubleshoot high load server biar persepsinya sama.

Langkah 1 — Konfirmasi Dulu, Jangan Nebak

Buka terminal, jalanin ini:

vmstat -w 1 5

Perhatiin kolom cs (context switches per detik) dan in (interrupts per detik). Output-nya kurang lebih begini pas server lagi sakit:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs  us sy id wa st
 6  0      0 152304  12288 2098176    0    0     0     0 45233 287563 45 41 12  2  0

Lihat cs di angka 287 ribu per detik? Itu alarm besar. Kolom sy (system time) yang ikut tinggi juga ngasih konfirmasi tambahan — CPU-nya kebanyakan dipakai buat overhead kernel, bukan kerja user. Buat bandingin historis, pakai sar dari sysstat:

sar -w 1 5

Kolom cswch/s itu jumlah total context switches per detik. Aturan main kasarnya: server biasa di angka puluhan ribu itu wajar. Kalau udah ratusan ribu, berarti ada yang bolak-balik gak jelas. Kalau mau lebih dalam soal baca-baca metrik ini, kamu bisa mampir ke panduan lengkap vmstat dan sar.

Langkah 2 — Cari Pelakunya dengan pidstat

vmstat cuma nunjukin total. Buat nemu siapa pelakunya, pakai pidstat:

pidstat -w 1 5

Output-nya bakal ada kolom cswch/s dan nvcswch/s per proses. Ini kuncinya: cswch itu voluntary context switch — proses ngantri karena nunggu sesuatu (I/O, lock, resource). nvcswch itu involuntary — proses dipaksa keluar karena di-preempt sama scheduler. Kalau nvcswch yang mendominasi, CPU-nya oversubscribe, artinya kebanyakan thread runnable daripada jumlah core. Kalau cswch yang dominan, cari proses yang bangun-tidur terus — itu biasanya sumber masalahnya.

Mau langsung lihat yang paling boros? Jalanin pidstat beberapa detik, lalu eyeballing output-nya. Angka tertinggi di kolom cswch/s atau nvcswch/s itu kandidat utama. Gak perlu tooling ribet, output-nya pendek kok.

Langkah 3 — Bedakan Voluntary dan Involuntary

Ini penting banget, jadi aku taro tabel biar jelas:

Pembedaan ini yang nentuin arah solusi. nvcswch tinggi berarti kamu butuh ngerampingin jumlah thread atau nambah kapasitas CPU. cswch tinggi berarti masalahnya di efisiensi proses: terlalu banyak pooling, koneksi pendek, atau resource yang diperebutkan. Salah diagnosa di sini bikin kamu tuning hal yang salah, dan hasilnya nol.

Langkah 4 — Cek Interrupt dan Softirq

Network interrupt itu biang kerok yang paling sering kelewat. Cek dengan:

watch -n 1 cat /proc/interrupts
mpstat -I CPU 1

Kalau satu core numpuk interrupts doang, core itu bakal kayak satpam yang kebanjiran tamu — gak sempat kerja. Ini umum banget di server yang banyak short-lived connection (kayak web server yang gak pakai keepalive atau load balancer dengan koneksi kecil-kecil). Cek juga irqbalance nyala atau gak:

systemctl status irqbalance

Langkah 5 — Fix yang Paling Sering Kerja

5.1 Nyalain irqbalance

Kalau irqbalance mati, hidupin. Ini nyebarin interrupt ke semua core biar gak numpuk di satu titik:

systemctl enable --now irqbalance

5.2 Kurangi jumlah worker aplikasi

PHP-FPM yang max_children-nya overkill itu penyebab klasik. Worker kebanyakan bikin banyak thread tidur-bangun, dan tiap bangun itu context switch. Atur sesuai memory dan core. Buat panduan lengkapnya, cek artikel optimasi PHP-FPM di VPS.

5.3 Tuning scheduler kernel (hati-hati)

sysctl -w kernel.sched_migration_cost_ns=5000000
sysctl -w kernel.sched_wakeup_granularity_ns=4000000
sysctl -w kernel.sched_autogroup_enabled=1

Biar permanen, simpan di /etc/sysctl.d/99-context-switch.conf. Nilai di atas relatif konservatif — sched_migration_cost yang naek bikin scheduler gak gampang mindahin proses antar core, sementara autogroup bikin sesi-sesi tty jadi satu group yang adil. Kalau mau paham dalem soal setting kernel, baca dulu kernel sysctl tuning buat performance.

5.4 Khusus workload real-time atau latency ekstrem

Untuk yang workload-nya super sensitif (database latensi ekstrem, trading, media streaming), ada opsi kernel command line nohz_full dan rcu_nocbs buat ngurangin timer tick dan RCU di core tertentu. Tapi ini ranah senior. Jangan dicoba malem-malem tanpa rollback plan dan pengujian. Kalau belum paham, skip dulu.

Langkah 6 — Verifikasi Hasilnya

vmstat -w 1 5
sar -w 1 5

Bandingkan angka cs sebelum dan sesudah tuning. Kalau cs turun tapi throughput malah naik, berarti fix-nya jalan. Kalau gak berubah sama sekali, balik ke Langkah 2 dan selidiki lagi — jangan nambah-nambah setting sysctl tanpa data. Jangan lupa jaga-jaga pakai monitoring biar gak nunggu server nangis dulu baru sadar. Kalau belum punya, cek artikel monitoring Linux pakai Netdata sebagai starter.

Tabel Troubleshooting Cepat

FAQ

Sebelum close ticket, pastiin kamu udah cek: 1) baseline cs di vmstat, 2) pidstat -w buat tau siapa pelakunya, 3) config terbaru yang berubah sebelum server lemot. Kalau semuanya kelar, case closed. Done.