You see a high load average on a multicore box, but top shows one core pinned at 100 percent system time while the others are idle. You check iostat, you check vmstat, and everything looks clean. It turns out your high-traffic network interface is blasting every single interrupt to the same CPU core, creating a bottleneck that has nothing to do with your application logic.

Why the kernel gets lazy with IRQ routing

By default, many systems just dump all hardware interrupts onto core zero. If you have a 10Gbps NIC pushing massive traffic, that core spends its entire life handling softirqs, leaving zero headroom for your actual user-space threads. Moving the affinity around is not just for supercomputers; it is basic hygiene for any production server hitting significant network throughput.

grep eth0 /proc/interrupts | awk '{print $1}' | tr -d : | xargs -I {} sh -c 'echo 0f > /proc/irq/{}/smp_affinity'

• Check /proc/interrupts to see which core is actually taking the brunt of the traffic
• Verify your NIC driver supports multiqueue before you waste an hour tuning affinity
• Watch for IRQ balance daemons that might silently fight your manual overrides
• Use taskset only if you are debugging, otherwise stick to smp_affinity for persistent hardware interrupts

If you notice latency spikes during heavy traffic, look at the softirq column in mpstat. Spreading these interrupts across multiple cores won’t make your packet processing faster, but it will stop one core from becoming the king of bottlenecks, which is usually exactly what you need to smooth out those mysterious micro-stutters.