我有一台运行 Debian GNU/Linux 5.0.8 (lenny) 的机器，8 核，12GB RAM。我们有一个核心永久等待大约 40% 到 60%，试图找出发生了什么，我意识到我们的中断比 CPU 上下文切换更多。我发现上下文切换和中断之间的正常比率大约是上下文切换比中断多 10 倍，但在我的服务器上，值完全不同。
backend1:~# vmstat -s
12330788 K total memory
12221676 K used memory
3668624 K active memory
6121724 K inactive memory
109112 K free memory
3929400 K buffer memory
4095536 K swap cache
4194296 K total swap
7988 K used swap
4186308 K free swap
44547459 non-nice user cpu ticks
702408 nice user cpu ticks
13346333 system cpu ticks
1607583668 idle cpu ticks
374043393 IO-wait cpu ticks
4144149 IRQ cpu ticks
3994255 softirq cpu ticks
0 stolen cpu ticks
4445557114 pages paged in
2910596714 pages paged out
128642 pages swapped in
267400 pages swapped out
3519307319 interrupts
2464686911 CPU context switches
1306744317 boot time
11555115 forks
如果这是个问题，您有什么想法吗？在这种情况下，我该如何找出原因并解决它？
更新
按照评论的说明并重点关注卡在等待中的核心，我检查了附加到该核心的进程，您可以在下面找到列表：
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND
24 root RT -5 0 0 0 S 0 0.0 0:03.42 7 migration/7
25 root 15 -5 0 0 0 S 0 0.0 0:04.78 7 ksoftirqd/7
26 root RT -5 0 0 0 S 0 0.0 0:00.00 7 watchdog/7
34 root 15 -5 0 0 0 S 0 0.0 1:18.90 7 events/7
83 root 15 -5 0 0 0 S 0 0.0 1:10.68 7 kblockd/7
291 root 15 -5 0 0 0 S 0 0.0 0:00.00 7 aio/7
569 root 15 -5 0 0 0 S 0 0.0 0:00.00 7 ata/7
1545 root 15 -5 0 0 0 S 0 0.0 0:00.00 7 ksnapd
1644 root 15 -5 0 0 0 S 0 0.0 0:36.73 7 kjournald
1725 root 16 -4 16940 1152 488 S 0 0.0 0:00.00 7 udevd
2342 root 20 0 8828 1140 956 S 0 0.0 0:00.00 7 sh
2375 root 20 0 8848 1220 1016 S 0 0.0 0:00.00 7 locate
2421 root 30 10 8896 1268 1016 S 0 0.0 0:00.00 7 updatedb.findut
2430 root 30 10 58272 49m 616 S 0 0.4 0:17.44 7 sort
2431 root 30 10 3792 448 360 S 0 0.0 0:00.00 7 frcode
2682 root 15 -5 0 0 0 S 0 0.0 3:25.98 7 kjournald
2683 root 15 -5 0 0 0 S 0 0.0 0:00.64 7 kjournald
2687 root 15 -5 0 0 0 S 0 0.0 1:31.30 7 kjournald
3261 root 15 -5 0 0 0 S 0 0.0 2:30.56 7 kondemand/7
3364 root 20 0 3796 596 476 S 0 0.0 0:00.00 7 acpid
3575 root 20 0 8828 1140 956 S 0 0.0 0:00.00 7 sh
3597 root 20 0 8848 1216 1016 S 0 0.0 0:00.00 7 locate
3603 root 30 10 8896 1268 1016 S 0 0.0 0:00.00 7 updatedb.findut
3612 root 30 10 58272 49m 616 S 0 0.4 0:27.04 7 sort
3655 root 20 0 11056 2852 516 S 0 0.0 5:36.46 7 redis-server
3706 root 20 0 19832 1056 816 S 0 0.0 0:01.64 7 cron
3746 root 20 0 3796 580 484 S 0 0.0 0:00.00 7 getty
3748 root 20 0 3796 580 484 S 0 0.0 0:00.00 7 getty
7674 root 20 0 28376 1000 736 S 0 0.0 0:00.00 7 cron
7675 root 20 0 8828 1140 956 S 0 0.0 0:00.00 7 sh
7708 root 30 10 58272 49m 616 S 0 0.4 0:03.36 7 sort
22049 root 20 0 8828 1136 956 S 0 0.0 0:00.00 7 sh
22095 root 20 0 8848 1220 1016 S 0 0.0 0:00.00 7 locate
22099 root 30 10 8896 1264 1016 S 0 0.0 0:00.00 7 updatedb.findut
22108 root 30 10 58272 49m 616 S 0 0.4 0:44.55 7 sort
22109 root 30 10 3792 452 360 S 0 0.0 0:00.00 7 frcode
26927 root 20 0 8828 1140 956 S 0 0.0 0:00.00 7 sh
26947 root 20 0 8848 1216 1016 S 0 0.0 0:00.00 7 locate
26951 root 30 10 8896 1268 1016 S 0 0.0 0:00.00 7 updatedb.findut
26960 root 30 10 58272 49m 616 S 0 0.4 0:10.24 7 sort
26961 root 30 10 3792 452 360 S 0 0.0 0:00.00 7 frcode
27952 root 20 0 65948 3028 2400 S 0 0.0 0:00.00 7 sshd
30731 root 20 0 0 0 0 S 0 0.0 0:01.34 7 pdflush
31204 root 20 0 0 0 0 S 0 0.0 0:00.24 7 pdflush
21857 deploy 20 0 1227m 2240 868 S 0 0.0 2:44.22 7 nginx
21858 deploy 20 0 1228m 2784 868 S 0 0.0 2:42.45 7 nginx
21862 deploy 20 0 1228m 2732 868 S 0 0.0 2:43.90 7 nginx
21869 deploy 20 0 1228m 2840 868 S 0 0.0 2:44.14 7 nginx
27994 deploy 20 0 19372 2216 1380 S 0 0.0 0:00.00 7 bash
28493 deploy 20 0 331m 32m 16m S 4 0.3 0:00.40 7 apache2
21856 deploy 20 0 1228m 2844 868 S 0 0.0 2:43.64 7 nginx
3622 nobody 30 10 21156 10m 916 D 0 0.1 4:42.31 7 find
7716 nobody 30 10 12268 1280 888 D 0 0.0 0:43.50 7 find
22116 nobody 30 10 12612 1696 916 D 0 0.0 6:32.26 7 find
26968 nobody 30 10 12268 1284 888 D 0 0.0 1:56.92 7 find
更新
根据建议，我查看了 /proc/interrupts 以及以下信息：
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
0: 35 0 0 1469085485 0 0 0 0 IO-APIC-edge timer
1: 0 0 0 8 0 0 0 0 IO-APIC-edge i8042
8: 0 0 0 1 0 0 0 0 IO-APIC-edge rtc0
9: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi acpi
12: 0 0 0 105 0 0 0 0 IO-APIC-edge i8042
16: 0 0 0 0 0 0 0 580212114 IO-APIC-fasteoi 3w-9xxx, uhci_hcd:usb1
18: 0 0 142 0 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb6, ehci_hcd:usb7
19: 9 0 0 0 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb3, uhci_hcd:usb5
21: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb2
23: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb4, ehci_hcd:usb8
1273: 0 0 1600400502 0 0 0 0 0 PCI-MSI-edge eth0
1274: 0 0 0 0 0 0 0 0 PCI-MSI-edge ahci
NMI: 0 0 0 0 0 0 0 0 Non-maskable interrupts
LOC: 214252181 69439018 317298553 21943690 72562482 56448835 137923978 407514738 Local timer interrupts
RES: 27516446 16935944 26430972 44957009 24935543 19881887 57746906 24298747 Rescheduling interrupts
CAL: 10655 10705 10685 10567 10689 10669 10667 396 function call interrupts
TLB: 529548 462587 801138 596193 922202 747313 2027966 946594 TLB shootdowns
TRM: 0 0 0 0 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 0 0 0 0 Threshold APIC interrupts
SPU: 0 0 0 0 0 0 0 0 Spurious interrupts
ERR: 0
所有核心的所有值似乎都或多或少相同，但这个值IO-APIC-fasteoi 3w-9xxx, uhci_hcd:usb1仅影响核心 7（等待时间为 40%~60%），可能是连接到 USB 端口的某些东西导致了此问题？
先谢谢了
答案1
我从未听说过“上下文切换与中断的正常比率”。正如其他人所说，这不一定是个问题。但是，如果中断发生得太频繁，则可能会导致性能问题。这取决于中断的类型，因为有些中断应该发生得非常频繁，但对于磁盘控制器或网络适配器等中断处理程序较慢的设备，高中断率可能会导致严重的性能问题。
重要的是要弄清楚发生了哪些中断，以及是否可以用其他方式处理它们，例如对导致问题的设备进行轮询、使用更好的驱动程序或用更好的设备替换该设备。我相信在 Linux 中，/proc/interrupts 将引导您解决问题。
答案2
上面top说的是什么？是软件中断还是硬件中断？
要获取有关中断的更多信息，请查看/proc/interrupts- 这可能会让您了解核心消耗和中断。
通过运行，您可以看到哪些中断最为严重watch -d -n 1 cat /proc/interrupts。
您可能需要检查您的进程亲和性，或者安装类似 irqbalance 的东西。
答案3
我想说这是正常行为，您是否注意到任何特定的性能问题？
我刚刚在这里检查了一个 Ubuntu 框，得到了以下内容，
1406721073 interrupts
942882359 CPU context switches
干杯，鲍勃