Üretimde bazı network incident’ları “servis bozuldu” gibi görünür ama kök sebep kernel’in paket işleme yolunda yaşanan satürasyondur: SoftIRQ artar, ksoftirqd CPU’yu yer, paketler drop olmaya başlar, gecikme yükselir. Bu tablo çoğu zaman “CPU boş görünüyor ama network ölü” şeklinde yanıltır.
Bu runbook; yüksek trafik gateway, NAT, edge proxy, IDS/IPS veya yoğun east-west trafiği olan node’larda, softirq satürasyonunu hızlı triage edip güvenli tuning yapmanız için pratik bir yol sunar.
Ne zaman şüphelenirim?
Şu semptomlar birlikte geliyorsa softirq düşünürüm:
- p95/p99 latency artıyor, error rate yükseliyor
sar -n DEVilerxdrop/txdropartıyortop/htop’taksoftirqdve%si(softirq) yükseliyor- NIC istatistiklerinde
rx_missed_errors,rx_no_buffer, ring overflow benzeri sayaçlar artıyor
0) Güvenlik: İlk 5 dakikada ne yapmam?
- Kernel / NIC tuning’i “panic” ile değiştirirsen yanlış ayar daha büyük kesinti üretir.
- Önce ölç, sonra küçük adım at, her adımda etkisini doğrula.
1) Hızlı triage: 10 komutluk kontrol listesi
1.1 CPU ve softirq dağılımı
mpstat -P ALL 1 5Bak: bazı core’larda %si aşırı mı? Tek core’a yığılma var mı?
1.2 SoftIRQ sayaçları
cat /proc/softirqsBak: NET_RX ve NET_TX hızlı artıyor mu? Tek CPU’da mı?
1.3 NIC drop ve error sayaçları
ip -s link show dev eth0
ethtool -S eth0 | egrep -i 'drop|miss|error|no_buffer|timeout' | head -n 501.4 IRQ dağılımı
cat /proc/interrupts | egrep -i 'eth0|mlx|ixgbe|i40e|ena|virtio' | head -n 20Bak: IRQ’lar tek CPU’da mı toplanmış?
1.5 Socket / TCP durumu (kuyruklar)
ss -s
netstat -s | head -n 801.6 Uygulama tarafı
- Bu node’da aynı anda CPU heavy job var mı?
- IRQ affinity değişti mi? (son config/deploy)
2) Kök neden sınıfları
Softirq incident’ını ben genelde şu sınıflara ayırırım:
- Tek CPU’ya yığılma (IRQ affinity kötü, queue sayısı düşük, irqbalance yanlış)
- NIC ring/queue yetersizliği (burst’te overflow)
- Packet processing maliyeti (conntrack/NAT, iptables/nftables, encapsulation, VXLAN/GRE)
- Driver/firmware (bug, offload uyumsuzluğu)
- Gürültülü komşu (virt üzerinde CPU steal / noisy neighbor)
Bu sınıfı belirlemek, doğru tuning knob’unu seçtirir.
3) Müdahale adımları (kontrollü)
3.1 IRQ affinity düzelt (en sık kazanç)
Amaç: NIC interrupt’larını tek core’a yığma.
irqbalancebazen iyi, bazen kötü çalışır. Üretimde kritik node’larda “bilinçli sabitleme” daha güvenlidir.
Kontrol:
systemctl status irqbalanceUygulama:
- NIC queue sayısına göre CPU core’ları seç
- IRQ → core mapping yap
- Değişim sonrası
/proc/interruptsile dağılımı doğrula
3.2 RX/TX queue sayısını artır
NIC’in desteklediği queue sayısı, paralel paket işleme kapasitesini belirler.
ethtool -l eth0
sudo ethtool -L eth0 combined 8Not: değer, NIC/driver’a göre değişir. Aşırı artırmak da overhead üretir.
3.3 Ring buffer’ı büyüt (burst’te nefes alanı)
ethtool -g eth0
sudo ethtool -G eth0 rx 4096 tx 4096Bu, mikroburs’lerde drop’u azaltabilir. Ama ring büyütmek gecikmeyi az da olsa artırabilir; ölçerek ilerle.
3.4 RPS/RFS (interrupt’tan sonra işi dağıt)
IRQ affinity ile yetmiyorsa, receive path’i dağıtmak için RPS düşünülebilir.
Bu knob’lar güçlüdür ama yanlışsa CPU tüketimini artırır. Bu yüzden:
- Önce IRQ affinity + queue ile dene
- Sonra sınırlı bir RPS ile canary uygula
3.5 Offload ayarları (GRO/LRO/TSO) — dikkatli
Offload’lar CPU’yu azaltabilir ama bazı trafik tiplerinde latency veya debug kabiliyetini etkileyebilir.
ethtool -k eth0 | head -n 40Değişiklikleri kademeli yap, her adımda p95/p99 + drop’ları izle.
4) Doğrulama: “düzeldi” demek için kanıt
Ben şu kanıtları ararım:
rxdrop/txdropsabitlendi veya düştü%sidağıldı (tek core satüre değil)ksoftirqdCPU tüketimi azaldı- Uygulama p95/p99 SLO bandına geri döndü
5) Kalıcı önlem: Alarm ve kapasite
Bu incident’lar tekrar eder. Kalıcı olarak:
softirqoranı için alarm (host-level)- NIC drop/error sayaçları için alarm
- “peak PPS” ve “CPU per packet” için kapasite baseline
- NAT/conntrack kullanıyorsan ayrı bütçe ve limitler
Sonuç
SoftIRQ satürasyonu, doğru runbook ile yönetilebilir bir incident sınıfıdır. Önce ölç, kök neden sınıfını belirle, sonra küçük ve doğrulanabilir adımlarla ilerle: IRQ affinity, queue, ring ve gerekirse RPS. Böylece “network bazen gidiyor” gibi belirsiz şikâyetler, kontrol edilebilir ve tekrarlanabilir bir operasyona dönüşür.