Troubleshoot Softirq CPU Tinggi: Panduan Lengkap 2026

Aku masih inget kejadian itu. Tahun 2023, jam 3 pagi, dan aku yang waktu itu masih dianggap NOC junior dapat notifikasi dari monitoring. Salah satu server production client, load average naik drastis dari 2 ke 18 dalam waktu satu jam, padahal traffic-nya segitu-segitu aja. Gak ada spike, gak ada serangan, gak ada yang aneh di aplikasi. Aku buka top, dan di situ kelihatan jelas: kolom %si di beberapa core makan 40-60%, sementara %us biasa-biasa aja. Terus ksoftirqd muncul di daftar proses teratas. Waktu itu aku cuma mikir, server ini kena apa sih?

Ibarat antre di bank yang tiba-tiba cuma nyisain satu loket buat ngurus semua transaksi. User tetap bisa masuk ke aplikasi, tapi semuanya kayak jalan di tempat, karena satu loket itu kewalahan. Nah, %si itu ceritanya mirip. Bukan aplikasi-mu yang lemot, bukan juga disk yang penuh — tapi kernel-nya sendiri yang kewalahan di bagian pemrosesan interrupt (softirq). Dari insiden itu aku belajar satu hal yang sekarang hampir tiap minggu kepake: sebelum panik restart, cek dulu softirq-e. Di artikel ini aku mau ceritain step-by-step lengkap, biar kalau suatu hari kamu ngalamin hal yang sama, kamu gak perlu ngalamin masa bingung kayak aku dulu. Dan kalau belum familiar soal load average, cek dulu panduan baca load average Linux biar konteksnya nyambung.

Masalah: Softirq CPU Tinggi Itu Bukan Sekadar CPU Tinggi

Soalnya bukan cuma sekadar angka CPU yang tinggi. Ketika softirq CPU tinggi udah kena ke production, dampaknya bertingkat: latency aplikasi naik, throughput turun, koneksi TCP yang setengah jalan mulai ngebuset, dan dalam kasus parah ada aja request yang ke-drop. User ngerasainnya sebagai ‘website-nya lemot’, padahal akar masalahnya bukan di web server. Kalau dibiarkan, kebiasaan nge-restart server tiap kali begini itu cuma nunda masalah — dan di level production, restart itu sendiri udah jadi downtime yang dihitung sama client.

Softirq (software interrupt) itu mekanisme kernel buat nunda pekerjaan interrupt ke waktu yang lebih aman. Bedanya sama hardirq: hardirq itu kerjaan cepat yang langsung diproses pas interrupt masuk — kayak resepsionis yang cuma nerima kartu nama — sementara softirq itu kerjaan lanjutannya yang lebih lama, kayak admin yang baru ngurus kartu nama itu satu-satu. Kalau paket jaringan datangnya kebanyakan, antrean softirq ikut membeludak, dan kernel mulai ngerekrut ksoftirqd buat bantu-bantu. Ksoftirqd yang muncul di daftar proses itu sinyalnya: softirq udah lewat batas dan mulai jatah CPU. Kalau kamu pegang VPS dan lagi galau masalah performance, mampir juga ke artikel soal cek CPU steal di VPS Proxmox, karena gejalanya bisa mirip-mirip.

Penyebabnya biasanya bukan satu, tapi campuran. Yang paling sering aku temui di lapangan: (1) interrupt storm dari satu interface, biasanya karena burst paket kecil tapi jumlahnya gila-gilaan; (2) NIC single-queue yang semua RX-nya numpuk di satu core, apalagi kalau irqbalance mati; (3) offload GRO/GSO yang ke-disable diam-diam, entah karena salah setting atau ganti driver; (4) traffic dari veth atau container (Docker, OpenVZ) yang numpuk di softirq NET_RX dan SCHED; dan (5) kernel bug atau regresi di versi tertentu. Nah, buat tau yang mana yang lagi jahat di server-mu, kita harus baca data dulu — bukan nebak. Nih, mulai dari yang paling dasar.

Langkah 1: Konfirmasi Dulu, Jangan Nebak

Sebelum ngubah apa-apa, pastiin dulu ini beneran masalah softirq. Buka terminal dan jalanin ini:

mpstat -P ALL 1

Perhatiin kolom %si. Kalau ada core yang konsisten di atas 30-40% dan nilainya naik terus, plus %usr tenang, kemungkinan besar ini masalah softirq. Kalau yang tinggi justru %usr atau %sys, ceritanya beda lagi dan artikel ini bukan tempatnya. Sambil mpstat jalan, cek juga:

