Linux sunucularında CPU Interrupt Storm, sistem performansını ciddi şekilde etkileyen yaygın bir sorundur.
Linux sunucularında CPU Interrupt Storm, sistem performansını ciddi şekilde etkileyen yaygın bir sorundur. Bu durum, donanım kesmeleri (IRQ’lar) nedeniyle CPU’ların aşırı yüklenmesiyle ortaya çıkar ve sunucunun yanıt verme süresini dramatik biçimde düşürür. Özellikle yüksek trafikli web sunucuları, veritabanı kümeleri veya sanallaştırma ortamlarında sıkça rastlanır. Bu makalede, interrupt storm’un nedenlerini, tespit yöntemlerini ve çözüm stratejilerini adım adım ele alacağız. Sistem yöneticileri için pratik araçlar ve komutlar üzerinden rehberlik sağlayarak, sorunun kök nedenini bulma ve giderme süreçlerini aydınlatacağız. Bu analiz, sunucu stabilitesini artırmak ve kaynak kullanımını optimize etmek amacıyla kritik öneme sahiptir.
CPU Interrupt Storm, bir veya birden fazla IRQ hattının sürekli tetiklenmesiyle CPU çekirdeklerinin kesme işleme döngüsüne hapsolmasıdır. Normalde kesmeler, ağ kartları, depolama cihazları veya USB gibi donanımlardan gelir ve kısa sürede işlenir. Ancak storm durumunda, saniyede binlerce kesme oluşur; bu da CPU’nun kullanıcı süreçlerini ihmal etmesine yol açar. Örneğin, hatalı bir ağ sürücüsü veya yüksek bant genişlikli bir NIC (Network Interface Card), paket flood’unda interrupt patlaması yaratabilir.
Nedenler arasında sürücü hataları, donanım uyumsuzlukları ve yanlış yapılandırmalar yer alır. Eski kernel sürücüleri veya firmware’ler, modern donanımlarla uyumsuzluk göstererek storm tetikleyebilir. Ayrıca, irqbalance servisinin devre dışı olması veya NUMA sistemlerde IRQ affinity’nin optimize edilmemesi, yükü dengesiz dağıtır. Pratik bir örnek: Bir sunucuda eth0 arayüzünden gelen IRQ’lar %100 CPU kullanımına neden olursa, bu klasik bir storm belirtisidir. Bu aşamada, sorunun kaynağını belirlemek için sistem loglarını ve metrikleri incelemek şarttır.
Linux’ta IRQ’lar /proc/interrupts dosyasında listelenir. Her satır, IRQ numarası, cihaz adı ve CPU başına kesme sayısını gösterir. Storm’da belirli bir IRQ’nın sayacı hızla artar. Örneğin, cat /proc/interrupts | grep eth0 komutuyla ağ kartı IRQ’sunu izleyebilirsiniz. Bu yapı, shared IRQ’larda (aynı hattı kullanan birden fazla cihaz) sorunları karmaşıklaştırır; çünkü bir cihazın aşırı kesmesi diğerlerini etkiler. Anlama için, modern sistemlerde MSI/MSI-X gibi kesme mekanizmaları tercih edilir, ancak legacy PCI cihazlarında edge/level-triggered interrupt’lar storm riskini artırır. Bu bilgiyi kullanarak, donanım envanterinizi gözden geçirerek potansiyel riskleri önleyebilirsiniz.
Ağ adaptörleri (örneğin Intel igb veya Broadcom bnxt), depolama RAID controller’ları (LSI MegaRAID) ve GPU’lar en sık storm kaynağıdır. Yüksek PPS (packets per second) trafiğinde, sürücülerin poll mode’u etkinleştirmemesi kesme sayısını patlatır. Firmware güncellemeleri ihmal edildiğinde, donanım hataları kronikleşir. Çözüm odaklı yaklaşım: lspci -vv ile cihaz detaylarını listeleyin ve vendor dokümanlarını kontrol edin. Bu tetikleyicileri bilmek, proaktif bakım rutininizi güçlendirir ve downtime’ı minimize eder.
Storm tespiti, gerçek zamanlı izleme araçlarıyla başlar. top komutunda %wa (I/O wait) ve %si (softirq) değerleri yüksekse şüphelenin; ancak kesin tanı için mpstat ve sar gibi sarf araçları idealdir. mpstat -P ALL 1 ile CPU başına IRQ istatistiklerini saniyelik izleyin. Storm’da bir CPU’nun %irq oranı %50’yi aşar. Ayrıca, perf top -e irq:* ile kesme olaylarını profilleyin. Bu araçlar, sorunun hangi kernel modülünden kaynaklandığını netleştirir.
watch -n1 'cat /proc/interrupts | sort -nrk1 | head -10': En aktif IRQ’ları dinamik takip edin.Bu komutlar, sorunu saniyeler içinde teşhis etmenizi sağlar. Loglarda dmesg | grep -i irq ile kernel uyarılarını arayın; “too many interrupts” gibi mesajlar confirmatorydir. NUMA sistemlerde numastat ile bellek/CPU dengesizliğini de kontrol edin.
Otomatik tespit için cron job’lar kurun. Basit bir bash script: #!/bin/bash; watch=$(cat /proc/interrupts | awk '{print $2}' | sort -nr | head -1); if [ $watch -gt 100000 ]; then mail -s "IRQ Storm Alert" [email protected]; fi. Bu script’i dakikada çalıştırarak threshold tabanlı uyarılar alın. Prometheus + Node Exporter ile Grafana dashboard’unda IRQ grafikleri oluşturun; threshold alert’leri entegre edin. Bu yaklaşım, 7/24 izlemeyi sağlar ve manuel müdahaleyi azaltır. Script’i /etc/cron.d altına yerleştirerek kalıcı hale getirin.
perf record -e ‘irq:*’ -a -g sleep 10 ile 10 saniyelik trace alın, ardından perf report ile analiz edin. Flame graph’lar oluşturmak için perf script | stackcollapse-perf.pl | flamegraph.pl kullanın. Bu, stack trace’lerden suçlu fonksiyonu (örneğin net_rx_action) gösterir. bpftrace ile bpftrace -e 'tracepoint:irq:irq_handler_entry { @[args->irq] = count(); }' yazarak IRQ frekansını izleyin. Bu ileri seviye araçlar, root cause’u pinpoint eder ve debugging’i hızlandırır. Pratikte, bu trace’leri logrotate ile yöneterek depolama yükünü dengeleyin.
Storm doğrulandıktan sonra, IRQ affinity’sini ayarlayın: echo 1 > /proc/irq/XX/smp_affinity ile IRQ’yı belirli CPU’lara bağlayın (hex maske kullanın, örneğin 0x3 ilk iki CPU). irqbalance servisini etkinleştirin: systemctl enable –now irqbalance. Sürücü parametreleri için modprobe.conf’a ekleyin, örneğin options ixgbe InterruptThrottleRate=100. Bu adımlar yükü dağıtır ve storm’u bastırır.
Yüksek trafik için NAPI poll mode’u zorlayın veya RSS (Receive Side Scaling) ile çoklu queue etkinleştirin. Kernel parametresi isolcpus=2-7 ile CPU’ları izole edin, real-time süreçler için. Test için stress-ng –irq 4 ile yapay storm simüle edin ve çözümleri doğrulayın.
/proc/irq/ dizininde smp_affinity_mask dosyalarını inceleyin. NUMA için numactl –hardware ile topolojiyi anlayın, ardından taskset ile süreçleri affinity’ye eşleştirin. irqbalance.conf’ta POWER_SAVING=no ayarlayarak agresif balance sağlayın. Örnek: Bir 8-core sunucuda IRQ 42’yi CPU 0-3’e (0xF) bağlayın: echo F > /proc/irq/42/smp_affinity. Bu, %30-50 performans kazancı verir. Kalıcı için udev rules yazın: SUBSYSTEM==”irq”, ACTION==”add”, RUN+=”/bin/sh -c ‘echo F > /proc/irq/%k/smp_affinity'”. Sürekli izleyerek ayarları tweak’leyin.
lsmod | grep driver ile modülü bulun, modinfo ile versiyonu kontrol edin. DKMS ile güncel sürücü yükleyin veya kernel’i LTS’ye upgrade edin (örneğin 5.15+). ethtool -i eth0 ile firmware versiyonunu doğrulayın. Güncelleme sonrası reboot ve stres testi yapın. Bu, %90 vakada storm’u çözer. Backup alın, live patch için kpatch kullanın. Uzun vadede, donanım uyumluluğunu vendor matrix’inden teyit edin.
Sonuç olarak, Linux sunucularda CPU Interrupt Storm analizi, proaktif izleme ve targeted optimizasyonlarla yönetilebilir bir sorundur. Yukarıdaki adımları uygulayarak, sistem kararlılığını artırabilir ve kaynak israfını önleyebilirsiniz. Düzenli audit’ler ve otomasyon script’leri ile bu tür olayları minimize edin; böylece kurumsal ortamlarınızda kesintisiz hizmet sağlayın. Pratik deneyimle, erken müdahale downtime maliyetlerini önemli ölçüde düşürür.