top -d 1

Di top, lihat field %Cpu(s) bagian si. Terus scroll ke daftar proses — kalau ada ksoftirqd/x yang duduk di posisi atas dengan pemakaian CPU gede, tebakanku makin kuat.

Langkah 2: Baca /proc/softirqs — Ini Kunci Utamanya

Aku selalu bilang ke tim, kalau mau paham softirq, rumahnya ada di /proc/softirqs. File ini nunjukin hitungan per-vector dan per-CPU, jadi langsung kelihatan jenis softirq mana yang lagi ngebut:

cat /proc/softirqs

Biar keliatan trend-nya naik apa nggak, jalanin pakai watch biar update tiap detik:

watch -n1 cat /proc/softirqs

Nah, bandingin angka NET_RX antar core. Kalau kebanyakan numpuk di satu atau dua core aja, itu petunjuk kuat: interrupt-nya gak terdistribusi. Itu nanti bakal kita beresin di langkah RPS dan IRQ affinity.

Langkah 3: Cek /proc/interrupts dan irqtop

Lanjut, cek siapa yang ngirim interrupt sebanyak itu. Catatan interrupt per device ada di /proc/interrupts:

cat /proc/interrupts

Kolom paling kanan itu nama device. Cari yang namanya eth atau enp (biasanya NIC PCIe). Kalau angka di kolom interrupt-nya naik puluhan ribu dalam hitungan detik, itu interrupt storm. Biar lebih enak dilihat, kalau kernel-mu 5.14 ke atas ada tool irqtop:

irqtop

irqtop itu kayak top-nya /proc/interrupts — nunjukin interrupt per CPU secara real-time. Dengan irqtop kamu bisa langsung lihat core mana yang lagi gempor dilanda interrupt, dan dari NIC mana.

Langkah 4: Cari Interface yang Lagi Teriak

Setelah tau arah interrupt-nya, sekarang cari tahu dari mana paketnya. Mulai dari statistik NIC:

ethtool -S eth0 | grep -iE "rx_packets|rx_missed|dropped|error"

Perhatiin kolom yang naiknya gak wajar. rx_missed yang naik cepat artinya NIC udah kewalahan dan mulai buang paket. Terus, buat tau pola traffic-nya:

iftop -i eth0 -n

Dan kalau perlu dibedah lebih dalam, ambil sample-nya:

tcpdump -i eth0 -n -c 100

Kalau ternyata yang teriak itu bukan interface fisik tapi veth (docker0, vethxxxx), berarti ceritanya container. Softirq NET_RX dan SCHED yang tinggi dari arah veth itu klasik. Tapi balik ke tujuan utama kita: cari tahu dulu mana yang numpuk, baru putusin solusinya.

Langkah 5: Fix #1 — RPS dan XPS

Masuk bagian yang paling sering jadi penyelamat: RPS (Receive Packet Steering) dan XPS (Transmit Packet Steering). Prinsipnya gampang — kalau NIC-mu single-queue, semua paket masuk diproses kernel di satu core doang, dan core itu tenggelam. RPS itu trik buat nyebarin pemrosesan paket ke core-core lain. Cek dulu ada queue berapa:

ls /sys/class/net/eth0/queues/

Kalau cuma rx-0, berarti single-queue. Nah, aktifkan RPS ke core 0 sampai 3. Bitmask pakai hex: core 0-3 itu f (core 0-7 = ff, 0-15 = ffff, dan seterusnya):

echo f | sudo tee /sys/class/net/eth0/queues/rx-0/rps_cpus
echo 4096 | sudo tee /sys/class/net/eth0/queues/rx-0/rps_flow_cnt

RPS doang gak berasa lengkap tanpa RFS (Receive Flow Steering) — biar flow yang sama tetep diproses di core yang sama, jadi cache CPU-nya hangat. Aktifkan lewat sysctl:

sysctl -w net.core.rps_sock_flow_entries=32768

Ingat: total rps_flow_cnt dari semua queue gak boleh melebihi rps_sock_flow_entries. Dan semua perubahan di sysfs ini gak persisten — habis reboot ilang. Kalau mau permanen, taruh di script rc.local atau systemd unit. Sempat-sempatnya, baca juga artikel tuning kernel Linux buat production buat konteks sysctl lain yang saling nyambung.

Langkah 6: Fix #2 — IRQ Affinity dan irqbalance

Kalau NIC-mu multi-queue, sebenarnya lebih clean pakai RSS plus IRQ affinity daripada RPS. Tapi pertanyaan besarnya: apakah irqbalance jalan? Cek:

systemctl status irqbalance

Kalau mati, hidupin dan set biar nyala tiap boot:

systemctl enable --now irqbalance

irqbalance bakal otomatis nyebarin interrupt ke semua core. Kalau server-mu punya banyak core dan paket masuknya gede, kadang aku lebih prefer setting IRQ affinity manual — kayak ngunci queue 0 ke core 0-3, queue 1 ke core 4-7, dst. Tapi buat mayoritas kasus, irqbalance plus RSS udah cukup. Nek gak yakin, mulai dari irqbalance dulu, ukur lagi, baru naik level ke affinity manual.

Langkah 7: Fix #3 — Aktifkan Offload NIC

Yang ini sering banget ketemu di server hasil migrasi atau restore config lama: GRO, GSO, dan TSO ke-disable diam-diam. Kalau offload mati, kernel harus ngerjain lebih banyak kerjaan per paket, dan softirq langsung naik. Cek status offload sekarang:

ethtool -k eth0

Cari baris-baris ini:

generic-receive-offload: on
generic-segmentation-offload: on
tcp-segmentation-offload: on

Kalau ada yang off, aktifin:

ethtool -K eth0 gro on gso on tso on

Yang GRO ini pengaruhnya signifikan banget buat NET_RX. Tapi catatan penting: kalau kamu pake bond mode tertentu atau VLAN, atau ada isu CRC dari provider, offload bisa bikin error. Jadi selalu pantau ethtool -S dan dmesg habis ngubah.

Langkah 8: Fix #4 — Tuning Kernel netdev_budget

ksoftirqd tinggi itu tanda kernel udah ngelakuin kerjaan softirq lebih dari budget yang dialokasikan. Budget ini diatur lewat net.core.netdev_budget dan net.core.netdev_budget_usecs. Nilai default biasanya 300. Kalau traffic deras, kita bisa kasih nafas lebih:

sysctl -w net.core.netdev_budget=600
sysctl -w net.core.netdev_budget_usecs=8000

Biar persist, taruh di /etc/sysctl.d/99-netdev.conf:

net.core.netdev_budget = 600
net.core.netdev_budget_usecs = 8000

Lalu apply dengan sysctl –system. Ini bukan magic bullet, tapi sering banget bantu ngecilin tekanan di ksoftirqd.

Langkah 9: Fix #5 — Multi-Queue RSS dan Upgrade Driver/Kernel

Kalau NIC-mu sebenarnya multi-queue tapi cuma jalan satu queue, sayang banget. Cek:

ethtool -l eth0

Bagian Combined itu jumlah queue yang aktif. Kalau kelihatan 1 padahal max-nya 8, aktifin:

ethtool -L eth0 combined 8

RSS bakal otomatis nyebarin paket ke queue-queue tadi, dan ini yang paling clean dibanding RPS. Kalau setelah semua langkah masih tinggi, cek versi driver dan kernel:

ethtool -i eth0
uname -r

Kadang jawaban paling jujur adalah upgrade kernel. Ada beberapa versi kernel dengan regresi netstack yang fix-nya cuma ada di rilis lebih baru. Selalu test di staging dulu sebelum sentuh production.

Tabel Ringkas: Gejala ke Penyebab ke Solusi

Verifikasi: Ini Bukti yang Kamu Cari

Setelah semua fix dipasang, jangan langsung tutup ticket. Pantau beberapa menit:

mpstat -P ALL 1
watch -n1 cat /proc/softirqs

Targetnya: %si turun, ksoftirqd gak lagi di daftar proses teratas, dan NET_RX di /proc/softirqs udah gak nyembur. Aku juga suka nyalain sar buat bandingin grafik sebelum dan sesudah:

sar -u -P ALL 1 5

Kalau ini production, jangan lupa update changelog atau info client — perubahan netstack itu selalu harus dicatat. Dan kalau mau insiden kayak gini ketahuan lebih cepet, setup monitoring server pakai Netdata biar alert-nya nyampe sebelum user ngerasain.

FAQ

Pernah ngalamin kasus softirq yang arahnya beda tapi tetep bikin pusing? Cerita di komentar ya — sopo ngerti, mungkin kamu punya cara yang justru lebih efektif dari yang aku tulis di sini. Aku juga masih terus belajar soal netstack, jadi pengalaman kalian itu berharga banget. Kalau mau refresh dasar, mampir ke artikel soal cara baca load average atau setup monitoring Netdata biar insiden kayak gini bisa ketahuan lebih cepet. Matur nuwun udah baca sampe sini!